Engineering is a practice and to help guide your designs, decisions, and direction you need to coninusuly reflect, review, and refine your work and approach. To help with this everyone should have a personal Manifesto to help you guide and look back on your growth. This way you can re center yourself, update your and become a better engineer and better at your pratice. With that said here aremy core development philosophies.
Normalized Deviance happens when undesirable behaviors become culturally accepted. Detecting it is challenging as these behaviors may seem standard. Identify and avoid normalized deviance by increasing situational awareness through visibility & observability practices like logging, trend tracking and analyzing metrics. This allows for the recognition of trends, identification of risks, and documentation of actions, providing the necessary awareness to identify problems and develop informed solutions.
Avoid getting attached to specific tools or processes. Just like treating computing resources as cattle, not pets, implementations should follow suit. If needs change or better solutions come up, be ready to drop or adapt the implementation for the desired outcome.
Ensure that you sign your work with a big signature so that people know who created it. However, avoid bragging; instead, let people recognize the signature in the code through your comments, docstrings, clear variable names, and detailed commit messages.
When we make mistakes or have misconceptions, we have the opportunity to learn and correct misunderstandings that could arise in the future. A good engineer acknowledges this, handles it gracefully, and views these moments as learning opportunities. This holds true for both the party that corrects and the one being corrected.
Documentation should not be seen as a chore, but instead as automation to save you time in the future—either by enabling others to understand something without you having to explain it to them or by helping you re-teach yourself what you did.
Users are the foundation of any software project, and you have a responsibility to act as their advocate. They’ve placed their trust in you by sharing their data and expecting your project to be there when needed. It’s essential to advocate for their needs, especially since they don’t see the behind-the-scenes work. This means promoting sound testing practices, building reliable systems, and ensuring robust security.