3 ms·

Because to verify something is correct you have to understand the what makes it correct which is 99% of writing the code in the first place.

crazygringo 8mo ago
That doesn't make any sense to me. When the code is written, it's all laid out nicely for the reader to understand quickly and verify. Everything is pre-organized, just for you the reader. 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, hunt down documentation on another function you have to integrate with, and make a bunch of mistakes that you need to debug until it produces the correct result across unit test coverage. There's so much time spent on false starts and plumbing and dead ends and looking up documentation and debugging when you code. In contrast, when you read code that already has passing tests... you skip all that stuff. You just ensure it does what it claims and is well-written and look for logic or engineering errors or missing tests or questionable judgment. Which is just so, so much faster.
- layer8 8mo ago
  > 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.
  - crazygringo 8mo ago
    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.
    - oblio 8mo ago
      > What you're describing sounds closer to studying the Talmud than to reading and reviewing most code. https://www.joelonsoftware.com/2000/05/26/reading-code-is-like-reading-the-talmud/ https://www.joelonsoftware.com/2000/05/26/reading-code-is-li... 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.
      - crazygringo 8mo ago
        Hilarious you found that reference. I think it's obvious that's in reference to poorly written code. Or at least horrifically underdocumented/undercommented code. There's a reason coders are constantly given the advice to write code for a future reader, not just the compiler/interpreter. If I got code like Joel describes for a code review, I'm sending it back asking for it to be clearly commented.
- jama211 8mo ago
  Well said, you’re absolutely right. In practice code review is orders of magnitude faster than code creation and it always has been, baffling anyone is arguing otherwise. Perhaps they’ve never worked in a real organisation, or they’ve only worked on safety critical code,m or something?
  - wredcoll 8mo ago
    Sometimes code review is so fast it's literally instant (because people aren't actually reading the code). I think it's one of those sort of, dunno, wink wink situations where we all know that doing real in depth code reviews would take way more time than the managers will give (and generally isn't worth it anyways) so we just scan for obvious things and whatever happens to interact with our particular speciality in the code base.
    - jama211 8mo ago
      I’ve rarely seen this happen personally but it does happen from time to time. Even thorough code reviews don’t take anywhere near as long as the writing though.
jama211 8mo ago
No, you don’t. This is a fundamental principle of cryptography, unless you’ve got a hidden proof of p=np up your sleeve.

crazygringo 8mo ago

That doesn't make any sense to me. When the code is written, it's all laid out nicely for the reader to understand quickly and verify. Everything is pre-organized, just for you the reader. 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, hunt down documentation on another function you have to integrate with, and make a bunch of mistakes that you need to debug until it produces the correct result across unit test coverage. There's so much time spent on false starts and plumbing and dead ends and looking up documentation and debugging when you code. In contrast, when you read code that already has passing tests... you skip all that stuff. You just ensure it does what it claims and is well-written and look for logic or engineering errors or missing tests or questionable judgment. Which is just so, so much faster.

layer8 8mo ago
> 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.
- crazygringo 8mo ago
  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.
  - oblio 8mo ago
    > What you're describing sounds closer to studying the Talmud than to reading and reviewing most code. https://www.joelonsoftware.com/2000/05/26/reading-code-is-like-reading-the-talmud/ https://www.joelonsoftware.com/2000/05/26/reading-code-is-li... 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.
    - crazygringo 8mo ago
      Hilarious you found that reference. I think it's obvious that's in reference to poorly written code. Or at least horrifically underdocumented/undercommented code. There's a reason coders are constantly given the advice to write code for a future reader, not just the compiler/interpreter. If I got code like Joel describes for a code review, I'm sending it back asking for it to be clearly commented.
jama211 8mo ago
Well said, you’re absolutely right. In practice code review is orders of magnitude faster than code creation and it always has been, baffling anyone is arguing otherwise. Perhaps they’ve never worked in a real organisation, or they’ve only worked on safety critical code,m or something?
- wredcoll 8mo ago
  Sometimes code review is so fast it's literally instant (because people aren't actually reading the code). I think it's one of those sort of, dunno, wink wink situations where we all know that doing real in depth code reviews would take way more time than the managers will give (and generally isn't worth it anyways) so we just scan for obvious things and whatever happens to interact with our particular speciality in the code base.
  - jama211 8mo ago
    I’ve rarely seen this happen personally but it does happen from time to time. Even thorough code reviews don’t take anywhere near as long as the writing though.

jama211 8mo ago

No, you don’t. This is a fundamental principle of cryptography, unless you’ve got a hidden proof of p=np up your sleeve.