Top Ten Golden Rules

Top Ten Golden Rules

In professional ethics, some would list the following as their top ten:

  • honesty, trustworthiness, transparency, teamwork, accountability

  • confidentiality, objectivity, respect, strive for excellence, loyalty

The following is a somewhat ad hoc list in the context of software engineering:

(1) Avoid Repeating YourselfPrefer Cut 'n Paste; Avoid Copy 'n Paste... Refactor proactively!Copy 'n Paste is probably the most insidious habit in software development and one of the primary sources for software maintenance headaches and technical debt.
(2) Be IntentionalMake your intent as clear as possible whenever you write codeLike a good storyteller, make your intent clear. In general, strive for self-documenting code. Think about those that will need to read/understand your code a month from now, 1 year, 5 years, 10 years, 20+ years,...
(3) EvolveKeep up with evolving technologies & patternsWhether it be in the languages and frameworks that are already in use, or newer libraries and technologies that could potentially be utilized. And, always avoid using deprecated features.
(4) Detect Errors EarlyDetect coding errors at compile-time vs. at runtimeTry to force the compiler to do as much work as possible. For example, when coding in a strongly typed language (e.g. TypeScript), prefer the use of concrete types or use basic OO custom typing fundamentals instead of weak typing (e.g. avoid type "any").
(5) Highlight AssumptionsSometimes intent (see above) is not so obvious in the code itselfJudicious commentary can help when coding logic is complex and tricky, or steeped in historical/legacy context. Debug assertions can sometimes be good practice too.
(6) Don't overindulge in the "Happy Path"Implement error handling & logging proactivelyGo ahead and add appropriate error handling and logging in your code as you develop it - don't put it off for later!
(7) Avoid being overly PuristThe one-size fits all methodology is a misnomerDon't fall into the trap of thinking that such-and-such is the silver bullet... whether it be a particular language or framework, a testing ideology (e.g. test-driven development), or some well-known "process". Adaptability and flexibility are important, while of course still striving to maintain structure and consistency.
(8) ToolsA bad workman blames his tools... Forget that old proverb, instead: A good workman uses the best tools at his (her) disposal and learns how best to use those tools!Use the best IDE's for the languages/frameworks in question, and keep up with the features that can help you to develop better code (linters, AI assistants, debuggers, etc.). Get good at finding the "best answers" online using your favourite search engine and techie web sites.
(9) TransparencyFoster transparency and constructive criticismSugar-coating is unhealthy. Instead, our goal should be to foster a culture where we feel empowered to give constructive feedback and, in return, be willing to take criticism from our peers and use it to grow both technically and in our collective relationships.
(10) Curiosity & VulnerabilityBe curious and don't be afraid to show your vulnerable sideDon't blindly implement some piece of functionality without asking questions about the overall goal of the feature, specific requirements, and the potential scope of that feature down the line. Coding something with minimal context upfront invariably results in poor design decisions and problems in the future, particularly in the area of non-functional requirements (like performance & extensibility). And, don't be shy to ask questions and to seek assistance.