Teach yourself Everything: the Art of Self-Learning

For the first twenty years of your life, someone hands you the syllabus. Chapters, deadlines, an exam at the end. You learn what you are told to learn, and the reward comes on schedule.

Then you get a job, and for a few months it feels the same. Onboarding docs, a mentor, a starter ticket. Someone is still pointing.

And then that stops. Nobody tells you. There is no announcement. One day the pointing just ends, and from that day forward, everything you learn is a choice you make on your own time.

Most people never notice the handover. That is the whole problem.

At a product company, nobody hands you anything#

I learned this the hard way.

There is no one walking you through the codebase. Nobody sits with you and explains why the system is built this way. You get a task, often half described, and you are expected to work out the rest yourself. What it touches, why it matters, what breaks if you get it wrong.

It gets very real the day you break something on production, the live site that real users are on. People notice fast. Someone will tell you it is broken. But nobody is going to sit next to you and fix it for you.

It was your change, so it is on you to find out what went wrong and put it back. The first time, it is scary. After that, it is the fastest learning you will ever do.

The knowledge is all there, in the code, in old pull requests, in the head of the person sitting two desks away. But it is never delivered to you. Nobody hands you knowledge at a product company. You go and take it.

The people who wait to be taught stay stuck at the first task forever. The people who dig, read the old code, ask the uncomfortable question, and trace the thing end to end, become useful in months instead of years.

Your job will teach you your job, and nothing else#

A job is not a school. A job is a set of problems your company happens to have this quarter.

Do it well for two years and you will get genuinely good at a narrow strip of things: this codebase, this deploy process, this way of writing a component. That is real skill. It is also rented. It lives inside one company's walls.

I have watched engineers with five years of experience who really had one year, repeated five times. Not because they were lazy. They worked hard. They just worked hard only on what was handed to them.

The ticket queue is a comfortable place to hide. It always looks like progress, because closing tickets feels exactly like learning until the day you interview somewhere else.

The people who pull ahead learned things nobody asked them to learn#

I have worked next to two engineers everyone called a coding god. I wrote about them already. Here is the part that matters for this post.

It was not talent, and it definitely was not speed. It was that they had spent years learning things nobody assigned them:

• They read parts of the system that had nothing to do with their ticket.

• They went one level below the tools everyone else just used.

• They kept digging after the bug was already fixed, because "why did that happen" is a different question from "is it green now".

None of that showed up on a sprint board. All of it showed up the day something broke and the room turned to look at them.

That is the trade. Self-education is invisible for years, then it is the only thing anyone can see.

The year I started reading code I had no reason to read#

For a long time I optimised for the wrong thing. Finish the ticket, close it, look productive. I measured myself in output.

Then I started doing something that felt like a waste of time. I opened pull requests I was not reviewing. I read code in parts of the product I would never touch. I took work that had already shipped and traced how it actually got from a branch to a user.

For weeks it produced nothing. No ticket moved faster. Nobody noticed.

Then it started paying, quietly. I began recognising problems instead of discovering them. A bug would get described in standup and I would already have a guess, because I had read that file for no reason two months earlier.

Same brain. Same hours in the day. The only thing that changed was what I chose to point it at.

I built things nobody asked for, and they taught me the most#

Reading only takes you so far. At some point you have to build something where no senior engineer is standing behind you.

I built FreeClothes.in to learn what a day job would not teach me. I built this blog instead of just posting on Substack, for the same reason.

Both were, by any sensible measure, unnecessary. And both taught me more per week than any sprint I have ever worked, because a side project refuses to let you specialise. You are the frontend, the backend, the deploy, the person who gets woken up when it breaks, and the person who has to decide what it should even do.

A job gives you a slice of the problem. A thing you build yourself gives you the whole problem, and the whole problem is where the learning is.

Do you know how your company actually makes money?#

Here is the part almost no engineer bothers with, and it is the fastest way to separate yourself.

Most of us know our team, our repo, our sprint. Ask what happens outside that and the answer goes quiet. So go and learn the business you are already sitting inside:

• How does the company work? Who are the customers, what do they actually pay for, and which teams touch that path.

• How does it make a profit, and how does scale work here? What one more customer costs the company, and what breaks first when the customer count doubles.

• How does the infrastructure work, and how does code get deployed? What happens between someone clicking merge and a user seeing the change.

• How does marketing get customers in? Where the users come from, what convinces them, and why a feature was prioritised over the one you thought was better.

None of it is your job. Nobody will ever assign it. That is exactly why so few people know it.

But it changes how you build. You stop asking "is this feature done" and start asking "does this feature make us money or cost us money". You start spotting the expensive design before it ships, because you finally know what expensive means here.

Learn the business and you stop being a person who writes code. You become a person the business can talk to.

AI raised the floor, so the floor is no longer worth standing on#

Something changed recently, and it is the part I would take most seriously.

Shallow knowledge is now free. Anyone can get working code for a thing they do not understand, in seconds. The stuff that used to make a junior look competent, syntax, boilerplate, the standard implementation of a standard thing, has been flattened for everyone.

What has not been flattened is judgement. Knowing why this approach and not that one. Knowing what will break at scale. Reading a generated answer and spotting the one line that is quietly wrong.

That judgement only comes from depth, and depth only comes from learning things nobody asked you to learn. AI did not make self-education less important. It deleted every other way to stand out.

What being deeply self-taught actually buys you#

Not a promotion, at least not directly. Something better.

You stop asking permission. When you understand the whole system and not just your corner, you no longer wait for someone to tell you what is possible. You become the person who decides.

And you keep your options. A narrow specialist is safe until the company reorganises, the product dies, or the framework goes out of fashion. Someone who has proven they can teach themselves anything is never one layoff away from irrelevance.

The skill is not React, or Node, or whatever is hot this year. The skill is being able to learn the next thing without anyone helping you. That one never expires.

There is no such thing as motivation#

People wait to feel ready. They watch a video, feel something for two days, and then it wears off and they call it a motivation problem.

It is not. Motivation is a mood. It shows up when things are going well and disappears the moment they are not, which is exactly when you need it.

The people who get good are not walking around more motivated than you. They just made it work anyway. Tired, bored, stuck on a stupid bug at 11pm, in a week where nothing went right. They did the hour regardless of how they felt about it.

And nobody is checking. Your manager will never ask if you felt motivated this week. The interviewer will not ask either. Nobody asks how you felt. They only ever see what you did.

The part nobody warns you about#

It is boring. That is the honest version.

Self-education has no deadlines and no grades. You will spend a Sunday understanding something no one at work will ever ask you about, and at the end of it you will have nothing to show. No merged pull request, no ticket moved, nothing that looks like a day's work.

That is exactly why it works. If it were comfortable, everyone would do it, and it would stop being an edge.

You do not need four hours a day. You need one honest hour, most days, aimed at something slightly beyond what your job requires. Pick one thing:

• Read the source of a library you use every day.

• Rebuild something you rely on, badly, just to see how it works.

• Ship one small thing end to end, alone.

Then do it again next week. The compounding is unglamorous and it is brutal in your favour.

Nobody is coming#

There is no next syllabus. No manager whose job it is to make you good. No course that will do it while you watch.

The gap between where you are and where you want to be is not made of talent. It is made of the hours nobody assigned you, and it closes only if you decide to close it.

Educate yourself, or spend your whole career waiting to be taught.