Actually, I did read the article before my comment, just in case I had magically come across a "Top X" article that was actually worth reading.
This one wasn't.
I think perhaps this list might make more sense for 'enterprise programmers', but not for exploratory, research, or many startup programmers. So the first strike is that it grossly generalizes programming behavior -- people program for different reasons in different organizations using different styles. If the author were trying to make some point about all of them, he failed.
And considering the audience here at Hacker News, the style he's describing is not even the most appropriate -- perhaps it fits on proggit where I'd guess there are more enterprise and/or beginning programmers, but not here with so many startuppers and research students. Obviously it's not his fault this article is posted here, but my point is that it's especially annoying to find such top X lists on Hacker News.
In case anyone's curious, here's a quick point-by-point rebuttal that explains my view of programming:
10. Small, functional (no-side-effects) functions with explanatory names are far superior to leaving comments that explain the how or the why. I would take that small chunk, make it a function called newtonRaphson() and be done with it.
9. Fair enough.
8. I'm a researcher and startupper so feature creep is the norm, not the exception -- I don't know what the next step will be until I do the current one and see whether it works (research) or gains traction (startup).
7. My research advisors/co-founders are the closest I have to managers, and they defer to my judgment about programming matters. That means that we plan schedules, etc., keeping a realistic view of how long things will take to program. We work with each other, not against each other as enterprise bosses frequently seem to do. (Also, the xkcd cartoon linked has almost no relevance to his point.)
6. I used to believe this, until I realized that writing documentation made my programs better. This is especially true when documenting UIs -- if it's too complicated to explain easily in the docs, it's too complicated to use.
5. Agreed.
4. Again, this is something I used to believe before, but am now finding useful to actually learn about the hardware to some degree. Not only does it let me fix (and sometimes prevent) problems, it's good to have an idea of what's going on in the actual system so you have a better idea of what to upgrade when the time comes. Scalability is a lot about hardware.
3. Agreed, although I bet he doesn't consider the converse: when programmers try to explain things to laymen using jargon. And in many senses, the 'user is always right.' In particular, nature can't be fooled (research), and if I'm doing something that lots of users are complaining about, it's my fault, not theirs (startup).
2. If this list is supposed to apply to all (or even some large subset) of programmers, and this claim is about all other programmers, then it follows that he himself is not pleasant to work with. Undoubtedly there are many people it is not fun to work with, but I've worked with many people over the years who have been fantastic partners. We had disagreements, people wrote shitty code and made mistakes, sure, but we still got on well enough to work together. And of course, I'm constantly evaluating myself, making sure I'm not the one being an ass, etc. (which perhaps the author's article doesn't consider).
1. I find programming to be an iterative process -- if I'm not adding more functionality step-by-step, I'm doing something wrong. Working code at every stage is so important for morale and momentum. I also find it impossible to plan for everything up front and I inevitable end up rewriting portions of code to better fit the features I need. I don't mind this at all, and in fact see it as a necessary step in writing good programs. So while sometimes I do wince at seeing some old code of mine, more frequently I find it a good starting point for adding some new feature or even working on some completely unrelated problem.
Finally, if the author is actually annoyed that (a) he's going to be ridiculed because (b) he can never reach perfection and (c) "it's simply not possible to write perfect code because the standards upon which our code is judged is evolving every day", he's a completely different species of programmer (and perhaps human) from me. The unreachable goal of perfection is one of the greatest thrills for me -- if I could truly become perfect at some task, I'd be rather disappointed. I'm also not going to be ridiculed because of bad code, in large part because I'm the harshest critic of my own code. And finally, while it may not be possible to write perfect code, it has nothing to do with the fact that the judgment standards are changing -- code is either good or not, and I always strive to make it better than it currently is.
Anyways, I've spent way too much time now rebutting this article.
The typical case involves statements like, "What design pattern are you using?" and "we need to document everywhere we use a design pattern" and the dreaded, "Your code doesn't have enough design patterns".
2. Bikesheds.
The bikeshed problem can lead to ridiculous and endless meetings devoted to the color of icons, or the background shading of icons, etc. I once sat through a meeting in which NINE people dicussed the color of an icon for 30 minutes. Rough labor cost: 1000 dollars [1]. Worse is the fact that bikeshedders think they are contributing, when they are actually wasting money.
3. Titles.
There is a non-trivial chance that your company's "Senior software architect" is a worse programmer than you were at age 18. Not necessarily a problem until he gets it into his head that skills are derived from titles.
[1] Math was wrong on the first run. I calculated the full-length meeting at 3000 dollars. BTW, the icon stayed blue. Light blue.
That's $667 / hour / person. I could put up with a lot of crap for that kind of enumeration, assume 25% overhead that is still $1M per year.
I think you missed a zero.
We've built a network caching tier, but network bandwidth is expensive so we'll actually cache all the data three times in the client GUI. This will increase the complexity of implementing and testing the GUI exponentially.
