Software Engineer's Creed

I shall use indentation.

I shall use whitespace to make the code easier and quicker to read.

I shall comment appropriately, both on creation and later refactoring.

I shall make the code easy to understand, even when the underlying principles might be obscure.

I shall design the code and write design docs before I start writing the code.

I shall use meaningful names for identifiers for everything, including array indexes.

I shall use named constants, and never use magic numbers.

I shall endeavor to leverage type safety in all possible scenarios, eschewing the use of any in TypeScript, dynamic in C#, and any similar constructs in any language I write. In the exceedingly rare cases where these methods are absolutely necessary, I will thoroughly document my reasoning.

I shall make edits and refactors of existing code in the same coding style as the code that surrounds it.

I shall have others examine my code before merging it.

I shall take seriously examining other's code when they ask.

I shall not submit code 4 hours or less before a weekend or holiday.

I shall treat warnings as errors.

I shall put real life ahead of work.

I shall sleep 8 hours, exercise, eat healthy and maintain my social life so that my mind is in the best condition to write code.

I shall endeavor to limit work to 8 hours a day.

I shall double my time estimates, as there is always snag.

I shall take my vacation time.

I shall not make a meeting for what can be done in an email.

I shall not interrupt another programmer unless the interruption is worth more than the hour of time they will lose. This includes smells, proper hygiene is required.

I shall try first before googling an answer.

I shall always take the time to understand exactly how code found online works, and translate said code into the conventions of the source I am working in. Not just copy/paste and call it done.

I shall educate others on source I am the sole owner of.

I shall attempt to fully understand reasons behind the problem to be solved by the code I am writing. This includes asking questions of the originator of a task to make sure the solution you are making fits the problem they are trying to solve, as they might not know of an easier/already existing way.

I shall not write generic code until I have 3 spots that will use said generic code.

I shall lessen cache misses. And if I don't know what that means, I'll educate myself on this.

I shall learn a new thing every day.

I shall understand that some may think all the above is a joke, but really, it makes me a better engineer.