Recently, I've been annoyed by the behavior of the majority of the developers on the project (those who are new compared to how long I've been on the project). Whenever they see something wrong in the codebase developed by former team members, like poor quality code or simply a defect, they laugh about it, making fun of the developer who wrote "such bad code"(without even knowing the developer in question or the context that caused him/her to write such bad code). Now, I've been long enough on the project to know that many reasons can explain poor quality code (like short deadlines, low budget, etc...), and the quality of the developer is not always one of these.
Of course poor quality code should be pointed out, showed to people to learn what not to do or what is a better way of doing things. But It should not be used to make fun of people or humiliate them, especially when the people mocking others do not even write "triple-A" code. What also bothers me is that, the two other oldest members of the team don't say anything about that behavior. And that's why I'm asking if I should say anything or just let it go? Am I wrong feeling the way I feel? What would be the better way of telling it to the whole team? What would you do in my position?
Is this the kind of person I am? Is this the kind of team I belong on? Where shit like this is treated as normal and passes without comment?
It’s a powerful anxiety. Speaking it out loud is a natural step, and it’s easy to see why people reach for it. Suppressing or forgetting about it is also an option, but people tend to correctly recognize that they’ll die a little inside by doing that.
It takes experience and maturity to find productive ways of channeling that feeling. People don’t always get there right away. If you think you have, model it. Show healthy ways of dealing with the “holy shit this is garbage” feeling.
If you really need people to swim in shit uncomplainingly, then either a) hire junior people who can’t even tell what’s wrong with it or b) expect to pay a premium for senior talent knowingly specializing in that niche. Your team might just not be a fit for people who want to do good work.
To the author, I've experienced this from both sides, and I want to say that it can be very hurtful to receive criticism that goes beyond the work and feels directed personally. It can feel isolating and ostracizing. That said, I want to encourage you to try to distance your sense of self from your prior work. I know that can be difficult.
It can be hurtful to hear that your work is "bad", you might even disagree that it's bad. As long as those comments are focused on the quality of the work and not the quality of the person who wrote it, that's a discussion that can be productive even if it's exceedingly inconsiderate. That work isn't you. If you're ready to acknowledge that it was compromised by certain constraints, you can find ways to value the drive to improve it as new minds with a different set of constraints come in.
We all have an opportunity to learn. For those of us maintaining debt-ridden code, we can welcome improvements, however gradual or wholesale, as they're introduced. For those of us walking into what seem like trap doors and quagmires, we can welcome opportunities to be more aware of the stress and effort put in by the people who came before us.
Software can always be more correct and more precise and more forgiving and any number of values we might search for in our engineering pursuits. Software engineers can always be more kind and more compassionate and more caring.
1) Mocking prior developers - there is nothing wrong with calling out bad code. But it should be done respectfully. We all write bad code every day. If you are not looking at your own old code and seeing how it could be better, then you are not growing as a developer. Having a discussion with the team about respect around code quality sounds like a good idea.
2) You need to accept that the team has changed. The guy who has been around the longest can often turn into a grumpy old man nostalgic for ye olden days. It might be a good time to look at the good that the new developers bring, appreciate them, and try to adapt to the new reality.
Between those two things, you can probably find a balance where they stop the negative behavior, and you seek out the positive, and you all come together as a team.
This sort of behavior is bad for teams and bad for culture. Distributing the responsibility of code is a possible strategy.
More pairs programming, will force people to work together, and remind everyone that no individual is really that smart.
Incorporating mentoring responsibilities into employees work, is another way to distribute responsibility.
Rotating job descriptions was a strategy used at qumulo. If you were hired on as a SWE, you would be rotated to different teams every few months in order to increase your understanding of entire code base. Bakes diversity comparable to your employee diversity into the code base.
At Isilon pairs programming was used during code reviews, and reviewers were often held responsible to later fixes.
Flat teams are used at Galois, Grammatech (Research), Steam, and JPL (Research).
Many remote-first companies require all comments to be made in the ticket. This forces people to explain their concerns in writing. "Is dumb" is not an actionable critique.
Ideally arrogance should be filtered prior to hiring, but if you have a lot of it in the company, its worth asking why and how to grow those people toward cooperative thinking.
If the person you are hiring believe they are "the smartest person in the room" then their growth is dependent on them not being in that room. Firing brilliant people is a wonderful past-time.
“When you come across poorly written code, do you think:
1. ‘Wow this guy was an idiot or lazy.’
2. ‘Maybe this code looks bad but the author probably wasn’t an idiot. It was probably reasonable solution at the time.’
The 2nd answer is the one of wisdom. Ask the interviewee to expand on this so you can tell if they really believe it.
In your situation I would've said to the new devs they should be more worried about screwing up my lunch order being so new, and claimed I wrote the terrible code myself instead of selling out the old devs, and that they need to pick up the pace and step up if they want to compete with my 10x skills pushing working product out the door. I would've also nicknamed the loudest critic 'Triple A' from there on in too just like how they nicknamed me when I started and took forever to finish anything.
I've usually heard these stories from older coworkers who were telling horror stories of past times - usually that involves low salary, terrible working conditions, etc. not a thing even older coworkers wants to remember without a shudder. Bad code always comes with bad salary, rushed code and other disasters. And no one - even old coworkers want to do anything with that bad code and it will be tormenting older coworkers for years. Sometimes it is a relief that someone is so eager to deal with that stuff that no one else wants to deal anymore.
PS Change your attitude. Have a laugh and carry on... or go where your older and smarter colegues have went already.
The most you should do is explain what the reasons were for the bad code at the time, if you know them, and also explain why it can't be fixed right now, if there are any good reasons for it. There is nothing that you can say to defend bad code itself; it is, by definition, bad. Doing so will only give the rest of the team the wrong impression about you.
There is value in correcting bad code. There is only toxicity in insulting those who went before you.
One, there is no excuse for garbage code. Deadlines don't cause people to suddenly forget how to code. Perhaps corners get cut and things need to be refactored but if developers are coming and going and saying the code is bad I doubt that's just because of a deadline. That sounds more like a bad developer using a deadline as his excuse.
Two, do you have code reviews? Are you looking at their code? Are they looking at yours? Why would you expect them to write triple A code when they have to use what you say is a garbage code base? Garbage code breeds garbage code. Maybe their arrogance is a way of venting their frustration with being forced to write bad code? Or maybe they're telling the truth but for some reason you interprit it as arrogance?