
Ask HN: How do I stop being resentful towards other devs - resentfuldev
We are a new team of developers working on a new project. We share a git repo and we are split between product teams. We are 6 developers and we review each others code.<p>Even though all of us have a lot of experience, we came from different organizations and we have different styles. I come from a very strict team where everyone was forced to give their best, the standards were really high and the code reviews were brutal.<p>Even though I appreciate my new colleagues and I want us to have a healthy team culture, I often find myself resenting them each time I review their code.<p>I don’t think highly of myself as a developer but I find my coworkers extremely sloppy and it seems to me they focus more on narrow problems than the big picture.<p>I don’t want to be the grumpy developer that thinks he is better than everyone else but that’s what I&#x27;m becoming.
How do I stop?
======
a-dub
If you think of rigorous code reviews as brutal, you're seeing it the wrong
way. Reviews are about the code, not the people that write it, and the process
of reviewing means teaming up to make sure it will be the best it can be.

If its really sloppy, bend your boss' ear and see if they agree. If so,
develop a plan of action with your boss to get things up to standard for
everyone.

If it's sloppy and terrible and no one wants to change, find a new job.

~~~
barry0079
I wouldn't suggest going straight behind your team's back to your boss to
"Tell". That seems like a quick way to get them all to resent you. I'd try a
candid discussion first before this.

~~~
a-dub
Maybe you're right. ... but I think "telling" is also the wrong way to look at
it. It's not about who's right and who's wrong or who's the best or who should
get dinged or whatever will get people's backs up and invoke pride and
resentment among equals. There's a reason why there's a boss, they're there to
set direction where their role in doing so is clearly defined to everyone.

I suppose every team is different though.

~~~
Haydos585x2
I think most people will immediately get their back up if a team member was
going straight to their boss anytime something the team member disagreed with
was pushed to git.

Something like a style guide might help clarify points. There's also no
guarantee that what OP feels about the code is correct. They might like one
way but wasn't present for discussions or doesn't understand the work
completely. If they're running straight to a manager every time it's only
going to end poorly.

------
resenteddev
Bike shedding code style is more likely to be the narrow problem that has no
influence on the bigger picture.

I don't care how shitty your code looks, I see little risk as long as it has
well contained boundaries with system at large.

You have ownership of your module, and if you leave, and someone needs to work
on it, and cringes at how it looks, since the input/output edges are clear, it
can be thrown out at re-written to said dev's personal taste.

Focus on delivering business value and creating the best END-USER experience.

If you are focused on pretty code, you will likely be the only one patting
yourself on the back when all is said and done.

~~~
oldboyFX
> Focus on delivering business value and creating the best END-USER
> experience.

I agree 100%. For most projects clean code comes secondary.

Moreover, what is clean and what is sloppy is extremely subjective. If the
code doesn't produce too many bugs and is understandable enough for others to
modify, great. That's all you need.

From my experience, the correlation between writing clean code and delivering
business value isn't a thing. I would even go so far to say that people who
really care about writing clean code often tend to ignore business goals.
Additionally, I've worked with a few clean code/TDD enthusiasts whose output
very often contained bugs.

NOTE: This is my personal and VERY anecdotal experience from working on mostly
small to medium sized projects (up to 100k LOC).

------
CognitiveLens
Here are a couple great articles about code review that I've learned a lot
from - they address the 'social' aspect of code review specifically, which I
think is where you're having a hard time finding traction.

