Most developers learn to code by writing it from scratch. College, bootcamp, online tutorial — every path starts the same way: a blank screen, a problem, and you typing solutions into existence. When you get a job, everything is different. You open a repository that already has hundreds of files, written by people who left months ago, solving problems you don't fully understand yet. And nobody trained you for this.

A few years ago I joined a project that was already in motion. The MVP was being closed, the architecture had been chosen, the patterns had been picked. My job was to ship features in code I had not written, against constraints I had not designed.

Nobody sat me down to explain the codebase. I had a Tech Lead to help me, but he had no time for an onboarding doc, or show me an actual architectural diagram, or a walkthrough, not because he didn't want to, but because he genuinely didn't have the time. There was a backlog of small bugs in the mobile app, and there was me. So I started picking up the smallest tickets I could find and fixing them, one by one.

Day one, I fixed a misaligned button. Day three, a validation that wasn't firing. End of the first week, a state that wasn't being cleared between screens. Each fix was tiny. But to make each fix, I had to read more code than I had to write. The change was three lines. The reading to find those three lines was three hours.

That ratio — three hours read for three lines written — never really stopped. It got better, but it never inverted. I now think that's the actual job.

The bugs grew over time. After the app, I started touching the web backoffice. Then the API. Then CI/CD and the infrastructure pieces. Today I cover the whole stack alone. None of that expansion was planned. Each step happened because the previous step had given me enough context to take the next one. Fix enough bugs in the app and you start to see what the API is doing wrong. Fix enough things in the API and you start to see what the deployment pipeline is doing wrong. The radius keeps growing because each new layer is the layer the previous layer was complaining about.

Along the way, I developed a habit that helped more than anything else.

Every time I had to change something, I would pick one button, one field, one interaction — and trace it. What endpoint does it call when tapped? What does the API send back? What error code if the user is missing a field? What's the happy path, what's the sad path, what happens in between? I would draw the whole flow on my iPad. By hand. Boxes, arrows, error codes written in the margin.

I didn't know this was a technique. Nobody taught it to me. I had not read any book on reading code, because I didn't even know this was a thing. I just couldn't hold the system in my head, so I put it on a screen.

A few months in, I had dozens of those drawings. And without realizing it, I had also learned something else: every drawing had the same shapes. The same patterns kept showing up. Repository here. Service there. DTOs crossing this line, domain objects staying behind that one. The codebase was teaching me design patterns the textbook way had never managed to — by repetition, in context, with consequences I could see.

That was the unexpected lesson. I had read about design patterns before, vaguely, the way you read about something that doesn't matter to you yet. Then I spent months tracing real code written by people who knew what they were doing. At some point, the patterns stopped being names in a book. I now reach for a Repository or a Service the way I reach for a fork — without thinking, because the shape of the problem already implies the shape of the solution.

You cannot learn that from writing code from scratch. You can only learn it from reading code that's already alive, while you're making it slightly more alive.

A few habits stuck from that period:

• Start with the smallest possible change. Don't try to understand the system before contributing to it. Fix a typo. Fix a misaligned button. Fix the bug nobody else wants because it's boring. Each tiny fix forces you to read just enough code to understand just enough of one thing. You are not learning the codebase — you are accumulating it, one ticket at a time.
• Let the bugs choose the path. If you keep getting bugs in payment, that's where you should be reading. If the CI keeps breaking, that's where you should be reading. The system tells you where it hurts, and where it hurts is where the knowledge you're missing lives.
• Draw what you read. Whiteboard, iPad, paper, whatever. The act of drawing forces you to commit to a model. Reading lets you stay vague. Drawing exposes what you don't actually understand yet. Every box you can't label is a question you need to answer.
• Notice when shapes repeat. The third time you draw the same kind of arrow between the same kinds of boxes, you've found a pattern. That's how patterns enter your hands. Not from books. From your own drawings of code that someone else already wrote.

None of this is taught. Bootcamps give you blank screens. Books on algorithms give you blank screens. Open source tutorials usually say "fork this and add a feature" — you're back to writing.

But the job is reading. The faster you can understand code somebody else wrote, the more useful you become — to the team, to the project, and to yourself when you reopen your own file from six months ago and realize past-you was also somebody else.

Writing code is the part that shows up in the screenshot. Reading is everything else.