Generate, Then Interrogate: How I'd Learn to Code Today

In 2017 I lost a whole weekend to a project that wouldn't run. Not writing it. Just running it. My Python was pointing at the wrong interpreter, and the thing is, I didn't even know that was a thing that could go wrong. So I did what you do when you're broke and alone and stuck late at night: I read forum threads until 2am, changed settings at random, and slowly lost my mind. Nothing worked. I closed the laptop on Sunday night honestly wondering if I was just too dumb for this. Nobody in my apartment to ask. No chat window to paste the error into. Just me, Google, Stack Overflow, Reddit, and something like four hundred open tabs.

I was 27. Eight months earlier I'd walked out of a high-school history classroom, and I was teaching myself to code at night after barista shifts, living on basically nothing. People ask if I'm glad I did it the hard way, and my honest answer is: about half of it, yeah. But that weekend? That weekend taught me nothing except despair, and if you handed me a time machine I'd give every hour of it to an AI and not lose a wink of sleep.

Quick word to the person reading this at midnight, half-convinced it's already too late to bother. It isn't. I know the fear. Everybody and their newsletter is telling you the robots write all the code now, so why start. Hang on, because I think that's exactly backwards, and I've got the scar tissue to explain why.

The suffering that taught me nothing

The hard concepts were never the hard part. Recursion is hard whenever you meet it. So are pointers, so is async, so is basically everything worth knowing, and honestly, wrestling that stuff is the good kind of hard. You come out the other side a little smarter than you went in.

No, the thing that nearly ended me was the dumb stuff. The environment. The tooling. The rabbit holes where you're trying to do one small thing, and the fix for the first error summons a second error that sends you three towns over, until you've completely forgotten what you sat down to build. That weekend I lost to a mispointed interpreter didn't test whether I could think like an engineer. It tested whether I happened to know one specific incantation, and there was nobody around to whisper it to me. I didn't know what I didn't know. I hadn't even leveled up my Google-fu yet, so half my searches came back with nothing useful at all.

Here's what kills me about it now. If I hit that exact wall today, I'd paste the error into an assistant, get walked through it in about four minutes, and be back to the actual learning before my coffee went cold. That's the case for AI, and I don't make it grudgingly. I make it because I lived the other version. Being able to type a question in plain English and get a patient answer back, instantly, like a help desk that never sighs at you? When you've done it the lonely way, that isn't a small thing. It's kind of miraculous, and I already can't quite remember how we lived without it.

Where I'd let the machine carry me

So where would I lean on this stuff if I were 27 and starting over? A few specific places, and I wouldn't feel an ounce of guilt about any of them.

First, getting unstuck when there's nobody to ask. The single biggest gift you've got that I didn't is that the 2am wall is a lot lower now. Back then, a single dumb blocker could stall me for days, not because it was hard but because there was nobody to ask, and half the time I'd just give up and go to bed no closer than when I started. Now you've got something that'll explain the same idea five different ways until one of them finally lands. A lot of what people call tutorial hell, that swamp where you finish course after course and still can't build a thing on your own, is really just loneliness wearing a technical costume. Having something patient to ask genuinely helps.

Second, environment setup and boilerplate. The config. The toolchain. The tenth form component that looks exactly like the nine before it. That is not where the learning lives, so hand it over. I typed my hundredth CRUD form by hand, the slow honorable way, and I promise you I remember nothing from it except a faint resentment. That hour would've been better spent reading somebody else's good code.

Third, and this is the underrated one: reading unfamiliar code with a tutor sitting right next to you. Point a decent assistant at a file you don't understand, ask it to walk you through line by line, and suddenly you've got the patient explainer I'd have killed for at 2am. As of August 2026 the options are crowded and, annoyingly, all pretty good. Copilot lives in most editors. Cursor rebuilt the whole editor around the thing. Anthropic's Claude Code runs from your terminal and will go off and edit your files while you watch, which still feels a bit like witchcraft. You don't need to agonize over the "right" one. You need one, and you need to treat it like a tutor instead of a vending machine. Which, yeah, brings me to the part I actually care about.

Where leaning on it robs you

Now the flip side, and it's the one I watch juniors fall into pretty much every month.

If you let the assistant write code you don't understand, and then you ship it, you didn't learn anything. You borrowed an answer. And that loan comes due later, always, usually at the worst imaginable moment. Production. A Friday. Somebody from another team standing behind your chair.

Addy Osmani, who spent years leading developer experience at Google, has a name for this that I've straight-up stolen for my code reviews: comprehension debt. The code runs today, but nobody on the team can say why, and that gap gets a little wider every time somebody stacks another floor on top of it. For a beginner it's even nastier, because you're not just racking up debt in some codebase you can quit and walk away from. You're racking it up inside your own head, in the exact spot your skill was supposed to be growing.

