Reading code without running it in your head feels like reading prose without actually comprehending it.

My technique for getting to know a codebase is to look at one thing in particular, probably with the help of a debugger, tracing the call stack and how the data flows and changes. I get to know a whole project in sections, focusing on individual bits of functionality.

And if I'm honest, I rarely ever 'read' code this way either - I usually do it because I want to add a feature or improve performance, or squash a bug, and I stop when I understand enough to be fairly sure I'm doing things in a responsible manner - keeping with the architecture and not making what I leave when I'm done any more additionally complex than is required to accomplish my task.

I don't understand how people can 'read code' in any sort of a straightforward manner. The phrasing seems to suggest to me a linear 'reading' like a book or a technical manual. But you can't read code like that. If a project is of even moderate size, there are too many interweaved dependencies. Even a very well factored codebase is at best a top-down or bottom-up tree, and you (or, at least, I) often can't understand the trunk without understanding the disparate branches and leaves. I generally can't keep all that in my head without a task to focus on.

I think it's arguably even irresponsible to suggest to newcomers that they should 'read code' because it sets them up for failure when they try to do it and the complexity inevitably overwhelms them.

Do I misunderstand what people mean when they say "read code"?

But it is very effective as a way of spotting certain kinds of bugs, while at the same time gaining a much deeper understanding of a codebase.

Reading code in a non trivial way is a very special skill that not many developers have, but that is very worthwhile to attain.

Whenever I come to a new codebase, I start by grabbing a pretty random bug and reading the code in that area. just flicking through, forcing myself to ask questions about it and finding out the answers.

actively engaging with code like that is an amazingly effective way of absorbing a codebase.

One thing this means is that in any substantial codebase you are never going to understand all of it. You will typically only have time to learn a fraction of the system, so if you are going to proactively explore the codebase, you will need to prioritize. You probably (but not necessarily) want to get a handle on the top-level architecture before digging deep anywhere.

My final piece of advice is that I personally find it impossible to understand just about any non-trivial piece of code without running it, and running it multiple times (1). Perhaps even many, many times. You can run under a debugger (single stepping or breakpoints) and this seems to work for many people. I still rely on print statements sprinkled through the code myself, adding and removing them as I run the code in question over and over again as my current point of interest moves from place to place in the code. This might sound scary, but it's not that different from the way you normally debug code.

(1) It's entirely possible that the person that wrote the code in the first place also ran it many, many times (testing each small change) as they wrote it. So it's perhaps not unreasonable that you yourself may need to run it many, many times in order to understand it later.

that's probably a sign that you don't want to use that code especially if YOU can't understand what the hell it's doing.

I tend to look at tests first more often then dive into the actual code.

I can read code by the page, hitting next page at about a 1Hz rate. If the code is not overheated. That means, avoid lots of syntactic bloat, keep it concise, keep it modular, with low branching. Just about what the OP says.

How much time did you take to do this, I can read code, but I simply can't casually take a look at code like this and say, hey that's cool, hey that's interesting, I have to concentrate and go line by line, a more debugging state of mind.

There are programmers that can sort of skim read code which just amazes me.

Until the docs and tutorials fall short, or something unexpected happens, or they want to see why something behaves the way it does.

Personally, I like writing code and borrowing ideas from other, better engineers. I also like my code to be clean and without cruft: https://github.com/keithb-/Valley

But I don't even know if I could "read" my code. It's a web app; there isn't a main(), there isn't a loop. In order for someone to read it, they would need to mentally "send a request" which means they need to somehow have the concepts or the context in their mind when they sit down with the source code. I just don't know how that is supposed to help an engineer, regardless of age or experience.

Try it with an interpreter running.

That said, I personally DO read code. Besides code reviews that were mentioned in the article I read the code that my code depend on. Especially when I want to better understand some API, I read not only the headers, but the actual implementations of the functions that I'm using.

Sometimes I read code to better understand some algorithm. I only understood how Transformer architecture worked when I read some of its implementations.

So yeah, reading code is cool. We just don't read it as we read books.

Since most of the code I read (C# code) can be ran on my platform, I'll sometimes run into that rare piece of code that I can't believe it does what it says it does, in those cases I'll download the repo and debug it and many times be surprised to find there was a gap in my understanding. Reading code helps me find knowledge gaps I didn't even know were there.

Read and ask questions about what you don't understand.