Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Dealing with newcomers' arrogance?
30 points by brianaluv 6 days ago | hide | past | web | favorite | 43 comments
I've been working(as a developer) on a software development project for quite a long time now. During this time, the team has changed a lot (a lot of people left, others arrived). Two coworkers and me are the oldest members of the team.

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?

I've been coding for almost 30 years for startups to fortune 50 companies and they all have code bases with some level of messiness, f*'d up-ness. What an intro the real world when during a college internship for the bluest of blue companies I saw all manner of goto/macro/spaghetti contortions in a flagship product. If it were me I wouldn't let these guys comments bother me. If I had to say something I'd say "Awesome observations guys, you're so right .. WOW! I had no idea we have all this technical debt you're finding, THANKS! .. How long do you think it will take you to find all the rest of the bad code and FIX IT ALL.. Can you give me an estimate by the end of the week??" That should shut it down.

I've often said that complaining about something is a waste of good oxygen unless you have a plan on fixing it or changing it. Or at least have thought of a way to make things better

When you’re starting to have craftsmanship, taste, a sense of quality, whatever you want to call it, being surrounded by what you can now recognize as bad work is distressing. Especially when no one else is even acknowledging it.

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.

I understand what you mean. However, I said earlier that I have no problem with improving poorly written code. But I also said that I spent enough time on this particular project to know that some problems that existed before (and no longer exist today), prevented us from writing clean code and were not related to the quality of the developers (some of whom are making fun of today). In other words, the problem is not that the old developers didn't know how to produce good quality code, it's that they didn't always have the possibility. Come on, do you all work on projects where everything runs as smooth as you want?

>> 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...

The surest way to reduce the amount of such derision is by making people responsible for fixing the things they criticize, at the team culture level. It's fun to have a laugh at the expense of someone who's no longer on the team, it's much less fun if you then have to spend weeks or months of your own time to fix it, with the possibility of still producing shit for the same reasons why the original code wasn't too hot.

That's nice, but it wouldn't work all the time. Sometimes the reasons for bad code no longer apply, and the code in question doesn't get updated because there are higher priorities.

>> and the code in question doesn't get updated because there are higher priorities

Well, 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.

You lost me.

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.

No, to "threaten" anyone in a professional context is a noob move, it doesn't work. You (or your boss if you're not a manager) just say something to the effect of: "on this team, if you don't like something, you don't just criticize, you go ahead and fix it". Basically, make empty bitching, moaning, and derision, socially unacceptable, and cultivate the sense of ownership. If nobody owns problems, they don't get fixed.

That's exactly what it is. Does the fact that I have succeeded in doing a task better than another person (knowing above all that the context is not the same) give me the right to ridicule or criticize him/her beyond necessary? That's why I think the strategy suggested by m0zg may have limits... But again, this is the first time I'm confronted with this situation, so I don't really know.

Well and the old ugly code is known to work properly.

It will get old very quickly - they will soon realize that there are much better vacancies with better offers and move on. And author of this question will stay... bound by his insecurity of his unprofessionalism.

Well, that's one way to solve this problem. Replace them with folks who are prepared to own the problems and follow through with the solutions. Simply bitching about something and not doing anything about it has negative value to the team, hence the OP's question.

What makes you say that the newcomers aren't doing anything about it? The OP didn't say anything about it one way or the other.

At least where I am, we are both fixing the bad code and sharing unkind thoughts about its origin.

>>And author of this question will stay... bound by his insecurity of his unprofessionalism.

Could you elaborate?

I can't really understand what is the problem and why this has to be discussed. Coders suddenly don't write bad code because they are out of time - they write bad code because they can't write good code and they are out of time to learn how to write a good code.

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?

Why do you read "insecurity" in this situation? I don't read that at all. If anything it's the newcomers that are insecure - that's why they're putting down the people who wrote the code in the first place. In all likelihood they don't fully understand it (just because code is harder to read than it is to write), so the inclination is to excuse their own lack of progress by shitting on people who aren't there anymore and chalking it up to "bad codebase".

If anyone then author feels bad about the situation. Two colegues of author seems to have no voiced opinion on this situation. The only one who is making fuss about this situation is OP. Besides - your point is applyable to OP, because he/she is currently the only one who is in your own words "shitting" on people who are not present in this situation. How about hearing other side? All I read is that op has no power over these matters. Yeah, op can stomp feet on the ground and gain result what op desires... eventually that would lead to the hasty leave of newcommers(and maybe even some older collegues, too) or op will have to resign or be asked to leave. That's why it is imperative for op to sort these things out by herself/himself - what is the further goal of this communication. Is op justified to name newcommers arrogant - as maybe it is op who has not been out and has no idea about their background and experience.

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.

PS If there is bad code, there should be no excuses not to improve it. Code that is not fixed means more bugs, that are created because other people are not aware of these "features". FFS, if the bad code is the only thing that newcommers are laughing about - just fix it and carry on. Fixing others is completelly different problem.

I think this post deserves a more serious response than it's gotten so far and I fear it won't get the response it deserves. I think part of the reason for that is the nature of programming, because it requires a degree of precision and correctness that most social spaces don't. But I think that attracts a lack of social consideration that is unfortunate.

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.

