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:
- Does this change benefit users?
- Could I extend the behavior in this PR?
- Could we accomplish the requirements of the “why” with something simpler?
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:
- Does no harm to users?
- Does this change compromise the privacy of our users or customers?
- Does this change make it harder to get things done for our users?
- Will users be surprised or confused by these changes?
- Does no harm to our platform?
- Will this change cause unstable memory usage? Does it have a query that will cause a problems for the production database?
- When this feature breaks, what will the error message look like? How hard will it be to troubleshoot the problem?
- Should we track any metrics around these changes? Do we need observability tools?
- Does no harm to the project?
- Is this code understandable for a new engineer 3 months from now?
- Would the project be better if we changed the structure of the code?
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.