20 years ago, colleges taught you to program slowly, with good architecture and with maintainability. When I was taking CS courses we were taught to flowchart

20 years ago, colleges taught you to program slowly, with good architecture and with maintainability. When I was taking CS courses we were taught to flowchart our programs, write them all out, and really create the software on paper before even touching a computer. I've observed that programmers from successive generations become more and more likely to just sit down and start writing before they've even had proper time to think. I think there's a spectrum, with one extreme example being the person who writes 1,000 lines in 2 hours of code that is buggy and unmaintainable but that the boss is really impressed because it does %70 of what is needed. These guys really impress PHBs. At the other end of the spectrum is the guy who gets the same assignment, does nothing but sit in his cubicle thinking for a week. And then over the course of a day writes 100-200 lines that does %90 of the assignment, and with no bugs. Current culture seems to favor the former guy-- which is why we have unit tests (to catch all his bugs) and the assumption that code is crap. There isn't much cultural support for the latter guy... but those guys, in my experience are the better programmers. For trivial programs speed is king, but trivial programs can be done by either guy with a difference of a few hours in time to completion. For programs of significance... the slower guy can save you months or years and even cut your required engineering headcount. But that guy doesn't seem to be recognized for what he does-- in fact, he's often perceived as not working as hard, and is many times interrupted for no good reason, but because they think he needs more work.