Happier development

On programming "the good old fashioned way"

I have been marinating in some ideas for a few weeks now after having conversations with my manager. I suspect these suggestions will be disagreeable to a lot of folks, but hear me out.

What I’ve been feeling

The past few months have been a drag. I’m spending the overwhelming majority of my time reading code. 85-95% of it. Cursor’s code, Claude’s code, my coworkers’ code. Far more code than one person was ever meant to read.

It’s exhausting. But that’s what the job demands. The problem is context: if I spend 60 minutes writing code and 60 minutes reading my code, when I read it I’ve already seen it before. If I spend 60 seconds prompting Cursor, go get a snack, and spend 60 minutes reading the code, I’m learning it fresh. I have to figure out where the code starts and ends, what the edge cases are, think up the constraints that Opus 4.6 put in place on my behalf.

Think of how much time major open source projects spend on contributor onboarding. Curating good “new contributor” tickets, dedicating time to reviews, and managing questions. Except you’re the project owner, the PR reviewer, and the new contributor at the same time. You’re figuring out how the new chunk of project is structured and what it’s doing. You’re checking that best practices were followed, and reasoning about edge cases.

This isn’t the computer science that I signed up for.

It’s not that I don’t like it. I do like it. But in the same way that I don’t want to sit for over 11 hours watching a Lord of the Rings director’s cut marathon, I don’t want to spend all my time doing the most mentally grueling part of the job.

On hiring

My manager said something to me the other day that really got stuck in my mental teeth, so to speak. We were talking about hiring junior engineers, and he remarked that a senior engineer and a junior engineer both prompt Claude at the same speed. There’s maybe an argument to be made that the senior engineer types more, or the junior engineer is less likely to one-shot a task, but more or less the rate at which you can prompt an LLM is bounded by how fast you can type.

I think this is an important idea. As companies make the naïve decision to cut back on hiring junior engineers (who needs an intern when you have Claude), nobody is thinking about the baby being thrown out with the bathwater: prompting Claude isn’t the hard part.

When I was a teenager, I taught myself to program. It was an exceedingly brute-force approach. I would load up a floppy disk on my dad’s computer with zip files I downloaded from Planet Source Code¹ over the dialup internet, carry them upstairs to my bedroom, unload them onto my desktop, and start reading through them one by one. I wasted so much time spinning my wheels, grinding through problems that I didn’t understand. Thankfully, I was motivated and enthusiastic enough to become mostly-competent.

I think about how much more effective I could have been if I just had a mentor. Someone to say, “your string manipulation function is slow because it runs in O(N^N) time,” or “instead of HashTable in .Net, use Dictionary.” I probably spent a thousand hours wasting my own time.

Many folks haven’t had the luxury of learning the hard way. Perhaps they struggle more to independently solve problems, or they don’t do well with learning by example. But there’s no excuse anymore: you can easily learn all of these things with an LLM.

In fact, if we assume the junior engineers are still mature adults (they should be), then following simple rules is enough to give them the competence to complete pretty much any task: read your code, write tests, document what you do, understand the constraints, challenge your assumptions. Easy.

My first insight is this: you need more junior engineers. Hiring people who are good programmers isn’t enough. It’s not about who is the smartest anymore, it’s about enthusiasm. Hiring a team of engineers that biases senior has become an active detriment to your ability to move fast. Five junior engineers with Claude and some human guidance will go a lot further than two Staff+ engineers trying to type faster to their LLM of choice.

It’s baffling to see companies cut back on hiring junior engineers. It assumes a lack of maturity and a propensity for problems. That’s not a junior engineer’s fault! Rational, mature adults (which your hiring pipeline should already be biasing towards) are perfectly capable of doing the work you need them to do. They will make mistakes. But in an era where the problems have shifted from engineers making mistakes to LLMs making mistakes and engineers failing to catch them, I suspect you’re not going to see any real bump in product quality, reliability, or technical rigor by only hiring senior folks.

On Staff+ engineering

As a Staff+ engineer, your job is to make the people around you better. The org mostly doesn’t (or rather, mostly shouldn’t) need another person writing code.

So why are you using Claude Code?

My shelves are stuffed with books like Staff Engineer: Leadership beyond the management track by Will Larson and The Product-Minded Engineer by Drew Hoskins, and none of them tell you how you should be writing more code.

Two of my favorite engineering thinkers get to have their books smooch on my shelf

Being Staff+ means:

• Establishing patterns for development

• Anticipating the needs of the company in the future

• Planning in the direction of the company’s needs

• Coordinating outside your team and building consensus

• Talking to customers

With relatively few exceptions, being Staff+ means you’re working with people more than you’re working with the machines. Especially now, when the machines can do their own thing, they don’t need you. Your skills should be making junior engineers 10× more effective, not by being 10× more productive yourself.

I’m not just saying this without putting in the work myself. Last week, I stopped using tab completion in Cursor. I’ve stopped using Claude Code, and I’m only using Agent mode in Cursor for tasks where the code isn’t super important (e.g., I’m writing a one-off script, or it’s CSS for an internal service, or other inconsequential tasks like that).

At first I was frustrated. I still get a twinge of “Ugh, I don’t want to type” when I start a new task. But you know what? It’s been refreshing. Programming doesn’t feel exhausting any more. I feel more motivated to log on in the morning.

The fatigue of using an LLM, as it turns out, was making me hate work. The handful of dopamine hits from having Claude one-shot something, quite frankly, aren’t worth the distillation of my remaining time into hyperfocused code reviews.

What’s broken

These past couple months have shown me that we’ve all been in kind of a mania. Vibe coding kind of wrecked me as a person. It’s such a relief to build something fast, but then fixing issues creates a crust of tech debt that’s hard to unravel. At some point, the cost of getting the LLM to do the job right is as high as or higher than the cost of just rewriting it “the old fashioned way”. I certainly find myself getting sucked into the trap of trying to ride the high of having the LLM one-shot the fix instead of just doing it myself.

But here we are, in a world where we say that engineers can get so much more work done, that everyone can be more productive. But then we also say we need to bias more senior, that it’s more critical than ever to have Staff+ talent, that we can’t trust the models. We can’t have it both ways, chat.

If Staff+ folks grind away on the same tasks that we put junior engineers on, the title is, quite honestly, meaningless. More senior at what…prompting Claude? Most of the college new grads looking for work are better at prompting than folks who have 20 years in the industry: us old timers didn’t have to prompt our way through college.

Consider: you can hire a staff engineer or two L1 engineers. In either case, you’re probably closing 1-2 tickets a day. Hire all three, and the staff engineer (in theory) should make the L1 engineers close 3-6 tickets a day. The staff engineer is serving the mentorship role that I wish I’d had when I was a shitty 13-year-old running up and down the steps with a floppy disk.

If you’re Staff+, my advice is to take an LLM vacation. Spend a couple weeks working without vibe coding. Stop using agent mode when you don’t need to. Stop using tab completion. Reconnect with the keyboard shortcuts that you’ve lost muscle memory for. Refocus on pushing your org in the direction you think it should be going in. See how it makes you feel, and what the impact is on the folks in your orbit.

1. Rest in peace, sweet prince