Guiding Principles

I recently read the guiding principles of Daniel Stenberg, curl’s BDFL. Although the principles are written for an open-source project with a diverse set of contributors, I believe that every software team, and by extension every software engineer, should have their own guiding principles. On this page I’d like to jot down what my principles are and how I apply them, both as a member of a team, and as an individual. Some of these are my own, while others have been adapted from Daniel Stenberg’s post.

Do good, be good

Software engineering, unlike what most people think, is a collaborative process. Additionally, software is created with the intention of making the world a better place. This means that one interacts with people either directly, by collaborating closely to design, test, and release the software, or indirectly, as users begin to use it. With this in mind, each of us shall strive to bring our best self forward to do good, and to be good unto others.

Build rock-solid software

Good software is the one users rely on. To this end, we shall ensure that we have processes and practices in place that help us ship reliable software. For example, thorough code reviews, extensive test coverage, timely resolution of bugs, adherence to best practices, maintaining backward compatibility, to name a few, shall be a part of the development process.

Leverage open-source

Some of the world’s best software is open-source. Adopting open-source software allows us to benefit from the expertise of the many individuals who create it while simultaneously providing an opportunity to contribute back to the community. It is also more robust, secure, and scalable. As a result, we will try to use open-source, whenever possible, and open-source our code, whenever we get the opportunity.

Provide top-notch documentation

A lot more time is spent reading code than writing it. We may spend time reading our own code a few months from when it was written, or perhaps someone else will read it to refactor or extend it. Writing clear documentation makes the process of understanding and changing the code easier. It also allows transferring context from one engineer to the next. Similarly, it is important to document the architecture of larger software systems. Therefore, we shall write clear and concise documentation for whatever software we create.

Stay abreast with the bleeding edge

Software evolves with time. With time the frameworks, languages, and other technologies that together make our system will undergo evolution. They will release bug fixes, performance improvements, or security updates. Therefore, we shall make sure to stay abreast with the latest technologies. From time-to-time we may also come across a competing piece of technology that does something differently. We shall keep an open mind and adopt it if it makes our systems better.

Take care of yourself

Finally, we shall take care of ourselves by taking time out and doing things that we enjoy the most. Take a walk. Read a book. Watch a movie. Spend time doing something you like. Enjoy life. :)