10 main programmer disappointments

Those who have nothing to do with software development may find the developer’s work quite easy: you are in demand in the market, pay well, companies try to please with pleasant nishtyaks, and so on. All this is true, but if you are honest, there are a lot of unpleasant moments in the programmer’s work. We have collected ten of the most popular things that most upset the creators of software.

10. Iron

Of course, programs need equipment so that they can run. And no matter how some developers try to ignore the role of iron, sooner or later, when creating and debugging software, they will inevitably encounter hardware-specific problems. Therefore, beginners are recommended to always study the features of iron and the systems on which their code will be executed, so that later there will be less difficulty.

"Every programmer who at least once debugged a strange crash on a database server or tried to understand why RAID drives do not work correctly knows what a pain it is - hardware problems." Steve borthwick

“Programmers hate hardware because they can't always blame everything on it!” Anonymous

9. Sit all day

Until you have a desktop with a treadmill, software development will never be like a kind of aerobic exercise. Most programmers spend long hours sitting on their ass, knocking on the keyboard and gazing at the screen (s) intently. After some time, a long sitting can become very uncomfortable. And if you can not even move to another place to change the entourage, it sometimes quickly drives in anguish.

“I sit all day in a chair and stare at the screen. It started some time ago ... first my back, then my neck, my eyes were tired and seemed to burn, my head was aching ... I had no rest ... I tried to compensate for this with fitness, Tai Chi, yoga, qigong, went to work by bicycle - and still I can’t sit eight hours or more. Spending the whole day in the office ... watching the sun pass through the sky, not looking up from this damn chair, as life passes by. " Markus toman

8. Debugging

Even the best, carefully written code does not do without bugs. Naturally, developers are forced to regularly spend time searching for and fixing defects - both in their code and in someone else's. Some bugs are found and treated easily, while others can bring to the white heat with their elusiveness, forcing them to spend many hours and doubt the stability of their psyche.

“Detection of a hard-to-reproducible or, worst of all, manifested in the integration test of a bug that accidentally passes or fails on the same piece of code !!! Then you get the feeling that you can never find these damned mysterious bugs hiding somewhere in the code. Ugh ! ” Emmanuel Ngwane

"We write such large programs (sometimes small ones too) that when debugging we delve into such jungle and forget about what the bug itself is . " Ayush bhatnagar

“Debugging, especially when working on large projects from thousands of lines. Many geeks like me prefer to display the image through the projector when debugging so that it is easier for the eyes ”. Isaac perez

7. Bad documentation

Working with someone else's code is sometimes annoying, but not so much if it is well documented. Unfortunately, this is not always the case. If there are no comments in the code or a well-written explanation of how everything works, you have to spend much more time debugging, extending or integrating the application. And this is not the best effect on the well-being of programmers.

“Most annoying when you are hired to deal with poorly documented software. This makes life difficult for those who accept work on the project. Lack of comments and bad semantics, especially when a lot of bugs and errors remained after the previous programmer. ” Angel Angeles III

"Proceedings in undocumented and uncommented code written by some idiot." Abhishek chauhan

"I, like most programmers, spend more time maintaining a poorly documented code than writing a new one." Walt karas

6. Merge code

Source control systems like Git or Subversion are great tools that allow many programmers to work on the same codebase at the same time without pushing their elbows. But in the end, changes need to be committed to the repository, and conflicts can arise here, if, say, two developers change one file or subroutine. Sometimes such conflicts are resolved easily, sometimes - not very.

“ I do not like mergers, because I want to change the code so my colleague wants to do it differently - and how should we be? I always try to find ways to combine both solutions, but if there is a real conflict, then merging becomes a very unpleasant task. ” Jessica su

"Conflict of merger" absolute evil " . " Koustuv sinha

5. Unrealistic expectations

Software developers are far from stupid people. But for this very reason, all kinds of bosses, project managers, and salespeople often show unrealistic, high expectations that a programmer or a team of programmers can create by a certain date, and therefore plan too much. As a result, developers eventually fade at work and generally do not feel pleasure from it.

“The most unpleasant thing is to explain to people that you are not a magician, that your knowledge has boundaries, what exactly can be realized using the available tools within the allotted time, and try to bring it all to people who have never done programming and are not eager to do it " . Mark miller

“Your boss expects a lot from you and your colleagues, but there is not enough time and resources to even get closer to the expected results.” Kevin sekin

"Project managers and business analysts promise customers to get the moon from the sky, and programmers should do this by all means . " Ratnakar sadasyula

