As programmers are not allowed to do anything else

The ability to program - one of the few skills that limits you in the eyes of others.

I was a product manager, a project manager, a scrum master and product owner, a usability engineer, and a bunch of other things. I can design interfaces based on interviews with users, I can lead and train teams, distribute work before the deadline and run projects. All this I did, and successfully.

But as soon as I mention that I am writing code, I become a “developer”. That's the point. Now I need to assign a project manager who will assign me the task. Someone will write a technical task, according to which I must give an estimate of the execution time. I no longer speak with clients and should report periodically on the work done.
')
This is a very curious phenomenon, which I observed repeatedly, in many situations and organizations, and not only with me. It got to the point that now in some projects I actively avoid writing code (or pretending that I don’t know how) because I want to gain trust from the user or customer (for example) to allow me to plan and draw up technical tasks. But as soon as I write something, I immediately become a “developer” team. And stay them forever.

At the same time, dedicated project managers strongly co-operate with harmonious developers who are capable of more than just writing code. They are extremely happy to work with engineers who communicate well, are able to create a working architecture (not only at the technical level, but also at the project / business level) and can anticipate product usage scenarios. Not surprising; these abilities are not enough for them; they fill in empty places. However, in many projects, this separation of duties only adds an extra layer of communication, without which a harmonious developer could often do a better job.

At first I thought that this phenomenon was mainly related to age. If you are relatively young and agree to be a programmer, then it is easier for people to look at you as a typical developer, inspired by the spirit of Silicon Valley; a kind of living in a garret, dressed in a hoodie antisocial guy-geek. But I have seen the same thing happen to experienced older engineers.

These engineers watched companies appear and disappear, they started their start-ups, worked in companies at different levels and in different roles, they had comprehensive technical knowledge that made them so valuable in all roles. Imagine that there will be another person nearby (usually a “jacket”) and they will go to a meeting with clients. If customers say that one of them has comprehensive technical knowledge - everyone will automatically take him for a “techie”. For questions of strategy, planning, and so on, they will turn to the "jacket." Although the engineer could be much more competent to discuss these issues.

Why is that? Why such an urgent need to put a stigma on a guy with a technical education and remove him from participation in other areas?

Maybe because people tend to sort things out, put things in different categories. Ideally, all things in life have a single task and goal, so you can say: "This is an ax, they can chop down" or "This is a monitor, it shows an image." So everything becomes clear and predictable. Of course, this is how we develop good software, look at least at the Unix philosophy.

But of course people are not like that. We are machines whose benefits are constantly changing and improving. The more a person knows, the more he saw and where he was, the better and more harmonious he would be for any given task. We recognize this development of experience in a single role, but for some reason not between different roles.

I believe that the ability to program should never deny the right to actively participate in the project. On the contrary: it makes a person more qualified than those who do not have such a skill. If you are able to bring strategic discussions directly to a specific technical level and walk through it with the logical mind of a developer, then this is much more valuable than the idle chatter of “jackets”. You can discuss the user's problem and immediately understand the consequences of all possible solutions in the system - and not necessarily because you created this system, but because you are able to derive technical consequences from experience. Then you will make a more informed decision with the user on the spot.

In my ideal team, everyone is able to do the work of any other, but simply chose a specialization that he likes more. Continuous role changes are encouraged, communication lines are optimized, and the set of roles is often revised. Such an ideal is not entirely realistic in specialized professions, but an ideal is not something that is achievable, but something to strive for.

That is why I think that every developer should strive for harmonious development, then he will be able not only to write code, but also to contribute at different levels. And for this it is important to encourage and not prohibit developers to expand their role.