I asked a trainee "which language should I learn first?" and answered it the way everyone does — a language name. He was stuck 3 months later, having written a lot of code that didn't stick to anything. So I stopped answering that question. I started asking a different one first — and once that one lands, the language choice barely takes any deliberation at all.
TL;DR: "which language" is the question that reliably produces an answer (search gives you dozens of ranked comparisons in seconds); "what do you want to build" is the question that actually predicts whether someone finishes — and once it's answered, the language choice is settled in 5 minutes.
What actually happened
I train programming beginners. For years, the first thing almost every trainee asked me was "which language should I start with?" I used to answer it directly — Python, JavaScript, whatever fit the surface details of their situation. It felt helpful. It wasn't.
After watching hundreds of trainees hit the same wall, I noticed the pattern: the people who get stuck on language choice have almost never actually answered the question that comes before it — what do you want to build? So I stopped leading with the language question and built a 6-question intake instead. Below is what happened when each question landed, or didn't, with real trainees.
One trainee had a fully concrete goal from day 1: "I want to automate listing items on a flea-market app." Landing on Python took 5 minutes. He skipped the textbook's chapter order entirely, cherry-picked only the chapters he needed, and by 3 months in had a working self-built tool running.
A different trainee spent his first 3 months doing "Python, for no particular reason," working through a beginner textbook — hands moving, nothing sticking. When I finally asked him directly what he wanted to build, the honest answer was that he'd never once considered it. We set a concrete goal together — "build a web service as a side project" — and the quality of his learning changed starting the following week. Same textbook chapter, but now he could ask "where in my own service would I use this."
# the diagnostic I actually run, in order
1. What do you want to build? <- if this is blank, stop here
2. Can you explain it in 1 sentence, in
in 30 seconds, to someone who isn't
technical? <- tests borrowed vocabulary vs real goal
3. Was this goal handed to you, or is it
yours? <- both work, if #2 eventually passes
4. What's the exact moment you got stuck
last time you tried this? <- not "it was kind of hard"
5. How much study time do you actually
have, per day, on average?
6. (only now) What language fits what
you just told me?
That's not pseudo-code for effect — it's the literal order I run through in an intake conversation. The language name is the last thing mentioned, not the first.
The number that changed my mind
Here's what I mean by "5 minutes." Once purpose is genuinely fixed, language choice stops being a debate — it's close to automatic. Below is the pattern across trainees, before and after question 1 actually landed:
| trainee | time to language decision | outcome |
|---|---|---|
| flea-market automation goal | 5 minutes | 3 months later: working self-built tool |
| "Python, for no reason" (goal never asked) | 3 months of stalled effort | changed the week after goal was set |
| environment-setup burnout case | never got there | 1 week lost, quit before writing a line of code |
| naptime parent, 30 min/day | fast, once time constraint was named | used every session at high density |
Available study time matters just as much as purpose, and it changes which material actually fits. Someone who can only grab 1 hour after work on a weekday and someone who can block out 8 hours on a weekend will not progress through the same beginner textbook at the same rate, even with identical goals. Hand the 1-hour person a chunk of material that needs a full 8 hours to click, and they close the book mid-thought every time, forgetting where they left off before the next session. Hand the 8-hour weekend learner a textbook broken into fragments of 15 minutes each, and the pacing feels too thin to hold their attention. The lesson isn't "more time is better" — it's that the fit between available time and chunk size has to be deliberate, not accidental.
The step everyone wants to skip — "what do you actually want to build" — is the one that predicted whether, in every case I ran this on, the next 3 months were productive or wasted. Skipping it doesn't save time. It just moves the cost to later and makes it bigger.
The rule I extracted
People start their search with a language name not because it's the right first question, but because it's the question that reliably produces an answer. "What do you want to build" produces zero search results — you have to look inward, which feels uncertain — while "which language" produces dozens of ranked comparison articles in seconds. The comfort of "I researched something" gets prioritized over the discomfort of an unanswered internal question, even though the research does almost nothing for actual learning speed.
Asking "which language" before "what do you want to build" is like asking "which train should I take" before deciding where you want to go.
The goal doesn't need to be self-generated, either. One trainee's goal was handed to him by his employer — "you're now involved in modifying our internal system" — not chosen. The first few weeks were pure obligation. But working inside the existing codebase, he developed his own opinion: "this part of the code is confusing, I'd write it this way." The borrowed goal became a functioning one once he translated it into his own words.
And "finishing" isn't a talent problem — it's 3 separately diagnosable failure modes, and the fix is different for each:
- Environment-setup failure. Error messages don't map to anything findable by search. One case: a beginner spent a full 1-week stretch on environment setup, exhausted himself, and dropped out before writing a single line of code. Fix: restart in a browser-only, no-install environment (plain JavaScript, or a service like Progate) specifically to remove setup from the equation.
-
"I understand
if/forbut don't know what to write." The learner knows the syntax but freezes at a blank editor because they can't decompose the problem. Fix: tiny, single-answer tasks ("create one variable and print it") instead of an abstract assignment. - Motivation failure. Technically progressing fine, but "what is this even for" goes blank and learning stops outright. Fix: stop talking about the technology and go back to the original goal.
A trainee who hit failure mode 1 on PHP environment setup — not PHP the language — was moved back into simple JavaScript work first rather than straight back into PHP. It looked like a detour. It led to faster net progress. A different trainee retried PHP without first naming what had actually stopped him, hit the identical error message on the second attempt, and concluded "I'm just not cut out for this" — when the real cause was re-deriving the same setup steps from zero each time, not aptitude. Naming the exact moment you got stuck, instead of "it was kind of hard," is what predicts whether you hit the same wall twice.
AI changed the stuck-loop, not the fundamentals
AI changes what happens the moment a beginner gets stuck. It doesn't change the two things that were already true before AI existed: learning without a purpose still doesn't stick, and building something you experience running with your own hands is still necessary.
One trainee submitted assignments with AI-written code he couldn't explain out loud when asked. A different trainee, using the same tool, made a habit of re-asking "why does this code work" every single time before moving on. By 3 months in, that second trainee could fix errors unassisted. The difference wasn't AI usage — it was whether the order was "think first myself → ask AI → check the answer against my own attempt," instead of skipping straight to asking AI.
Try it yourself
Here's the fully worked version of the intake, numbers intact, because it's easier to copy than to describe: no initial goal stated → surfaced annoyance is "weekly attendance tallying is a minor pain" → refined to "automate turning weekly attendance data into a graph" → prior attempt was self-taught Python that stalled at chapter 3 → available time is 30 minutes on weekday evenings → no study partner, solo after training ends → resulting plan: re-enter avoiding the earlier environment-setup stall, break work into 30-minute completable chunks, commit up front to "think → ask AI → verify" since there's no one else to ask, and land on Python — chosen because it fits data work and isn't a from-zero restart. The language name is the very last line of that conversation, not the first.
If you mentor anyone — juniors, bootcamp students, a new hire — try running question 1 before you answer their tooling question. What's the smallest goal they can state out loud in 30 seconds, and does it survive being explained to someone non-technical?
Sho Naka (nomurasan). I train programming beginners and write down what actually predicts who finishes, instead of what feels like helpful advice.
This is an adapted English version of an essay I first wrote in Japanese. I worked with AI to shape and translate the piece; the incidents, the numbers, and the conclusions are my own firsthand account from training beginners.
This article was written in collaboration with AI: the teaching experience, the reframed question, and the timing observation are the author's; drafting and editing were AI-assisted.
Top comments (0)