Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do I stop being resentful towards other devs
91 points by resentfuldev 6 months ago | hide | past | web | favorite | 41 comments
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.

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.

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.

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.

I don’t want to be the grumpy developer that thinks he is better than everyone else but that’s what I'm becoming. How do I stop?




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.


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.


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.


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.


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.


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


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://medium.freecodecamp.org/unlearning-toxic-behaviors-i...

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.


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


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.


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.


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


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.


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.


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.


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.


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


Formalizing expectations is the best way to get everyone on board. My team relies on custom linting rules to act as that coding rules doc and builds the checks into the deployment pipeline so your build won't succeed if you have poorly formatted code. It doesn't catch everything, but it makes you more aware while writing code and gives a baseline minimum for standards.

Also, there is a way to provide constructive feedback without attacking the person behind the keyboard or phrasing it as 'you're wrong, make it right'.

The best reviewer on my team takes the time to point out where the 'big picture flaws' are, but phrases it in a way of 'this works, but here's why it won't work later on, and why you should consider fixing it now, just my 2c', rather than 'you're dumb if you think this is acceptable'.


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.


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/


And automate listing of these rules!


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.


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?


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.


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.


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.


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


Read this book: https://www.goodreads.com/book/show/27036528-ego-is-the-enem...

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.


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.


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.


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


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.


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


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!


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


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


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.


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


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.


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.


Good question. I'm not sure.


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




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

Search: