A field guide for Spiff Engineers

View on GitHub

Getting Work Done

Engineering work takes a lot of different forms, but the most common unit of work is the Pull Request. A lot of our standard practices revolve around breaking problems down into Pull Requests that we can review and deploy independently. In most cases we aim for each Pull Request to represent around 1 day worth of work so that the changes can be understood and reviewed effectively.

Code Reviews

All changes to Spiff codebases should go through a pull request step. Pull requests are a great time to understand what other people in the team are working on and how it might affect your work. They are also a great time to ask questions.

“I followed the pattern in UpdateUserMutation here, does anyone know why we do it this way?”

During code review we try to automate as much of the mundane feedback as possible. Code formatting standards should be enforced by CI, rather than engineers spending time debating about it. The person opening the pull request should write up a brief that explains why a change is being made. Does it fix a bug? Part of a new feature? Refactoring?

The person reviewing a PR should focus on questions like:

This type of code review can be time-consuming because you will need to understand the “why” of the changes before you can really answer these questions. You might need to follow a few links or talk to the product team. This is exactly why we want human beings focused on these questions and why we push for automation of things that can be automated.

Projects at Spiff are generally setup to automatically deploy when we merge to master. The project README should specify if this is not the case.

The Hippocratic Oath of the Shipit

When you are reviewing code from a teammate, it’s your responsibility to protect and increase the quality of our system. Much like the Hippocratic Oath, we need to “first do no harm”. Specifically you should consider the following types of harm:

If you can’t answer all of the questions above with confidence, consider leaving a comment along the lines of:

Looks good in terms of code quality, but I’m not sure about performance. Have we done any benchmarks against production data?

This is going to be great for the onboarding team❤️. Is it safe for us to change this part of the graphQL? Or should we add a new field so the frontend code can switch to it in a backwards-compatible way?

20% Time

Most of our time as engineers is spent working as a team to iterate towards a shared goal, but great engineering often has step changes, unexpected connections or ideas that seem surprising at first glance. We foster this creative spark in the Spiff engineering team by setting aside 20% of our time as engineers to work on things outside the normal iterative flow. This 20% time can be allocated in a regular planned fashion (use each Wednesday) or as a sporadic activity when your mind makes a connection unexpectedly. How this time is used, is entirely up to you. Read a book that you’ve had recommended 6 times. Go learn how to program with “R” because it might have some common themes with our platform. Prepare a presentation for a local meetup or programming conference. We can’t predict or control intutive leaps and creative solutions, so the best advice here is to do something new or something that you feel inspired by.