After a few years of working in software, I have come to appreciate a few engineering principles that I try to follow in my work. Some of them are more general, while others are specific to the software industry. Some of them are mine*, some of them are borrowed from other people. I hope you find them useful.

1. Simple is better than complex

From the Zen of Python, but it applies to software engineering in general. Simplicity is key to maintainability. A simple system is easier to understand, change, and maintain. Simple, reliable and predictable building blocks are the foundation of a good software system.

2. Code is mostly read, not written

Donald Knuth said that "programs are meant to be read by humans and only incidentally for computers to execute". While I don't dig literate programming, I think you should optimize your code for readability. Avoid clever tricks, write code that is easy to understand.

3. There is no free lunch

It is all about trade-offs. Every decision you make in software engineering has a cost, and you need to be aware of it. Most decisions you make will have a trade-off between complexity and performance, or between maintainability and reliability. There rarely is a silver bullet. You need to be aware of these trade-offs and make informed decisions based on the context of your system and organization.

4. Strive to reduce entropy

Software systems are complex, and they tend to become more complex over time. You should strive to reduce entropy everywhere you can. Make your codebase as simple as possible, ensure that your architecture is as simple as possible, and make it as homogeneous as possible. This will make it easier to maintain, understand, and change.

5. A perfectly engineered system without users is useless

Engineers often get caught up in the details of their designs, sometimes OCDing over implementation details striving for a perfectly crafted system. That is all in the nature of an engineer. However, keep in mind that without users -without revenue- that system is useless.

This is not to say that you should not strive for a well-designed system, but rather that you should keep in mind the trade-offs between a perfectly engineered system and the value it brings to users.

6. Choose boring technologies

When choosing technologies, go for the boring ones. The ones that have been around for a while, that are battle-tested, that have a large community, that are well-documented, that have a lot of libraries and tools available.

Engineers tend to get excited about new technologies, but often these new technologies are not ready for production, and they can introduce risk and complexity to your system. Boring technologies are often more reliable, more stable, and easier to hire for. They might not be the latest and greatest, but they are often the best choice for your system.

7. Know when to stop

Software is never finished, it is always evolving. You will always find bugs, you will always find ways to improve it. You will always find new features to add. Embrace this reality and learn when to stop. Perfection is the enemy of good. A software that is never finished is a software that is never deployed, and therefore never used.

8. Beware of fads

As mentioned above, engineers tend to get excited about new technologies, new methodologies, new trends. While some of these trends can be useful, many of them are just fads that will fade away over time. Be critical of new trends, ask yourself if they are really useful in the context of your system and organization. What works for Google or Meta does not necessarily work for your company. Do not fall for the latest fad just because it is trendy.

9. The bottleneck is somewhere else

When you are trying to optimize your system, remember that the bottleneck is often somewhere else. Do not optimize without profiling, and do not optimize for the sake of optimizing. Focus on the areas that are actually causing problems, and don't waste time optimizing areas that are not causing any issues.

10. Sharpen the axe

Invest in your tools, every % improvement in your tools will compound over time. The more you invest in your tools, the more productive you will be. This includes your IDE, CI/CD, testing tools, etc. Do not skimp on your tools.

--

*Note: I do not claim to have invented any of these principles, some I might have read somewhere and forgotten about it! Nonetheless I will try to credit the original author if I remember them. If you know the original author of any of these principles, let me know and I will update the post accordingly.