Weapon of choice
Three weeks to pick one language and get fluent enough that syntax stops being where your attention goes. The choice matters far less than people fear and the fluency matters far more than the canon admits, so this task spends one section on the picking and the rest on the getting-out, because the place beginners actually get stuck is not the decision. It is the tutorial loop after it.
The truth first: it does not matter much
The r/learnprogramming FAQ has answered "which language should I learn first" the same way for over a decade: it does not really matter, pick one and start. That answer survives because it is correct. The skill you are building is problem solving — turning a fuzzy want into precise steps a machine can execute — and that skill transfers completely. The syntax is rented; you will re-rent it in a different language within a few years no matter what you pick, and the second language costs a fraction of the first.
So the only real mistake available here is spending a month choosing. The people who agonise between languages and the people who switch languages at week two are losing the same thing: the early reps that make everything later cheaper.
Our pick anyway
"It doesn't matter" is true and also unhelpful, so here is an opinion. Pick by what will keep you coming back:
- Python, if data, scripting, or interviews are what pull you. It reads close to pseudocode, the standard library carries you far, and it is the most common language people interview in, so everything from task 4 onward translates with no friction.
- JavaScript, if you need to see things on a screen to stay alive. The browser is the most accessible runtime ever shipped: no install, instant feedback, and the thing you build is a thing you can show someone. For a lot of people that visible loop is the difference between week six and quitting at week three.
Both have honest study paths in the languages codex, and when a concept lands strangely, the ELI5 shelf exists for exactly that moment. Pick today; this plan will not check your reasoning.
Why not C++ first
The hbkaye-style guides of an earlier era said start with C++, on the theory that managing memory by hand builds discipline that easier languages let you skip. The theory was not wrong about the discipline; it was wrong about the price. A beginner fighting segfaults is not learning how memory works, they are learning that programming hurts, and the dropout rate of that curriculum was its quiet cost.
Honest update: this plan still delivers that discipline, it just moved the bill. Task 3 teaches you what the machine is doing — the stack, the heap, what a pointer actually is — by watching it happen rather than by being punished for not already knowing. You arrive at the same understanding without the months of attrition.
jwasham's caution: ask, don't assume
A cautionary detail from the coding-interview-university story: jwasham spent three weeks working through a thousand-page C++ book, then ended up interviewing in Python. His own conclusion, preserved in the repo for the rest of us: "it's good to ask, not assume." Three weeks is, not coincidentally, this entire task's budget.
The general form of the lesson: when a concrete target exists — a company, an interview loop, a team — check what it actually uses before investing. When no target exists yet, the cheap default wins, which is exactly why the picks above are the picks.
Tutorial hell, and the ladder out
Tutorial hell is the loop where finishing one course makes you feel ready for nothing except another course. The mechanism is simple: typing along with an instructor exercises recognition, and writing programs requires recall, and the two feel identical while you are in the chair. The way out is not a better tutorial. It is a ladder with three rungs:
- Guided. One course or book, typed along honestly. This rung is fine. It becomes hell only when you stay on it.
- Semi-guided. Build something adjacent to what the tutorial built — your own code, references open, docs allowed, but no walkthrough to follow. The tutorial made a to-do list? You make a habit tracker. Close enough to reuse the concepts, far enough that nobody is holding the pen but you.
- Unguided. An idea of your own, from an empty folder. It will be small and the code will be embarrassing. That is the rung working as intended.
Rule of thumb for this task: one rung-one item, then climb. Two guided courses in a row is the loop forming.
The fluency bar before problem one
Every problem list in the canon silently assumes a baseline of fluency, and beginners bleed on the gap between finishing a tutorial and having it. Before you touch task 4's practice problems, you should be able to write each of these idiomatically, without looking anything up:
- A loop that builds and then reads a hash map (count word frequencies in a sentence).
- A sort with a custom comparator or key (sort a list of pairs by the second element, descending).
- A recursive function with a base case you chose yourself (sum a nested list).
If any of the three sends you to a search engine for the syntax, you are not behind, you are just not done with this task. Drill them until your fingers know them. The alternative is spending your problem-solving time boxes fighting the language instead of the problem, which corrupts every signal the practice method in task 1 is supposed to give you.
Three tiny inventions before moving on
Typing along teaches syntax. Invention teaches programming. Close this task by building three tiny programs nobody walked you through:
- A unit converter. Kilometres to miles, celsius to fahrenheit, whatever. Input, arithmetic, output, and your first taste of handling garbage input.
- A file renamer. Point it at a folder, rename everything by a rule. First contact with the filesystem and with code that can do real damage, which is worth feeling early and on files that do not matter.
- Guess-the-number. The machine picks, you guess, it says higher or lower. A loop, state, and conditionals cooperating, and accidentally your first meeting with binary search, which you will formally meet again in task 4.
Each should take an evening or two. When all three run, this task is done. And for the record, a second language is already scheduled, not aspirational: Go arrives in task 6, when you build real things, and it will cost you a weekend instead of three weeks precisely because of what you just finished. Next, though, you go one level down and learn what the machine is actually doing with all this code you can suddenly write.