10 problems that every programmer has to face in his life

A Programmer Developing Applications is a great job you get many advantages but there are downsides too

1. Hardware

The forehead smacker: Software, of course, can’t do much of anything without hardware on which it can run. As much as some software developers would like to ignore the hardware end of things, it’s inevitable that, sooner or later, they’ll be faced with hardware-specific issues when building or debugging a program. That’s why some programmers strongly recommend that new software engineers get familiar with the underlying hardware and systems that their code will run on, so as to reduce future aggravation.

Quotes: “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.“ Steve Borthwick

“Programmers hate hardware: because they cant always blame it on the hardware!” Anonymous.

2. Sitting all day

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 8h+ 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

3. Debugging

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 originally the bug 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

4. Poor documentation

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 rather than writing new code.” Walt Karas

5. Merging code

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

6. Unrealistic expectations

The forehead smacker: Software developers are usually assumed to be pretty smart cookies. Unfortunately, this often leads bosses, project managers, and salespeople to have unrealistic expectations for what a programmer, or team of them, can reasonably produce by a certain date and to over-promise on deliverables. That, in turn, can lead to developer burnout and general unhappiness amongst the coders.

Quotes: “The most frustrating thing is disabusing people of the notion that you’re actually not a wizard, that there are limits to your knowledge base, and what can be physically accomplished using the tools available, within the time constraints, and trying to explain what those constraints are to those who have never programmed a computer before, and don’t want to.” Mark Miller

“Your boss having very high expectations of you and your collegues but there not being enough time/resources to even come close to these expectations.” Kevin Sekin“Project Managers or business analysts promise the moon to the client, and programmers have to do it, come what  may.“ Ratnakar Sadasyula

“I love it when somebody asks about something trivial, and then just casually throws in a feature that would require advancing the field of CompSci by a couple of decades” Vladislav Zorov

7. Other people breaking my code

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

8. People don’t understand what I do

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

9. Lack of time

The forehead smacker: Like in most endeavors, it takes time to craft good software. Unfortunately, again as in most endeavors, upper management and/or clients usually aren’t willing to wait very long for an ideal solution to be implemented properly. As a result, software developers are all too often pushed to get something done quickly, which can lead to ugly hacks, technical debt, and lack of documentation, all of which can cause more headaches down the road, particularly for the programmers who will have to deal with the resulting code in the future.

Quotes: “I want to do things well, but there’s a lot of pressure to do things quickly and familiarly instead. Sometimes it’s justified, but it feels like the current programming/business culture has swung way too far in that direction.” Tikhon Jelvis

“for me it’s being in a rush, writing code that I would call kluge code, then knowing that there’s code in the product that I wish I had written more elegantly. There’s a constant time pressure …” Gene Sewell

“… when many of the things you do aren’t even remotely related to what you know is good programming practice, but because fast is more important than quality, you have to do what they ask you to.” Jose Palala

“… there is never enough time and money for the right solution, yet enough for fixing quick and dirty, over and over again.” Romi Awasthy.

10. Working with other people’s code

The forehead smacker: As a software developer, sooner or later, you’ll have to work with code written by someone else. Whether it’s legacy code you inherit from someone who came before you at a job, a third party API, or code written by a consultant, you won’t be able to completely escape having to fix, enhance, and/or integrate someone else’s program. Needless to say, having to do so can often cause developers to pull out some – or alot of – hairs.

Quotes: “… the worst part is having to walk through some one else code, figure it out, debug it, tweak it around. And it’s even worse, if the person before you has left the company, and you really never had any knowledge transfer of it.“ Ratnakar Sadasyula

“Trying to decipher thousands of lines of uncommented code.” Simon Zhu

“There has been times when I’ve dealt with TERRIBLE code written by consultants.” Joe Samson

“Another problem I think can be very frustrating is third party API’s. You rely on them a lot sometimes and then you notice an issue with it or need a new feature but that particular API doesn’t give you any source to fix the issue yourself, so you need to ask the author of the API nicely and hope for the best.” Kevin Sekin

“Language and framework bugs. You spend days figuring out why your code doesn’t work. Only to find out you’re hitting a bug on the language or framework.” John Paul Alcala

“Living with finding code written by someone who was not nearly as qualified to write it as they should have been….” Nani Tatiana Isobel

Take your time to share your feedback on this article