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 6 hours ago | parent | next [-]

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 2 hours ago \| parent [-]
		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 6 hours ago | parent | prev | next [-]

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 2 hours ago \| parent \| next [-]
		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 4 hours ago \| parent \| prev \| next [-]
		> 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 5 hours ago \| parent \| prev [-]
		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.

▲

teeray 6 hours ago | parent | prev [-]

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.