I just recently started writing software >40 hours a week, and have been constantly torn between "getting things done" and "doing things right". The best way to program well might very well be a variation between the two modes.
Actually, it's a lot easier to make it work if you've made it right to begin with. (That said, I've always found the best way to develop is to add functionality to a working program, no matter how small it starts out).
1. Sometimes, making it work is enough. (one time code and such) There's no reason, other than for practice, to waste time designing such cases.
2. You may find out that you're solving the wrong problem, and it's much easier to justify throwing out code that you didn't labor over an extensible design, etc. It's much harder to throw away wrong code that you've put work into the internal design.
3. This doesn't mean that you don't design the outward facing interfaces correctly. Thus, you have a good set of unit tests already set up, and you can quickly tell if something is working as you refactor. You have a good baseline with which to compare.
I just recently started writing software >40 hours a week, and have been constantly torn between "getting things done" and "doing things right". The best way to program well might very well be a variation between the two modes.