Why do developers spend so much time reading code?

People who aren't familiar with software development often imagine a developer as someone who writes code. They picture someone opening an editor, typing a few lines, running the program, and repeating the process.

In reality, when I'm working on a project, I often spend much more time reading existing code than writing new code. And over the past few years, I've also spent part of my time reading and understanding the AI-generated code I use while programming.

Understanding what a program actually does, why it works that way, and what impact a change might have is often far more important than adding a few new lines. That's exactly what we'll explore in this article.

Writing code is rarely the hardest part

When you're building a feature from scratch, you usually have a good level of control over the environment. You know the objectives, you choose the architecture, and you write the code. The situation changes as soon as that feature has to fit into an existing project.

Before changing anything, I usually need to understand how the different parts of the application communicate, which conventions have been followed, what dependencies are involved, and why certain decisions were made.

A change that looks trivial can easily require me to browse several files before writing the first line of code. That's probably one of the most common situations in software development: you spend a lot of time understanding the problem before actually coding the solution.

Reading code means reconstructing how it works

When I encounter a section of code I don't know, I usually try to answer several questions:

• Where does this data come from?
• Where is it modified?
• Why is this function called here?
• What happens if it fails?
• Who uses the result?
• Can this class be modified without breaking something else?

It feels more like an investigation than ordinary reading. Little by little, you build a mental model of the application. You try to understand the relationships between its different parts, sometimes without even needing to modify them.

The older or more complex the project is, the longer that mental model takes to build. Generative AI can be genuinely helpful at this stage. For example, you can ask it to explain how an unfamiliar part of a project works. For me, it's a real time saver, especially when I need to understand an existing codebase quickly.

Existing code contains more information than the documentation

Even with good documentation (who honestly reads the docs?), I always end up going back to the code. Documentation can explain that a function exists and what it's supposed to do. The code shows what it actually does.

This is especially true in projects that have evolved over several years. A function may have been created to solve one specific problem, then gradually reused in completely different contexts without its documentation ever being updated.

Sometimes, important decisions simply aren't documented anywhere. In those cases, the code becomes the only reliable source of information.

That's one of the reasons developers spend so much time navigating a project before changing anything.

The older the project, the more important reading becomes

In a new project, it's relatively easy to build a good overview of the codebase. After several years, that changes.

The project may have gone through different developers, frameworks, databases, or even architectural styles. Some parts may be beautifully designed, while others exist simply because they still work.

When I work on this kind of project, I have to understand decisions I didn't make. Why is this function written this way? Why does this table contain this column? Why is this value validated here instead of somewhere else?

Sometimes you discover that the code which looks strange today was the perfect solution to a very real problem when it was written. That's another reason reading code often requires more effort than writing it.

Changing code without understanding it is risky

It's tempting to edit the function that appears to be causing a bug. Before doing that, I usually check everywhere that function is used.

A small change can have unexpected consequences: an API behaves slightly differently, a SQL query returns different results, or a validation suddenly rejects a case that used to work.

Reading the code beforehand helps identify those dependencies. It also explains why you can spend an hour solving a problem and end up writing only five lines of code.

Those five lines aren't necessarily the main work. The understanding that made them possible is.

And besides, not everything is covered by unit tests. Even with excellent test coverage, there are always untested cases.

AI tools don't eliminate this problem

Programming assistants can generate code incredibly quickly today. But generating a change isn't the same thing as knowing whether that change is correct.

Even when I use AI to help me code (which is basically all the time), I still need to understand the context, verify its assumptions, and identify possible side effects. If anything, AI makes reading code even more important.

When an AI produces dozens of lines in a few seconds, you still have to decide whether those lines actually belong in the project.

The challenge isn't just producing code. It's being able to read and judge the code that's produced.

Personally, I reread every line of code generated by AI. But I have to admit it doesn't carry the same weight as code I've written myself. It's surprisingly easy to let questionable code slip through when you're not its original author.

Reading code is a form of maintenance

Software maintenance is often associated with bug fixes and dependency updates. In reality, a large part of maintenance is simply understanding the system well enough to change it without breaking it.

That's why I believe readable code has real value. I don't hesitate to ask my AI assistant to rewrite code it generated if I'm not happy with it.

Clear variable names, reasonably short functions, a consistent architecture, and as few unnecessary abstractions as possible can save enormous amounts of time for everyone who works on the project later.

Time spent making code easier to understand is rarely wasted. You often get it back months or years later when someone has to return to it.

Conclusion

In the end, programming starts with reading.

Reading other people's code, rereading your own, understanding what already exists, and anticipating the consequences of every change. Generative AI may help us produce more code than before, but it doesn't change the essential part of the job: we still have to read and understand what we're building.