Interesting, it seems like best practices are easy to teach (just follow these simple rules!), and the dysfunctional thing I’d expect would be for professors to tell you to follow them but not tell you why.
the dysfunctional thing I’d expect would be for professors to tell you to follow them but not tell you why.
That’s the failure mode that most of my profs fell into. When I was in school, there was a strong emphasis on correct style—in the extreme case, for example, some professors would fail an assignment if it didn’t have a high enough fraction of comments to functional code—but very little to suggest a coherent theory of software engineering.
From what I remember, most of my peers approached it with the attitude of being just another hoop to jump through.
One dysfunctional thing I’d expect would be the existence or perceived existence of a contrary movement, using the word “dogma” and saying things like “worse is better” and “if it’s stupid but it works, it isn’t stupid” and “those ivory-tower academics never have to deal with real-world problems” and “when theory and practice clash, theory loses”.
For example, this article makes a specific point about a specific situation (mixed in with some crazy), but might still leave one with an impression of “boo carefully planned programs, yay big hairy messes where you don’t know what half the API calls are for”.
Also, general hyperbolic discounting and programmers just not caring.
Maybe they do, now. When I was in CS, we had no classes on software engineering. But that was a long time ago, in CS terms. So you should not believe that I know what I’m talking about.
Interesting, it seems like best practices are easy to teach (just follow these simple rules!), and the dysfunctional thing I’d expect would be for professors to tell you to follow them but not tell you why.
Updated.
That’s the failure mode that most of my profs fell into. When I was in school, there was a strong emphasis on correct style—in the extreme case, for example, some professors would fail an assignment if it didn’t have a high enough fraction of comments to functional code—but very little to suggest a coherent theory of software engineering.
From what I remember, most of my peers approached it with the attitude of being just another hoop to jump through.
One dysfunctional thing I’d expect would be the existence or perceived existence of a contrary movement, using the word “dogma” and saying things like “worse is better” and “if it’s stupid but it works, it isn’t stupid” and “those ivory-tower academics never have to deal with real-world problems” and “when theory and practice clash, theory loses”.
For example, this article makes a specific point about a specific situation (mixed in with some crazy), but might still leave one with an impression of “boo carefully planned programs, yay big hairy messes where you don’t know what half the API calls are for”.
Also, general hyperbolic discounting and programmers just not caring.
Also, sort of implied by that: methodologies that don’t actually work.
Unexpectedly semi-relevant: the latest xkcd, Good Code.
Maybe they do, now. When I was in CS, we had no classes on software engineering. But that was a long time ago, in CS terms. So you should not believe that I know what I’m talking about.