Why you should not become a programmer – experts talk about the shortcomings of the profession

Each profession has its own shortcomings, but often they learn about it only after some time. Let’s see what the disadvantages of the programming profession are for a beginner to be prepared for.

High entry threshold and the complexity of the profession itself

At first glance, it seems that everything is simple – learn the programming language and you will row money with a shovel, at least that is how beginner developers think so. However, as you dive, it turns out that everything is completely wrong. The more complicated and confusing the code, the more unpredictable it behaves, compilers throw errors, exceptions fly out of the blue, you need to keep in mind a huge amount of small details so as not to miss anything. At some point, it begins to seem that the compiler / interpreter is living somehow with its own mind and is desperately resisting. And from the point of view of information theory, there are no at least any complex programs without any errors at all. It’s hard to put up with this.

On the other hand, the feeling of satisfaction is incomparable when the problem is still defeated and the code begins to work out as it was intended. It turns out that the compiler / interpreter still just followed the instructions given by the programmer, dryly and thoughtlessly.

To facilitate entry into the profession, you need to read a lot about best practices, preferably in English, try to work in a team with professionals and constantly study, study and study, both in theory and in practice.

Cost of error

Few people realize that the cost of a developer error can be calculated in huge amounts. Imagine the loss of an online store where you can’t order anything, or what kind of loss will result from a failed stock exchange software.

The sense of responsibility puts pressure on the developers, although they do not, as a rule, bear a direct risk of punishment. Here you can recommend using the best practices of CI / CD (continuous integration / continuous deployment) with automated testing, the practice of pair programming and code review (code review), which will minimize such risks and gain a sense of confidence and peace over time.

Lack of feedback or overly active feedback

So it turns out that pronounced introverts usually go into the profession of a programmer – people with the highest level of self-immersion and high ability to analyze. And at first life in this sense seems wonderful – you only have to interact with the team leader or, in the worst case, the manager, and the programmer does not see and does not hear the rest. But then the shortcomings of this situation begin to appear. Tasks come strange, they have to be redone several times, and the programmer begins to dream of getting more detailed tasks, to hear direct feedback from clients and users. But life is not so simple.

As he grows into a team leader or manager, unnecessarily active communications begin to fall on the shoulders of the programmer and the former developer gradually begins to understand the reasons for the confusion that he suffered from before, only now he dreams of being left alone.

You can only understand and accept these shortcomings, make your choice at what level to work with customers / clients and work in companies where this level is maintained for developers.

Business / Market Realities

There are two problems here.

Each code, sooner or later, requires refactoring – rewriting in such a way that the code is beautiful and harmonious, there are a minimum of errors and maintaining such a code would be as easy as possible. But there is a problem – the more code, the longer refactoring takes until the heavily launched code is faster and cheaper to completely rewrite than trying to optimize.

And here all this conflicts with the realities of the business, for which refactoring is simply additional costs that do not bring anything of value. Business in every way postpones or directly prohibits doing this, at the same time not agreeing that errors will occur more often and their consequences will be more serious.

This requires good teamwork, in which developers honestly highlight only the truly necessary code optimizations, and the manager sells them to the business in one way or another.

The second problem is that the market often does not tolerate laggards. And this translates into a constant race into which developers are involuntarily drawn into. It seems good practice not to do code calculations on Friday night, but what if the task itself was set on Thursday and everything should work on the weekend? At the same time, the task came described only superficially, because the business is also in a constant race and there is not always time and / or specialists in the staff to think through all the screens and their interaction in detail.

This problem can only be solved by choosing a job in an industry where the business is not changing very dynamically and there is the opportunity to do everything slowly and in the right way.


Sooner or later, many developers begin to come up with a choice: to be highly specialized in a particular technology or to know many different technologies, but more superficially.

Different people make different choices: someone tries to cover the maximum of everything, gradually becoming a “full stack” developer, someone from the very beginning refuses to study additional technologies and grows only in his stack. Both the one and the other approach have their pros and cons.

“People-orchestras” can help colleagues with many tasks, which highlights them in the eyes of leaders, theoretically, it is easier for them to find a job, selling only those skills that the employer needs, they grow into managers more quickly and easily. On the other hand, it is more difficult for them to create truly high-quality code in a separate stack and it is more difficult to speak the same language with professional developers as they grow into managers.

Highly specialized specialists perform their immediate duties better and more professionally, can get into cool companies and earn more in their stack, as professionals are highly valued. On the other hand, there is a much higher risk of being sidelined if the technology becomes obsolete, which leads us to the next disadvantage of the profession.

Industry development rate

This, in my opinion, is a key flaw that people really begin to realize and accept only with age, although at first the race is exciting and breathtaking – new exciting technologies are constantly booming, they are expanding and improving, and at the same time they are simplified and complicated.

At first, keeping up with it is not so difficult: you can read numerous articles, choose employers who either use advanced technologies or do not limit their choice, write articles yourself and participate in advanced community development.

Over the years, more and more I want to use the accumulated vast knowledge, and not continue to study without stopping, but it is almost impossible to afford. Sooner or later, any developer faces a choice: either grow horizontally, “stiffen” in a particular set of technologies and bear the risk of their gradual obsolescence and extinction, or grow vertically — to some extent retrain and go to management, where skills are much slowly become obsolete over the years, and some do not become obsolete at all, such as managing people, negotiating, and many others.

Similar Posts

Leave a Reply Cancel reply