• Hector_McG@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      1 year ago

      Pinning the client down to deciding what they actually want/ need from the software. Preferably before you’ve delivered it, not afterwards.

      • derpgon@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        You don’t want the client to choose, he doesn’t want to choose either. Just tell him one is better than the other. Preferably the one that’s easier to transform to the other one if he changes his mind.

    • TheLinuxGuy@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      It’s incredibly difficult task to master/learn an old technology or an old concept that aren’t documented well. For an example, parser algorithms are very well known for being too verbose and unnecessarily over-complicated in documentation, if you ask anyone you know in the programming community, for the next 100 people, they wouldn’t know how to implement LALR parser or Earley parser even if they graduate from university with a computer science degree.

      One of the way I use to learn a concept is writing a full manual of it in LaTeX in a way that I am explaining every single aspect of it to a layman and how it can be implemented in every way as well as providing examples in C code forms. It’s a bit interesting that you sometime learn better by trying to teach it to a make up audience when writing a manual.

      Example page from a book I’m current writing in rough draft:

      spoiler

    • exapsy@programming.dev
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      not if you have invested in making it scaleable. but if you’ve inherited already one from another dev then you’re probably fucked. we barely cared back then about scaleability.

      • flamboyantkoala@programming.dev
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        It’s usually the domain knowledge that gets lost over the years that causes maintenance problems not the code or tech.

        Why things are done this way gets lost. The decisions that led to it. The hard earned knowledge by the original dev team.

        New team comes in and everything they do breaks something else because they don’t understand the up and downstream of their project.

  • Phoenix@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Commenting.

    I suck at it documentation. I always forget to do it, and then I forget what the code actually does, later. Then I spend a few hours analysing my own dogshit code before scrapping the whole thing.