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.
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.
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.
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.