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.
As someone that's a senior at a large corp, I absolutely do not want someone making the codebase more complex with the only benefit being being that it's now barely measurably faster. Especially when there are probably better things to be spending time on (spoiler, there are). Unless you're knocking like 20% off a very impactful metric, or addressing a looming scaling probably, go find something better to do than making tiny algorithm optimizations.
I've seen rewrites at startups that were slower and less stable than what we had before and everyone cheered it on like clapping seals. This stuff is rife no matter the size of the company.
At least at large orgs there's hopefully someone able to measure it. The smaller you go it's silos all the way down.
Typically this is backwards: simpler solutions often are more optimal, and complex solutions are not. Most code is slow because it’s just poorly written. If you write it simpler, then you can make it faster and easier to read. This isn’t always true, but it is true for 99% of the low hanging fruit optimization work that’s done in practice.
Yeah good luck with that attitude over time. Most people don’t hang around in an org long enough to see that assumption scale to renting hardware than costs $900k a node a year.
Seeing what you made get to the point that that's an issue is a "a good problem". Yes, it's worth it to optimize at that point, but that's still an argument for what I consider premature optimization.
I meant any institution where such cost of delay can be absorbed more easily. The cost of one day of that kind of work in a startup is probably more expensive than in a more established firm.
I used to think this but you only know which were the right corners to cut after the fact. And most things are not obviously right or obviously wrong, instead it’s a slow zombie death by a thousand fuzzy signals.
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)
Yes, but it does get easier with experience and some battle scars. Telling a startup to stick to the problem and not go wild with microservices and event sourcing is not exactly a hot take.
I think there is nothing inherently wrong with changing code that can be improved but shouldn’t have focus as long as the other work also happens. It improves his understanding of the codebase and makes the code “better”. (Obviously, feedback needs to be taken into account.)
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.
Yeah, I can argue against it. How much time did he spend on it, how much is games on the user the (as in, is this a common use path or an uncommon one) you may have doubled the speed but did it go from several seconds to a few, it a split second to a half split second? Are there other things that should be implemented before speeding things up. Etc etc.
One of the PRs was some data visualization code in the Elm language. They explained the solution so beautifully, showing how the problem lay in how the Elm compiler compiled to JS and how JS managed memory. It just blew me away that this person did this in an evening, with no experience in Elm or front-end developement, and that it would've taken me days to be that precise. And they weren't even out of college yet.
Edit: This was pre-LLM, where research and reading were a big part of the job
So much of this is written with an air of superiority over the noob. Indicates a bit of an ego problem.
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.
I think the article is explicitly saying, "Ok, you're green, we know that. We're spending extra time with you to make you productive. You can help that process or hinder it, and if you're unteachable or uninspired, we'll probably end up letting you go. So here's some attitudes that get people singing your praises at this early stage."
I'm not sure if this is the last gasp of this type of thinking as AI changes the landscape. There's a good chance that the future is just noobs, perpetually begging LLMs to do better until it works.
One possibility is it makes grasping these points quickly even more important.
IME new grad hires are break even effort for me for the first 6-9 months. If it’s clear they will become positive after that I put more effort into helping them.
I like Kent Beck, but this reads as mostly boomer nonsense. What if that C player is working 3 jobs at once making 3x as much with more job security to boot. What if that C player is simply working less because they’re content working less and having less responsibility?
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.
If I hired a full time programmer and found out they had two other jobs I'd probably let them focus on those other two. If they were showing the "C" behaviors in all three jobs, they have no job security, unless they work where they can't be let go.
IME many people are in it for the love of the game. They want to get better, they want to be able to perform the “magic” the Sr people come up with. It’s fun.
I agree. A more modest way of speaking would be welcome. It takes effort to get through but the content is quite interesting: it gives pragmatic milestones.
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 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.
This is my own personal experience as a senior engineer.
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.
> It makes less sense in an era when tenure is better measured in months than years.
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.
Maybe this depends on the framing? Ex. 18 months is fairly common in some circles, but that could alternatively have been expressed as a year and a half.
6-12 months? Red flag
12-24 months, especially early-to-mid career? Not uncommon
> It makes less sense in an era when tenure is better measured in months than years.
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?
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.
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.
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.
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?
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.
> 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.
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.
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.
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.
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.
So, these self-proclaimed seniors... are they the one who signed the employment contract with the juniors? No? Then you're not their boss, you're a colleague. So stop confusing the two. Take some classes in employment law first.
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.
I don't think this reductionist view of colleagues (dividing them into categories rather than discerning individual strengths and weaknesses, team-building, empowering) is very success-oriented.
I have known a lot of people who think they are (the only) As and spend all their time bike shedding and generally dicking around with tooling and griping about patterns that they prevent everyone around them getting anything done.
I’m a “junior” senior and I’ve got a junior whose faith I’ll need to decide in a few months. How do you know if they are gonna be good? And how do you give them all of the possible tools to actually be good?
Not like I don’t have a clue, but I’ll appreciate some advice.
I think the biggest problem is that they almost dont ask questions. It’s like one question in two days. In past I had to deal with juniors who would flood me with questions, and with them it was pretty clear how they are doing (yes we talked about it).
I like to always tell interns/new hires that I measure their productivity in the amount of questions they're asking (whether its to me, seeing them roam into people's cubes or in company chat systems). AI has changed that calculus a bit since they can use the magic talking box to query the codebase with varying degrees of accuracy or as a search engine for someone's random internal wiki article/ticket from years ago.
Nevertheless though, we're blessed with a codebase that is several orders of magnitude larger than what the human brain can fully internalize so if you're trying to do anything remotely interesting, you're going to have questions.
> 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.
The flip side of this is the "high performer" who is constantly refactoring legacy code because they can only understand code that they wrote. And then add overly DRY refactors all over the place that is a pain to then make specific again.
This reminds me of a company where they wanted to put me at 100% contribution after 2 weeks.
I just told them “I can’t contribute as fast as seniors so they will just have to do more work to hit your burndown charts”
There were multiple red flags so I only lasted 2 months
> 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
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.
They should be getting praise and more mentoring, not sure why they'd worry about how the C's are being treated. It should also be clear to the C's that they are not making the cut and either they get better or they leave.
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.
Government work tends to also have structured pay scales that rise based on time worked and less so or not at all on performance. If the end result of working your tail off or doing the bare minimum is the same x% cost of living “raise”, no rational employee would put in any effort.
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.
"Scientific management" was largely developed to control soldiering, which is when workers move in lockstep at the rate of the slowest worker. Unions restore soldiering somewhat, or at least make it possible to negotiate the rate of output and the pay rate.
In the same way we have the concept of 10x, 1x and negative-x devs, other trades have faster and slower tradespeople. Anti-union American laborers usually believe that they can outrun their fellow workers while making the additional money that implies. Unions say that they're beggaring their neighbor and the end result is they will be paid the same for more work.
Most unions focus on things like seniority, which is a bit of a detriment to everything but is very reinforcing to the union. The most senior people have a lot to protect, and by the time the junior people achieve some seniority, they have invested a lot of time in the system. A union oriented around productivity or skills would have less strength as its members aged, and it would be easier to poach the high performers into a non-union position.
Indeed. And when the C is unmanaged, creating needless work for others (review code that doesn’t work, etc), making a negative contribution to forward progress, then the rest of the As and Bs are looking around wondering why this person is not fired.
Because it's not blatantly obvious what is a B versus a C until after the fact.
So you
1. Reduce morale of Bs with potential. Layoffs or just reducing opportunity affects the whole team
2. Enforce stereotype threat on Bs you've miscategorized, reducing their performance and turning them into Cs.
It probably affects the As too, but I know I'm not there yet, so I can't speak on it.
It has been interesting. The good guys got better with AI. The C grade guys mostly get confused, or follow hallucinations for a lot longer before they realise it’s a dead end. If anything AI seems to make it easier to see who is good and who isn’t.
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
"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."
Post is emblematic of a toxic workplace and reminds me why people remain stuck at a particular level - they learn the wrong lessons that “work” in their environment, and they just think “this is how it is”.
I see the article focuses on tasks and things to do or not do.
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.
> 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.
The trope of "ABC players" is tired at this point. To be honest, even talking about "players" is kind of square in my opinion. In a similar way as the saying "don't hate the player, hate the game" is square.
This perspective is more of a confession about the current state of employment in big-tech, less so than engineering in general.
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"
Compare and contrast following two A points: 1.) You make a convincing case that the task needn’t be done at all. 2.) You implement the task several ways.
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.
> 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.
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.
Reading through this, for some reason, something clicked for me that I've really struggled to understand for a long time.
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!"
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 kind of process oriented thinking eventually hits a scaling limit. Look at Meta as they struggle to scale their way out of basic problems that builder oriented labs had little trouble with. Zuckerberg bet on open weights but his company doesn't own GLM-5.2.
>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.
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.
Sounds like boomers crap, lemme guess, when you were a noob, was there any of this crap? Highly unlikely, probably no one even noticed you were sitting in the corner talking your sweet time to learn. Don’t make it harder on the new generation it’s already hard on them, thanks to you, mr.boomer. It is a job that’s making someone’s else wealthier, not a lifestyle, stop treating it like that or adding yet another source of stress. Even if they don’t perform the best that’s ok, it’s job, we are not supposed to be “maxxing” every category in life, mediocrity is mostly accepted in a lot of life categories. The crazy demands I see sometimes in job descriptions..
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.
> Growing up, in school, I did almost nothing and was consistently at the top of my class
It is clearly widely and indisputably demonstrated that many high achieving children in this situation are failures as adults because they never learn to put effort in.
Terrace tao is on the record writing about his experiences with it, and how it was only his failure in initial college admission shocked him into achieving what he has.
Ie. The point you are making is widely, clearly documented as the naive experience of someone who has not had to achieve at a high level.
> 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.
You're a manager. I am sure you have a predictable set of responsibilities, constraints
and want a “high performing” team.
Hows that working out for you?
Most advice I, personally, have seen, like this, comes from managers who want to have high performing teams, not ones that have high performing teams.
Its straight out of Be A Manager playbooks.
Whatever, you do you; but, I will emphasise that you are fooling yourself if you believe your experience is universal.
Most very successful people puts lots of effort in.
I… don't know what else to say. If you don't believe that, you are simply, objectively rallying against an extremely large well documented body of knowledge and work on the topic.
I don't know what to say, I'm sharing what has worked for me personally and you're going on about documented bodies of knowledge. I am quite possibly as least motivated by "business books" as it is possible to be.
You're trying to tell me that the advice I should give someone is "work harder not smarter". I'm not really interested in discussing with someone who is trying to convince me that what has worked for me isn't actually working.
> Companies will smartly balance the amount of work allocated to people.
Tell me you never worked in a workplace or was completely oblivious about workload of various people, without telling me.
Also, in my experience, people who consistently spend a lot of time in work tend to be very ineffective with their time. They are in the "overwork yourself, be ineffective, try to compensate by working more, be tired make more mistake, try to compensate" cycle.
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.
As someone that's a senior at a large corp, I absolutely do not want someone making the codebase more complex with the only benefit being being that it's now barely measurably faster. Especially when there are probably better things to be spending time on (spoiler, there are). Unless you're knocking like 20% off a very impactful metric, or addressing a looming scaling probably, go find something better to do than making tiny algorithm optimizations.
I've seen rewrites at startups that were slower and less stable than what we had before and everyone cheered it on like clapping seals. This stuff is rife no matter the size of the company.
At least at large orgs there's hopefully someone able to measure it. The smaller you go it's silos all the way down.
Agreed. Hardware is almost always cheaper than engineering time, until it isn't, and that's when you should spend the time on targeted optimizations.
Typically this is backwards: simpler solutions often are more optimal, and complex solutions are not. Most code is slow because it’s just poorly written. If you write it simpler, then you can make it faster and easier to read. This isn’t always true, but it is true for 99% of the low hanging fruit optimization work that’s done in practice.
Yeah good luck with that attitude over time. Most people don’t hang around in an org long enough to see that assumption scale to renting hardware than costs $900k a node a year.
Seeing what you made get to the point that that's an issue is a "a good problem". Yes, it's worth it to optimize at that point, but that's still an argument for what I consider premature optimization.
Most orgs never get to that scale
The difference can also be from having builds over night to being able to build, test and deploy in a few minutes with just a few optimisations.
And as you approach that point you should have fleet wide profiling (sample based) so it’s clear what’s worth improving.
I meant any institution where such cost of delay can be absorbed more easily. The cost of one day of that kind of work in a startup is probably more expensive than in a more established firm.
Related, but the best quality to have in a startup is knowing when and what corners to cut instead of going on these side quests.
I used to think this but you only know which were the right corners to cut after the fact. And most things are not obviously right or obviously wrong, instead it’s a slow zombie death by a thousand fuzzy signals.
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)
And sometimes the yak shaving side quest yields big improvements that were not even on the radar.
Good engineering intuition, the ability to learn new code/systems quickly and the ability to quickly validate ideas is extremely valuable.
Yes, but it does get easier with experience and some battle scars. Telling a startup to stick to the problem and not go wild with microservices and event sourcing is not exactly a hot take.
Which is exactly why you need people who have a good gut feel for such things.
I think there is nothing inherently wrong with changing code that can be improved but shouldn’t have focus as long as the other work also happens. It improves his understanding of the codebase and makes the code “better”. (Obviously, feedback needs to be taken into account.)
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.
Yeah, I can argue against it. How much time did he spend on it, how much is games on the user the (as in, is this a common use path or an uncommon one) you may have doubled the speed but did it go from several seconds to a few, it a split second to a half split second? Are there other things that should be implemented before speeding things up. Etc etc.
That person doesn’t sound like an A at all in my opinion.
Relative to my technical skills.
One of the PRs was some data visualization code in the Elm language. They explained the solution so beautifully, showing how the problem lay in how the Elm compiler compiled to JS and how JS managed memory. It just blew me away that this person did this in an evening, with no experience in Elm or front-end developement, and that it would've taken me days to be that precise. And they weren't even out of college yet.
Edit: This was pre-LLM, where research and reading were a big part of the job
Large corps value readability over algorithmic complexity too...
So much of this is written with an air of superiority over the noob. Indicates a bit of an ego problem.
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.
I think the article is explicitly saying, "Ok, you're green, we know that. We're spending extra time with you to make you productive. You can help that process or hinder it, and if you're unteachable or uninspired, we'll probably end up letting you go. So here's some attitudes that get people singing your praises at this early stage."
I'm not sure if this is the last gasp of this type of thinking as AI changes the landscape. There's a good chance that the future is just noobs, perpetually begging LLMs to do better until it works.
One possibility is it makes grasping these points quickly even more important.
IME new grad hires are break even effort for me for the first 6-9 months. If it’s clear they will become positive after that I put more effort into helping them.
LLMs may alter that break even math.
I like Kent Beck, but this reads as mostly boomer nonsense. What if that C player is working 3 jobs at once making 3x as much with more job security to boot. What if that C player is simply working less because they’re content working less and having less responsibility?
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.
If I hired a full time programmer and found out they had two other jobs I'd probably let them focus on those other two. If they were showing the "C" behaviors in all three jobs, they have no job security, unless they work where they can't be let go.
Shouldn't you measure output instead of hours spent on the job? People could be productive or not with one job as well as there.
Measuring output is what this whole post is about.
1. "If you have poor output, you won't last long. Here's what 'poor output' looks like..."
2. "But what if they have poor output because they're working three jobs?"
3. "Then I'd let them go."
You: "Cruel! Shouldn't you be measuring their output!?"
LOL
IME many people are in it for the love of the game. They want to get better, they want to be able to perform the “magic” the Sr people come up with. It’s fun.
> And when corporate needs to lay off 30% they’ll think nothing of it.
Having seen this literally play out this year: it was all of the C’s that were first to be cut shrug
> Typical Kent, trying to do the right thing, regardless of the cost. Unfortunately, this time the cost was him losing his job.
Well Kent got fired from Facebook, so maybe he wasn’t such an A player in their eyes. ;)
I agree. A more modest way of speaking would be welcome. It takes effort to get through but the content is quite interesting: it gives pragmatic milestones.
The seniors are superior to the noobs. Kind of by definition.
Yeah, the author clearly has his head up his own arse.
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.
> It makes even less sense in an era of LLMs.
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.
This is my own personal experience as a senior engineer.
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.
> It makes less sense in an era when tenure is better measured in months than years.
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.
Maybe this depends on the framing? Ex. 18 months is fairly common in some circles, but that could alternatively have been expressed as a year and a half.
6-12 months? Red flag 12-24 months, especially early-to-mid career? Not uncommon
> It makes less sense in an era when tenure is better measured in months than years.
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 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.
This is often win-win as the junior ends up with a robust list of resume bullets that help push their career forward.
> They hire juniors because they have junior level tasks that need completed.
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.
Not anymore. We give those tasks to genies and hire juniors as apprentices
>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.
We used to hire explicitly to train junior engineers in the days before the dotcom boom.
Stock options which vested over 5 years were meant to make it worth everyone's time.
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.
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.
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.
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?
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.
> 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.
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.
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.
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.
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.
So, these self-proclaimed seniors... are they the one who signed the employment contract with the juniors? No? Then you're not their boss, you're a colleague. So stop confusing the two. Take some classes in employment law first.
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.
No offense but you sound like you’d be a huge pain to work with.
If you want a slave, I'm indeed a huge pain to work with.
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.
Same. This does not align with my experiences working with early stage startups at all.
I don't think this reductionist view of colleagues (dividing them into categories rather than discerning individual strengths and weaknesses, team-building, empowering) is very success-oriented.
I have known a lot of people who think they are (the only) As and spend all their time bike shedding and generally dicking around with tooling and griping about patterns that they prevent everyone around them getting anything done.
I’m a “junior” senior and I’ve got a junior whose faith I’ll need to decide in a few months. How do you know if they are gonna be good? And how do you give them all of the possible tools to actually be good? Not like I don’t have a clue, but I’ll appreciate some advice.
I think the biggest problem is that they almost dont ask questions. It’s like one question in two days. In past I had to deal with juniors who would flood me with questions, and with them it was pretty clear how they are doing (yes we talked about it).
I like to always tell interns/new hires that I measure their productivity in the amount of questions they're asking (whether its to me, seeing them roam into people's cubes or in company chat systems). AI has changed that calculus a bit since they can use the magic talking box to query the codebase with varying degrees of accuracy or as a search engine for someone's random internal wiki article/ticket from years ago.
Nevertheless though, we're blessed with a codebase that is several orders of magnitude larger than what the human brain can fully internalize so if you're trying to do anything remotely interesting, you're going to have questions.
> 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.
What if you’ve become too curious and critical of yourself?!
You're now a C.
The flip side of this is the "high performer" who is constantly refactoring legacy code because they can only understand code that they wrote. And then add overly DRY refactors all over the place that is a pain to then make specific again.
This reminds me of a company where they wanted to put me at 100% contribution after 2 weeks. I just told them “I can’t contribute as fast as seniors so they will just have to do more work to hit your burndown charts”
There were multiple red flags so I only lasted 2 months
> 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
I think he worked at Facebook for a long time, which is… pretty toxic by some standards.
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.
They should be getting praise and more mentoring, not sure why they'd worry about how the C's are being treated. It should also be clear to the C's that they are not making the cut and either they get better or they leave.
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.
Government work tends to also have structured pay scales that rise based on time worked and less so or not at all on performance. If the end result of working your tail off or doing the bare minimum is the same x% cost of living “raise”, no rational employee would put in any effort.
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.
"Scientific management" was largely developed to control soldiering, which is when workers move in lockstep at the rate of the slowest worker. Unions restore soldiering somewhat, or at least make it possible to negotiate the rate of output and the pay rate.
In the same way we have the concept of 10x, 1x and negative-x devs, other trades have faster and slower tradespeople. Anti-union American laborers usually believe that they can outrun their fellow workers while making the additional money that implies. Unions say that they're beggaring their neighbor and the end result is they will be paid the same for more work.
Most unions focus on things like seniority, which is a bit of a detriment to everything but is very reinforcing to the union. The most senior people have a lot to protect, and by the time the junior people achieve some seniority, they have invested a lot of time in the system. A union oriented around productivity or skills would have less strength as its members aged, and it would be easier to poach the high performers into a non-union position.
Indeed. And when the C is unmanaged, creating needless work for others (review code that doesn’t work, etc), making a negative contribution to forward progress, then the rest of the As and Bs are looking around wondering why this person is not fired.
Yes, but the takeaway is the opposite if what you're implying. Working with C's is draining for everyone and a drag on morale.
Because it's not blatantly obvious what is a B versus a C until after the fact.
So you
1. Reduce morale of Bs with potential. Layoffs or just reducing opportunity affects the whole team 2. Enforce stereotype threat on Bs you've miscategorized, reducing their performance and turning them into Cs.
It probably affects the As too, but I know I'm not there yet, so I can't speak on it.
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.
It has been interesting. The good guys got better with AI. The C grade guys mostly get confused, or follow hallucinations for a lot longer before they realise it’s a dead end. If anything AI seems to make it easier to see who is good and who isn’t.
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
"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.
Post is emblematic of a toxic workplace and reminds me why people remain stuck at a particular level - they learn the wrong lessons that “work” in their environment, and they just think “this is how it is”.
I see the article focuses on tasks and things to do or not do.
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.
> 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.
Some new hires end up cleaning the mess that their manager left behind from back when they were the noob…
Generally A players work for C players. B players tend to work for the government.
The person who the article sounds like a complete moron, though.
The trope of "ABC players" is tired at this point. To be honest, even talking about "players" is kind of square in my opinion. In a similar way as the saying "don't hate the player, hate the game" is square.
Yeah, someone is pulling up the ladder here.
This perspective is more of a confession about the current state of employment in big-tech, less so than engineering in general.
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.
Sounds very similar to that leaked Mr. Beast document.
Compare and contrast following two A points: 1.) You make a convincing case that the task needn’t be done at all. 2.) You implement the task several ways.
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.
> 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.
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.
Details are important. Tasks are details.
Reading through this, for some reason, something clicked for me that I've really struggled to understand for a long time.
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 you can't help your employer to be more profitable, it's not meaningful to talk about this.
It is all about capitalism
at this point i'd take people who complete tasks
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 kind of process oriented thinking eventually hits a scaling limit. Look at Meta as they struggle to scale their way out of basic problems that builder oriented labs had little trouble with. Zuckerberg bet on open weights but his company doesn't own GLM-5.2.
>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.
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.
It’s interesting that you have to be an A to tell the rest apart.
And good luck if you have a lot Bs that believe they are As.
Sounds like boomers crap, lemme guess, when you were a noob, was there any of this crap? Highly unlikely, probably no one even noticed you were sitting in the corner talking your sweet time to learn. Don’t make it harder on the new generation it’s already hard on them, thanks to you, mr.boomer. It is a job that’s making someone’s else wealthier, not a lifestyle, stop treating it like that or adding yet another source of stress. Even if they don’t perform the best that’s ok, it’s job, we are not supposed to be “maxxing” every category in life, mediocrity is mostly accepted in a lot of life categories. The crazy demands I see sometimes in job descriptions..
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.
> Growing up, in school, I did almost nothing and was consistently at the top of my class
It is clearly widely and indisputably demonstrated that many high achieving children in this situation are failures as adults because they never learn to put effort in.
Terrace tao is on the record writing about his experiences with it, and how it was only his failure in initial college admission shocked him into achieving what he has.
Ie. The point you are making is widely, clearly documented as the naive experience of someone who has not had to achieve at a high level.
> 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.
You're a manager. I am sure you have a predictable set of responsibilities, constraints and want a “high performing” team.
Hows that working out for you?
Most advice I, personally, have seen, like this, comes from managers who want to have high performing teams, not ones that have high performing teams.
Its straight out of Be A Manager playbooks.
Whatever, you do you; but, I will emphasise that you are fooling yourself if you believe your experience is universal.
Most very successful people puts lots of effort in.
I… don't know what else to say. If you don't believe that, you are simply, objectively rallying against an extremely large well documented body of knowledge and work on the topic.
I don't know what to say, I'm sharing what has worked for me personally and you're going on about documented bodies of knowledge. I am quite possibly as least motivated by "business books" as it is possible to be.
You're trying to tell me that the advice I should give someone is "work harder not smarter". I'm not really interested in discussing with someone who is trying to convince me that what has worked for me isn't actually working.
> Companies will smartly balance the amount of work allocated to people.
Tell me you never worked in a workplace or was completely oblivious about workload of various people, without telling me.
Also, in my experience, people who consistently spend a lot of time in work tend to be very ineffective with their time. They are in the "overwork yourself, be ineffective, try to compensate by working more, be tired make more mistake, try to compensate" cycle.