Top 10 Things That Annoy Programmers

Programmers all have their personal pet peeves. Whether it's scope creep, Hungarian notation, or smelly coworkers, there are certain nuisances that we must put up with in our line of work. The following is a list of the top 10 things that annoy programmers, compiled from the results of my recent question on StackOverflow along with some of my own experiences as a programmer:

10. Comments that explain the "how" but not the "why"

Introductory-level programming courses teach students to comment early and comment often. The idea is that it's better to have too many comments than to have too few. Unfortunately, many programmers incorrectly interpret this to mean that they must comment every single line of code, which is why we often see code like this (from Jeff Atwood's post on Coding Without Comments):

r = n / 2; // Set r to n divided by 2

// Loop while r - (n/r) is greater than t

while ( abs( r - (n/r) ) > t ) {

r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)

}

Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it's doing it. If there were a bug in the program and you stumbled across this code, you wouldn't know where to begin. Now, consider the same code with a different set of comments:

// square root of n with Newton-Raphson approximation

r = n / 2;

while ( abs( r - (n/r) ) > t ) {

r = 0.5 * ( r + (n/r) );

}

Much better. We still might not know exactly what's going on here, but at least we have a starting point.

Comments are supposed to help programmers understand the code, not the syntax. It's usually a fair assumption that the people reading your code are going to have a basic understanding of how a for loop works, so there's no need to add comments like "// iterates over a list of customers". What the people reading your code are not going to be familiar with is the business logic and reasoning behind it.

9. Interruptions

Very few programmers are able to go from 0 to code at the drop of a hat. We tend to be more akin to locomotives than ferraris; it may take us awhile to get started, but once we hit our stride we can get an impressive amount of work done. Unfortunately, it's very hard to get into a programming zone when you are constantly being bothered by clients, management, and fellow programmers.

There is too much information we need to keep in our heads while programming to be able to stop working on a task, handle another issue, then pick up the task without missing a beat. Interruptions kill our train of thought and getting it back on track is a time-consuming, frustrating, and worst of all, error-prone process.

8. Scope creep

From Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

Scope creep turns relatively simple requests into horribly complex and time consuming monsters. It only takes a few innocent keystrokes by the requirements guy for scope creep to happen:

Version 1: Show a map of the location

Version 2: Show a 3D map of the location

Version 3: Show a 3D map of the location that the user can fly through

Argh! What used to be a 30 minute task just turned into a massively complex system that could take hundreds of man hours. Even worse, most of the time scope creep happens during development, which requires rewriting, refactoring, and sometimes throwing out code that was developed just days prior.

7. Management that doesn't understand programming

Ok, so maybe there are some perks.

Management is not an easy job. People are fickle and fragile. Keeping a large group of people content and cohesive is a mountain of a task. However, managers really should have some basic understanding of what their subordinates are doing, especially in the tech industry. Otherwise you end up with scope creep, unrealistic deadlines, and frustration on both sides of the table. This is a pretty common complaint amongst programmers and the source of a lot of angst (and one hilarious cartoon strip).

6. Documenting our applications

There are a lot of documentation-generating applications out there, but in my experience those are only good for generating API documentation for other programmers to read. By and large, if you are working with an application that normal everyday people are using, you're going to have to write some documentation that the average layman can understand (e.g. how your application works, troubleshooting guides, etc.).

It's not hard to see that documentation is something programmers dread doing. Just take a quick look at all the open-source projects out there today. What's the one thing that all of them are constantly asking for help with? You got it. Documentation. I think I can safely speak on behalf of all programmers everywhere when I say, "can't someone else do it?".

5. Applications without documentation

I never said that we weren't hypocrits. :-) Programmers are constantly asked to incorporate 3rd party libraries and applications into their work. In order to do that we usually require some documentation. Unfortunately, as I mentioned in item 6, programmers hate writing documentation. And no, the irony is not lost on us.

There's nothing more frustrating than trying to utilize a 3rd party library while having absolutely no fricken idea what half the functions in the API do (and no way to find out). What's the difference between poorlyNamedFunctionA() and poorlyButSimilarlyNamedFunctionB()? Do I need to perform a null check before accessing PropertyX? I guess I'll just have to find out through trial and error! Ugh.

4. Hardware

Any programmer who has ever been called upon to debug strange crashes on a database server knows that hardware problems are terrible. Unfortunately, many people make the assumption that because we work with computers that we know how to fix them. While this may be true for some programmers, the vast majority of us don't know, or care, about what's going on after the code gets translated into assembly. We just want it to work so that we can focus on higher level tasks.

3. Vagueness

"The website is broken". "Feature X isn't working properly". Vague requests are a pain to deal with. It's always surprising to me how exasperated non-programmers tend to get when they are asked to reproduce a problem for a programmer. "It's broken, fix it!" is not enough information for us to work off of.

Software is (for the most part) deterministic. We like it that way. Humor us by letting us figure out which step of the process is broken instead of asking us to simply "fix it".

2. Other programmers

Programmers don't always get along with other programmers. Shocking, but true. This could easily be its own top 10 list, so I'm just going to list some of the common traits programmers have that annoy their fellow programmers and save going into detail for a separate post:

Being grumpy to the point of being hostile.

Failing to understand that there is a time to debate system architecture and a time to get things done.

Inability to communicate effectively and confusing terminology.

Failure to pull ones own weight.

Being apathetic towards the code base and project

And last, but not least, the number 1 thing that annoys programmers...

1. Their own code, 6 months later

Don't sneeze, I think I see a bug.

Ever look back at some of your old code and grimace in pain? How stupid you were! How could you, who know so much now, have written this? Burn it! Burn it with fire!

Well, good news. You're not alone.

The truth is, the programming world is one that is constantly changing. What we regard as a best practice today can be obsolete tomorrow. We have to accept that we will never know it all and that perfect code is a pipe dream. It's tough to cope with the fact that your work, as beautiful as it may seem now, is probably going to be ridiculed later. And it's frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, our goal always seems slightly out of reach. For me, this is the most annoying thing about being a programmer; the fragility of what we do is necessary to facilitate improvement, but I can't help feeling like one of those sand-painting monks.

Well, there you have it. The top 10 things that annoy programmers. Again, if you feel that I missed anything please be sure to let me know in the comments!