I decided to write down heuristics for my personal life, in the hope that I refer back to them frequently when making decisions.
Stand on the shoulders of giants
Or, “shun ‘not invented here’”.
Embrace and use solutions that already exist rather than creating from scratch. Unless you are creating from scratch in order to gain a deeper understanding of the thing. Because of course ...
If you wish to make an apple pie from scratch, you must first invent the universe — Carl Sagan
Compare yourself to yourself
Comparing yourself to others is a quick way to feel inadequate. There is always someone better at something than you are. The only person you should be comparing yourself to, is your previous self. Me a year ago would be proud of where I am now, and that's good enough for me.
Participation to promotion ratio
Be mindful of how much you promote yourself, vs helping others and participating in a community.
This is something I feel I need to work on. I write a blog post in isolation and then publish it and whack a link on Twitter. But currently nobody really cares: I can count the number of clickthroughs from Twitter on my fingers and toes.
This is fine. And expected. Shouting into the void and expecting a response is silly. The better way to help people is to proactively find people with problems and help them.
Participating in a community is the best form of self-promotion.
Sell your sawdust
Or, “the byproducts of creation are not worthless”.
If you've learned a new skill, write about it, and tell people, or see if you can help people using your newfound knowledge.
If you've solved a coding problem, see if you can extract it to a package.
This doesn't always mean sell literally, although if you can justify writing some longform content off of the back of learning a new skill, you should definitely stick it on Gumroad. This ties in to Passive Assets, which I may add here at some point.
Comments capture the why
A lot of the time, code can be self-documenting: small, well-named functions with well-named parameters; descriptive variables; etc. This helps understand what a program is doing, but not always why. Comments help with the why.
Never attribute to malice that which can be adequately explained by neglect — https://fs.blog/2017/04/mental-model-hanlons-razor/