There is no senior engineer down the hall and no training budget approval to wait for. What replaces them is a system: read narrow, build to understand, keep a written record of what surprised you.
The hardest part of working alone is not the workload. It is that nobody corrects you. In a team, bad assumptions get caught in review, in a hallway, by someone who has seen it go wrong before. Alone, an incorrect belief can survive for years and quietly shape everything you build on top of it.
So the learning system has to do two jobs: take in new things, and catch the wrong things you already believe. Most advice only addresses the first.
Read narrow, not wide
The instinct when you feel behind is to consume more — newsletters, threads, conference talks, a list of frameworks to try. That produces the sensation of learning and very little of it. Recognition is not understanding, and a familiar name is not a usable skill.
What works better is going deep on the few things the current work actually touches. When building an app that writes into Shopify's collection order, read that API's documentation properly — the rate limits, the error shapes, what happens at the boundaries — rather than skimming ten adjacent topics. Depth on what you use compounds. Breadth on what you do not use evaporates.
Build the smallest thing that proves you understand
The honest test of understanding is whether you can predict what something will do before you run it. Reading about an API gives you a story about it. Writing twenty lines that exercise the edge you are unsure about tells you whether the story is true.
Most of what I know about Shopify's sorting behaviour came from small probes like that, not from documentation. Documentation tells you the intended behaviour. A probe tells you the actual one, including the cases nobody wrote down.
Keep a record of what surprised you
This is the highest-return habit and the one almost nobody keeps. When something does not behave as expected, write down what you expected, what happened, and what you now believe. A few lines is enough.
It pays twice. Immediately, because writing it forces you to articulate the model you had, which is often where the error was. And later, because you will meet the same class of problem again and your past self will have left you a note. Our codebase is full of comments that exist for exactly this reason — the surprising constraint recorded at the place where someone would otherwise re-learn it the hard way.
Let tests be the colleague who disagrees with you
Without a reviewer, an automated suite is the closest thing to someone who will tell you that you are wrong. The trick is writing tests adversarially rather than confirmingly: not 'show that it works' but 'find the input that breaks the assumption I have not noticed I am making'.
A suite written that way changes how it feels to work alone. It is the difference between hoping you are right and having something that argues back.
Publish, and let it be checked
Writing publicly about how something was built is a learning mechanism disguised as marketing. You cannot write a clear explanation of something you only half understand; the gaps show up in the sentences that will not come out right. And once it is public, people who know more than you occasionally tell you so, which is exactly the correction that working alone removes.
It is one reason we publish our test methods rather than just claiming accuracy. The claim is worth little; the method is checkable.
What to deliberately ignore
A system for learning also needs a rule for what not to learn. Mine is simple: ignore anything that is not either used in current work or a genuine shift in the ground everyone stands on. Most new tools are neither. The cost of skipping something that turns out to matter is a few weeks of catching up later. The cost of chasing everything is never being good at anything.
