In this position, you will be a bad developer.
You never thought that you could be fired not because you are a stupid and bad developer, but because all the processes in the organization are built so that you are a priori curved and bad in this position! And the only option to stop being crooked is to change the responsible section for which you are responsible.
If you worked in large companies (more than 30 developers), you might notice that in certain areas of responsibility, developers change much more often than others. And what is most interesting, developers are often dismissed for incompetence, violation of labor discipline (swears with tech dir, lead), and general pofigism (burnout). And you know, there is a certain regularity in this.
Each company has different areas of responsibility. Someone is cutting new features, someone is modifying existing ones, someone is developing and optimizing the infrastructure, and someone is supporting Legacy systems and correcting errors that exist in them. And if we are talking about the likelihood of becoming a bad developer, we move to Legacy systems, and the less these systems are connected to customers, and the stronger they are with the internal office, the higher this probability.
')
Let's say a month goes by, an idea of ​​what the developers by the teams managed to do is coming.
Those. others, including business owners, have a clear understanding that some guys develop a product, save money, relieve customers' pain, and someone does some secondary garbage.
Imagine that you are developing a new functionality, and for some reason the terms start to burn. The business owner goes to the product and starts to force the product, that everything is bad, what is terrible. The product takes the main anger, and somehow it starts “let's guys faster, we have deadlines and so on”. Moreover, everyone understands that this is a new functionality, disruption of terms is a common thing, therefore, they are treated with understanding. Those. no one directly presses developers.
If we are talking about Legacy systems, then most often the situation looks like this. In the lead comes some of the departments (sales, accounting, marketing, etc.). And they say, we have a problem that needs to be fixed. The lead sends the developer and forgets about this thing.
Conditionally after a week, the head of the marketing and sales department again comes into the lead and says - what the fuck did you not fix this joint. We cannot work like this, “what should we get higher?”. The lead walks into the developer and says, “What the hell are they pressing me here because you can't do something here?” Let's fix it already. ”
Imagine there is a distribution of awards. First of all, they will receive those who have contributed to the development of the product. After all, they are cool guys who develop a product, make new features and stuff. Customers are happy, sales are happy, these guys are heroes.
And at the very end, they will remember the guys who did something according to the Legacy Systems. And if so, then the chance to get the premium will be lower, and the index will be lower.
Plus, you need to understand that if you have made a new feature, then everyone sees that there is a feature, you have done it - you are great. When we make some kind of fix on Legacy, the result of this work is taken by the marketing, sales, support department - but not you.
When we talk about the new functionality, it is obvious to everyone that it can work with errors. After all, this is a new feature, unknown field, and so on.
When we talk about legacy modules, they should work correctly. Therefore, cases occur very often when a developer makes changes to the system, which he does not understand very well. The testing department catches a bug, the developer fixes it, then testing catches another bug, and so on. Or God forbid, the mistake will fall on the prod, and already the head of some department will conditionally go into the lead and say “What the fuck did you do there, nothing works for us.”
As a result, in the first case - an error, this is a valid situation. Secondly, you asshole, that you made a mistake and broke everything.
Imagine that there is a thought that someone from the developers is not working well and needs to be fired. Lead enters the PM asks about the dismissal. The PM will say, “You have gone crazy over there, and the deadlines are already burning, if you fire Max now, we will not have time.” I’ll just tell tech diru that this is your school, and let him fuck you already. Lead thinks he will really fuck him, so he postpones this dismissal. ” And there already Max will think again, or something else will happen.
If we are talking about legacy systems, then no one will particularly stand up for such a developer. After all, if it works well, nothing just happens. If he works with errors, then he is an asshole who harms the work of other departments.
As a result, the guys who sit in such areas have a legitimate feeling that they are being fucked from all sides, they do not appreciate their work, they don’t pay extra bonuses, or they are dismissed for mistakes, or they break down and start swearing at the leaders, diras and so on. That in any case leads to dismissal.
If you worked in large companies (more than 30 developers), you might notice that in certain areas of responsibility, developers change much more often than others. And what is most interesting, developers are often dismissed for incompetence, violation of labor discipline (swears with tech dir, lead), and general pofigism (burnout). And you know, there is a certain regularity in this.
Why do you become a bad developer?
Each company has different areas of responsibility. Someone is cutting new features, someone is modifying existing ones, someone is developing and optimizing the infrastructure, and someone is supporting Legacy systems and correcting errors that exist in them. And if we are talking about the likelihood of becoming a bad developer, we move to Legacy systems, and the less these systems are connected to customers, and the stronger they are with the internal office, the higher this probability.
')
Legacy systems are not sexy
Let's say a month goes by, an idea of ​​what the developers by the teams managed to do is coming.
- Food teams show new features, they all rather clap, as it became cool.
- The development teams of the existing functional show how they have corrected abruptly the mistakes and shortcomings that the support and sales department raped by customers (everyone was delighted).
- The infrastructure development team shows that they were able to optimize the work and now we can save 4-5 thousand dollars a month on servers (tech-directors in ecstasy).
- The support team of Legacy Systems, says that they corrected the formation of the report for the accounting department, if there were invalid data from the counterparties (Everyone doesn’t care).
Those. others, including business owners, have a clear understanding that some guys develop a product, save money, relieve customers' pain, and someone does some secondary garbage.
Legacy systems punish your ass
Imagine that you are developing a new functionality, and for some reason the terms start to burn. The business owner goes to the product and starts to force the product, that everything is bad, what is terrible. The product takes the main anger, and somehow it starts “let's guys faster, we have deadlines and so on”. Moreover, everyone understands that this is a new functionality, disruption of terms is a common thing, therefore, they are treated with understanding. Those. no one directly presses developers.
If we are talking about Legacy systems, then most often the situation looks like this. In the lead comes some of the departments (sales, accounting, marketing, etc.). And they say, we have a problem that needs to be fixed. The lead sends the developer and forgets about this thing.
Conditionally after a week, the head of the marketing and sales department again comes into the lead and says - what the fuck did you not fix this joint. We cannot work like this, “what should we get higher?”. The lead walks into the developer and says, “What the hell are they pressing me here because you can't do something here?” Let's fix it already. ”
Legacy systems don't give you value
Imagine there is a distribution of awards. First of all, they will receive those who have contributed to the development of the product. After all, they are cool guys who develop a product, make new features and stuff. Customers are happy, sales are happy, these guys are heroes.
And at the very end, they will remember the guys who did something according to the Legacy Systems. And if so, then the chance to get the premium will be lower, and the index will be lower.
Plus, you need to understand that if you have made a new feature, then everyone sees that there is a feature, you have done it - you are great. When we make some kind of fix on Legacy, the result of this work is taken by the marketing, sales, support department - but not you.
Legacy systems do not make mistakes
When we talk about the new functionality, it is obvious to everyone that it can work with errors. After all, this is a new feature, unknown field, and so on.
When we talk about legacy modules, they should work correctly. Therefore, cases occur very often when a developer makes changes to the system, which he does not understand very well. The testing department catches a bug, the developer fixes it, then testing catches another bug, and so on. Or God forbid, the mistake will fall on the prod, and already the head of some department will conditionally go into the lead and say “What the fuck did you do there, nothing works for us.”
As a result, in the first case - an error, this is a valid situation. Secondly, you asshole, that you made a mistake and broke everything.
Developer with legacy systems easy to dismiss
Imagine that there is a thought that someone from the developers is not working well and needs to be fired. Lead enters the PM asks about the dismissal. The PM will say, “You have gone crazy over there, and the deadlines are already burning, if you fire Max now, we will not have time.” I’ll just tell tech diru that this is your school, and let him fuck you already. Lead thinks he will really fuck him, so he postpones this dismissal. ” And there already Max will think again, or something else will happen.
If we are talking about legacy systems, then no one will particularly stand up for such a developer. After all, if it works well, nothing just happens. If he works with errors, then he is an asshole who harms the work of other departments.
As a result, the guys who sit in such areas have a legitimate feeling that they are being fucked from all sides, they do not appreciate their work, they don’t pay extra bonuses, or they are dismissed for mistakes, or they break down and start swearing at the leaders, diras and so on. That in any case leads to dismissal.
Source: https://habr.com/ru/post/448660/
All Articles