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.
Yes, the noobs are noobs, but the goal isn't to exercise your status over them. Or even to waste that much time trying to categorize between A, B, C. The goal should be to boost everybody's productivity instead of treating them like a game.
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.
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.
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.
There were multiple red flags so I only lasted 2 months
These are primarily driven by skills of the junior. Though you should expect they have none.
What sort of comes out between the lines is the attitude of the person, and I think this matters most and should be framed directly.
You want someone curious that will peek beyond what you asked. Someone proactive that will not sit and wait for an assignment. Someone meticulous that will not self-satisfy of quick-and-dirty.
When said like this, the article content resonates as the consequences rather than objectives.
The person who the article sounds like a complete moron, though.
Holy crap this person has only ever worked in toxic work environments
> 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.
There are plenty of places outside of FAANG where you can just be a butt-in-seat, completing tasks.
I met plenty of principal, staff engineers in defense and medical device companies who were just amazing engineers who knew how to complete tasks and dispatch them.
> That stack of tasks you have to do? 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"
Ehhh.
I have received a truck load of positive feedback (but of course some negative too) in my career and I've always felt somewhat undeserving of it. It's not even imposter syndrome, I just never felt that, for example, "attention to detail" was really something I was good at, but I got that one over and over. In fact, I've often felt I am more than a bit hasty. I always edit my comments after posting them to fix something minor. Sometimes I am so hasty, that I force push the same branch like four or five times in a row before I actually have things in order.
But I think I get it now. Attention to detail is what it looks like. I probably pay attention to fewer details than average, but through experience I've honed a pretty good sense for which ones are most important. The things I tend to screw up and need to amend quickly are usually mundane things that in some cases should possibly even just be automated. But even when I do realize shortly after pushing that something is full-on not gonna work, it's not that I sat there and did a careful sweep over all of the important details; my undiagnosed executive dysfunction would never allow for that. It was rather that I double checked just a few details as a sanity check, running things through mental models. And I think having a very good sense for what details you need to scrutinize is exactly what looks like careful attention to detail. It's nothing special, just experience; kind of like when they analyze the gaze of experienced drivers vs inexperienced and can see that the experienced drivers quickly fixate on important details whereas inexperienced drivers are less focused and scan more broadly.
What does that have to do with this article at all? Well, when I read the C list I felt a little nervous. I mean I've broken production a fair few times. Have I ever failed to adequately communicate what I'm working on? Not often but certainly too many times. Generally I am also just mediocre at best at the parts of the job that aren't writing code. But, then when I read the A list, it just felt like reading a description of how I like to work. And I'm not special in that regard at all, but it's at least easier to understand what types of concrete behaviors might set us apart from less senior engineers, aside from more gray hairs and remembering using Windows 98, whereas most peer and manager feedback often feels too detached from the actual behaviors; because the feedback is what people perceive. And I am realizing it's actually rather important to understand the gap between how you feel inside about yourself and how people perceive you, if you really want to earnestly accept feedback, both negative and positive.
I fully realize there is no non-conceited way to format this comment. "Oh, woe is me. I receive too much positive feedback that I feel like I didn't really earn." But, there really is a uniquely bad feeling from getting compliments you don't feel you have earned; what do you say, "But you're wrong! I suck!"
>If I am trying to sway others, I would say that an org that has only known inefficiency is ill prepared for the inevitable competition and/or belt tightening, but really, it is the more personal pain of seeing a 5% GPU utilization number in production. I am offended by it. — John Carmack’s resignation letter from Meta (December 16, 2022)
It's definitely possible to have a builder culture in a large company, but you need to insulate them from the rest of the org and have protective management. Nobody who happens upon a breakthrough is expecting it, all startups expect a breakthrough (their owners are crazy). Don't create a pattern of "stealing" tech from your employees; "tax" them instead. If this is correct then I'd expect to see breakthroughs out of valve in the next decade or 2.
Otherwise, no one gives a crap about what the n00b is doing.
And good luck if you have a lot Bs that believe they are As.
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.
I just don't find this to be true and if this is true then the company should rethink how they use juniors. Maybe stop micromanaging them as much and expecting them to do thing your way. Or maybe give them lower stakes or easier tasks. Or maybe let them figure out some stuff by themselves. I dont know what the exact issue in this hypothetical company is, but if they are slowing you down so consistently, something is wrong.
I also find this expectation that a person should do the listed "A" improvements from the get go weird. Juniors, but actually also new seniors, employees grows from just closing tasks to suggesting bigger improvements over time. The people doing A things grow from people doing B things, as they gain experience with particular code base, experience with local politics and mainly gain confidence - or loose excessive confidence.
> You include solid unit tests. (I wish this was a B signal, but baby steps...)
Like, for christ sake, tell them in the first code review. It is not that deep.
I think that I can make convincing case that doing task several ways is not needed at all. And also that task is actually done only after the decision which solution to pick was made.
It is all about capitalism
I can think of two reasons why he worked that way:
1. It was unclear exactly what he should be focussing on. Were there tasks/tickets describing what needed to be done? Or was it just a vague “fix this”. Doing peephole, local changes to code are easier and improve understanding of the whole. 2. In addition to working on the main tasks, I tend to fiddle around with other code while the main problem is percolating in my brain. Somehow working on other problems helps me solve my main problem faster than just focussing on the main goal.
I would argue that out makes even more sense in the era of LLMs. LLM shaped tasks are tasks that we would hand out to junior engineers. Now, I can implement one of these tasks in 1hr instead of waiting for a junior engineer to finish this in 1-3 days. This means the equation for investing in junior engineers has shifted towards disfavoring investment.
If a person's tenure in companies is measured in months then they're signalling they're a C by your logic, or is at least raising a red flag to whoever's hiring. I may be showing my age but that sounds wild to me if that's the norm now.
Is this common though? Most places I have worked have had people with pretty long tenures. Maybe Silicon Valley during peak ZIRP where you could just keep jumping as long as you could pass the leet code... but then why aren't you staying for RSU vesting?
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
Corporations love people with Kent Beck’s mindset, ladder climbers willing to jump on command for praise, working twice as hard for a raise or meaningless title that may not justify the stress and hours.
And when corporate needs to lay off 30% they’ll think nothing of it.
If you have Kent Beck’s mindset and you’re not pouring it into something you have equity in, you may as well just call yourself a useful idiot.
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.
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?
I have never worked at a place where this was true. Either senior devs would pound through the tasks, or we’d cut them as unimportant.
The only reason we ever hired a junior was because we saw potential and thought they could grow into solid colleagues.
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.
Stock options which vested over 5 years were meant to make it worth everyone's time.
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
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.
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.
> 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.
Guys like this are exactly the reason I don't work in big orgs. They might want their ass kissed, I'm not the one who is going to do that.
At least at large orgs there's hopefully someone able to measure it. The smaller you go it's silos all the way down.
And the management tier of the startup will too easily color the signal by the flavor they want to see.
My latest take on this matter is to separate speed as in fast from quick. Quick is the thing you want and almost always good. Fast is what usually gets lauded and measured but fast just gets you large volumes of fuzzy signal faster.
(quick means that something can take time and be measured, not rushed, things can bake, and the feedback loop is responsive quickly throughout the loop. while fast is looking at wall clock time and goaling on the end-result yield from the loop. i think it’s very misguided. things very often need bake time)
I hired my first ever intern for myself this past week for a personal. Rather than expecting someone who is experienced to knock out tasks or whatever & try to justify the expense, Intern and I just check in once a day about whatever feels like most important, and each do our thing. We chat as needed. I told Intern we’ll work on whatever, just making sure that they will have something tangible and targeted to show at the end of the summer. No ticket tracking or Slack or anything. Just texting, video chats, and the occasional email. I pay someone to listen to me rant long enough to get to the point, giving me focus that’s hard to find on my own, intern works on targeted things for a day at a time, and we’re just plodding along. It’s great and I find the process to be extremely refreshing.
When I’m trying to brainstorm with Claude Code or pick-an-AI-tool, I find the process frustrating and draining. The results I get from trying to do everything myself with a robo-junior are mediocre and uninspiring.
I didn’t even interview intern. I just reached out directly on LinkedIn and offered a summer internship. I figured anyone with a half decent profile will be smart enough to follow along and offer ideas of their own. Basically my thought was if I offer ever and expect nothing, I’ll take all the pressure off, and just let them work. Ask me again in a months if this was a good idea or not.
I think working with newbs is fantastic, and I plan to do a lot more of it.
6-12 months? Red flag 12-24 months, especially early-to-mid career? Not uncommon
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.
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.
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.
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.
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.
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.
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.
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.
Ironically on the token use leader boards the C guys are crushing it.
Edit: I was worried about Claude+junior myself but it’s not working out that way. It’s like giving an apprentice access to a full woodworking shop full of tools and expecting fine joinery, but getting a high school spice rack and 2 tons of sawdust
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.
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.
There's something that is very pernicious in the government in Brazil (where I'm from) where in a department there's one person that does all the work while everyone else sits around. You can't fire the non-performing ones or push them because there is a very strong worker protection system for them. Back in college it took me a full week to get my grade history because the person that did all the work was on vacation and nobody else bothered to learn how to pull it or cared if students couldn't get the report.
These are the C's, people that have to be forced to do the work, and that will eventually cause all the work to pile on everyone else. There's no fun in working in an environment like that and its a quick recipe for a burnout.
It tends to be the reason so many Americans are anti-union. They do a lot of good for the average worker but they also carry along a lot of dead weight that can’t easily be shed.
Welcome! I am going to pass on to you the secret to a successful and brief noobitude, and I won’t even keep you in suspense: nobody cares how many tasks you complete. Why not, and what we care about instead are the subject of the rest of this essay.
Look at your situation from our perspective (by “our” I mean “older engineers”). We hired a bunch of people like you. Some of y’all (we’ll call them A’s) will be amazing game-changers, making everyone around them wildly more productive. Many of you (B’s) will be solid performers. Some of you (the C’s) won’t be here in a year.
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.
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.
That stack of tasks you have to do? 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. If all we cared about was today’s productivity, we wouldn’t have hired you at all. Instead, we (the seniors) are focused on the future: we know there’s going to be far more work here than we could possibly accomplish. 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. If not, we’ll have to be doing the same engineering jobs ten years from now, and we really don’t want to be doing that.
This quarter’s newsletter is brought to you in partnership with WorkOS.
WorkOS is the infrastructure B2B and AI-native companies use to sell to enterprise. It covers everything enterprise security requires: SSO, SCIM, RBAC, Audit Logs, AI governance, and more. Engineering teams ship it in days. Trusted by 2,000+ fast-growing companies, including OpenAI, Anthropic, Cursor, and Vercel.
Noob A accomplishes 40 tasks this quarter. Noob B accomplishes 20. Which is better?
Not enough information. What if all the tasks were the same difficulty? Then which is better? Still not enough information. Remember, we’re trying to figure out if you’re an A, a B, or a C. What is the information we require to figure that out?
The first level of sorting is figuring out if you’re a B or a C. Here are goals that are more important than closing your task in the absolute minimum time:
Your code works.
You told other people what you were doing.
You got done in a reasonable amount of time (be good if it was within a factor of three of the initial estimate).
You did not cause other people unreasonable amounts of work. Work for people you asked for help—okay; reviewers who had to spend extra time—bad; on-calls who had to respond to errors—very bad; devops who had to respond to incidents you caused—double plus bad.
Any attempt to game the system by claiming to have done work you haven’t done marks you immediately as a C. Assume you can’t game this system.
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.
The second level of sorting is, given you’re at least a B, are you an A? What distinguishes A’s is not how many tasks they close, but how much they learn from each task. Remember, your productivity sucks by our standards. We expect that. It’s the first derivative of your productivity that we’re looking for. Here are some signals that you’re an A:
You make a convincing case that the task needn’t be done at all.
You mine data and discover the 10% of the task that creates 90% of the benefit.
You implement the task several ways.
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).
You submit a string of diffs instead of one big one. Bonus points if you push the diffs daily.
You write an internal tool that simplifies similar tasks. (You lose points if there are no similar tasks.)
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.
You are an insightful and responsive reviewer.
You include solid unit tests. (I wish this was a B signal, but baby steps...)
Isn’t it nice that the “kick ass” list is so much longer than the “don’t mess up” list? You have many ways to shine.
All the A signals share one trait—they take longer than just doing the work necessary to close the task. This isn’t permission to spend forever on shiny side-bars. Always get the task done in a reasonable amount of time, just not the absolute minimum time.
You may be wondering where this “extra” time is going to come from. You’re already committed up to your eyeballs. That’s where Everything You Need To Know About Programming But Didn’t Know To Ask [ed: to be written] comes in. We’ll talk about time management, task queue management, diff queue management, and other topics that will accelerate your progress.
Take the time you save and invest it in yourself in ways that benefit others. That’s what we’re looking for.