Getting good at programming requires not programming

The internet's model developer looks like this: eight hours at work, then a side project, then a course at night, then open source on the weekend, then a newsletter about how you did all that.

Nobody lives like this. A few people perform it for about eleven months and then quietly disappear, and the ones still posting about it are usually selling a course to people who feel bad for not keeping up.

So here's a claim that sounds contradictory and isn't: a real part of getting good at this is not doing it. Not as a reward. Not as recovery so you can grind harder. As an actual input to the work.

The math of the ninth hour#

You already spent eight hours today thinking about software. That was not a warm-up.

The question isn't whether more study would help in the abstract — it's what hour nine is actually worth compared to what it costs. And hour nine is your worst hour. You've spent the day's supply of focused attention. What happens instead is a simulation of studying: a tutorial playing while you scroll something else, three chapters read and none retained, a side project where you rename files for forty minutes because deciding is too expensive right now.

You feel productive. You are mostly just awake near a computer.

One hour of deliberate study, when you still have something left, beats four hours of tired grazing. Not because "quality over quantity" is a nice slogan, but because the tired version isn't learning at all — it's the appearance of learning, bought with the hours that were supposed to restore you.

The bug you solve in the shower#

Every developer has had this happen: you fight something for three hours, give up, go do something else, and the answer arrives while you're washing dishes.

That's not folklore. It's the incubation effect, and it has a meta-analysis behind it — setting a problem aside measurably improves solution rates, and the improvement is larger when the preparation was longer, which is exactly your situation after three hours of failing at it.

The same paper contains the detail that makes this actionable: incubation works worse when you fill the break with another cognitively demanding task. So the "break" where you close the bug and open a different codebase isn't a break. Walking, cooking, the gym, a game that doesn't feel like work — those are the conditions the effect needs.

Walking in particular has its own research: in a set of Stanford experiments, the large majority of participants generated more novel ideas while walking than while sitting, and the effect carried over to sitting down to work shortly afterward. Indoors on a treadmill facing a blank wall worked too, so it isn't about nature or fresh air. It's about not being parked in front of the problem.

The uncomfortable implication for grind culture: some of your best engineering happens specifically when you are not at the keyboard, and you cannot get it while at the keyboard. Refusing to leave is refusing the tool.

Sleep is a performance setting, and it's the first thing you spend#

Here's the trade nobody names honestly. The extra study hour doesn't come out of nowhere. It comes out of sleep, essentially always, because it's the only unguarded block left in the day.

And sleep loss degrades precisely the faculties this job runs on: sustained attention, working memory, and error detection. You don't feel it as "I am impaired" — you feel it as normal, which is the dangerous part. The tell isn't sleepiness. It's the three-hour debugging session on Wednesday for something you'd have caught in ten minutes on Monday.

So the grind is self-defeating in the most literal way: you buy an hour of low-grade study by paying for it with the quality of the next day's eight hours. That's a terrible exchange rate, and you make it every single night.

The part that isn't about productivity#

The WHO and the ILO have put numbers on the far end of this. Working 55+ hours a week is associated with a 35% higher risk of stroke and a 17% higher risk of dying from ischemic heart disease versus a 35–40 hour week, and they attribute hundreds of thousands of deaths a year to it. Long hours are not neutral. They're a documented occupational hazard, in the same category as any other thing at work that can kill you slowly.

I don't think most devs reading this are at 55 hours. But "8 to 6, then two hours of side project, then a course, plus Saturday" is 55 hours, and it doesn't feel like 55 hours because part of it is labeled passion.

What you're actually protecting#

Now the real reason, which has nothing to do with metrics.

Most of us got into this because something about it was fun. You made a thing appear on a screen and it felt like a small superpower. That feeling is the engine — it's the reason you'd read documentation on a Sunday for no reason at all, and that unforced curiosity is what made you good in the first place.

Grind culture eats that engine. When every hour must be justified by advancement, curiosity stops being curiosity and becomes unpaid overtime with a self-improvement label. The Sunday reading turns into an obligation you're behind on. The side project stops being a toy and becomes a portfolio item with a deadline you invented and now resent.

A hobby that has to produce ROI is just a second job with worse pay and no colleagues.

And when it goes, it's hard to get back. I've watched people who genuinely loved this work optimize their way into hating it — not because they stopped being able to do it, but because they turned it into a permanent performance nobody was even watching.

The video game is not what's stopping you from becoming senior. The series is not the reason you didn't get promoted. Those things are the reason you'll still want to do this at 45.

So what does the week actually look like#

Roughly:

• Eight hours of work. That's the main event, and it's where most of your real skill growth happens anyway — production systems, code review, other people's constraints. Nobody got senior from tutorials.
• About an hour, most days, on one thing you chose deliberately. One thing. Not six open tabs. Depth on a single topic for a month beats a shallow sweep of the ecosystem, and it's also the only version you'll still be doing in week three.
• Some days, zero. By design, not by guilt. Skipping Thursday does not reset your progress.
• The rest belongs to you. The gym, the walk, the game, the series, people who don't work in tech. Not scheduled as "recovery for peak performance" — just yours, because a life made entirely of inputs to your career is a bad life even when the career goes well.

Two obvious caveats, because I don't want this read as an excuse to coast. There are legitimate sprints: switching careers, learning enough to land the first job, a launch week, a genuine deadline. Sprints are fine — sprints are how you get through a specific thing. The failure mode is making the sprint permanent and calling it discipline.

And the hour has to be real. An hour of actual, uncomfortable, I-don't-understand-this-yet study is worth more than a full evening of content that agrees with what you already know.

The practical move#

This week, pick a time to stop. An actual clock time. When it arrives, close the laptop even if you're not finished — especially if you're not finished, because unfinished is what your background processing needs to do its thing.

Then go do something with no professional justification whatsoever.

You'll notice two things. Bugs that owned you on Thursday become obvious on Friday morning. And programming starts being interesting again, instead of a treadmill you're afraid to step off.

That second one is the whole point. The people who are excellent at this in their forties aren't the ones who ground the hardest at 25. They're the ones who never stopped finding it fun — which required, more than anything else, not doing it all the time.

Related: meditation as a working tool, and why the anxiety being sold to you is a product, not a forecast.