[chalupa-supreme]

For a B level: > * You did not cause other people unreasonable amounts of work.*

I would be careful with this one. As the examples listed after, such as an on-call incident or extra review of code isn’t necessarily on the n00b. Maybe I’m biased being only 4 years into my career but engagement on stuff you did wrong or even points on what you can do better are extremely valuable. From my standpoint, screwing up isn’t a problem if you can engage with the team to recover and learn from it.

[accurrent]

A lot of this article reads like an egotistical toxic senior dev. I agree with your take. I tend to agree that "not generating unreasonable work" is not a good signal. If I do 0 work I can fall in the "not generating unreasonable work" category - thats not a good signal.

Also the "Your manager or your tech lead could finish those in much less time and with much less hassle than it takes to help you through them." suggests that he is not hiring talented juniors.

It is also a good senior dev's job to architect and scope tasks so that juniors dont bring the whole system crashing down.

[actsasbuffoon]

Yeah, I know Kent is a very respected developer with a long and celebrated career. But I did not like the attitude of this article at all.

I’m a principal engineer. I have an obligation to less experienced engineers I work with to help develop them as engineers and help ensure they go on to have great careers. No part of that involves shaming them, assigning letters of talent to them, or browbeating them.

I feel like I’d have heard about it by now if Kent was a raging asshole, and I haven’t heard that. So I’m guessing he had some idea in mind when he wrote this that just isn’t coming across correctly. But… I would definitely take this article down and spend some time re-working it if I were the author.

[throwaway219450]

The article sounds like a company with toxic blame culture. If critical aerospace can be no-blame, software can too.

Sure, try not to be useless, but if the company doesn’t have guardrails that’s not on them. If an intern deletes something: why did they have access in the first place? Why wasn’t there a backup?

[Eridrus]

This sort of process over responsibility culture is one way to drive incidents to zero, but it's also a way to wrap yourself in so much process and bureaucracy that you move at the speed of aerospace.

Of course, many companies are far away from the pareto frontier, but there are often tradeoffs for safety and people have to use judgement about when to go slow and when they can go fast.

[Zarathustra30]

> You will send out some C signals. That’s inevitable. We all did. Never, never send out the same C signal twice. And make sure the balance of the signals are that you are a B.

This bit is important. It's not great if a new hire nukes production, but it doesn't preclude them from being a B or A.

Additionally being considered a C isn't necessarily a blame game. If an employee nukes production multiple times, they may not be in the right headspace to work at that company, through no fault of their own.

[Negitivefrags]

I get the sentiment, but it's possible to go too far with the "It's always the process's fault" direction.

It's trendy in buisness culture right now to erase the individual. Zero accountability can also mean zero growth. I don't think it's honestly the most enjoyable situation to be in.

[projektfu]

Where is it no-blame in aerospace? Specifically JPL or something? I've been spending a lot of time studying aviation and there's almost always blame when things go wrong, even though there is also a lot of systems thinking. There are many complaints as well that the system is likely to formulate a rule because of a mistake, rather than just acknowledging that mistakes happen, or that a specific facility, company, or individual needs to do something differently.

[teeray]

I would as well. If you didn’t stop it at the review stage, it’s the team’s problem. It’s not “X’s code broke prod.” In at-will, X can up and leave before you have time to give them shit for it. Then it’s the team’s problem anyway. Make sure you collectively own what you merge.

[sleples]

It's not so simple, especially in the AI slop era. Reviewers are already flooded because people of varying skill opening PRs at a rapid rate and it's not practical to be able to dive deep into every line. It's up to the implementor to take some responsibility and make sure things are correct.

Because of the AI lunacy going on at most companies, if you call any of this out you get labelled a luddite and are put on top of the layoff list, so at least for now it's just something you have to deal with.