iFreeplay Engineering Team Virtues

At Freeplay Engineering, we…

1. Practice Collective Code Ownership
   1. As a team, we believe in collective code ownership, which means that every engineer on the team has equal responsibility for the quality and maintainability of the codebase. There is no piece of code that is owned by an individual. If we spot knowledge silo’ing we actively work to bust up those silos. This approach promotes knowledge sharing and collaboration, eliminates SPOFs, and enables us to deliver better results for our customers.
2. Limit work in progress to maintain focus against our priorities
   1. We limit work in progress (WIP) to maintain focus and ensure high-quality outcomes. We believe that multitasking and juggling too many tasks at once can lead to lower quality work and burnout. By setting clear priorities and limiting WIP, we can focus our attention on delivering quality results that meet our customer's needs.
3. Choose boring technology
   1. As an engineering team, we prioritize using well-established, proven technologies to build our software systems. By focusing on "boring" technologies, we minimize unknowns, streamline operations, and ensure our team can concentrate on solving our company's core challenges. We recognize that choosing technology is a collective decision, requiring careful evaluation. By opting for reliable, time-tested solutions, we foster an environment that allows our engineers to tackle bigger questions and drive meaningful innovation, rather than being bogged down by the complexities of the latest trends. Read for more: https://mcfunley.com/choose-boring-technology
4. Follow existing patterns unless there’s an order of magnitude improvement
   1. When designing a new system or feature, we first look for existing patterns and solutions that we can leverage. If we find something that works, we follow it unless there is an order of magnitude improvement to be made. By doing this, we can save time and reduce the risk of introducing bugs or errors into our codebase. However, we are always open to new ideas and approaches, and we encourage our engineers to experiment and innovate when appropriate.
5. Default to vendors unless it’s our core competency
   1. Build versus buy decisions should consider the full implementation and maintenance costs. It is often more intellectually interesting to build commodity solutions than to use existing vendor solutions, but the cost of operating, maintaining and extending those solutions is often much higher. Good build versus buy decisions look beyond the initial implementation cost, and don’t prioritize initial fun over long-term maintenance pain.

Process & Guidelines

Code Review

• Review Requirement: Before merging to the main branch, all production code must be reviewed by a peer other than the author.
• Commit Syntax: Use Co-authored-by syntax in commit messages to document the reviewer.
• Review Process: Conduct code reviews synchronously in person or via screen sharing. The author explains their changes line by line to the reviewer.
• Pair Programming: If code is developed jointly, a formal review can be skipped, but the Commit Syntax is still required.

Exceptions

1. Emergency Commits:
   • Direct commits to main are allowed in emergencies (e.g., critical bugs). Explain the urgency in the commit message and request a retrospective review via Slack.
2. Off-Hours Contributions:
   • Prefer opening a PR and waiting for a weekday review for off-hours work. If immediate action is necessary (for example when testing infrastructure), direct commits to main are permitted with a justification in the commit message and a follow-up review request on Slack.

Pairing

• We strongly embrace pairing to facilitate our collective code ownership value.
• Engineers on our team are expected to pair, on average, 50% of the time.