It depends

We're currently reading "Code Health Guardian" with the rest of my team. So far, it's been a good summary of some good practices in software development (inspired by some other books that stood the test of time). I like to take the opportunity to step back from the content and think at a higher level about his approach and thinking model.

One idea the author communicates throughout the book is the ability to question everything (he doesn't do this directly, but hints at it in several locations), even wisdom that's been around for decades. Yes, these guidelines can be helpful to keep in mind, but realistically, there's rarely a perfect storm that allows for all the good things to manifest: being able to move fast, delivering impactful features, unblocking others, writing perfect code with simple interfaces, perfect test coverage, ...

Anyone who has been in the industry long enough knows that the answer to many questions in the technical field is "it depends". When you study system architecture—as you might have noticed from some of my previous posts on reviewing system architecture—you'll see that many decisions are not absolute truths in every situation. They vary based on the needs of your application and your circumstances. I find this to be applicable to many things in life.

It's fun to rethink "best practices" that have been passed from generation to generation of developers. I've realized that the clashing of these ideas often comes from strongly opinionated individuals. But the best engineers I've had the pleasure to work with understand better than anyone else which compromises should be taken and what the consequences are. They're very good at communicating the balance they're trying to strike.

Thought

My general thought for today is an invite: when you're reading anything technical—or about personal growth, leadership, or anything teaching you something—feel free to second-guess and truly understand whether the opinion, as authoritative as it may be, applies to yourself, to your circumstances, and to every situation you've personally witnessed.

Distill the content into primitive principles that you can follow and adapt to your life. This is also true for software development. There are certain principles that should stay true no matter which pattern you follow. The classic example is small functions vs big functions. They all come with pros and cons, and it's more about understanding what your goal is rather than strictly following "all functions should be short" dogmatically.