Here are some small things I try to encourage when looking at or writing code to prevent easily avoidable bugs or problems.

1. Use types

Typed languages are great, and now even traditionally non-typed languages like Python or PHP have types as an option. They’re great and adding type info does not add much overhead. Instead it helps you understand the data you’re sending.

2. Reduce dependenccies

There are many benefits to reducing dependencies, but these are some of my favourites

1. Easier upgrade path.
2. Easier to reason about the dependencies you do have and why they’re there and what they do.
3. Smaller chance of getting affected by supply chain attacks.

When opting for adding dependencies, consider whether it’s simple enough that you can build it yourself, or if you can just copy the code directly instead of relying on a dependency. When you copy the code directly into your codebase or build it yourself, you own the upgrade path, you own the release cycle, and so you won’t suddenly get hit by an incompatible version or functional changes that can be hard to spot.

3. Brevity is better than clever

(dont use reflection/lodash etc)/don’t hide code, use proper constructors It’s always tempting to use tools that make the code look better via reflections or simple functions that magically grabs the data you want. This makes the code look great when it works, but can easily end up breaking in the future during a refactor. Try to avoid using components such as reflection, lodash, lombok etc if you can avoid it. Instead opt for code generation, helper methods that are type/compile-checked, and similar. The code might end up longer with more boilerplate, but its easier to refactor in the future and seeing code paths becomes much easier at a glance.

4. Optimise for glancability

We all read way more code than we write. I want to be able to know what is happening at a glance when scanning code. This saves me the trouble of thinking “where in this chain does x happen”.

Allow yourself to have easy to understand names, add comments that explain why a check is added. Git Blame is good for big architecture explanations but if you want to explain a specific part of the code, please use comments.

Make the code “airy”. I don’t agree with max-length of a line being 80 characters, but make it something reasonable like 200, and add line gaps! You’re not optimising for minimum amount of bytes, you’re showing your future self and others what logically hangs together in your code.