

Top 10 things that annoy programmers  - nickb
http://www.kevinwilliampang.com/post/Top-10-Things-That-Annoy-Programmers.aspx

======
mynameishere
It's an interesting topic, but he missed some.

1\. Cargo cultists, especially when managers.

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.

~~~
bstadil
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.

~~~
mynameishere
Nah. 200 * .5 * 9 = 900, which was my rough estimate. The CEO was there, which
brought up the average.

------
apu
Top X lists...

~~~
sh1mmer
It is a shame it's a bit link baity but the article content itself is worth a
read.

~~~
apu
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.

------
watmough
Superstitions.

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.

Anything else would be 'too chatty'.

------
known
Irrational questions!

------
radley
11\. Users.

