
Ask HN: Dealing with newcomers' arrogance? - brianaluv
I&#x27;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.<p>Recently, I&#x27;ve been annoyed by the behavior of the majority of the developers on the project (those who are new compared to how long I&#x27;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 &quot;such bad code&quot;(without even knowing the developer in question or the context that caused him&#x2F;her to write such bad code).
Now, I&#x27;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.<p>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 &quot;triple-A&quot; code.
What also bothers me is that, the two other oldest members of the team don&#x27;t say anything about that behavior. And that&#x27;s why I&#x27;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?
======
f2000
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.

~~~
tcbasche
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
brianaluv
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?

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

------
pizzaparty2
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?

~~~
brianaluv
>> 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?

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

~~~
probinso
this is unnecessary drivel

