Know how good your code needs to be for the task at hand. Start with a rough draft. Try to soften requirements if you can. Don't get distracted. Make small changes. Practice specific skills.
  • daniskarma@lemmy.dbzer0.com
    3·
    3 hours ago

    Don’t go crazy about abstraction.

    Sometimes it’s better to write some code twice than expending two weeks trying to make a fit-all new class with 50 interfaces.

    Sometimes you should do that, but for many projects that level of abstraction is not needed.

    • Ephera@lemmy.mlEnglish
      2·
      1 hour ago

      Well, the writing-part isn’t the bad part about duplicated code. It’s the maintaining of it. In particular, if you duplicate logic, it happens all too quickly that you make modifications to one, but not the other, or you make differing modifications to both.

      Eventually, you’ll end up with two wildly different versions, where you won’t know why certain changes were made and not applied to the other version. Similarly, if you do need to make a similar change to both, you might now need to implement it two times.

      I guess, I do agree that it isn’t *always* worth it, but in my experience, it is far more often worth it than one might think.

  • ExLisperA
    4·
    9 hours ago

    Cut corners, remove features and sacrifice quality. Pretty much what I do in my hobby projects.