The Dojo4 Playbook

A work in progress...

dojo4 on GitHub

Technology Philosophy

As described in lists:

Universal best practices are imaginary. This is how we think about software. This is not necessarily how you or anyone else should make software, unless you are in the codes with us.




Encrypted secrets > Deleting code > Avoiding writing code > Easy to read code > Easy to follow execution flow > Easy to debug code > Easter eggs > The team’s coding style > Easy to self-teach the codebase > Easy to test > Easy to extend > Community conventions > Easy to read a diff of the changes between commits > Abstractions > Your coding style > Being clever


Encrypted secrets > Production stability > Production security > Local development speed/performance > Local development observability > Local development debuggability > Production observability > Production debuggability > Production speed/performance > Everybody can deploy to every environment > Continuous integration > Automated test speed/performance > Standardized environments across projects > Works on Windows 👿 (you hafta help tho) > Bastion hosts


Encrypted secrets > Easy-to-use scripts for most development tasks > Easy to understand the contents of said scripts > Accurate project setup docs > Accurate common issues docs > Enforcing team’s code style > Well-participated-in pull requests > Standardization of aforementioned dev scripts across projects > Accurate architecture docs when the system is kinda complex > Works in PowerShell 💀 (you and your doing-it-the-hard-way hafta help tho)


Encrypted secrets > Boringness and maturity > Fewer moving parts > Fun to use > Well-documented FOSS > Pleasant to debug > Pleasant to maintain in production > Easy to hire for > Used in the past > What projects dictate > What clients want > What blogs say > What’s popular according to crawlers and search engine analyses > New and shiny > The JavaScript ecosystem 🤠 (no hate…shit’s just crazy…be careful out there yall)


Encrypted secrets > TDD for logic that has catastrophic consequences when it fails > TDD for code that handles real-ass money or assets > Writing tests for actions that have lots of side effects > Writing tests for things that are difficult or cumbersome to manually test in the CLI/API/UI > Deploying untested code to production > Writing tests for bugs that bork production > Writing tests for practical use cases that, in part, demonstrate how parts of the system work together (is better than documentation because failing tests force you to keep them up-to-date and accurate) > Arbitrary tests > Code coverage > TDD > Automated tests for HTML (there are infinite correct HTML, there can only be one correct datum)


Plagues (only if you must)