I've met maybe 1-2 people in my whole life who were clearly beneficial 'A' from the get go. There's also a weird 'A' that tries very hard but causes more pain than inspiration. Meaning, they're clearly smart but think that's all that's necessary to be useful.
I once worked with an intern from MIT who came in and immediately submitted large PRs everyday that improved the algorithmic complexity for a bunch of functions. Which was awesome to see but the changes were off the hot path and the code was much harder to read.
The part that still comes to me was when I'd said during a code review that there were other more pressing concerns, the intern said yes but you can't argue against the improvement in time complexity.
Smart guy. Inspirational, even. But better suited to a large corp than a startup. I think a startup 'A' has a lot more to do with attitude about speed and uncertainty than competence.
This makes complete sense in an environment where people transition from noob to senior engineer within the same company.
It makes less sense in an era when tenure is better measured in months than years.
It makes even less sense in an era of LLMs.
One area where it might be relevant is the military. People are more likely to stay for longer (unvalidated assumption) and the same personnel jacket follows them if they are transferred.
It might also be thought of as a guide as to when to jump ship. If you have managed to get yourself categorized as a C, then leave. Start fresh somewhere else, take the learning with you, and discover if you have what it takes to make it as an A or B.
This is an interesting perspective(and a great roadmap for juniors to try to improve), but I think for the most part the thesis is wrong, at least in my experience.
Companies do not hire juniors as some long tern play to develop them into good engineers. They hire juniors because they have junior level tasks that need completed.
That does happen, and that junior level work is constructive, but what I've also experienced and noticed is that companies put a lot of effort into finding and hiring exceptionally skilled juniors (industrial placement schemes, graduate fast-tracks, etc.) where they can make safe bets on those people delivering significant value to their companies/projects. Some bigger companies do make an effort to build a mutually beneficial working relationship with a clear 5 year career roadmap (some sectors really struggle with those best candidates choosing FinTech instead). I've worked with high-performing junior programmers that have (quantitatively and qualitatively) dramatically outperformed experienced mid-level programmers, so I'm always an advocate for investing in them.
>Companies do not hire juniors as some long tern play to develop them into good engineers
Working for companies, as a manager, I have. I have said to my management that is what my intention was, and subsequently hired people for exactly that.
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.
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?
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.
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.
> You submit useful diffs in areas that having nothing to do with your team, but not at the cost of finishing your official tasks.
> You write up what you learned in an interesting, useful and persuasive way.
Very curious (and appreciative) that some company cultures allow this. I haven't had such experience (although I work in a parallel role). It's usually just grinding out tickets.
I work at a place that is actively hiring juniors. While they don’t have an explicit rating system I feel like we unconsciously follow a similar pattern with new coders and it’s unfortunate.
Given that older staff generally have a legacy of responsibility they don’t always have the time required to coach people who lack that self-starting spark. The quality of the questions and how much effort they have put in to answer things themselves are what differentiates a C from a B.
Mostly you can quickly answer something a B asks. But a C who sponges up your day quickly gets categorised into not being given fun or difficult work.
With funding and resources this wouldn’t have to happen but the industry treats mentoring time as lost time. You aren’t getting your story points done if you’re helping somebody else do theirs.
The stupid agile bollocks management style has no eyes on the future of an organisation.
One thing is that the A's are watching how you treat the C's. They might not have a good gauge of the culture from their own experience because they take care of themselves.
> You uncover a better design and submit a string of diffs not only implementing the task but simplifying other parts of the code too. Bonus points for doing this before you implement (make the hard change easy then make the easy change).
The last part of this really stands out. A high performer understands that software is malleable. However, the way you shape it, when things change, and how much is changed at one time matters a lot
As a senior you can get into a bad habit of being scared to make changes. It happens after enough experience with enough codebases.
It’s good to not just go change things for the sake of it — it’s equally as important to ask yourself if you’ve gone too far in the other direction and to always remain curious and critical of yourself.
"Brutal as it seems, we’d like to expend as little effort as possible on people who aren’t going to make it. It’s your job to get in the category you want to be in and send us the signals that tell us that’s where you belong."
And this is what a complete lack of leadership looks like.
"We are paying your salary now as the option premium on the engineer you are going to become. If we play this game right, we’ll have a kick-ass next generation of engineers."
You missed figuring out if your position is supposed to make [grandiose] proposals.
Monitor what everyone else is doing, how fast they do it and what you can do to help. Condition everyone to think it's Xmas if you hand them something. After doing that 200 times hand them something obviously nonsensical just for laughs.
This only works if the culture is healthy and the seniors are mentally healthy. Usually, most are trying to protect their turf. Because even having “seniors” in the first place means they been there for a few years and they would like to keep it that way.
Otherwise, no one gives a crap about what the n00b is doing.
> We seniors have our regular work to do, but we also have to figure out which category you fit into. We support the superior performers as much as we possibly can. We support the solid performers enough to help them mature. Brutal as it seems, we’d like to expend as little effort as possible on people who aren’t going to make it.
Holy crap this person has only ever worked in toxic work environments
what a foolish take. our benevolent overlords currently are bragging about how many lines of code that AI writes for their companies. clearly output volume is the only relevant metric, why would anyone bother demarcating quality and quantity
The A signals are not A signals in this article, and this:
> You may be wondering where this “extra” time is going to come from. You’re already committed up to your eyeballs. …We’ll talk about time management, task queue management, diff queue management, and other topics that will accelerate your progress.
Is just corporate dog whistling.
If you are over committed, no amount of time management will solve your problem. Using AI wont solve your problem.
You have a fixed amount of time and too much work?
Work. More. Hours.
Thats the real game; spend extra time outside of your normals hours doing extra.
Congratulations, you’re an “A”.
Makes no difference; your resilience against restructures is not correlated with how much respect you have from senior developers.
That shouldn't be your goal.
There are many places that do what they call “data driven” performance evaluation (translation: avoid being racist by looking only at anonymised numbers) and they do, indeed, look at 40 completed tasks and go: we will keep this one.
The strongest advice for a new starter is: at your specific company ask what you will be reviewed on, and do your best to do whatever that is.
Generic advice is a dime a dozen; don't fall in the trap of assuming [generic advice here] will apply to your specific workplace.
Not true at all.. I know people who work strict 9-5 and are clearly A. And I was unlucky to have a coworker who worked extra long hours just to write huge amount of code which did not solve the task required and kept breaking prod too.
There is a lot to be said about how efficiently you work. This involves making choices about how you solve problems, in what order you solve problems, how you manage people interrupting you, your personal life interface with work, how you advocate for what work to be done... on and on and on.
An easy example: spending 2 days on automation for a task that takes an hour to do manually -- is this a task you have to do once a year or once a week? -- what do you choose to do?
How many meetings do you schedule? How many do you accept? How long do you spend struggling on a problem before asking for help? How often do you not even try something before asking for help?
I'm telling you for me being a better more productive engineer had a lot to do with making better choices. I'm not selling you a book or inviting you to my TED Talk.
Not wasting a tremendous amount of time automating something is indeed an important skill to learn (because automating things is way more fun for some people than actually doing the thing).
Coaching junior employees to neither ask me for help the instant they're confused nor spin their wheels for two weeks without asking for help is a COMMON thread.
>High achievers, across the board, consistently demonstrate putting more effort in.
Growing up, in school, I did almost nothing and was consistently at the top of my class until I got older and things started requiring effort for me. The early years of high achievement had literally nothing to do with effort.
These days being a high achiever has a lot to do with managing the perception of your work.
I've met maybe 1-2 people in my whole life who were clearly beneficial 'A' from the get go. There's also a weird 'A' that tries very hard but causes more pain than inspiration. Meaning, they're clearly smart but think that's all that's necessary to be useful.
I once worked with an intern from MIT who came in and immediately submitted large PRs everyday that improved the algorithmic complexity for a bunch of functions. Which was awesome to see but the changes were off the hot path and the code was much harder to read. The part that still comes to me was when I'd said during a code review that there were other more pressing concerns, the intern said yes but you can't argue against the improvement in time complexity.
Smart guy. Inspirational, even. But better suited to a large corp than a startup. I think a startup 'A' has a lot more to do with attitude about speed and uncertainty than competence.
This makes complete sense in an environment where people transition from noob to senior engineer within the same company.
It makes less sense in an era when tenure is better measured in months than years.
It makes even less sense in an era of LLMs.
One area where it might be relevant is the military. People are more likely to stay for longer (unvalidated assumption) and the same personnel jacket follows them if they are transferred.
It might also be thought of as a guide as to when to jump ship. If you have managed to get yourself categorized as a C, then leave. Start fresh somewhere else, take the learning with you, and discover if you have what it takes to make it as an A or B.
I completely disagree with you and it seems like your assumption is that the transition times are years.
I've seen a B player on my team turn into an A player in just the last couple of months
But I do agree with you about the C thing, if youre a C you need to move immediately to at least a B, otherwise leave
This is an interesting perspective(and a great roadmap for juniors to try to improve), but I think for the most part the thesis is wrong, at least in my experience.
Companies do not hire juniors as some long tern play to develop them into good engineers. They hire juniors because they have junior level tasks that need completed.
That does happen, and that junior level work is constructive, but what I've also experienced and noticed is that companies put a lot of effort into finding and hiring exceptionally skilled juniors (industrial placement schemes, graduate fast-tracks, etc.) where they can make safe bets on those people delivering significant value to their companies/projects. Some bigger companies do make an effort to build a mutually beneficial working relationship with a clear 5 year career roadmap (some sectors really struggle with those best candidates choosing FinTech instead). I've worked with high-performing junior programmers that have (quantitatively and qualitatively) dramatically outperformed experienced mid-level programmers, so I'm always an advocate for investing in them.
>Companies do not hire juniors as some long tern play to develop them into good engineers
Working for companies, as a manager, I have. I have said to my management that is what my intention was, and subsequently hired people for exactly that.
The thing is when you're starting out this is probably what you have in mind for each job you apply. But that only happens one out of ten.
Not anymore. We give those tasks to genies and hire juniors as apprentices
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.
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?
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.
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.
> You submit useful diffs in areas that having nothing to do with your team, but not at the cost of finishing your official tasks.
> You write up what you learned in an interesting, useful and persuasive way.
Very curious (and appreciative) that some company cultures allow this. I haven't had such experience (although I work in a parallel role). It's usually just grinding out tickets.
I sure wish I could relate to this but I haven't been at a company that hired juniors since i was the junior being hired 15 years ago.
I work at a place that is actively hiring juniors. While they don’t have an explicit rating system I feel like we unconsciously follow a similar pattern with new coders and it’s unfortunate.
Given that older staff generally have a legacy of responsibility they don’t always have the time required to coach people who lack that self-starting spark. The quality of the questions and how much effort they have put in to answer things themselves are what differentiates a C from a B.
Mostly you can quickly answer something a B asks. But a C who sponges up your day quickly gets categorised into not being given fun or difficult work.
With funding and resources this wouldn’t have to happen but the industry treats mentoring time as lost time. You aren’t getting your story points done if you’re helping somebody else do theirs.
The stupid agile bollocks management style has no eyes on the future of an organisation.
Not to sound soulless but why would you want to invest on the C’s?
Unless we have no options I don’t see why so that. I’ve had to deal with people like that and it’s a tar pit.
One thing is that the A's are watching how you treat the C's. They might not have a good gauge of the culture from their own experience because they take care of themselves.
How is the place you’re at approaching AI in this context?
As a senior I worry about the juniors coming in — Claude can do what I would have previously tasked to a junior.
I guess the shape of the junior role just changes.
> You uncover a better design and submit a string of diffs not only implementing the task but simplifying other parts of the code too. Bonus points for doing this before you implement (make the hard change easy then make the easy change).
The last part of this really stands out. A high performer understands that software is malleable. However, the way you shape it, when things change, and how much is changed at one time matters a lot
As a senior you can get into a bad habit of being scared to make changes. It happens after enough experience with enough codebases.
It’s good to not just go change things for the sake of it — it’s equally as important to ask yourself if you’ve gone too far in the other direction and to always remain curious and critical of yourself.
Some new hires end up cleaning the mess that their manager left behind from back when they were the noob…
"Brutal as it seems, we’d like to expend as little effort as possible on people who aren’t going to make it. It’s your job to get in the category you want to be in and send us the signals that tell us that’s where you belong."
And this is what a complete lack of leadership looks like.
"We are paying your salary now as the option premium on the engineer you are going to become. If we play this game right, we’ll have a kick-ass next generation of engineers."
Not if you do jack shit to help them improve.
You missed figuring out if your position is supposed to make [grandiose] proposals.
Monitor what everyone else is doing, how fast they do it and what you can do to help. Condition everyone to think it's Xmas if you hand them something. After doing that 200 times hand them something obviously nonsensical just for laughs.
This only works if the culture is healthy and the seniors are mentally healthy. Usually, most are trying to protect their turf. Because even having “seniors” in the first place means they been there for a few years and they would like to keep it that way.
Otherwise, no one gives a crap about what the n00b is doing.
> We seniors have our regular work to do, but we also have to figure out which category you fit into. We support the superior performers as much as we possibly can. We support the solid performers enough to help them mature. Brutal as it seems, we’d like to expend as little effort as possible on people who aren’t going to make it.
Holy crap this person has only ever worked in toxic work environments
Yeah, someone is pulling up the ladder here.
what a foolish take. our benevolent overlords currently are bragging about how many lines of code that AI writes for their companies. clearly output volume is the only relevant metric, why would anyone bother demarcating quality and quantity
The A signals are not A signals in this article, and this:
> You may be wondering where this “extra” time is going to come from. You’re already committed up to your eyeballs. …We’ll talk about time management, task queue management, diff queue management, and other topics that will accelerate your progress.
Is just corporate dog whistling.
If you are over committed, no amount of time management will solve your problem. Using AI wont solve your problem.
You have a fixed amount of time and too much work?
Work. More. Hours.
Thats the real game; spend extra time outside of your normals hours doing extra.
Congratulations, you’re an “A”.
Makes no difference; your resilience against restructures is not correlated with how much respect you have from senior developers.
That shouldn't be your goal.
There are many places that do what they call “data driven” performance evaluation (translation: avoid being racist by looking only at anonymised numbers) and they do, indeed, look at 40 completed tasks and go: we will keep this one.
The strongest advice for a new starter is: at your specific company ask what you will be reviewed on, and do your best to do whatever that is.
Generic advice is a dime a dozen; don't fall in the trap of assuming [generic advice here] will apply to your specific workplace.
Not true at all.. I know people who work strict 9-5 and are clearly A. And I was unlucky to have a coworker who worked extra long hours just to write huge amount of code which did not solve the task required and kept breaking prod too.
Eh.
There is a lot to be said about how efficiently you work. This involves making choices about how you solve problems, in what order you solve problems, how you manage people interrupting you, your personal life interface with work, how you advocate for what work to be done... on and on and on.
An easy example: spending 2 days on automation for a task that takes an hour to do manually -- is this a task you have to do once a year or once a week? -- what do you choose to do?
How many meetings do you schedule? How many do you accept? How long do you spend struggling on a problem before asking for help? How often do you not even try something before asking for help?
And on and on and on.
This is self-help nonsense your manager will tell you when giving you too much work.
Companies will smartly balance the amount of work allocated to people.
…and then they will push you to take on more work.
High achievers, across the board, consistently demonstrate putting more effort in.
Its just a bitter pill to swallow for some people.
I'm telling you for me being a better more productive engineer had a lot to do with making better choices. I'm not selling you a book or inviting you to my TED Talk.
Not wasting a tremendous amount of time automating something is indeed an important skill to learn (because automating things is way more fun for some people than actually doing the thing).
Coaching junior employees to neither ask me for help the instant they're confused nor spin their wheels for two weeks without asking for help is a COMMON thread.
>High achievers, across the board, consistently demonstrate putting more effort in.
Growing up, in school, I did almost nothing and was consistently at the top of my class until I got older and things started requiring effort for me. The early years of high achievement had literally nothing to do with effort.
These days being a high achiever has a lot to do with managing the perception of your work.