The fundamentals that actually got me hired had nothing to do with typing speed. They were about what I did when the thing broke. Can you read a stack trace and come up with a real theory about what went wrong? Can you reason your way to why a function keeps handing you undefined, instead of just poking at it until the red goes away? Do you actually have a model in your head of what your program's doing, or just a hopeful feeling? That's the muscle. It only grows while it's under load, which means it only grows in the uncomfortable stretch where you don't know the answer yet. An assistant that deletes every second of that not-knowing also deletes the exact thing the not-knowing was building. Kind of a devil's bargain, if you're not paying attention.

I'm not romanticizing pain here, by the way. I already told you which pain was pointless: the broken-interpreter weekend that taught me nothing but how to hate myself a little. Debugging something from first principles until it finally clicks is the complete opposite. It isn't a pointless obstacle blocking you for no reason, the way a broken config is. It's the actual job you're going to get paid to do.

The one rule I wish somebody had handed me

If you take one thing from a self-taught senior who's now watched a whole lot of people try this: generate, then interrogate.

Never accept a line of code you can't explain back to another human. Let the assistant write it, fine. Then make understanding it your job before it goes anywhere near your project. Ask why it went with this approach over another. Ask what breaks if you change one line. Close the window and try to write it again from memory, and squirm a little when you can't. Treat the tool like a sparring partner you're trying to out-think, not an oracle you nod along to.

The difference this makes shows up over a year in a way that's almost unfair to watch. Two juniors, same tool, twelve months, and they come out as completely different engineers. One asked "why" every single time and slowly built a real map of how things work underneath. The other typed "just make it work" every single time and built nothing under the surface, and it shows the very first moment the output is wrong and there's nobody around to ask.

What this looks like from my side of the interview table

I interview engineers now. A lot of them self-taught, most of them AI-native, and I want to be really clear about something, because it cuts against a fear I hear constantly: I am not trying to catch you using AI. I use it every day. I assume you do too. Testing whether you can code with the assistant taken away would be like testing a carpenter by hiding his nail gun and watching him sweat. Pointless.

What I'm actually trying to figure out is whether there's an engineer under the tooling.

So I'll ask you to walk me through code you wrote and tell me why you made a particular call. I'll drop a bug into something and watch how you hunt it. I'm not waiting for the right answer, I'm watching the process, the way you make a guess and close in. The people who fall apart in that room aren't the ones who learned with AI. They're the ones who used it to skip the learning. Take the assistant away for fifteen minutes and there's just nobody home. They can produce code, sure, but ask them to defend a choice, or chase a bug through it, and the room goes real quiet.

And I'll be straight about the market, because telling you it's easy right now would make me a liar and you'd see through it anyway. From where I sit doing the hiring, the entry-level door is the narrowest I've ever seen it. Fewer junior openings than there used to be. Way more applicants stacked against each one. Not a lot of patience left for a profile with nothing to show. I can't hand you a clean stat I'd stake my name on, so I'll just tell you what I see with my own two eyes: the juniors getting hired are the ones who can prove, in a live back-and-forth, that they understand what they built. Fundamentals aren't a nostalgia trip. They're just scarce now. And scarce, in a market, is another word for valuable.

How I'd actually spend my first six months today

Drop me back into that 27-year-old's crummy apartment with today's tools, and here's what I'd change, and what I wouldn't touch.

I'd still pick one language and learn it properly. Python, again, for me. I'd still build real things with my own two hands. And I'd still make myself sit in the problem before I reached for help, because that discomfort is the whole workout, not a bug in the plan. My rule would be dead simple. Try it myself for twenty minutes. Form an actual guess about what's wrong. Only then bring in the assistant, and even then, make it explain the fix instead of just doing it for me.

I'd point AI straight at everything that used to eat my nights for no good reason. The environment nightmares. The boilerplate I could type in my sleep. The cryptic error that has nothing to teach me and just wants my Saturday. And I'd guard, with my life, the parts that actually turned me into an engineer: the debugging, and the slow work of building a picture in my head of why a thing behaves the way it does. Then I'd talk my way through my own code out loud, alone in the room like a weirdo if that's what it took, until I could explain every line without the crutch. Because that's the exact muscle someone like me is going to press on when you're sitting across the table trying to get the job.

The tools are so much better than anything I had. That was never the question. The question is whether you use them to build yourself a brain or to rent one by the month. I did it the slow way because there was no other way. You've got a faster way now, and it's real, but it only pays off if you stay awake while you use it. Generate, then interrogate. That's the whole thing. Now go get stuck on purpose.