Engineering Principles

These are the core principles that guide our engineering practice and development philosophy. They represent the accumulated wisdom of our team and the broader software development community.

• Contribute to the Commons: You learn by reading the docs, so will everyone else. If something isn't clear or up-to-date, take the time to update it.
• YAGNI: You Aren't Gonna Need It: “Yagni originally is an acronym that stands for 'You Aren't Gonna Need It'. It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because 'you aren't gonna need it'.”
• DRY: Don't Repeat Yourself: “DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.”
• It's harder to read code than to write it: “This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings. They write their own function because it's easier and more fun than figuring out how the old function works.”
• “Premature optimization is the root of all evil”: “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.” (Also see: Make it work → Make it right → Make it fast)
• Technical Debt: “Software systems are prone to the build up of cruft - deficiencies in internal quality that make it harder than it would ideally be to modify and extend the system further. Technical Debt is a metaphor, coined by Ward Cunningham, that frames how to think about dealing with this cruft, thinking of it like a financial debt. The extra effort that it takes to add new features is the interest paid on the debt.”
• Private > Public: In a constantly growing codebase, keeping complexity in check means being intentional about what's exposed. Functions should stay private and near their consumers until another part of the system truly needs them. Every export or file adds to the surface area, increasing the risk of misuse and unnecessary cognitive load.
• Only add type when TypeScript can't infer it. Every type is another thing to maintain. Start with JavaScript, type when needed.

These principles help us build software that is maintainable, understandable, and adaptable to changing requirements. They represent decades of collective wisdom from the software development community.

If these principles resonate with you and you're interested in building the future of AI-powered marketing, we'd love to hear from you. Check out our talent page to see current opportunities and learn more about joining our team.