>> To the author, I've experienced this from both sides,

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.

I hear two major problems in this story:

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.

Working with arrogant people is a bummer. I have very little patience for people who know more than they do, and people who take opportunities to tear down rather than educate.

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.

I've had a teammate like this. Very smart, very young, had the strong opinions of a senior with the actual experience, narrow-mindedness, and general attitude of an unprofessional junior. He got moved out of one team, then was just as bad on the next one, and eventually left. By the end I stopped trying to debate with him and his toxic attitudes toward other people's code because I decided someone like that isn't worth the energy. Hopefully he'll find a better fit at his new company.

Great interview question:

“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.

This is absolutely what you want, but any reasonable interviewee will respond with the answer that seems most likely to lead to an offer.

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.

Yes, partisan said it much better.

Where I work we routinely openly disparage each other's skills and work ethic, but keep it jovial without any serious personal attacks or ganging up on one person. Criticism is never taken personally, and you build a culture of friendly competition, and nobody is ever afraid to tell anybody else that their code sucks because everybody has shitty code somewhere, took a short cut to meet a deadline, made a mistake, etc.

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 suspect that this actually is an enjoyable environment, despite how it reads. I also suspect it is a very successful team. It likely has little diversity in employees. I've been on these teams before, and had a lot of fun in a sea of persons who all have the same cultural and educational background.

This usually works until teams get large, or start to grow diversity

That environment sounds horrible. Something similar is going on where I work now and it's really discouraging and negative.

Some people love it. I had an uncle who was like that with his coworkers in construction; constantly teasing and criticising (and coworkers giving the same right back). Many people would think they were fighting, but they were the best of friends and enjoyed the repartee.

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.

True, on paper sounds horrible but it's not done in any kind of vindictive bullying manner or in a jock locker room way. New hires feel more confident communicating instead of panicking and not telling anybody. Code quality attacks like OP described don't come off as personal, so nobody is silently seething because they've been offended. It eliminated all bs notions about work place 'teams' when in reality we're competing with each other every day for more recognition, bonuses, promotions. Everywhere else I worked people did this anyway but behind other's backs, which to me is truly negative and a shitty dysfunctional work environment. The latest new hire said this was the only office where there was no anxiety of coming to work because fucking up wasn't the end of the world anymore.

Regularly on Ask HN questions about "What is best practice when I join a new team?" top advice is not to criticize existing systems, not plan to rewrite them in $newlanguage and assume there's a reason it was built like that. Low budget, short deadlines certainly is a good reason. So is bad specs, constant changing specs, or maybe $language or $framework just didn't have the features back then.

Is that a problem of yours? If it is your code - either deal with it and fix it or assign someone else.

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.

Well, would it make any difference if it was my code? It doesn't matter to me. I certainly produced some low quality code here and there. So what? I don't mind correcting it or having it corrected. But I am a human being and as such, I try to treat those with whom I work (or have worked) as I would like to be treated. Which excludes making fun of them or ridiculing them.

As for my salary, I'm not complaining about it either. Also, I'm not a dinosaur like you seem to think.

Look at it from their perspective: some people left a bunch of nasty messes that they will eventually have to spend time and effort to clean up without providing any good explanation of why the messes were there. Naturally, they assume Hanlon's Razor applies and they are venting about it.

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.

I'm not defending poor quality code. I'm looking for a way to avoid someone being insulted because they've written bad code. That's all. Do you ridicule or insult your current colleagues because they have written bad code? If you don't, why would you do it for the people who were on the project before you?

The last guy I worked with who often would call people 'idiots' and far, far, worse (Ironically, he was over 60) was fired for his crap attitude.

There is value in correcting bad code. There is only toxicity in insulting those who went before you.

Two things.

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?

>> One, there is no excuse for garbage code. Deadlines don't cause people to suddenly forget how to code.

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?

This isn’t true if you’ve been in a situation where execs are pushing hard to meet a deadline. Corners need to be cut or dates need pushing back, you can’t do both in most cases.

1. Have you talked to your "old" coworkers if they share your feelings. Maybe you can learn something from their perspective... 2. Judging from your username you might be a lady. I have been working as a single male coder in company of other 3 female coders. I just can't get through my mind that they would forgive me if I was leaving crappy code for them to deal with that later... that would be very unprofessionally for them to make excuses about my bad job!!! 3. Let's be more precise about your complaint- there is no way for new people to mock people they do not know and have not seen - but they can comment about code... that you or other 2 gentlemen might be responsible... just take these things with grain of salt. Admit your mistakes - better yet: LEARN FROM THEM and move on. What you are looking right now is not healthy for you. 4. Other Solution doesn't exist, because you are either not in control of company and can't change things globally or unable to move to better workplace or unable to grasp that your solution is not viable. The good thing is that you have found the problem, but are you sure that solution that you have in mind is the right one? Moralizing about behavior of others is not healthy - your morals will differ with that what other people have. New people will bound together by your oppression and you will not be able to even understand your failure.

this is unnecessary drivel

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact