First Principles

Core Values

Get Shit Done (GSD)

The first responsibility of any development team is to Get Shit Done. This simple motto covers a lot of territory.

  • What kind of shit are we doing? Generally speaking, there are two types of work that we do -- work driven by the product team that delivers business value and work driven by the engineering team that enables us to better scale, operate, or develop and maintain applications.
  • What does it mean for it to be done? In one sense, a project is never "done" as long as it's running, as there will always be work needed to maintain it. In another sense, determining when a particular task is "done" (ie, task scoping) is one of those difficult problems that they don't teach you how to solve in school.
  • And, most importantly, how is it that we go about getting it done? This can include both tactical decisions like picking particular technologies to use and more meta questions about how we go about making those decisions.

There are no easy or quick answers to these questions.

Culture of Quality

Software is a living creature that requires constant love and care. We do not simply write code once and call it done -- it will require maintenance as we add new features, fix bugs, and scale our applications to meet larger workloads. We believe that investing in quality in the present will pay off in increased throughput in the future.

Quality can mean something different to different developers; however, a good rule of thumb is that high quality code can be easily maintained, especially by somebody other than the original author. This means that code should ideally be readable, easy to understand, easy to verify that it follows the spec, and easy to extend when necessary. In practice, this means not only following best practices when designing and writing code but also communicating with the rest of the team to share knowledge about each program.


The difference between a team of developers and a group of developers working independently is communication. Communicating effectively is hard! Each of us needs to evaluate what sorts of information to share, determine how to express that knowledge effectively, and be good at listening to others as they communicate. On top of this, we also need to be able to reconcile when people have different opinions and learn to agree or disagree.

A large part of this document will discuss our best practices around communication; however, our first principle of communication is, "when in doubt, always overcommunicate."

Humility, Respect, and Trust (HRT)

We adopted the principles of Humility, Respect, and Trust from the Team Geek book. This book aligns with a lot of our values, and we highly recommend that each developer read it. If you don't have a copy, ask Donnie to order you one.

Paraphrasing from the book,

  • Humility is remembering that you are human. This means that you make mistakes, you don't know everything, and you have things to learn.
  • Respect is remembering that others are human. This means treating others like you want to be treated and appreciating both their abilities and their accomplishments.
  • Trust is believing that we are all working towards the same goals and are able to contribute to those ends. This means understanding that even when we disagree, we are still on the same team. It means being comfortable with occasionally being a leader and sometimes following other people's leads.

Honest, Open, Trustworthy, and Fun

Our core company tenets are "Be Honest, Be Open, Be Trustworthy, and Be Fun". Bizo is built with information about people, and we must always be sensitive to the responsibility that this carries.

Rules and Processes

We believe that rules and processes serve several important functions.

  • They standardize expectations across the team, simplifying communication.
  • They provide healthy defaults for how to efficiently write and maintain software.
  • They encode our shared experiences, like a regression test suite for teamwork.

However, like any living codebase, our rules and processes still contain bugs, inefficiencies, and room for improvement. Part of maintaining our team is identifying places where our processes are not working and fixing them. Don't hesitate to break a rule if it is preventing you from GSD, creating high quality applications, or working together as a team. Do make sure that if you break a rule or change a process, you do so thoughtfully and communicate with the rest of us about how we can improve.