Objective: Every engineer at Float should ship code every day


Be curious

Seek to understand product requirements, code history, and rationale behind decisions. Take ownership of problems we solve. Be open to trying new tools and patterns that solve new problems.

Ship intentional, small units of high-quality code

Write tested code in small chunks to be confident that it will work as designed. Understand the consequences of our code – short term and long term. Vet external libraries before adding them to our platform. Take responsibility for our code, its deployment, and the impact on our customers.

Respect our customers and our colleagues

Float Engineering is built on respect. Respect our customers’ time and their problems. Our code isn’t perfect but we assume that the engineers who came before us did their best at the time. Similarly, we assume other engineers are currently doing their best. Respect each other and ourselves. Feedback is given and taken based on this mutual trust.

Write code for each other

Code that functions is the bare minimum. Good code is code that is written to be understood. We break down knowledge silos as we work, striving to communicate through our code and not just code comments. Our goal is to write code that others can safely and confidently maintain, even when we aren’t around.

Collaborate and communicate

Review others’ code frequently and diligently. Engage in thoughtful design discussions around product changes. Provide good context in pull requests for current reviewers and future curious minds. Write appropriate documentation. Work with our colleagues outside of Engineering, helping them understand product engineering so we can all work together to solve customer problems.

Build for evolving requirements

Strive to understand requirements as best we can, but stay flexible. We don’t know when or how customer requirements will change, so push to release code quickly so we can learn from customers. Don’t over-build, but don’t under-build either.

Manage tech debt

Treat technical debt like actual debt: it can be useful but it only serves us when used responsibly. Responsible technical debt is known, measured, and tracked. Make informed decisions on what to prioritize and when. Our goal is to leave code in a better state than when we found it. Make the change easy, and then make the easy change.