Programmers with an allergy to the subject area

Programmers with an allergy to the subject area

In 2012 WikiLeaks started publishing closed documents of a private intelligence company Stratforknown as the “shadow CIA” Among others, a document related to onboarding – a glossary of terms for new employees – was discovered. The introductory word to this dictionary looked like this:

“Each subject area has its own terms, it’s pointless to discuss a football game using terms like baseball, so this document compiles the terms we use.”

This is followed by twenty pages of detailed analysis of specific (and not so) terms to introduce newcomers to local cuisine. Of course, we will not study them, but let’s talk about the attitude to the subject area of ​​the average developer, which are most often encountered.

An example from practice

Once, Jun came to my team, although he himself told everyone that the middle is made of diapers and even conducts webinars for students of some courses there, they say, he ate a dog at your development (he is not Korean – it is a figure of speech). Even the position did not predict that June would appear in it, but the interview was conducted then, unfortunately, without my participation. It is noteworthy that he fell not so much on the lack of knowledge and skills, as on a sharp unwillingness to understand the subject area of ​​the business, which he was going to automate.

Setting the task turned into a headache: difficult communication, errors related to misunderstanding of the data, different readings, when everyone nods and says “understood”, but “understood” somehow in its own way, in a special way and you go to the second, third and Finally, the tenth round of analyzing the task. Neglecting a subject area by one single developer inconvenienced the entire team and took a lot of time without going into detail – it was very expensive for all of us. He, excuse me, is loud, he has these two quarters or three halves and, moreover, four periods in this snooker of yours in general like a drum – an allergy to sports (if you have one too, don’t pay attention – this is a funny joke about sports that and was the subject area).


Perhaps, as a manager, I have no right to shift responsibility to a negligent employee and in general I am to blame. It’s just that we didn’t get along and I’m sure that everything is fine with him, he’s grown up and is a great specialist. But the fact remains that the mediocre professional skills of the developer, well, those that are usually called solid (turn on the computer or open the IDE), turned out to be not so important compared to the acute intolerance of the subject area, but rather to the lack of understanding that it is important.


Is it possible for an ordinary coder not to bother with understanding the subject area and write high-quality, productive code? Exactly – yes.

If you don’t believe it, take a look at companies and their meetings: two participants argue for half a day, ten listen to them silently, and they solve a problem that, as it turns out, doesn’t exist yet. Involuntarily, you start looking around: it seems that the Tigris and Euphrates are roaring in the distance, and somewhere nearby, the same tower is about to collapse, the languages ​​are already mixed and no one can understand each other. And what? And nothing – they work, moreover, successfully, when someone pays for the banquet.

Bring something I don’t know what

Often (more often than you can imagine and in places where “well, this definitely cannot happen”) it happens that everyone does their job to five plus, but the business problem is not solved and the user has already cried crocodiles on the keyboard tears in trying to get what he needs. But the code is a work of art, productive, even SonarQube admires you (this is a code base analysis tool, with blackjack and metrics).

This happens even because the executor (programmer) is unable to complete the task, does not know the user and does not understand business problems. It is important to understand that this is a normal situation for a green beetle: let the team member with the mentor cough up these questions, he still does not fully know the syntax of the language. Or, let’s say, in the development to order – the roof will go deep into the subject area of ​​each project.

But in any other case (in my opinion) understanding the subject area is vital for a programmer. From the bonuses: you can significantly reduce the volume of meaningless work, influence the release of a product that really works. Not in the sense that the buttons are pressed, and the jasonchiki are translated – no. In the sense that the business problem is solved and the user gets what is due (humiliation, disdain and problems are not).

Shape av may hart

Let’s assume that we have immersed ourselves in the subject area, there is an excellent programmer: he understands the business and understands the user. If only he could load another notorious T-shape into his piggy bank (don’t imagine the cleavage of a plumber, please) and there will be happiness. What does the product do? And the project? Testing and design? Do analysts even do any work? With that, it is clear – this one delegated everything.

No, don’t get me wrong, you don’t need to thoroughly understand all “other people’s” work, it’s “other people’s” for that, but understanding your peers and the stages at which you come across is priceless. For example, a front-end person who knows UX no worse than your designer, and not only makes an excellent pumpkin latte, a manager with a technical background can be extremely pleasant to work with, as can a designer who understands the limitations and possibilities of development, and a scrum master, which … which was kicked out in disgrace (yes, I know that the scrum master is just a role, but I couldn’t pass by). All this increases the chances of making something really good, not just code. And let this code be perfect, but it may turn out to be completely useless (and you don’t even know).

The best thing a programmer can do for himself and his team is to understand the subject area. Who is arguing?

Conclusion and motivation

I would like to meet many more conscious professional developers who understand that a programming language is just a tool; code alone is worthless if it doesn’t solve a business problem; “someone else’s” work (unfortunately or fortunately) is not really “someone else’s”, because it affects your and many other different and useful things that fill the daily routine with meaning. And without meaning, you are like coal in the stove: you are already thinking of a new article on Khabrakhabr, which has slipped, about how you got burned.

Powered by Programming is a Telegram channel for programmers, in which we do not rewrite documentation, but talk about the eternal – about what is important (and not always obvious) in the work of a programmer and, of course, we joke. Come, subscribe, participate in the discussions, if something from what was said resonates somewhere in your heart. Have a great day at work everyone, keep a fire extinguisher nearby.

Related posts