The terrible 10: Programmers’ biggest frustrations

To non-software developers, a developer’s job must look pretty sweet: You’re in high demand, you get paid really well, companies give you all sorts of fun perks, etc. Truth be told, though, while all that is true, the job, like any other, has plenty of moments that make a programmer want to pull (what’s left) of his or her hair out. There are any number of things that can happen during the day in the life of your average software engineer that can be beyond frustrating.

Based on comments and votes from actual programmers in online discussion forums, use the arrows above to see the 10 most frustrating things about being a software developer. If, after reading this, you still want to become one, don’t say you weren’t warned.

See also:

• Superclass: 15 of the world’s best living programmers

The forehead smacker: Unless you’ve got a treadmill desk, software development isn’t exactly an aerobic activity. Most programmers spend long hours sitting on the rear ends, hunched over their keyboards, staring intently at their computer monitor(s). All that sitting can be pretty uncomfortable after a while. It can also get pretty depressing if you don’t at least change where you do all that sitting once in awhile.

Quote: “Sitting on a chair the whole day and staring into the screen. Some time ago it started.. the back first, the neck next, the eyes burn and are tired, the head hurts, legs starting to get restless…. As much as I tried to counteract with fitness, taijiquan, yoga, qigong, taking bike to work — I can’t do it for 8+ hours a day anymore. Being stuck in the office the whole day, seeing the sun come up and go down, still sitting on that stupid chair while life passes by.” Markus Toman

The forehead smacker: Even the best, most carefully crafted code is going to have bugs. Naturally, then, developers have to regularly devote time to tracking down and fixing software defects, whether in their own code or in someone else’s. While some bugs can be quickly found and squashed, others can be maddeningly elusive and can lead to many lost hours of good development time, not to mention a bit of a coder’s sanity.

Quotes: “Discovering a defect that is hard to reproduce and in the worst-case scenario manifested by an integration test that randomly passes and fails for the same piece of code!!! Afterward having the feeling you may never find those mysterious evil bugs lurking somewhere in code. Yikes!” Emmanuel Ngwane

“We write such big programmes (even small sometimes) that while debugging, we go so deep that we forget what the bug originally was.” Ayush Bhatnagar

“Debugging, especially when you are working on big projects that involve thousand lines of code. Most geeks like me tend to use a projector to debug because that makes our eyes more comfortable.” Isaac Perez

“Heisenbugs.” Awal Garg

The forehead smacker: Working with other developers’ code can be frustrating, but it’s a lot less annoying if said code is at least documented well. Unfortunately, that isn’t always the case. It simply takes a lot longer to debug, enhance, or integrate with software that is poorly commented or otherwise lacks a well written explanation of how it works. Plus, it’s bad for a programmer’s blood pressure.

Quotes: “The most frustrating thing is being hired to work for a poorly documented software. It makes things hard for those who take over the project. Lack of comments and poorly written semantics especially when the previous programmer leaves a bunch of bugs and errors.“ Angel Angeles III

“Understanding undocumented and uncommented code written by some idiot.” Abhishek Chauhan

“I, like most programmers, spend more time maintaining poorly documented code than writing new code.” Walt Karas

The forehead smacker: Source code control systems, such as Git or Subversion, are great tools that allow multiple developers to work simultaneously on the same code base without stepping on each others’ toes. However, eventually, code changes have to be committed to the repository, at which point conflicts can occur if, say, two developers have changed the same file or routine. In that case those changes have to be merged together. Sometimes those merge conflicts can be resolved simply, other times, not so much.

Quotes: “I also dislike merges because it’s like, you want to change the code this way, I want to change the code that way, so how should we change the code?  I’ve always been able to find a way to incorporate both our changes, but if there was a real conflict it would be an awkward process.” Jessica Su

“Merge Conflict *pure evil*” Koustuv Sinha

The forehead smacker: Every developer’s code, at some point, has to work in conjunction with code written by other developers. Whether it’s a different part of the same piece of software, third-party libraries or tools, or another application entirely, no one developer’s code is an island. Unfortunately, that means that one programmer can, through haste, poor communication, or simple carelessness, break another programmer’s code, which can be the cause of much tension, stress, and, often, cursing.

Quotes: “The worst frustration I ever had was co-writing a program with someone who would change the library we were both linking to without telling me it had changed. That meant my calls to routines were missing variables or had added variables, or worse, the code would crash in the library that I didn’t have access to.” Sheri Fresonke Harper

“When your part of the code stops working because someone else changed their part of the code. Often their functions take more arguments than they did before.  Sometimes they are eliminated entirely or placed in a different file.” Jessica Su

“Constantly having to go back and rework stuff that you wrote just a couple of days ago that has just been ‘broken’ (for the nth time) by changes to the wider system implemented (without discussion) by someone who either didn’t test or didn’t care that their tests failed — the first thing you hear about it being ‘your code is broken’.” Simon Hayes

The forehead smacker: Despite the increasing number of software developers out there, not to mention the increased reliance on software by just about everything we use, many non-technical people still don’t understand what software developers really do. To non-technical folks, developers are just “tech people,” and little consideration is given to the difference between, say, those who work on software and those work on the hardware. The constant misunderstandings and misplaced expectations, particularly by family and friends, can really drive a programmer batty,

Quotes: “There seems to be a common misconception among non-technical people that since programmers work with computers, we must know how to fix them; this is a bit like assuming Jenson Button knows how to disassemble and reassemble a racing gear box just because he also knows how to drive an F1 car.” Steve Borthwick

“Yes, I write code for a living; no, I can’t help you with your printing problem or that attachment you can’t open or that laptop that won’t boot up. Unless you want to buy me lunch or a beer, then maybe I can help.” Phil Johnson

“To explain people that I’m not the one who has a shop in every corner to install Pirated OS and other pirated software to their PC.” Anbalagan Jeyabalachandran,

“Family and friends think you can fix anything remotely related to computers. Be it hardware or software. They don’t care. [You] eventually ending up listening to their taunts. Something like: ‘what kind of software engineer are you if you can’t even fix my laptop’s DVD ROM’.” Jazib Babar

“1%-2% people know what you are really doing” Yasin Pekşen