> But in order to write the code, you might have to try 4 different top-level approaches until you figure out the one that works , try integrating with a function from 3 different packages until you find the one that works properly
If you haven’t spent the time to try the different approaches yourself, tried the different packages etc., you can’t really judge if the code you’re reading is really the appropriate thing. It may look superficially plausible and pass some existing tests, but you haven’t deeply thought through it, and you can’t judge how much of the relevant surface area the tests are actually covering. The devil tends to be in the details, and you have to work with the code and with the libraries for a while to gain familiarity and get a feeling for them. The false starts and dead ends, the reading of documentation, those teach you what is important; without them you can only guess. Wihout having explored the territory, it’s difficult to tell if the place you’ve been teleported to is really the one you want to be in.
The goal isn't usually to determine whether the function is the perfect optimal version of the function that could ever exist, if the package it integrates with the the best possible package out of the 4 mainstream options, or to become totally and intimately familiar with them to ensure it's as idiomatic as possible or whatever.
You're just making sure it works correctly and that you understand how. Not superficially, but thinking through it indeed. That the tests are covering it. It doesn't take that long.
What you're describing sounds closer to studying the Talmud than to reading and reviewing most code.
Like, the kind of stuff you're describing is not most code. And when it is, then you've got code that requires design documents where the approach is described in great detail. But again, as a reader you just read those design documents first. That's what they're there for, so other people don't have to waste time trying out all the false starts and dead ends and incorrect architectures. If the code needs this massive understanding, then that understanding needs to be documented. Fortunately, most functions don't need anything like that.
> And when it is, then you've got code that requires design documents where the approach is described in great detail
And how do you write those design documents? First, you need to understand the landscape, and that means reading code, building experiments and trying out different variants, which then allows you to specify a design.
Our job isn't writing code, our job is to gain the understand required that allows us to write specifications and/or optimal code.
And while AI may be a better typewriter, it obscures the actually hard part of our job, the actual engineering, and the reason why others pay us to consult them.
I can read a line of code and tell you that it's storing a pointer in this array cell and removing this other pointer and incrementing this integer by 6 and so on. None of that tells me if that is the correct thing to be doing.
Detecting obvious programming errors like forgetting to check for an error case or freeing a variable or using an array where a set should be is, usually, obvious, and frequently machine can and will point it out.
Knowing that when you add a transaction to this account you always need to add an inverse transaction to a different account to keep them in sync is unlikely to be obvious from the code. Or that you can't schedule an appointment on may 25th because it's memorial day. Or whatever other sorts of actually major bugs tend to cause real business problems.
I mean, sure, if someone documented those requirements clearly and concisely and they were easy to find from the section of code you were reviewing such that you knew you needed to read them first, then yes, it becomes a lot easier. My experience as a professional programmer is this happens approximately never, but I suppose I could be an outlier.
And yes if you want to be extremely literal, some code is easier to read than write. But no one cares about that type of code.
Most human written code has 0 (ZERO!) docs. And if it has them, they're inaccurate or out of date or both.
Lots of code is simple and boring but a fair amount isn't and reading it is non trivial, you basically need to run it in your head or do step by step debugging in multiple scenarios.
> If I got code like Joel describes for a code review, I'm sending it back asking for it to be clearly commented.
I'd argue that most code written today is never code reviewed. Heck, most code today isn't even read by another human being, and I'm talking about code generated by other humans! :-)
Most code written today (and most likely most code ever written) is poorly written code.
Now, these days there are many companies with good engineering practices, so there are lots of islands where this isn't the case.
Outside of life saving critical software or military spec software, no one needs to review so hard they understand it to the level you’re describing, and they do not.
There is a mathematical principle that verification of a proof is easier than any proof. The same is true in code.
I mean, it's even easier to just not read the code in the first place, I'm not sure what that proves, other than perhaps an implicit collorary to the original quote "reading code is quite hard (so people rarely bother)"
If you haven’t spent the time to try the different approaches yourself, tried the different packages etc., you can’t really judge if the code you’re reading is really the appropriate thing. It may look superficially plausible and pass some existing tests, but you haven’t deeply thought through it, and you can’t judge how much of the relevant surface area the tests are actually covering. The devil tends to be in the details, and you have to work with the code and with the libraries for a while to gain familiarity and get a feeling for them. The false starts and dead ends, the reading of documentation, those teach you what is important; without them you can only guess. Wihout having explored the territory, it’s difficult to tell if the place you’ve been teleported to is really the one you want to be in.