Skip to content

findmypast/engineering-principles

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 

Repository files navigation

FMP Engineering Principles

We build it, we own it, we run it​

We are owners of our products, features and systems; both those we build and those we inherit. We are continually accountable for their entire lifecycle, from design, development, test, deployment, impact, maintenance, and even deletion. We continually monitor and support the systems we own.​

As engineers we are advocates for our code and systems. We are empowered to maintain and improve them. We share knowledge around them, we support teams to build upon them, and we facilitate contributions from others.

What good looks like

  • We consider how to make changes safely, using techniques such as feature toggles and gradual rollouts​
  • We ensure good coverage on testing, logging, metrics, and alerting so that problems can be identified rapidly​
  • We step in to support the response to incidents involving our systems, and ensure we document comprehensively to aid others.​
  • We push to make and balance technical improvements with other work, finding time to improve performance, fix bugs and build out our systems to a high standard.​
  • We work with other engineers looking to contribute or use our systems, for example, providing documentation, pairing on implementations, or accepting pull requests.

Ship value everyday​

We value speed of iteration and delivering value to both internal users and customers faster and more frequently, but without compromising quality. We slice our work thin, allowing us to commit code within hours and use DevOps practices to confidently push changes multiple times a day. We act with urgency to remove blockers and reduce dependencies. This allows us to be truly agile.

What good looks like

  • We break down tasks into smaller, manageable chunks, enabling quick iteration and rapid delivery without sacrificing quality​.
  • We use feature toggles to allow us to confidently push changes, enabling us to test them internally before fully tested​.
  • We maintain the cleanliness of our deployment pipelines, ensuring streamlined processes and optimal performance​.
  • We leverage automated tests to gain confidence in deploying to production.

Continuously learn and improve​

Continual improvement through learning is key to success at all levels. We work to master our craft to benefit ourselves, our teams and our customers. We accept that failure can happen but we look to fail forward, embracing all experiences, good or bad; always focusing on what learnings we can take to help us improve, sharing those learnings wherever possible. ​

What good looks like

  • Monitor and understand our career progression, and routinely share our learning experiences with others.​
  • Use retrospectives and post-mortems to learn from experience and thus drive improvement.​
  • Ensuring room for learning time in weekly schedule, catering for all learning styles.

We care deeply about quality​

We write high-quality code and high-quality supporting artefacts because they enable us to make changes fast and safely. Quality extends to all our work, not least to data, schemas and database management. We always leave code better than we found it, every little improvement helps, and the effort will be appreciated by others.   We collaborate with product to prioritise technical work and to ensure we have time to develop high quality solutions.​

What good looks like

  • We write tested, maintainable and documented code​.
  • We prioritise pair programming and code review​.
  • We use tools for version control and migrations to ensure data integrity and minimizing risk in database changes​.
  • We embody our learn and improve principle by making improvements to our code as we learn​.
  • We develop high quality solutions and push back on deadlines that force cutting corners.

Minimise blockers and dependencies​

We want to minimize the obstacles that can impact any teams ability to achieve their goals. Teams should have the capability, flexibility and can-do attitude to tackle any work needed to progress. They should also build platforms and codebases that are accessible to all. Communication is vital, the owning team should always have awareness of changes, and priority should be given to unblocking any work on their systems. ​

What good looks like

  • We document our code/services to ensure they are accessible to others.​
  • We communicate our plans/intentions to the owning team before we go ahead and make changes to their code/services.​
  • We prioritise code review of changes, whether they come from inside/outside our team.​
  • We show willingness to support others when they are having difficulty working in our codebases.​
  • Priority should be given to unblocking any work on systems you own.

We treat our data with respect​

The data we hold are our biggest assets and we treat them with respect: ​​

  • We look after our data.​​
  • We care about data integrity ​​
  • We protect the data ​​
  • Our records data are the result of years of investment. ​​
  • Our customer data represent years of research by our users. ​​
  • Our behavioural data are used to drive the business.​

Changes that can affect our data should be handled with care.

What good looks like

  • Automate GDPR processes ​
  • Databases - automate all changes to the DB schema and provided rollback automation ​
  • Backup data and test restore regularly ​
  • Use the principle of least privilege when accessing data​
  • Prioritize clarity, efficiency, scalability, and normalization in schema design​
  • Don't log PII ​
  • Ensure data accuracy ​
  • Rigorously test any changes that may affect the data.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published