In this chapter
We'll learn the habits that keep developers growing on their own — keeping technical notes, the struggle-then-ask rule, learning by building and by reading real code, and planning what to learn next — explained as a musician's practice notebook.
The Problem in Real Life
A week later, Anna opens a new pull request for the next pricing feature: small, well named, with a clear description and a link to the plain-English pricing doc. It's approved the same afternoon with two comments — one a "nit", the other: "Really nice."
John stops by her desk. "Now you write code for the next person, not for the compiler." Then, more quietly: "In a few months, I won't be checking your work every day. What will keep you improving when nobody's watching?"
Now you write code for the next person, not for the compiler.
John
Waiting to Be Taught vs. Teaching Yourself Every Week
Technology keeps changing
Tools, libraries and best practices change every year. Learning never stops.
Solving the same problem twice
Without notes, you search for the same answer again three months later.
Stuck, or asking too soon
Asking instantly stops you learning; struggling for days wastes time.
Keeping Technical Notes and Learning Independently
The practice notebook analogy: a good musician keeps a practice notebook: what they worked on, what was hard, what finally worked, what to practise tomorrow. They don't just play songs they already know — they pick slightly harder pieces on purpose, listen to great players, and play for others. A developer's growth works the same way.
- Keeping technical notes — your own manual: write down what you learn the moment you learn it: a command you'll need again, the fix for a strange error, how a part of the system works, a useful link. Short notes — "TIL" (today I learned) style — in one searchable place: a notes app, a Markdown folder, a personal wiki. Your future self will search there before searching the internet.
- The struggle-then-ask rule: spend a fixed time trying on your own first — say 20–30 minutes of real effort using chapter five's sources — then ask, with a good question (chapter four). Too little struggle and you don't learn; too much and you waste a day the team needed. Write down the answer when you get it.
- Learn by building: reading and videos aren't enough; skills come from making things. Build small projects slightly beyond what you can already do: a tiny API, a CLI tool, a clone of one BlueTicket feature. Finishing small projects teaches more than starting big ones (Act 27).
- Read real code: read your team's code beyond your own tasks, and good open-source projects. You'll pick up patterns, naming and structure that no tutorial teaches. Reading other people's pull requests and reviews is free mentoring.
- Learn in public, a little: explaining something — in a short internal note, a team demo or a blog post — is the best test of whether you really understand it. Teaching makes your understanding solid.
- Plan your learning: keep a short list of what to learn next, linked to your work: "this quarter: SQL query plans, because our reports are slow". Learn the fundamentals deeply — they change slowly (everything in this course) — and specific tools just in time, when you need them.
- Sustainable pace: a little learning, regularly — like an hour a week of deliberate practice — beats rare all-night sessions. Rest is part of learning, too.
| Part | Example |
|---|---|
| Title | Never compare money as floating-point numbers |
| Problem | Test expected 1147.5, got 1147.4999999999998 in CI |
| Cause | Floating-point numbers can't represent some decimals exactly |
| Fix | Store and calculate prices in cents (integers); format only for display |
| Link | PR #455, checkout pricing code |
| Date | 2026-11-28 |
| Habit | Musician version | How often |
|---|---|---|
| Technical notes | Practice notebook | Whenever you learn something |
| Struggle, then ask | Practise the hard bar, then ask the teacher | Every time you're stuck |
| Build small projects | Learn a slightly harder piece | A few hours a month |
| Read real code | Listen to great players | Weekly |
| Explain to others | Play for an audience | Monthly |
| Learning plan | This term's pieces | Every quarter |
Anna's system: she starts a notes/ folder of Markdown files, one per topic: git.md, debugging.md, pricing-system.md, errors-i-have-met.md. Every Friday, she spends 30 minutes tidying the week's notes and writing one "TIL" for the team channel. This week's: "Never compare money as floats — store cents. Thanks Liam." Three teammates react with 🙏, and the new junior who joins next month finds it in the search on her second day.
The close: John looks at her notes folder and the two-comment PR side by side. "Ten months ago you asked me what a server was. Now you're writing things down that other people learn from. That's the job."
Key Takeaway
Keep growing like a musician with a practice notebook: write short, searchable technical notes the moment you learn something; struggle for 20–30 minutes with good sources, then ask a good question; learn by building small projects slightly beyond your level and by reading real code; explain what you learn to others; plan learning around your work — fundamentals deeply, tools just in time — and keep a steady, sustainable pace.
Why This Matters
In technology, what you know today is only the starting point — the people who do well are the ones who keep learning without being told to. Good notes, the struggle-then-ask habit and learning by building are what turn a junior into a senior over a few years, and "how do you keep learning?" is a question nearly every interviewer asks.
Anna can now write code, docs, reviews, bug reports and questions that other people are glad to read. Next, John has a bigger test: an old BlueTicket service nobody has touched in years, with no documentation at all.