Some things I've learned about code quality in organizations where the quality is terrible:
1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer.
2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? They can't tell. They will usually default to seniority (meaning how long a developer has been with an org, not how good they are).
3. These organizations reward fires that are put out. They do not reward fires that were prevented from happening in the first place. Those "senior" developers will frequently be rewarded for putting out fires they caused.
4. If you do a lot of work that prevents fires and that means you weren't working on features or bugfixes, you are going to get punished, not rewarded because to the people above you it looked like you were doing nothing.
5. If you're going to do this kind of work, you need serious intrinsic motivation.
I would add that management will gladly save an hour now, even if it costs 10 hours down the road.
I'm getting really tired of the message from management of "Here's what we should do, here's why we should do it, and here's why we won't."
In other words, they will periodically acknowledge that there are systemic and cultural problems that seriously need to be addressed, but consistently fail to address them.
In general I agree with your points. But you seem to have some gripes with "senior" engineers. I think if you left that out your points would be better. In the end it comes down to management not understanding the work and rewarding unproductive behavior. This has nothing to do with "junior" or "senior."
While I haven't personally worked at such a company, I've observed some "toxic" workplaces and found that typically it is, in fact, the senior staff who are the biggest part of the problem.
Only certain types of people achieve seniority in a toxic organization, and they are typically those who (deliberately or incidentally) benefit from the culture that everyone else hates. They build a clique and try to build influence while the new hires -- who actually care about doing things well -- turn over every 3 months.
This is all anecdotal, of course, but I do think that in an engineering-hostile organization, the senior staff should typically take the brunt of the blame (just as in a successful organization they would take the lion's share of the credit).
It's not seniority per se (I count as senior), it's people with long tenure. If, as a developer, you've had a long tenure in an organization with bad code that's usually a bad sign.
I like this list. What I have found about point #4 is that even teams that try to actually measure performance in a meaningful way will miss things.
If the quality of the software is slowing down feature releases, causing fires but is not being measured, you can make some headway with presenting ways to measure code quality so that your work shows up on their radar. This is difficult with such a subjective word as "quality" but tracking number of fires of time would be a good way to show that the way you develop is better than other people.
The other thing that companies miss are employees that help other employees in a mentoring sort of way. These people essentially cast a buff on everyone they work with. These buffs can be in the form of better tools, improved workflows, recommending reading material, new technologies etc. Unfortunately it seems this is up to that person's superior to recognize their value and fend for that person to upper management. I feel like it's easy for me to identify peers that cast buffs but not sure how easy it would be for a manager to identify such characters.
In general the companies that don't both A) pay better and B) are located in tech hubs / do remote work. So, go for more money, prefer remote or in a tech hub.
You can also ask during interview about the coding experience of the manager you will report to. Usually they are up front about it. If you turn them down, do us all a favour and let the company know that was why (more coding managers and fewer MBAs please!).
I'm not gonna lie, it's not going to be possible for everybody to avoid this kind of company, especially in the more backwater places. I left Singapore because I basically found one company that didn't obviously follow that pattern. They frustrated me too for other reasons so I didn't take their offer.
I think that this is one of the most underrated reasons for the formation of technology hubs and one reason why Singapore, in spite of really trying to become a "silicon valley of asia" (VC money: check, money pumped into education: check, huge startup grants: check) just won't, and will bleed rather than attract talent.
> You can also ask during interview about the coding experience of the manager you will report to.
Yes, for tech leadership. No for people management.
Simply put, too many people in people management positions who were "technical" x years ago.
This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.
>Yes, for tech leadership. No for people management.
A good tech leader can handle people management too. A good "people management" leader can't handle tech. You want both.
>Simply put, too many people in people management positions who were "technical" x years ago. This leads to them making technical decisions that their team should be making, which they absolutely should not be doing.
Good tech managers will trust the judgement of their team and know when to give them agency and when to overrule them (there are sometimes legit reasons to do it).
Happy productive teams are teams which have a tech lead making tech choices (& involving team to some extent), with the people management side taken care of by a (dedicated) people manager who can cut across multiple teams ( & also taking care of the people management of the tech lead)
1. The problem starts with culture. These organizations are run top-down by people who don't understand coding. Sometimes they are ex-engineers, but that's usually about as good as non-engineer.
2. These organizations are systemically incapable of determining good work from bad. Who on the team is performing and who isn't? They can't tell. They will usually default to seniority (meaning how long a developer has been with an org, not how good they are).
3. These organizations reward fires that are put out. They do not reward fires that were prevented from happening in the first place. Those "senior" developers will frequently be rewarded for putting out fires they caused.
4. If you do a lot of work that prevents fires and that means you weren't working on features or bugfixes, you are going to get punished, not rewarded because to the people above you it looked like you were doing nothing.
5. If you're going to do this kind of work, you need serious intrinsic motivation.