Reading the codebase before reading the ticket

For a long time, my workflow started with the ticket. Read what needs to change, open the relevant file, start writing. It felt efficient: you know the destination, so go there.

What I kept running into was friction. I'd make a change that conflicted with something three files away. I'd duplicate logic that already existed under a slightly different name. I'd write a function that the codebase already had, or choose the wrong abstraction for where the feature was going.

The order of operations that changed things

Now I start from the user's perspective. I open the app, find the area that's being changed, and click around it as a user would. Then I trace one request: from the route handler or the component, down through the service layer, into the database and back. I do this before I read the ticket. By the time I read what needs to change, I have the system in my head.

It sounds like it takes longer. In minutes it does. In total time from ticket-open to merged PR, it's faster, sometimes significantly. The reason is that most of the friction in shipping a feature isn't writing the code. It's the back-and-forth that happens when you wrote the wrong thing.

What you find when you look first

You find the patterns the codebase has already established for exactly this type of change. You find the utility function that does 70% of what the ticket is asking for. You find the migration that already ran and constrains what the schema change can look like. You find the test that will break if you touch the function you were about to touch.

Finding these things before you start means your change fits. It slots into the codebase like it was always going to be there, because you understood the shape of the space before you filled it.

Your change fits because you understood the shape of the space before you filled it.

When the ticket is wrong

The other thing that happens when you read the codebase first: you catch tickets that describe the wrong solution. Not wrong in intent, the intent is usually right, but wrong in approach. The ticket says to add a new column; reading the codebase first reveals the column already exists, just populated from somewhere else. The ticket says to add a check; reading first reveals the check is already there, just not surfaced in the UI.

Catching that before writing a line of code saves everyone time. It's also a better use of your standing in the team than catching it in review.