4 ms·

Yeah, IMO this is like a publisher saying "we don't have editors: we trust our authors". The intended ethos of editors and code review is that mistakes and impe

• jiggawatts 5y ago
  Something that I've discovered is that as the volume of text that I write goes up, the errors increase. More experience hasn't resulted in fewer typos. On the contrary, I make far more small mistakes now than I used to. It's precisely because I've learned to read and write so fast that I "skip over" the simple parts of sentences, making me oddly blind to certain categories of spelling errors! Especially when I've gone over the same text over and over, I'll have memorised it to the point that I can skip entire sentences. This is why you need someone else to step in and read the text for the "first time" and not skip anything. The same applies to programmers and code review.
• hsn915 5y ago
  Books are published once, not through iterations. The equivalent in book writing would be that you are not allowed to write more than one page at a time, and someone must approve it before you start working on the next page.
  • kqr 5y ago
    Another difference between books and code is that books are read and interpreted by humans (who are very tolerant of grammar bad, in the grand scheme of things) and code is read and interpreted by computers (who will swallow any ambiguity whole and just steam on with their interpretation.) If books were read by machines rather than humans, and were published incrementally, then it would make sense to ask someone to edit each iteration.
  • deleted 5y ago
    [deleted]
  • dragonwriter 5y ago
    > Books are published once, not through iterations. Incorrect. Bugs (“errata”) are regularly fixed in bugfix versions (“printings”) of books, whereas feature changes are regularly fixed in more major versions (“editions”). And that’s after the equivalent of a “1.0” release. Books are also regularly iteratively released either to a closed group of reviewers or even the public (e.g., Manning MEAPs, PragProg Beta Books, etc.) prior to the equivalent of a “1.0” release.
    • mpweiher 5y ago
      > Bugs (“errata”) are regularly fixed in bugfix versions (“printings”) of books, But those fixes don't fix the already printed books.
      • dragonwriter 5y ago
        > But those fixes don't fix the already printed books. For actual physical books (as opposed to ebooks, where making the complete new version available to purchasers for errata, but usually not new editions, is common), this is usually true for logistical reasons, though issuing errata sheets (usually online now, though the practice is older but notification and distribution was harder in the past) to keep existing users up-to-date is not uncommon.
• mpweiher 5y ago
  > this is like a publisher saying "we don't have editors: we trust our authors" No it's not. If an author produces gibberish and nobody checks, the published result is gibberish. And with print books uneditable in a run starting in the thousands. If a programmer produces gibberish, it won't compile. It also won't pass the unit test or acceptance tests, never mind QA or the alpha/beta testers.
  • eterm 5y ago
    My experience tells me there's no shortage of compilable gibberish.
    • mpweiher 5y ago
      My experience tells me there's no shortage of published gibberish. ¯\_(ツ)_/¯
  • alecbz 5y ago
    True that compilers, tests, and QAing are nice protections that we get with code but not books (well sorta... books can still be alpha/beta-tested in the sense of having some people read them and share their thoughts). So yeah, not literally identical. But I think it's still the right analogy. You code review to make sure the code is comprehensible to other humans. You code review to make sure the tests (which are great automated protections) are protecting against the right things. And (most relevant to the analogy) getting those things wrong are not abnormalities that mean you're a bad programmer and we don't trust you, they're things that competent devs can get wrong all the time.