Skip to content

Latest commit

 

History

History
45 lines (35 loc) · 3.26 KB

decoded.md

File metadata and controls

45 lines (35 loc) · 3.26 KB
Raw

decoded

In many of my projects1 you’ll find an edu.md file where I record the lessons learnt, difficulties encountered and challenges overcome while working on that particular project. Here I cover general things which I’ve picked up over the course of many years of software development, many projects of varying scope and complexity, and above all, many, many mistakes ;)

Of course, take them with a couple grains of salt, since many are only my perspective – not to mention that my ‘years’ might not compare to others’ ‘years’ at all. And after all, there are no absolutes. Not all are of equal value, and some may be really niche or specific. Either way, enjoy~

  • Theory can only take you so far. At the end of the day, the only way you’ll learn is by doing it yourself.
  • Giving projects a name gives them life, character, and a soul. I feel way more attached to my projects because of the names I give them. Take Penguin, for instance – horrific code? Absolutely. But an adorable name and icon to go alongside it.
  • The time and effort you spend now doing stuff properly is time and effort you’ll save in future when you don’t have to worry about fixing your broken infrastructure.
  • If you’re planning on leaving something for later, leave a note. Chances are, you’ll probably forget. On that note, don’t leave things partially implemented. Chances are, you’ll probably forget it’s partially implemented.
  • Figuring out why something isn’t working can provide really helpful insight.
  • Syntax really doesn’t matter as much as semantics, and semantics really doesn’t matter as much as function. But that does not in any way mean they’re not still important.
  • Software entropy is REAL
  • The documentation is your friend. Unless the developers were not good documenters.
  • Longer identifiers are an acceptable evil given the added clarity they can provide.
  • Having a remote like GitHub to store a backup of your code is a lifesaver.
  • Do things one step at a time, especially when using Git.
    • For instance, if you feel like renaming a folder (which ripples changes recursively through all of its contents), commit all your current work, ideally sync it (pull, push), and then do it.
    • A great aspect of Git (and there are many great things, imho) is that it pressures you (or convinces you to pressure yourself) to make concrete, categorised commits.
  • Projects are never finished. If they’re not in development, they’re in maintenance, and if you come back to it after some time there’ll always be new features or improvements to add.
  • It is extraordinarily rare that something works exactly right first try.
    • Hold on, how do builders do it??
  • Leave for a couple weeks, and it really does feel like you forget years of experience.
    • Getting back into the flow of things isn’t too tough tho =)

Footnotes

  1. (probably not the older ones, since I only started doing this fairly recently) ↩