Engineering is one of the core disciplines at 383. We pride ourselves on creating outstanding experiences for our clients by making market-leading products. So when the Engineering team decided to get together away from the office, it was for a very good reason.
It’s often said that software development is a lot like changing the tyres on a Formula One car while driving it at 100mph. New technologies arrive at a breakneck pace, while best practices can fall into obsolescence in the space of a single project.
There are more engineers at 383 now than there were employees when the company started
What worked well when just one or two people were writing a website does not scale across an entire team creating global platforms. There are more engineers at 383 now than original employees when the company started. Many organisations, as they transition from the small to mid-sized spectrum, combat this by formalising the processes they use and so hamper their ability to adapt quickly to changing requests. 383 has always valued its dynamism.
The agenda of the day was simple; to determine the direction of the Engineering team. Everything was up for discussion. One of 383’s earliest company mottos was to embrace risk and trust each other and this session exemplified that freedom. Our team of engineers shared their ideas for what they wanted engineering to be like at 383. Consistency and change were the words of the day. Take what is working well and share it across the team. Find common pain points, rip them out and improve the overall experience.
Ten years ago, getting a website online meant purchasing an expensive dedicated server with a lead time of several weeks. Then cloud computing came along and revolutionised hosting; one or a thousand servers could be spun up in a matter of minutes. At 383, we were quick to adopt it, enabling clients to meet the demands of a sudden surge in traffic effortlessly and we wanted to ensure we could make similar changes at a moment’s notice later on.
Many topics came up: how to ensure pages remained as fast as possible on an ever-increasing range of devices; how we monitor sites and notify engineers if they experience trouble; how to commit and store code so that any other engineer can download it and instantly know where to look; ensuring that QA is not just something that happens at the end of development, but is a continual process that constantly ensures only the best code makes it through to production.
Like the frog in boiling water, these were issues that had started small
By the end of the day, problems had been identified, possible routes discussed and solutions agreed upon by all. The output of the day took many forms, some to be implemented straight away while others will continue to grow organically so the company does not lose its adaptability.
A handbook is being written, as a guide for new starters and veterans alike. Projects themselves will benefit from continuous integration and automated deployments meaning engineers can go back to focusing on what they do best; creating world class experiences by making the best damn products out there.