Engineering Operating Principles

Purpose

Wunder engineering principles are intended to help align our engineering team philosophically and operationally. Our operating principles are not intended to enforce dogma, but rather to help codify the practices that we believe to be most foundational to our team’s effectiveness. Our principles endeavor to identify constructs that support both our ability to maintain high velocity, as well as our ability to build robust and maintainable systems within our problem domain.

Criteria

To ensure that our principles are pragmatic, we believe that our principles should generally pass the following set of criteria:

• Is this (nearly) globally true?
• Is this practically useful?
• Can I give feedback on this?

Operating Principles

Prioritize Pragmatism

While it can be appealing to lean on dogma because of the certainty that it suggests, the reality often exists in gray areas. We value reasoning with intellectual honesty and from first principles. Many of the following principles are in tension with each other, so we rely on our best judgment to find pragmatic compromises.

Tradeoff Examples

• Shipping imperfect solutions may require later rework, but we’re able to get faster feedback and iterate
• Techniques and patterns may be applied inconsistently across code base, but the flexibility allows us to choose the right tool for the job

Seek simplicity

In a problem domain dominated by fundamental domain complexity, it’s imperative that we limit the extent to which our systems introduce complexity. If fundamental complexity is our adversary then simplicity is our weapon. When in doubt, reach for simple solutions.

Additional Resources

• Simple Made Easy
• YAGNI

Tradeoff Examples

• Finding a simple solution may delay shipping features, but the design iteration helps build the best solution
• A simple solution may be less performant than a complicated one, but it will be easier to read and maintain

Operate Methodically

When approaching a problem, take the time to understand both the problem and solution space thoroughly. Understand what is necessary to execute, and then execute deliberately. You should always be able to thoroughly explain every action you’re taking.

Tradeoff Examples

• Understanding the problem and context may delay shipping features, but will make sure we’re building the right solution
• Documenting the reasons for our decisions takes time and effort, but being able to go back and understand past decisions helps us learn
• Upfront overhead during planning/scoping takes time away from writing code, but better designs are easier to iterate on leading to better velocity over time

Small Bites

Break your work into the shortest reasonable constituent paths between point A and point B. This helps support your ability to work methodically, helps reduce code review time, and generally supports our ability to iterate rapidly.

Tradeoff Examples

• Releasing incremental changes may lead to local maxima, but allows fast feedback cycles.
• Small steps may lead to local maximums requiring rework, but the feedback from the first pass will lead to a better final solution

Shared Goals

Goals are a shared responsibility. While workstreams frequently have an owner, look to find ways to help your teammates work more quickly toward their goals. Equally important, look for ways that you can ask your teammates for help that will allow you to work more quickly toward your goals.

Tradeoff Examples

• Teammate loses time context-switching when helping out, but unblocks others on the team allowing them to deliver faster
• Teammates lose time learning an unfamiliar area when helping out, but spreading context in new parts of the codebase makes the team stronger