Something tells me in the anecdata above, the unfirable characters involved picked 1 _at most_:

The teflon engineers don't seem smart and probably can't get things done on time if at all.

While the sensitive engineer seems unpleasant to work with, while not contributing at all.

Neil Gaiman has a knack of saying immensely compelling stuff, that's all there is.

> Smart...pleasant to work with

Does anyone have tips for having high code standards, but still pleasant to work with? I got feedback that I have high standards, but I also go to the effort of explaining why I think an approach is better in code reviews and don't talk down to people in code reviews (and got feedback saying this), but I'm not sure it's enough.

if you want to enforce higher standards than your colleagues, you have to put in most of the work to reach those standards. For instance, if you think a section of a code needs unit tests, maybe write some of the tests yourself or at least suggest how to.

also be modest, and make sure to frame your standards as cooperating to improve the company’s code, not competing to show you’re a better programmer

the ultimate goal is to make your high standards more of an asset (“he’s improving the code”) then a burden (“he’s criticizing us and making us do more work”)

High code standards or specific preferences? Are your comments more like, "If this receives two requests at once it will result in a race condition" or more of the "you used tabs but I like spaces" sort?

Imposing preferences on others via the mantle of "best practices" is a great way to annoy them.

Well most of these preferences should be fixed by automated code formatting and listing tools so they shouldn’t be discussed unless people are turning them off for some reason.

I'm not sure how well it works exactly, but when I'm advocating for more rigor or error-checking or other high standards, I try to include justification for why changes to the project under consideration need to be held to this higher standard.

Have some conversations to build consensus with your team about what standards the codebase should be held to at this phase in its lifecycle, and when that decision should be revisited as the project matures and evolves.

It's fine to personally have high standards, but it's important to keep those distinct from the actual needs of the current development work.

For a given standard X like "always check errors" or whatever "Does this change maintain property X of the code?" is a very different question from "Is it worth maintaining property X in our codebase today".

Justifying that a change you advocate for is better is not enough; you also need to reach consensus on that improvement being worth the cost in time, complexity, maintenance, etc.

Also, don't try to revisit that consensus for small matters. Having consensus about what you're collectively aiming for, and people feeling confident that they're aiming at a stable target, is itself extremely important, and is worth trading off a bit of code quality for.

Something else I find really helpful for building credibility in your proposals being well-calibrated instead of universally "do better" is to look for opportunities to change your mind, to be persuaded by someone's argument, and for opportunities to say "This is great as-is; no need for complication here" or "Thanks for keeping this simple". You might consider aiming for "good taste and well-calibrated standards" as a replacement for "high standards".

Help people feel confident that you will advocate for lower standards when appropriate, and they'll believe you way more when you advocate that higher standards are worth it in a specific situation.

Comment on the code review but follow up privately and offer to pair.

It’s extra work but it shows the contributor that you’re not just out to poke holes and make extra work, it shows you actually care about their development and progression as an engineer

This - hammering someone's code review with tens of comments can put people on the back foot. Part of any good senior and higher engineers responsibilities is to lift the people around them up.

It might help to have some rationale or at least anecdotes.

The people nobody(tm) likes are the ones that insist on things without knowing why and/or without any relevant experience. They read it in a blog, or someone told them that's better, Google does it, cargo cult etc.

Start by assuming your coworkers have their reasons why they do something, not because their standards are lower. Maybe it's not worthwhile to spend time on making something a little more perfect when there's other more valuable things to invest your time in.

On the other hand, it is possible that your peers truly have lower standards, less experience, and don't understand what they're doing. Unfortunately there's no easy solution to that. It's possible that by being the annoying guy that always nitpicks you will be able to drive some improvement, but it'll take its toll on you. As others said, lead by example works somewhat. The problem though is that sometimes the "why" in software engineering only happens after many years.

I'll also second the idea of doing your code review with those people as a discussion vs. an offline process where you leave comments that can be interpreted in different ways.

Try this; 1. every PR review call out one neat thing you _really like_ and maybe ask how they figured that out 2. Be explicit in the dichotomy between "recommendations/nits" and "you shouldn't merge this". Weight things toward the former. Have a style guide for the latter things and be very conscious of when someone is violating the actual style guide or just your own biases. If you really have high "standards" write them down... Otherwise they are just whims, not really standards.

To put a finger point on the advice above: you should _never_ be enforcing "your standards" but the "team's standards". If you can't tell the difference, that's its own kind of problem.

Pick your battles. Try to identify cases where at the end of the day, it doesn't matter if the code is not "the best TM".

Also don't hesitate to tag your comments as "nitpicks".

Try and organise a workshop to set some common coding standards. Having a commonly understood standard for good is an excellent way to start the process.

Not clear if the meaning here is coding standards as in how you name things, spaces vs. tabs, comments etc. or something else about the code. Coding standards (the style aspects) should just be solved by tooling, you don't let anyone merge code that's not to standard by having a tool verify that.

You can be all 3. Lots of smart people out there doing great work who are pleasant to work with.

But you gotta treat them right. Everyone becomes unpleasant in a bad environment

I agree a lot of this depends on the environment. Are you asking people to work on things they enjoy working on? What's the team like? What's the culture like?

"Smart" is maybe something that can be measured in a vacuum (though in practice it means more than just IQ) but most of the other parameters are very much influenced by the company, team, managers. I totally agree that people can become unpleasant if they're in a bad environment or pushed in certain ways. I've worked with some people that I thought were total jerks and we eventually became great friends, often the friction at work is about something stupid/situational + the general social awkwardness of many software people.