\- [https://blog.plaid.com/building-an-inclusive-code-review-
cul...](https://blog.plaid.com/building-an-inclusive-code-review-culture/)

\- [https://medium.freecodecamp.org/unlearning-toxic-
behaviors-i...](https://medium.freecodecamp.org/unlearning-toxic-behaviors-in-
a-code-review-culture-b7c295452a3c)

The takeaway is that it's a communication problem, and one of the first steps
is probably setting some shared expectations. As others have mentioned, if you
can't get alignment on expectations, you're not going to be happy in your job,
but hopefully there's common ground somewhere, and you can all help each other
level up technically and as a team.

------
seattle_spring
I just took a new job and I think my coworker thinks this about me. Here's the
thing though: I'm not sloppy, he just overcomplicated _everything_. Seriously,
I'd have to be fucking telepathic to write a PR that passes whatever arbitrary
level of ultra-complexity he'd expect.

Being "strict" in code reviews is not necessarily a good thing. It's great if
you're strict with regard to stability and code standards, but it's not at all
great when you reject everything because, "hey, this super specific module
should be written because MAYBE ONE DAY in 20 years it could be maybe re-used,
so you should make it ultra-generic and over complex."

------
agitator
I've experienced this in the past, which resulted in me leaving jobs because I
just couldn't take working with some people.

I eventually realized that this problem will be worse overtime as I get
smarted, more experienced, and can predict issues even more than I do now. So
the best solution I think is to maintain your rigor, don't stoop to the lower
quality work that is the norm, and choose your battles in terms of what you
call people out on, and do it in an emotionally intelligent way.

As you progress in your career, it's inevitable that more and more of your
coworkers will not be performing at your level. Accept it, and use that as an
advantage in climbing the ladder and leading teams. That awareness of
potential issues and foresight of problems in designing architectures and
prioritizing work is very valuable.

Be smart about how you use your competitive advantages, put emotion and
frustration aside, and it will have great payoffs.

------
sj3k
Be a leader and help them write better code.

And as others have mentioned; code reviews shouldnt ever be brutal. You need
to look at code reviews as a way to improve your team's performance. It
shouldn't be a roast.

~~~
TheTrotters
That’s not how I interpreted “brutal.” My impression is that the OP doesn’t
want to sweep problems under the rug and wants to be frank (even if the truth
is harsh).

------
flippant
Be patient and point at specific "sloppy" things and explain why. If your
colleagues are reasonable, eventually you'll help them up to your level.

~~~
meltonian
Agreed. This will help everyone in the long run. The less shitty code you have
that can be copied and pasted the better.

Additionally, you may want to take a step back and see if you can
implement/point to a style guide. Linters/code formatters might help with this
some of the frustration.

------
godot
I've worked at 6 companies now and maybe I'm lucky, I find that there hasn't
really been a place where programmers are objectively better at a place over
another. Oftentimes people are better at certain things over others, and
oftentimes an organization does things a certain way (if not ideal) because of
historic reasons. I would encourage keeping an open mind.

If the entire team is newly formed and you truly believe there are a lot of
flaws in others' work, then the thing to work on for yourself is that feeling
of resent. Why do you feel resentful? Realize at the end of the day you're
talking about "work". You're not being personally attacked when others write
bad code. Just make suggestions in a friendly and nice way and people will be
accepting of it. There is no need to feel resent. A true engineering leader
who is currently in your position would take this opportunity to provide
guidance for the team and take leadership in improving things, not feeling
resentful. If after attempts to improve things, they don't work out, perhaps
it's time to find another place of work.

------
johnnyRose
My advice would be to choose your battles, because you can't win them all.
There are many ways to accomplish most tasks and sometimes good enough is good
enough.

That being said, it's OK to have high standards. I've found myself in similar
situations in the past and I discovered it's helpful to look at code reviews
as a learning experience for everyone. If you find yourself reviewing truly
horrendous code, it's an opportunity for you to develop your patience,
teaching, and communication skills.

------
fit2rule
Got a formal Coding Rules document? This really helps, especially if its well-
written in a friendly tone.

If you don't - well, be prepared for a bit of a bumpy ride until your group
can formulate one. However, it has to be said that getting a formal Coding
Rules guideline is easily one of the best things you can do for team cohesion
- it takes effort, but at the end of the process it should be quite clear that
you don't own the code...

~~~
CyberFonic
This response appears to have been down-voted.

Perhaps that is a symptom that many programmers do not like following
guidelines. Which in turn leads to technical anarchy.

~~~
dasmoth
I think I'd probably phrase it as "many programmers like to feel some degree
of ownership".

See also: [https://blog.codinghorror.com/you-gotta-own-
it/](https://blog.codinghorror.com/you-gotta-own-it/)

------
k4ch0w
I think just realize everyone learns to code in different ways and
environments. Some people self teach and others learn in academia. You should
respect that they learnt to code at all. I'd say just be honest in your
reviews and help them improve. Don't be a dick about it, but honest and fair
critique is something most people will appreciate.

------
poulsbohemian
Is their sloppiness hurting you in any way? Are you concerned that you could
be blamed for their sloppiness in some way? Are you having to pick up the
slack for their problems? Does your boss express any concerns about the
quality of the team's work?

If the answer to all of these is no, then what are you concerned about?

~~~
nil_pointer
There's nothing wrong with wanting to uphold high standards. If the feedback
makes his peers better in their practices, then it's a net positive.

------
jaredcwhite
In the past I've either been able to encourage a mutual respect towards
documentation and education to help everyone on the team get on the same
page…or I've tried to exit the project at the earliest opportunity. You may
not know yet if this sloppiness you're seeing is lack of awareness or lack of
care. If the former, it's your job to help your team become aware of the
problem. If the latter…well, you're probably not going to make much headway
and may even make the problem worse (because now you're the "bad guy"). So I
would tread carefully to see if it's just a lack of awareness problem, and
then help your team work towards more documentation and education around best
practices.

------
amorphous
Welcome to the world of software engineering! See, building software is more
about people than code or technology. It is always a people problem.

Use this as an opportunity to improve your social skills. If you think your
colleagues are sloppy, find a way to reach them. Learn how to give in-
offensive feedback. That's invaluable for your career, no matter what you do.

Also, the resentment you feel towards others is likely resentment that you
feel towards yourself (as you say yourself), so that is another area you have
now the chance to use and grow.

------
andrei_says_
I recommend removing evaluative words from your vocabulary when discussing
someone’s code or work.

“You’re always late” is evaluative. Causes an argument.

“You arrived at 10:30 am, and we agreed to meet at 10.” is descriptive — it
lists observable facts.

Take a similar approach to code.

“This is sloppy” will only bring up defenses.

“I’m reading this and notice that the one or two letter variables cause me to
have to re-read the method every time to figure out what each does. Maybe we
can use more descriptive variable names, like accounts_payable instead of ap?”

------
audiometry
Read this book: [https://www.goodreads.com/book/show/27036528-ego-is-the-
enem...](https://www.goodreads.com/book/show/27036528-ego-is-the-enemy)

And then reframe the situation into some kind of an opportunity for you. You
need to figure that out, but maybes it's something like, "chance for you to
learn how to mentor/influence others" or something.

------
CyberFonic
With 6 devs, I would hope that there is an experienced team
leader/manager/CTO. It would be up to the technical lead to set and maintain
consistency and standards and lead the code reviews.

Perhaps you have a more anarchical situation, in which case it would help to
elect a leader who can maintain the respect of the others and provide firm
guidance.

------
mrdependable
Don't think of it as them weighing you down. Think of it as an opportunity to
be extra valuable to your team by sharing knowledge. Some people might need
convincing that your way is better, but if you can't clearly show them that,
then it may not be a battle worth fighting. That just means move on to the
next thing you think you could improve on.

------
tronko
Use Continous Integration tools to rate and (if it is bad quality code) reject
it.

For example, for Rails development overcommit [1] is known to be useful.

[1]
[https://github.com/brigade/overcommit](https://github.com/brigade/overcommit)

------
aussieguy1234
When you see best practices being violated, send the Devs responsible a link
to a stackoverflow question or blog post which explains why they shouldn't be
doing what they are doing. These can be found via Google and will back up what
you're saying.

~~~
gargarplex
+1, and from _One Minute Manager_ , explain the impact that their sloppiness
has on the business.

Also: If you're the smartest person in the room, find a new room. Leave.

------
bjourne
I'm a developer that thinks he is better than most. But I also think that I'm
an awesome tutor so it evens up!

------
buboard
Reading the comments here makes me glad to be a solo dev. Having to discuss my
code would ruin all the fun.

------
oldboyFX
Could you give us some context? What kind of project is it? How important is
it? Are there any hard deadlines?

------
pasbesoin
I've found experiencing such "negative" emotions to be a sign to me that
things need to change.

The emotions are "healthy", in that regard. What isn't healthy, is when they
are not followed by positive change, most often including my taking action to
effect that change.

(Resent them. Hate myself. Sound familiar?)

In this case, it's reading to me like your larger dev environment is
substandard if not defective. Not that that's all that unusual, but you're in
a position to perceive it and to understand (from and in terms of your
perspective and experience) why.

Either that environment needs to change; is there some way you can
successfully build such an initiative in your current environment? Not a
"rogue" operation, but something that will be endorsed and reflect positively
upon you in terms of your standing and security.

Or, you need to change your environment?

Unfortunately, these days and in tech, being "older" is often a significant
barrier to the latter.

Anyway, speaking from experience: Don't let the negative emotions, unresolved,
end up consuming you -- while their cause goes or go on their merry way,
oblivious and skating by on larger life's externalization of longer-term
damages.

\--

P.S. I reread more closely. Smaller team. You are all "experienced". Maybe
their approach reflects different experiences, expectations, even just
personalities.

Nonetheless, don't let your negative emotions consume you.

In addition, or as an adjustment to what I said above, make sure you have
enough of a life outside of work. Take care of yourself.

It is not your job (heh!) to fix every deficiency (real or perceived) of your
co-workers.

Become more of an observer, and observe whether and how their behavior works
out -- for them and/or overall.

And start looking for the door you'll eventually use, if it doesn't. Having an
out might take off some of the pressure you're feeling, personally.

Best wishes!

And, maybe you'll actually come to perceive a development environment that
works while being less "brutal". I'm not taking their side. Just saying, you
never know.

I used to be very "strict" about "protecting" myself. Drugs are bad,
yadayadayada. I'm still no fan of excess, but I look around me and see that
the people who were more relaxed and less worried about such things, seem to
have ended up happier and even sometimes more successful in life. Then again,
a few of them nose-dived or ended up assholes.

On balance, though, I wish I hadn't been wound so tight, when I was young.
I've paid a price for that.

At the same time, I still get quite frustrated by sloppy work that imposes
upon co-workers and customers to compensate for its deficiency. Whereas I
actually enjoy problem solving and doing things well.

------
aidenn0
> I don’t think highly of myself as a developer but I find my coworkers
> extremely sloppy and it seems to me they focus more on narrow problems than
> the big picture.

Without knowing the full context I can't say who is right or wrong here.
Sometimes sloppy code that focuses on narrow problems is the right solution!
In some cases, good can be the enemy of good enough. From a business point of
view, code should be just good enough to get people to throw money at you, and
no better.

I'll be honest and say that writing the last paragraph left a bad taste in my
mouth; it's clearly a bit of an exaggeration, but I put it down to make the
point that it is obvious that there is _some_ point at which effort spent
working to make the code better is wasted effort, and carries opportunity
costs that are detrimental to the goals of the project. Obviously the reverse
is true as well.

Absent any other knowledge, I suspect the optimal point is somewhere between
what you would like and what your colleagues would like.

For each specific gripe you have that you see happening regularly, consider:
is this detrimental to the goals of the project, or is it something that is
merely unpleasant for me to deal with. When doing this calculus, remember that
short-term progress can be required for long-term survival (e.g. if you go
bankrupt before shipping anything, it doesn't matter how good the would have
been).

If the list of things that are not harmful to the projects survival but
distasteful to you is particularly long, you'll probably want to find a new
project to work on.

Finally a template for bringing up these concerns in some sort of team meeting
(or with the team-lead if you have one, with a team of 6 you might):

1\. I have a concern about [specific pattern X] I've seen in code reviews
because it will impact our ability to achieve [project goal Y] due to [reason
Z].

2\. A solution that worked on my previous team was [solution S].

3\. Do you think we could adapt [solution S] to work for this team?

The nice thing about this template is that nothing is labeled as "bad" but
rather things are couched in terms of what are (hopefully) common goals. There
is no implication that you are superior to others (as long as you aren't
patronizing in your delivery). There is plenty of room for them to disagree.
The main gate is item #1. If you and them almost always disagree at this
point, then this is a bad team fit. If they agree on that point, then even if
they hate your solution, you've started a conversation about how to fix the
problem, which is probably more important that adopting the specific solution
you had in mind.

Oh, how _not_ to use this template (just in case it wasn't obvious):

"I have a concern that everybody except me is writing shitty code. On my
previous team we solved this by actually caring about code quality, do you
think we could adapt that to our current project?"

Which follows the template but misses the point completely...

------
akulbe
Wow. Why was this flagged? Can someone not come here, be honest and candid,
and ask for help with something they're recognizing as a problem?

I hope whoever felt the need to flag this gets treated better if they're ever
in need of help.

~~~
sgillen
Is the flag always a message of “I think this should be taken down”. Maybe the
person who flagged it was thinking “this has the potential to get toxic
quickly, definitely something to monitor”...

Just playing devils advocate here.

~~~
akulbe
Good question. I'm not sure.

~~~
rl3
Or it was just a mobile user who unwittingly fat-fingered the link, or perhaps
lost signal. Accidental flags are surprisingly easy to do.

