10. Comments explaining “what”, but not “why”
Introductory-level programming courses teach students to comment early and often. And while this may be a useful practice during programming infancy (when even the simplest line of code can be incomprehensible), many programmers never bother to shake the habit.
Do you have any idea what the code above does?
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. Now consider the same code with a different set of comments.
Much better! Even if we still don’t fully understand what’s going on, at least we have some much needed contextual information to go off of.
Write comments to help readers understand the code, not the syntax. It’s fair to assume that anyone reading your code has a basic understanding of how a for loop works. What they may not be aware of is why your code works or why you chose to implement it the way you did.
In general, programmers 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 difficult to hit your stride (also referred to as “being in the zone”) when your train of thought is being constantly derailed by clients and colleagues.
8. Scope creep
Wikipedia defines scope creep as “uncontrolled changes in a project’s scope”. Scope creep can turn a relatively simple request into a horribly complex and time consuming task. All it takes is a few seemingly innocuous keystrokes for scope creep to destroy a project’s timeline:
- 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
7. Management that doesn’t understand programming
Ok, so maybe there are some perks.
Management is not an easy job. People suck; we’re fickle and fragile and we’re all out for #1. Keeping a large group of us content and cohesive is a mountain of a task. However, that doesn’t mean that managers should be able to get away without having some basic understanding of what their subordinates are doing. When management cannot grasp the basic concepts of our jobs, we end up with scope creep, unrealistic deadlines, and general frustration on both sides of the table. This is a pretty common complaint amongst programmers and the source of a lot of angst (as well as one hilarious cartoon).
6. Documenting our applications
Let me preface this by saying that yes, I know that there are a lot of documentation-generating applications out there, but in my experience those are usually only good for generating API documentation for other programmers to read. 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 this is something programmers dread doing. Take a quick look at all the open-source projects out there. What’s the one thing that all of them are constantly asking for help with? 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 hypocrites. Programmers are constantly asked to incorporate 3rd party libraries and applications into their work. In order to do that, we need documentation. Unfortunately, as mentioned in item 6, programmers hate writing documentation. No, the irony is not lost on us.
There is 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. 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.
Any programmer who has ever been called upon to debug a strange crash on the database server or why the RAID drives aren’t working properly knows that hardware problems are a pain. There seems to be a common misconception that since programmers work with computers, we must know how to fix them. Granted, this may be true for some programmers, but I reckon the vast majority of us don’t know or really care about what’s going on after the code gets translated into assembly. We just want the stuff to work like it’s supposed to so we can focus on higher level tasks.
“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. They don’t seem to understand that “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 that? 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. It’s simply not possible to write perfect code because the standards upon which our code is judged is evolving every day. It’s tough to cope with the fact that your work, as beautiful as it may be now, is probably going to be ridiculed later. It’s frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, there’s always the sense that what we’re truly after is 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 I’m one of those sand-painting monks.