Ask HN: Dealing with newcomers' arrogance?
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?
45 comments
[ 2.8 ms ] story [ 93.2 ms ] threadWell, don't criticize then unless you want to own it. There's a variation of this advice wrt communicating with your boss, which is blindingly obvious to anyone who's ever been a manager, but rarely obvious to the subordinate: don't come to me with problems. Any idiot can do that, and many do. Come to me with solutions, or at the very least a proposal on how to solve problems that you're prepared to follow through on. This is basically the surest way to advance your career on any team, yet people just don't do it. Nobody likes the complainer, everyone, especially managers, likes the problem solver.
The question was how to deal with newcomers' arrogance, and your suggestion is to have them try and fix things to find out why it needed a bad solution.
What I tried to reply to you is that they may have no problems fixing the bad code because the reason for it to be bad may be gone.
Now, if I understand correctly, your reply to that is to "threaten" them with having to fix it? The point of my comment was that they'll have no problem in fixing it and they'll keep being arrogant because they'll "prove" that there was no reason for it to be bad.
EDIT: s/shitty/bad/. I meant no offense to anyone.
Could you elaborate?
I would hire someone who would boast how he or she wrote excellent code in tight schedule. Because I've done that. And I have seen plenty of bad code and people who were making that code and could not improve even after a considerable time, because they were morons.
Laughing about them is best thing you can do - worse if you have to cry, because they are still there. There are no good ways to deal with this type of bad coding if your company do not have laid foundation of good coding practices and don't follow them.
Professionalism IMO means not only knowing how to code but also work experience on different working environments to understand the difference between good and bad workplaces and predict where things will go south(or great). The things you have described doesn't sound appealing to me - that would not motivate me to code or do anything. And it seems that your coworkers who moved on made a professionally better choice compared to you that is hurt by someone laughing at how things were done before.
Just think about this in different light: new people are looking at you amicable - because criticism that they are making is friendly gesture. Your intentions on crushing this behavior is based in your insecurity. So, are you going to change them all... Again, question from dino - Why do you think that they have to change and not you?
I had a laugh about code - about others and mine. Like I mentioned before - these things can be only changed by changing culture of a company(or by finding a company that does have good coding standarts) and that starts by showing example of how to behave - including attitude towards importance of writing good code. If company has no such foundation and it has created environment for bad coders, then smart coders will initially nervously laugh and seeing that nothing changes will leave. Telling them to consider circumstances of bad code writing sends completelly wrong message. Pardon my expression but that is f*cked up thinking. And I am giving a very friendly advice to sort op's head first and think critically about herself/himself at first, if you and others seems to boldly rush to "help". Because all I read right now is that op thinks that op is justified to do something about others and not apply this attitude towards oneself.
Think about it this way - customers will not laugh at bad code - they will be angry, frustrated and will damage company in the end. Are you really ready to accept EA and Bethesdas blunders because you do not know circumstances of the past? Lol - this is exactly what op is asking to consider. Bad code is a very serious matter - and forcing someone not to laugh at it is great way for a company to go down. You know what - I am all for that selfish workers like op bring down bad companies by implementing more and more absurd ideas... this seems to be working just fiiine in the end.
At least where I am, we are both fixing the bad code and sharing unkind thoughts about its origin.
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.
As for my salary, I'm not complaining about it either. Also, I'm not a dinosaur like you seem to think.
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.
>> 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 I knew, I wouldn't have asked the question.
But your answer makes me think that the term "arrogance" I used in the title of my question may be too strong...I dunno...
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?
Come on, really? I just gave one or two examples to illustrate my point! And they are valid examples (you even partially admitted that in your comment). Also, if you read the discussion, another user gave other reasons that can explain a bad code base.
>> 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? Should I even comment on this? really?
Also, did I even say or imply that the whole codebase is garbage or something?
There is value in correcting bad code. There is only toxicity in insulting those who went before you.
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.
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.
So do I. And it's true that it can sometimes be difficult to admit that I didn't write very good code. But I always think that what needs to be done must be done. That is why I agree to change my code or don't mind having it changed by someone else when I am shown that it is not correct or that it can be improved. In fact, my question has little to do with technology. It's just human relations advice in a workspace I'm looking for, and you seem to have understood it better than others.
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.
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.
Some might call it toxic, and it wouldn't be allowed in a corporate environment today, but clearly no environment will please everyone. For them, it was good.
This usually works until teams get large, or start to grow diversity
“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.
Instead, ask them about their experiences with legacy code. Not poorly written code, just "legacy". Talk through it with them, their changes, how they planned for them, how they dealt with the code.
This will tell you more than asking a softball question.
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.