• Saigonauticon@voltage.vn
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    I’m usually on the documenting side of things. If something like this starts unfolding, I produce text or HTML files anyway, they go on github/lab/whatever, and I wash my hands of what happens next.

    In the end I write documentation mostly for myself. When the company can’t figure things out over Discord or whatever ephemeral chat interface they use, I get called anyway.

    • 𝘋𝘪𝘳𝘬@lemmy.ml
      link
      fedilink
      arrow-up
      4
      ·
      1 year ago

      > I produce text or HTML files anyway

      I do extensive in-code documentation. The compiler discards all comments so I don’t worry about commenting my code. Source code is for humans to understand and write anyways.

      • Saigonauticon@voltage.vn
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 year ago

        Oh, yeah. My source code is like 60% comments by weight (or more). Although I typically produce separate standalone documentation for management or semi-technical staff. You know, people who know enough to possibly break something, but not enough to fix it afterward. I find it useful when trying to train new people too.

      • CallumWells@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Also writing documentation in-code like JavaDoc or equivalents has always seemed great for me. Then you can have your toolchain generate the written documentation directly from that, and it can be updated easily based on what’s actually documented in the code (but that does require that people keep that updated)