My software engineering philosophy
2 min readNov 3, 2021
- Read A Philosophy of Software Design (author’s link). I wish I read it back when I started my career. I read this book maybe 3–4 years into career as a software engineer, and I had many aha moments. This book put into words many senses that I had but could not describe. I wish that anyone who ask me for a code review read this book first. It is never too late in one’s software engineer career to read this book.
- Treat building software as building a car. Building a car is engineering. Building software is also engineering. (I know it doesn’t feel so at times.) A car needs planning, decision making, testing and needs to run for 10+ years. Treat software the same way. Design it. Ask for feedback. Make trade offs. Document it. Test it. Make you decision to make it last 10+ years. I know the tendency is to iterate quickly over generations of software, but I don’t necessarily think it is a good thing. Users like consistency with improvements, not new services that will shut down in a year.
- Write code not for yourself, but for your readers and future maintenance. Write lots of tests and write them thoroughly. If that means repeating lines of ASSERT_TRUE, just repeat them. Testing makes sure that the code behaves as expected now, and more importantly behaves as expected in the future. When someone else works on this code base, or when refactoring happens in the future, having abundant tests makes sure that the expected behaviors are not affected by careless mistakes and typos.
- Document your intention. Either put documentation in a central location, or put them right next to the code, so it is easy to find. The point of documentation is to help people who are unfamiliar with the code base quickly understand what is going on. It’s intention is too make life easy.
- For a code base / project to last, tests and documentation are essential. It helps the code grow consistently, however many times the maintainer changes.
- Choose improvements over starting a new project for the same purpose. For example, if you have a music app, try to improve it instead of deprecating it and making a new music app. Users will lose faith if a service only lasts for a short time. And they will get stuck in a state where the old app is no longer supported, and the new app is not ready. And there is no promise that the new app is better, because we tend to make the same mistakes over and over. (Including choosing to start over!)
