Ask HN: How do you deal with varying levels of competency in your team?

Radical Acceptance.

There will always be different skills levels. As much as the people on the lower end of the spectrum need to raise their own level, those at the top end of the spectrum need to accept that not everyone will be at their level.

You need to really think about choosing your battles. Are the concerns with their work truly having a negative impact on the goals of the business? Or are they just not matching your personal style and preferences? Can the imperfections in the code be cleaned up down the road as tech debt while using that effort as an opportunity to teach? Or is the current PR truly the correct time to invoke change?

Sometimes the PR is the right time. If they are bringing in complexity that will slow down the teams ability to update the code, that needs to be fixed. When doing so, approach it as a teaching/mentoring moment, not a time to slap them on the wrist for not being you. But if we're talking about suboptimal naming, or arguing over colors... let those things go and mentor them over time. But keep notes - you do want to go back and improve the elegance in the codebase as you have time. (And if you never have time, your leadership needs guidance, not the junior devs.)

I constantly see things done by more junior team members that I would have done differently. 3 out of 5 times, I let it go and know that I'll refactor it when I next touch that code, but if it works, then it works. For the other two times, one is when it does need an immediate change and I'll call it out as such in the PR. The last is when their idea is better than mine. Junior devs are just junior, not stupid. Sometimes their new view on the world is refreshing and good, so be open to that.

The junior devs make mistakes. The PR should be a platform for learning from the senior. Therefore I don't understand what lesson is the junior supposed take from this action:

> I let it go and know that I'll refactor it when I next touch that code

You accept it and then you rewrite it. Simple but as a dev, I would feel let down by the fact that my work was just temporary. This would make me bitter not more experienced. Also, I didn't learn what was the problem so the same situation make repeat.

If you discussed your opinions talk with the PR authors, then it's them who should rewrite the code, not somebody else.

Do you agree with this?

> upwards of 75% of the time I see better ways to do something. It's often small things, like making what's being build more configurable / hard coding less, abstracting differently so code is more reusable, naming things better, organising the code in a more logical way, etc. Other times I simply don't agree with the change because it adds complexity with little benefit.

Are there general rules about this that your colleagues can learn from (and are learning from), so that their PRs will improve over time?

And are these general rules documented somewhere in a coding standards document, so that less experienced developers can refer to it?

Or are the "better ways" you see of doing something different from case to case?

If you cannot write down general rules that can be put in an agreed-upon coding standards document, then it's possible you are not as good a developer as you think you are, and that you may not be good to work with either.

> You know those requests, "could we make this button green with larger text in this one specific place"? My answer to these requests are typically, no, because unless it's extremely important it's just adding complexity and making thins harder to maintain down the road.

Is your codebase so brittle that you can change the format of a button without "adding complexity and making things harder to maintain"? Or are you being a control freak about minor stuff?

I used to work for a company that had a few developers who were full of themselves, and nitpicked at every PR, often being given contradictory changes between PRs and even told that "I know it when I see it" when confronted about this. They were so obsessed with making code that was clean and easy to maintain, but the codebase was an insecure and inconsistent mess, and they painted themselves into corners that made bug fixes or refactoring difficult. It was a toxic place to work, with a significant turnover of developers.

>As I've become more senior I've struggled more with working with less experienced (and in some cases maybe less talented?) devs.

There should be no struggle at all. Dale Carnegie is already looking in.

>A lot of things we do as developers are quite easy to build in one way or another. The majority of complexity I find is in how you build something so it's easy to maintain, test and extend. It's also important not to overcomplicate things, of course, but there's a balance between building something very specific and building something with reasonable assumptions for how it might be used or changed in the future.

KISS principle. You learnt to do this through experience of opps I screwed up moments. The juniors are too going to screw it up and learn through experience and eventually become you. #cycleofopps

>You know those requests, "could we make this button green with larger text in this one specific place"? My answer to these requests are typically, no

No? The answer should be yes here but that's a different issue.

>I hate feeling like I'm blocking people and being a nuance. I try to communicate why I have a certain opinion and try to welcome feedback, but it's draining honestly. And if I don't do this then I have to watch what I build become an unmaintainable mess. It feels a fight against entropy because there's only so much I can do.

If you hate the feeling, your subconscious is tell you to stop doing it. Why is that? You may want to stop.

>Does anyone struggle with this? I suppose to explain the problem in a more succinct way, if you're in the top 5% of devs, 95% of devs by definition are doing things less competently to yourself and you either just accept that or try to micro manage every change made. Neither is ideal and the quality of the overall codebase tends to trend to the lowest common denominator of ability.

I'm certainly not top 5% of devs. You'll never see me micro managing changes.

I worked in a team of one senior and several juniors (university students at that time, I was one of them). The senior was a guy that had been programming a one-man-show project for several years and then needed help. In this setup, the guy was respected by all devs and he cared for the product, meaning that he wouldn't accept anything. Also, it's important to say that this senior guy was the one who hired all the others, therefore he had already pre-filtered the less skilled.

However, the risk of being swarmed by PRs was there anyway. We did the following things that lead to the improvement of juniors without significantly compromising the quality of the code. - We had an initial meeting where we agreed upon all the general rules and established a baseline for PR quality. (rrwo mentions such general rules in his comment) - PR had two levels of code review. The first round was reviewed by a fellow junior dev who was to review it thoroughly. This round was focused more and code smells and easy-to-spot bugs. Note that all the code review comments should have a relationship to the baseline we had already established so it wasn't just opinions. The second round was done by the senior himself who made sure that the design and complexity is correct.

This way, the juniors learned from the seniors and from themselves. Ultimately, - we improved ourselves in giving code review - the gaps between juniors' skills shrunk - senior still had the final say

On top of that, you can collect some contentious decisions and have a discussion about them, and incorporate it into the baseline.

I see better ways to do something.

As you become more senior, "better" is more and more measured in terms of business value.

Creating friction for coworkers generally does not create business value.

Engineering judgement is the art of determining what is good enough. The art of applying the right amount of resources to the right places.

That includes in the interpersonal domain...let the junior engineer own and maintain the design change that might be more work to maintain down the road so that they learn...or you learn that your intuition was wrong.

Good luck.

>and the quality of the overall codebase tends to trend to the lowest common denominator of ability.

I think you've hit the key issue here. You can't build a super high quality codebase if you have a wide range of abilities in your dev team. If you personally try to maintain the quality bar really high across the whole codebase, you'll just exhaust yourself.

Ultimately that's on the company, not you. If they want a really high quality codebase, they can pay double market rate and hire devs very slowly and carefully. I'm going to take a wild guess that they're not doing that.

So don't feel like it's on you to be the saviour of the codebase. Do what you can, within reason.

> It's often small things, like making what's being build more configurable / hard coding less, abstracting differently so code is more reusable.

I am the exact opposite. I learned that it just adds complexity and usually not going to be reused much anyway because every case needs something a little different, and then you had to build this complex thing which isn't worth it.

I'm at the bottom end. I get thrown under the bus a lot. I guess that's how my team(s) deal with it.