Hey N00b, Nobody Hired You to Complete Tasks

TLDR: Senior engineers don't care how many tasks you close, they care about the trajectory of your growth. Kent Beck lays out, with unusual honesty, the A/B/C sorting game that happens in the background during your first months on a team. Knowing the rules changes how you play.

Summary: Kent Beck opens this piece with a blunt admission that most experienced engineers know but rarely say out loud: your manager or tech lead could finish your task pile in a fraction of the time it takes to onboard you through it. You weren't hired to close tickets today. You were hired as an option on the engineer you'll become in a few years. That framing alone reorients everything.

From there Beck describes the two-stage sorting process that happens in any engineering org. The first stage is separating B's from C's, which is mostly about not creating chaos. Did your code work? Did you communicate what you were doing? Did you finish within a reasonable range of the estimate? Did you avoid dumping extra work on reviewers, on-call engineers, or the devops team? Sending a C signal once is understandable. Sending the same one twice puts you in a different bucket.

The second stage is figuring out whether a B is actually an A, and this is where things get interesting. A's don't close more tasks. They learn more from each one. Beck lists a range of behaviors that signal this learning rate: questioning whether the task should exist at all, finding the 10% of the work that delivers 90% of the value, shipping a string of small focused diffs rather than one big one, writing up what was learned in a way others can use, being a sharp and engaged code reviewer. All of these take more time than just closing the ticket, but that's the point.

What I find most honest about this piece is the acknowledgment that "extra" time has to come from somewhere, and Beck doesn't pretend there's an easy answer. He promises a follow-up on time management and task queue strategies, which means this is deliberately the first chapter of a longer conversation. Even without the follow-up, the mental model here is worth internalizing: you're not measured on output, you're measured on the slope of your improvement curve.

There's also a sharp warning buried in the middle. Any attempt to game the system, claiming work you haven't done, inflating your ticket count, marking things done before they are, immediately flags you as a C. Beck says to assume the system is ungameable. That's both practical advice and a character statement.

Key takeaways:

Senior engineers assess new hires on growth trajectory, not task volume
The first filter is reliability: does your code work, do you communicate, do you avoid creating incidents
The second filter is learning rate: do you extract insight, simplify, question scope, ship incrementally
A signals all require spending more time per task, not less
Gaming the system signals exactly the wrong thing about your character
You were hired as an option premium on your future self

Why do I care: As someone who has reviewed a lot of pull requests and mentored people across different seniority levels, this framing matches reality almost exactly. The juniors who grow fastest are not the ones who close the most tickets, they're the ones who ask good questions, write thoughtful PR descriptions, and come back the next week having clearly thought about the feedback they got. Beck puts a clean framework around something most seniors sense but rarely articulate. This is worth sharing with anyone who just joined a team or who manages people who recently did.

Hey, N00b, We Didn't Hire You to Complete Tasks