I despise this sort of single-dimension haughty evaluation of programming "goodness": It is garbage, and is the dismissive grenades that a particular type of maintenance programmer tosses to feel better about themselves as they try to feed the family with sloppy seconds.
I single out maintenance programmers because there is a stark difference between creating something out of nothing, and being the guy who looks at that something and -- with all that is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident -- can say "Oh clearly you should have A->E->Z: What a dummy!".
All novel works can be improved in countless ways, iteratively. This is a given of software development, and the fear of having to go through this inevitable process has stopped most projects before they've ever begun.
"His failures have tangible reprecussions that have long plagued the Minecraft hacking community and Mojang itself."
There is so much irony in this statement. Do you even realize?
Agreed. A programmer maintaining a new project is going to feel frustrated when the application cannot be easily extended in a way that they expect, but the original author should be forgiven for not predicting every possible future permutation of their existing code base. The best design decision might seem obvious from the maintainer's perspective, but given 100 different maintainers, you'll end up with 200 different solutions, half of which will make the original application seem ridiculous when framed in the context of a massive rewrite that takes into account every business decision that time and experience has yielded since the start of the project.
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.
Though there are some good points here, my experience has been that this "just get it done" above all else principle has sunk just as many projects as it has launched.
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.
I didn't say above all else, but I take your point. Of course, this is a balancing act, and I suspect we're both facing some selection bias, but I have to disagree that creating maintainable code is necessary for being described as a good programmer. At the end of the day, all programs are maintainable, as long as the source can be read and understood by a programmer. There is a huge advantage to having a well designed application structure, but there is no replacement for an application that meets its functional specification.
I would replace your "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." with, "Getting it done is a bare necessity of a good programmer, but what separates the great programmer from a transcendent programmer is whether they get it done in a more maintainable fashion."
Well if we're singling out maintenance programmers, lets also talk about programmers who use "maintenance" as a dirty word. They tend to be the type to vomit out whatever immediately comes to their head and ship when it just barely works, with no thought or consideration for maintainability. Because, hey, they're going to move on to their next project anyway, and "getting things done" in the short term is far more important than little details making sure your project, and your business by extension, is sustainable in the long term. Thats someone else's' problem.
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
There is a middle area here, where one doesn't worry about perfect code, but still takes a moment to consider design.
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.
Note that the bad programmer bit was a quote of the post I replied to, which I then thoroughly disagreed with. It was not a statement of fact on my part.
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.
Who skips step 2 without spending a lot more time on a non trivial project? How did you measure this skipped time in real world cases? And what makes it justifiable or not? Where do you get that information that this person(s) does?
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.
Agreed, I don't have much to add, I've been on both sides of the fence. Your comments hit it exactly, conjuring something from nothing takes amazing talent. Taking that and making it better is arduous but there is a path there, it's not easy I know, but the path is there.
Business people would think Notch is a good programmer, but what do they know. I'm commenting because I want a link back to this discussion. I wish HN made it easier to find old good stories that I didn't comment on, but I'm not bent out of shape about it. Anyway, programming is strange because you've got the output and the instructions for producing it, and sometimes one can be good while the other is not as good. Anyway blah blah mod me down. I find it unlikely that Notch is purely a bad programmer.
I despise this sort of single-dimension haughty evaluation of programming "goodness": It is garbage, and is the dismissive grenades that a particular type of maintenance programmer tosses to feel better about themselves as they try to feed the family with sloppy seconds.
I single out maintenance programmers because there is a stark difference between creating something out of nothing, and being the guy who looks at that something and -- with all that is laid in stone in front of you, all of those unknown lands revealed and detours and dead-ends made evident -- can say "Oh clearly you should have A->E->Z: What a dummy!".
All novel works can be improved in countless ways, iteratively. This is a given of software development, and the fear of having to go through this inevitable process has stopped most projects before they've ever begun.
"His failures have tangible reprecussions that have long plagued the Minecraft hacking community and Mojang itself."
There is so much irony in this statement. Do you even realize?