[mkl95]

Back when I was a junior developer I used to think tech companies -even the smallest ones- generally had some kind of reasonably accurate performance review process, where engineers who were underperforming for a while were eventually weeded out.

In my experience ever since, that's simply not true. There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get away with it for years. While their coworkers who have only been at the company for a few months will be routinely called out on their mistakes, missed deadlines etc.

Some people are less fireable than others and I'm afraid it has little to do with how good they are at what they do.

[lumost]

Companies rarely fire tenured staff except for layoffs. Often this is due to issues such as

- Tenured staff have a track record, if they are suddenly under-performing it seems more likely that their manager is to blame. Rather than a lack of ability.

- Tenured staff have institutional knowledge which can be hard to estimate and replace, the fact that a bad engineer still knows why something was done a certain way and can help others is sometimes sufficient.

- Tenured staff sometimes have implicit responsibilities that are unclear to new hires. An engineer with 10 years in the company might spend almost all of their time doing some form of product/tech leadership. The rare times they write code it may be deficient in some manner or another.

- Tenured staff know how to read the tea leaves. The fact that they are still with the company likely indicates that they know how to avoid situations where they will get let go. Sometimes this is as simple as hopping on maintenance work for profitable systems.

On the other hand, a new engineer doing their first project may actually not have the skills to get the project done. Or, more likely they were hired for new initiatives that leadership is fundamentally skeptical of.

[mushbino]

In my experience, an inner circle is established at a company when it is still relatively small. Those fortunate enough to be in that protected circle can do no wrong. Any hires after that in group is established bear the brunt of that companies issues. It's very true with startups.

[humanrebar]

Lots of good points here, but maintenance work for profitable systems seems like a valid use of time.

Now, some profitable systems are slowly bitrotting and tenured engineers can keep busy doing routine work while failing to address or escalate the bitrot. But I think people who are good at making sure boring and stable things stay boring and stable are usually underappreciated.

[Jensson]

Companies pay for people do to maintenance for profitable system even if those systems doesn't much need maintenance, meaning lots of people in those roles don't do much. The point isn't that all maintenance engineers are worthless, but that it is an area where you often can be incompetent but still be kept around.

[Simon_O_Rourke]

Unfortunately I know of one engineer right now who is basically completely impervious to getting fired, simply because they keep waving around some self diagnosis of being especially sensitive, not on the spectrum mind, just easily offended by trivial issues. Even going to the trouble of writing a blog about their challenges at work for being called out for doing no work, and then playing the victim. I think management have done the math and figured continued employment costs less that legal fees if they were fired.

[jtwebman]

More likely it is just that they have a bad manager not willing to go through the process of firing them. I know as a manager firing people sucks but you sometimes need to do it to keep the rest working the best together. Companies do make it really hard sometimes.

[loonster]

As a non manager, keeping parasites around is bad for moral.

[Jensson]

Firing them is also bad for morale, for different reasons. Only solution is to not hire parasites in the first place.

[david38]

It’s not. People who work hard don’t like when others are doing little and getting paid.

It makes them question why THEY are the suckers doing the hard work.

[leaflets2]

I suppose keeping "parasites" around, until eventually slowly slowly firing them, is the worst?

[andy_ppp]

Smart, gets things done on time, pleasant to work with. Pick any two and you’ll do fine. Neil Gaiman’s commencement speech. I think if two are lacking for a while you get fired…

[kalimanzaro]

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.

[worker767424]

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

[armchairhacker]

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

[willcipriano]

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.

[andy_ppp]

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.

[tene]

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.

[celim307]

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

[philjohn]

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.

[YZF]

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.

[dccoolgai]

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.

[dccoolgai]

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.

[dudul]

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

[scoopertrooper]

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.

[YZF]

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.

[Swizec]

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

[YZF]

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.

[axiolite]

> There are "teflon engineers" out there who can get virtually nothing done and make one mistake after another, and get away with it for years.

That would be Wally from the Dilbert comic strips...

I have seen that when the employee in question has much lower salary requirements than others, appearing to provide a sort of false economy to management, even as their actual value is entirely negative.

I accidentally solved one of those problems, myself... having stumbled upon evidence a very poorly performing employee was reading articles on the web most of the day, only doing a few minutes of coding and taking some steps to hide logging of this fact (which was actually the part that caught my attention). Setting up screen recording and running it for several days hammered the point home. Said employee at the end of this period conveniently reported running into technical difficulties with their project, necessitating more time to work on it. That nicely drove the point home, putting the final nail in and effectively catapulting them out the door...

[exdsq]

A company secretly screen recording me makes me shiver

[stretchwithme]

"evidence a very poorly performing employee was reading articles on the web most of the day"

Sounds like probable cause for a warrant. Not that employers needs a warrant to use their own property, but to assure employees that they aren't being watched unless there's legitimate suspicion.

[YZF]

A warrant??? I'm not aware of any country where you can/need to get a warrant to "spy" on your employees. In some countries that would be illegal. If said employee manages to do what others do while mostly surfing the web that's great. If they aren't delivering then by all means fire them (ideally with some sort of process to actually let them fix it). I don't see what the spying buys other than the mistrust of employees, the news getting out, and people not wanting to work for you.

[stretchwithme]

I didn't say they needed a warrant. I said the opposite.

[exdsq]

I think this is illegal in Europe or parts of Europe! I’d feel differently if you were told this would be happening.

[mkl95]

I think the general rule in Europe is that your employer may record your screen as long as you know it's happening.

[exdsq]

Which I do agree with, assuming it’s work devices too. But secretly recording devices is just weird.

[geoffbp]

Ah the “protected species”