Software Developer. 100K Job Phobias

Updated October 6, 2023

Software Developers Phobias
Developers, like all other people, have phobias. Someone is afraid of maniacs, someone is panicking because of the violation of his regular daily routine and someone starts banging his head against the wall from the sudden disappearance of communication in his smartphone.

All of this, if I may say so, universal phobias inherent to any generation, country, and continent. But there are also purely professional phobias, which are unlikely to be understood by representatives of other professions. Phobias are evil, both in life and in work. Because the object of fear is fictional, and fear itself is real. And the consequences of fears are also real.

Despite the fact, that there are many ways to hire a developer, because a developer will always cost a lot. It is important to know potential problems the expert may suffer, currently or previously and realistically understand how hard may they hit the developer’s performance. In this article, we will go through two stories of real devs and their professional phobias, which prevented them from living and working for their own pleasure. People are real, whereas names are fictional.


Alex has issues with self-confidence. He became a programmer just recently, he used to be a sysadmin, even though he had a higher engineering education. Alex, lucky or not, immediately fell into the disciples of a fairly experienced and confident programmer who on the first day took the bull by the horns – “I’ll teach you the life right now”.

He taught everything at once – algorithms, frameworks, queries, architecture, and communication with users, and approaches to development. This does not sound bad, you may think, but the teaching approach was very authoritarian. The mentor believed that the only true option for solving any problem is his own.

If Alex had his own solution, he was getting knocked on the head. He had neither experience, no skills to defend his opinion, so he always ended up being a fool. The mentor was not just convincing him – he was trampling him into the ground. This became Alex’s main phobia.

After some time Alex left to another job, and the phobia left with him.

Here the boss was quite adequate, though he did not immediately consider that something was wrong with Alex. He thought that Alex just needs a little bit more time than everybody else to find a suitable solution to a problem.

There are no standards for this, but to think 8 hours on which of the three well-known methods is better to solve the problem, and then implement it in 1 hour – seems like a stretch. And this all despite the fact that Alex understands all three versions very well, and the result of all three solutions is approximately equal.

Only a direct instruction would help Alex to make up his mind quicker. But this approach was not favored by the boss – he wanted his stuff to be more responsible. Pressuring Alex also did not help – he completely shut down, and it was for someone else than to solve his task. The boss, like his colleagues, was close to the decision that Alex was just very unprofessional and slow, and he was almost one step behind the door.

However, he decided to give him another chance. Or rather give himself a chance to understand Alex better. He created the right working atmosphere for him, in which Alex began to unfold, and eventually told the story of his first mentor, although Alex himself did not consider this story to be something important.

The boss understood the phobia and changed his approach. He realized why Alex was choosing the solution option for so long – on a subconscious level, he was afraid that he would be trampled into the ground again if he would choose the “wrong” option.

But in fact no choice is being made during those 8 hours – Alex simply postpones the inevitable for a maximum period of time to remain longer in the illusion of alarming security.

Bosses measures were simple:

First, he talked with Alex, and trust me, this was not a five-minute talk. He explained him everything the first mentor never bothered to tell. He used simple numbers – all three solutions can be done in 3 hours, instead of 8 hours of doing nothing. Yes, only one option remains alive, but Alex will get tons of experience during the process.

Second, for small-time, periodically, he reduced the importance of tasks – their solutions in many cases do not hold the fate of the world and the client.

Third, he began to observe Alex’s progress daily – personally, and through solved tasks in the tracker. Only to catch the moment, if Alex would once again be possessed by the phobia.

As a result, after 1-2 months, the phobia was gone for good, and Alex became an equal member of the team. And after a while – the best man on the team.


Ryan was a great programmer. Not the best in the world, but in certain niches, which he intuitively chose for himself, peers were rare. Ryan worked alone for a long time, but he always kept in touch with the web community – he understood what it takes to write a good code. It so happened that Ryan often distributed his products, mostly free of charge, and with open source. It was in those days when the dev-consumers actually looked inside on what they downloaded, cloned or forged.

And these “inside peepers” created Ryan’s phobia – they said that Ryan writes fantastic codes. From now on, Ryan had no moral rights to write anything less than fantastic. So that any dev could give it a huge thumbs up.

These other programmers estimations became a real drug for Ryan. He almost never wrote the code “for the client”, or “to solve the client’s problem” – he wrote the code to get the appreciation of programmers. Almost all of his decisions were as abstract as possible, easily applicable for other solutions and for other clients.

And Ryan was succeeding. He created dozens of decisions, each of which, on the one hand, completely satisfied the needs of the customer, and on the other hand was becoming a hit with free distribution among developers.

Was not long before Ryan started having some difficulties – he could no longer write “just a  code.” Every client, every project, and every product has tasks that can be solved simply, but if overthought, become the hardest to solve.

The problem was aggravated by the fact that Ryan was not publishing everything altogether – he had neither strength, no time. Simply putting the code out was not enough to get the likes, you also need to work on its promotion. As a result, Ryan formed a queue of solutions that were born for the whole world, and only one client was using them.

The problem was becoming even worse if Ryan was changing the place of work. The pool of decisions that Ryan failed to publish, stayed on the previous work – he was not interested in violating anyone’s rights. All attempts to tell his successors about the potential of the decisions left have ended in failure – new programmers preferred to create their own. Not as “fantastic”, but their own. It’s understandable – new devs were paid for creating a code, not using one.

Ryan’s phobia got cured by life itself. After several transitions between companies, the ratio between published and lost decisions for the community became menacing – 1 to 9. Ryan realized that he spent years of life in vain. Not in vain, of course – the experience was still there, and whenever there was a task of creating a universal component, Ryan was the best man for the job. But the ratio of such tasks varied from 10 to 50%.

The rest of the tasks he stopped solving abstractly. More precisely, he invented a different level of abstraction for himself – personal experience. It is not necessary to create a solution, a tangible product that can be given to someone right away. The product is a personal experience of solving such a problem because it takes much less time to reproduce your code than to create it for the first time.

As a result, according to Ryan’s own assessment, his overall efficiency has grown by 3-5 times. This figure included both abstract components and context-sensitive solutions. But most importantly Ryan lost the awaiting publishment universal solution queue. Yes, now he did less of those, but he published 100% of them. He simply stopped making solutions that he could not publish immediately.

As a result, the total number of universal solutions, which reached the publication stage and therefore, collected Ryan his likes, increased by 2-3 times, since the 1 to 9 loss funnel disappeared.


The two phobias described above are the phobias developers often witness, but there are of course a lot more of them, both people and phobias.

Phobias are complex and dangerous because they are not visible. A person can look pretty decent, work hard and efficient, smile and be a normal member of the team, but at the same time have a phobia and suffer from it.

If you observe the colleagues surrounding you, and of course yourself, you may notice signs of phobias. The main sign is important. Tasks, actions, attributes, rituals, approaches, reactions, at least something. When there is a phobia, there is importance. To verify that you are not mistaken, try to remove what is overly important for a person, what makes him shut down, break or hover.

Observation and trust are the best recipes for phobias. It should be very important for a proper leader since it opens a direct access to your worker’s motivation. Especially if one can help to overcome his phobia – this will be never forgotten, like healing from a terrible disease.

Leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.