There is a kind of learning you cannot get from reading, and it is cheaper than you think.
Take a thing that already exists and build a small, bad version of it yourself.
Not to ship. Not to publish. Just to see how it feels from the inside.
A tiny web framework. A key value store that only handles strings. A test runner that runs three tests. Something you use constantly and have never once thought about the shape of.
You will get about forty percent of the way in and hit the exact problem the real authors hit. That is the whole point.
Because until you hit it, every design decision in the real tool looks arbitrary. Afterwards it looks like the only sensible answer to a problem you now personally understand.
That shift is worth more than a month of documentation.
I remember writing a small dependency injection container, badly, over a weekend. I had used containers for years and always found the configuration slightly annoying and mysterious.
Two hundred lines in, I understood exactly why it was shaped that way. Nobody had to explain it. I had run into the wall myself.
A few rules to keep it useful.
Keep it small. You are not competing with the real thing, so cut every feature you can and stop early.
Do not read the source first. Struggle first, then go and look. The comparison is where the learning is.
Do not do this on work time and call it research. Do it on a quiet evening when you are curious.
And throw it away afterwards without guilt. The artifact is not the point.
What you keep is a mental model. Next time that tool behaves strangely you will have an instinct about why, instead of a search box and a hope.
The industry keeps telling you to learn by building something new.
Building something old works just as well, and you get a working reference to check yourself against.
Pick the tool you trust the most and least understand.
Go and make a small wrong version of it.
– Asael Shinder
Top comments (0)