Further, there are times when a good programmer must deliberately exclude forward thinking solutions because a non-functioning product precludes a successful business. Yes, it should still be a secure solution. Yes, a TODO label may be warranted, but a surefire way to get yourself labeled as a bad programmer is to spend weeks working out "future proof" solutions while the competition is shipping an application that can be successfully executed.

Getting it done is a bare necessity of a good programmer, but what separates the mediocre programmer from a good programmer is whether they get it done in a more maintainable fashion.

It is completely ridiculous to say as long as one can get a product launched, they are a good programmer, because you're likely praising a group, half of whom are good programmers, and half of whom are sinking the product more and more over time. This is a common happening I see with praise of engineers from a management perspective, and why so often companies sink without knowing where exactly they went wrong.

You can judge if a programmer is good, not by tearing apart and poking at the mistakes they made in a new project, but if they proceeded to code using strong abstractions and decoupled code. The easiest programmers to fire are the ones who don't ship, and the programmers that tend to be the costliest to a business are the ones who ship crap code.

Obviously no-one can see the future. The problem isn't when code can't be easily extended, the problem is when code is easily broken.

I'm not sure if there is much of a distinction there. I can extend your code with very little effort if I'm permitted to break it in the process.

There is a middle area here, where one doesn't worry about perfect code, but still takes a moment to consider design. However, you don't hear that often on HN, because it loves a good "Such coding, so productive!" circle-jerk. The reality is that a lot of "get it done fast" programmers could use a maintenance project or two, and develop the habit of actually thinking about what they write.

But no, lets hate on maintenance programmers and people who want some thoughtfulness in their development. They're just not agile enough. eye roll

Who said otherwise? The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted. Yet he did build a large product from nothing, that has provided millions of hours of enjoyment to users. A product that built a community and a company. To see him disparaged like that is just so laughably typical.

Everyone is the world's greatest programmer in their own imagination.

And yes, there is a type of maintenance programmer that I will absolutely disparage. It is the perpetually over-their-heads developer who is always surrounded by purportedly terrible code because it doesn't have a "insert your specific need here" structure.

Apparently a lot of HN posters. Looking at the siblings, you see the exact circle-jerk I criticized: "Only launching matters. Builders are so much smarter and more talented than maintainers. Code quality is a secondary concern that can be addressed later." And lets be honest, your comment itself did not really hint at any sort of balance -- it was highly insulting to anyone not writing code from scratch. "... tosses to feel better about themselves as they try to feed the family with sloppy seconds." Really? REALLY? That's horribly dismissive to anyone who has to work in an existing code base. Its shamefully dismissive.

> The person who kicked this off declared Notch a terrible programmer because he didn't build a runway in version 0.1 for people years in the future to do exactly what they wanted.

Said poster did not make the claim solely on the lack of mod-ability, but also on things like poor use of OpenGL APIs and extreme duplication of code. Some point between version 0.1 and release, one should take a step back, refactor, and clean up with an eye for maintainability.

Also, the fact that something is version 0.1 is not really an excuse for things like writing code that duplicates functionality. Its entirely possible to write an initial version that has passable code quality -- I've done it many times (and had coworkers comment on how easy it was to maintain). You just have to keep in mind that if you're writing throwaway code, it must be thrown away, and if that's not acceptable that you need to spend a little extra time on a maintaining a minimum level of quality.

> And yes, there is a type of maintenance programmer that I will absolutely disparage. It is the perpetually over-their-heads developer who is always surrounded by purportedly terrible code because it doesn't have a "insert your specific need here" structure.

Said programmers are often interested in improving the quality of the code-base. Your disparagement is misplaced. They are the people that take an unmaintainable mess and mold it into a reliable system. But of course, since the work" is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident" that's work that anybody can do. And that statement is not horribly dismissing and insulting at all. Right.

I've had more sleepless nights due to "special snowflake" developers than the maintenance programmers you disparage.

If his goal is to create code that other programs will love to read, then maybe he is terrible.

If his goal is to create software that millions of people will enjoy, then he is amazing.

My guess is that he would describe his goal as the latter. Maybe his goal is different from yours.

Nothing -> something that works (in any way possible, spaghetti code, written quickly) -> something that works (clean refactored code that can be maintained/improved/changed).

You can't skip step 2. If you do, you will likely spend more time overall.

Basically; almost all IT projects are delivered too late and for too much money (including games) (and usually they are still crap code); spending any more time on skipping 2 is clearly not justifiable.

I don't think anyone in a real life scenario can actually get this done; I know plenty of (open source) projects where step 2 is skipped, but not in time realistic for any commercial project. Note that I don't think step 2 is a bad thing to do; prototyping something and rewriting/refactoring is not a bad thing as long as you don't ship it as the actual product.