Engineering culture

Our cultural manifesto

This document explains what it means to be an engineer at Infinity Works; our core values, how we approach our work and the tools we use to do so. It reveals what it means to work for, and with, Infinity Works.

A summary of this page is also available as a slide deck.

Our values

Full stack engineering

Engineers at Infinity Works are encouraged to broaden their skill set as much as possible by constantly learning and excelling at new things.

• Learning and excelling across all technical disciplines
  • Everything from client UI technologies, through server-side languages and databases, to operating systems, low level networking, and infrastructure.
• Learning and excelling at every level of the product life cycle
  • From idea generation and requirements gathering, through design, development and testing, right through to operating a live service.
• Learning and excelling within each technical discipline
  • i.e. using multiple programming languages and tools. This provides flexibility when joining existing teams and helps build an ability to choose languages and tools based on their merits and suitability for a particular task.

No one person will be able to cover everything across all these dimensions but crucially everyone will have the desire to always learn more. The end game is essentially to be able to tackle any problem thrown at you, regardless of where it sits on the above spectra, and we refer to this as the Full Stack Engineer. We believe the breadth of experience of the Full Stack Engineer encourages systems thinking, drives collaboration, and creates teams focussed from end to end.

No blame culture

We are here to deliver value to our clients, so our engineers should always consider the big picture. If something cannot be delivered due to a failed dependency we should seek to resolve the dependency rather than pointing fingers. Infinity Works doesn't do "that's not our problem", we'd rather pitch in and get things delivered.

Pragmatism

All projects have different constraints and different ideas about what "good" looks like. Our approach is not to be dogmatic about following any particular best practice, or achieving any pre-conceived notion of quality. Instead, we seek to understand the constraints within which we're working and build systems to the best of our ability within this. Compromise is inevitable, and presenting the different trade-offs confidently and objectively allows us to work towards an approach that everyone agrees with.

How we do things

Focus on operability

Delivery of working software into production to solve a business problem is the ultimate goal of everything we do. To achieve this our engineers know that it is important to think about how the system will be operated from the very first day of development. How can the software be monitored? How will this component be deployed? What level of information do we need in the log files to diagnose problems? This focus allows us to bake in operational concerns from the outset and means deployments are simpler from the first release and the feedback loops necessary are set up from the first line of code.

Services, not software

We do not just write software, we do not just build infrastructure platforms. We do both and we do them collectively within the same multidisciplinary team.

We employ engineers with a broad skill set that can work on both software and platform development. By building software and platform in tandem we shorten the feedback loop between the two concerns and ultimately the two end up working better together. The platform supports the software and the software makes optimal use of the platform.

Our full stack engineering approach allows us to solve problems at the appropriate level (don't solve infrastructure problems with software or vice versa) and reduces process overhead by striping the two disciplines into a single team. Having a platform built early into a project also allows non-functionals to be tested and improved.

Prioritise non-functionals

Making something work functionally is often the easy part. Making something fast, scalable or highly available can be a lot harder. Our engineers recognise that the best way to tackle non-functional requirements such as these is to address them early in a project by building them into a system from the ground up. We seek to understand the non-functional requirements for a system as early as possible, build them into the foundations, and prove they are met empirically through non-functional testing. We believe this makes the development and operation of a system more effective and less expensive.

Put your money where your mouth is

We don't do "felt tip" or "ivory tower" architects. We believe that in order to truly understand systems, and how to design, build, and operate them, you need to roll your sleeves up and get involved in building and running them. It is not enough to be able to present some theoretical solution and expect others to do as you say; we put our money where our mouth is and lead from the front. Delivering useful systems, not just pretty diagrams.

The tools we use

Right tools for the job

We are independent of all software vendors and do not have financial incentives to recommend one product over another. Similarly we are not a "one trick pony" that will always recommend the same solution, no matter what the problem. We do not have a standard prescribed technology stack that we always use. We will pick technology based on the requirements of the client, product and project. We try to strike a balance between choosing a technology that is a good fit for the task at hand, that is mature enough to be used operationally, and that fits with the organisation's culture and recruitment needs.

Modern not trendy

We prefer to pick modern solutions where possible, rather than stick with safe old-school solutions that maintain the status-quo. For example we might advocate a NoSQL data store over a RDBMS. However, we recognise that technology does not exist in a vacuum and that the client's ability to support, maintain and develop with the chosen stack is just as important.

Whilst being modern we avoid picking new technology for its own sake; we never pick technologies just because they are "cool".

Cloud native

We are big fans of cloud and seek to use cloud offerings wherever possible as we believe they can reduce time-to-market and reduce the overall cost of delivery and operations.

We have a lot of experience in leveraging Infrastructure as a Service (IaaS) providers to create fully automated, highly scalable, and resilient platforms to run business critical applications. Using Platform as a Service (PaaS) for cloud-native services would always be our first choice for building out a platform for a new service before considering the use of IaaS or even physical infrastructure. Always prefer using Amazon RDS or Aurora before deploying MySQL in a container or EC2 instance, for example.

Open and honest technology

We like to pick technology that is open and honest. That does not necessarily mean it must be open source but we like to see software vendors provide easy access to everything needed to use their software.

In essence:

• Can I try out (and even buy) the software without needing to be visited by a salesperson?
• Can I access help without signing up to a maintenance contract?
• Am I free to use the product if I don't need support?
• Is there an open community around the product for which I can go to for help?

Ideally, the answers to these questions would all be "yes".