“I love it when someone asks you to do something trivial, and then casually throws up a demand in such a way, for the realization of which computer science needs to be developed for another twenty years . ” Vladislav Zorov

4. Other people break my code.

Code written by any developer, one way or another, should interact with the code of other programmers. It doesn't matter if they are parts of a single application, third-party libraries, tools, or another application altogether. Our code does not exist in isolation. As a result, someone may, due to haste, misunderstanding or disorder, break someone else's code, which causes discontent, quarrels, stress, and often curses.

“The worst thing I had was when I wrote the program with a person who, without any notification, changed the library to which we both referred. As a result, my subroutine calls lost variables or added them. Or, even worse, the library code fell, to which I did not have access. ” Sheri fresonke harper

“When a part of your code stops working because someone has changed their part of the code. Often their functions begin to require more arguments than before. Sometimes functions generally disappear or are transferred to another file. ” Jessica su

“The need to constantly go back and redo the code that you wrote a couple of days ago and that just“ broke ”(not for the first time) because of changes made to the general system without any discussion by someone who hasn’t even tested or scored on what tests fail. And as a result, they also declare that your code is “not working” . ” Simon hayes

3. People don't understand what I do.

Despite the growing popularity of the programmer profession and the widespread prevalence of software, many non-IT professionals still do not understand what the developers actually do. For them, we are just “techies”, and they don’t see much difference between, for example, software and hardware developers. Constant misunderstanding and inappropriate perceptions, especially among your family and friends, can put the programmer into a rage.

“It is a common misconception among people who are not related to IT that once programmers work on computers, they should be able to repair them. This is about the same as if you drive a car, you should be able to go through the gearbox. ” Steve borthwick

“Yes, I make a living by writing code. No, I can not help solve the problem with the printer, or opening a file attached to the letter, or not booting the computer. At least - as long as you don't treat me to dinner or beer, then maybe I can help. ” Phil johnson

"Explain to people that I do not have in every corner a store that installs pirated software on their computers." Anbalagan jeyabalachandran

“Family and friends think that I can remotely repair everything connected with computers. Both iron and programs. They do not understand. As a result, you have to listen to their caustic comments like "what kind of programmer are you, even if you can not fix the DVD drive on my laptop". " Jazib babar

"Only 1-2% of people know what I actually do." Yasin Pekşen

2. Lack of time

As in most other areas of activity, creating good software takes time. Unfortunately, as elsewhere, management and / or customers usually don’t want to wait long enough to correctly implement the perfect solution. As a result, developers are very often customized to make it faster. This leads to the use of unsightly hacks, technical debt, poor documentation. In turn, the described consequences cause a headache during subsequent modifications and maintenance, especially for programmers who have to deal with already prepared code.

“I want to do everything well , but because of the pressure, I have to do it hurriedly. Sometimes this is justified, but it does not leave the feeling that the modern programming culture has gone too far in this direction. ” Tikhon jelvis

“The worst thing for me is to hurry to write sloppy code and know that I could make it much more elegant. The lack of time is constantly pressing ... " Gene Sewell

"... When a lot of what you do, does not even remotely resemble good programming techniques, and just because speed is more important than quality, you have to do what you are asked to do." Jose palala

"... There is always not enough time and money to create the right solution, but it is always enough to correct them on the knee again and again . " Romi awasthy

1. Work with someone else's code

Sooner or later, software developers have to deal with code written by someone else. Whether it is legacy code inherited from its predecessor at work, or a third-party API, or code written by a consultant, you will not be able to completely avoid the need to fix, expand and / or integrate someone’s program. And it often makes developers tear their hair on their heads.

“... The worst thing is to climb another's code, understand it, debug, tune. And it is completely dark when the person who wrote it has already quit and will not help you in any way. ” Ratnakar sadasyula

"Trying to decipher thousands of lines of undocumented code." Simon zhu

“There have been cases when I had to deal with HORRIBLE code written by consultants.” Joe samson

“Another problem that can be very frustrating is third-party APIs. Sometimes you rely heavily on them, and then you notice a problem, or some kind of functionality is needed, but the API does not allow you to solve it yourself, so you have to contact the author and hope for the best. ” Kevin sekin

“The bugs of the language and framework. You spend days trying to figure out why your code is not working. And only to find out that the whole thing is in a language or framework bug . ” John paul alcala

“Detect code written by someone who did not have the proper qualifications to create it at all ...” Nani Tatiana Isobel

Maybe your top 10 includes something else? Welcome to the comments :)