A Job Taught Me More in 2 Hours Than Books Taught Me in a Day
I learned more in two hours this week than I used to learn in a full day. Nobody pushed me to do it. The job did.
In my last post, I wrote about what my internship taught me about how developers really work. This week I started the job properly, and the biggest lesson wasn't a technology. It was what responsibility does to the way I learn.
How I used to learn
I'm self-taught, so I thought I knew how I learn best. Pick a topic, read, take notes, come back tomorrow. It worked, but it was slow, and I rarely knew whether what I was learning would ever be used.
I'm also not a reader. Books put me to sleep. I read a few pages, reach the bottom, and nothing has stayed, whether it's fiction or non-fiction. I read mostly to stay away from my phone, because scrolling leaves me with a dopamine hangover.
The problem I carried home
This week our project needed a logging system. When something breaks, I want to know exactly what happened, and every log entry needs to be identifiable on its own. [One line on what a log entry looks like in your system, e.g. which fields it carries.] Many services write logs at the same time, so no single place can hand out IDs. I came home with that problem still running in my head.
At my daily study session I was already reading Alex Xu's System Design Interview. This time I skipped ahead to Chapter 7, Design a Unique ID Generator in Distributed Systems.
Here is what two hours looked like:
I started with one question: how do many services create unique IDs without asking each other?
I wrote down my constraints before looking at any solution.
I compared four approaches against those constraints and ruled three out.
I ended the night with a decision I could explain.
Before, the same two hours would have given me a page of notes on a topic I might never use. And I didn't fall asleep, because I could see where every idea would land in my own work.
Constraints come first
The chapter opens like an interview: ask questions, clarify requirements, agree on constraints, and only then design. I had read it before as interview preparation. This time I saw that the constraints step is real engineering. My constraints:
every log entry gets its own unique ID
many services generate logs at the same time
services shouldn't have to ask each other for IDs
Four options, quickly
Multi-master replication: auto-increment stepped by the number of servers. Simple, but it breaks when servers are added or removed.
Ticket server: one database that only hands out IDs. Easy, but a single point of failure.
Twitter Snowflake: a 64-bit, time-sortable ID built from timestamp, data centre, machine and sequence. Great design, but more setup, and it solves a problem I don't have.
UUID: a random 128-bit ID that every service can generate on its own.
Why I chose UUID
UUID is the only option that meets all three constraints. Each service creates its own ID with no coordination, and collisions are extremely unlikely.
Its weaknesses, the 128-bit size and no time ordering, matter less for me because every log already has its own timestamp.
One thing I still need to check: fully random UUIDs (v4) can be hard on database indexes, because new rows land in random places. Time-ordered UUIDs (v7) avoid that while keeping the no-coordination benefit. I'll test both before I settle on a version.
I didn't pick the "best" approach. The constraints picked the one that fit my problem.
Why I grew faster than I thought
The same chapter read differently this time. Same book, same words. The difference was that I had a real problem, and the problem decided what to read and what to skip. I wasn't reading to finish a book. I was reading because something depended on it. That's why I stayed awake.
It also compounds. Today's chapter gives me the vocabulary for tomorrow's design, and each piece I learn makes the next piece faster.
What I'm not sure about
I haven't built this yet, so I can't say how UUIDs will behave in the real system. I also haven't solved the second half of the problem, which is following a single request across multiple services. That likely needs a shared trace ID passed between them, and I'll have to learn how that works.
But I can explain why I made this choice, and a month ago I wouldn't have been able to. I didn't get smarter. I got responsibility, and it turned out to be a better teacher than any study plan I've written.
If you're stuck in a study loop, try this: don't pick a book first. Pick a real problem, then find the chapter that solves it.
