I find it’s difficult to know where somebody is coming from unless you know their background. Like everyone else, my opinion is formed over time based on my experience. So here’s a self-indulgent post where I share my work experience as both a manufacturing engineer and a software engineer.

I left school at 16 and got an apprenticeship working for Rolls-Royce, making turbine blades for aeroplane engines. This is where I began to turn a passion for solving problems into something the looked like a career, and RR has to be one of the greatest places on earth to do that.

After finishing my apprenticeship and working in the Precision Manufacturing Facility as a manufacturing engineer for a couple of years, I move on to work at Jaguar Land Rover at their Engine Manufacturing Center (engineers have never been famed for their clever naming practices).

Seriously, what’s this about actually? The Wikipedia article for Django (a popular framework for creating apps that live on the internet) states:

The framework was named after guitarist Django Reinhardt. Adrian Holovaty is a Romani jazz guitar player and a big fan of Django Reinhardt.

The Engine Manufacturing Center was named that because, well, they were going to manufacture engines there. Inspiring stuff.

My role at Jaguar Land Rover was a production manufacturing engineer, starting out on the cylinder block line. My job was to keep the machines running and, through a process called continuous improvement, try to do improve the process while it was running. This took the form of very practical, measurable things such as reducing the amount of scrap produced, improving throughput via cycle time reduction and improving process capability (how close to the nominal value we machined and therefore measured our parts).

I’ve got to give thanks to JLR here for allowing me such an immense amount of freedom in this role. I found a huge amount of passion and satisfaction in trying to find cool new ways to solve complex problems which spanned from the purely technical in nature to entirely people based. Over time, I left my role as a lineside manufacturing engineer into a more long term strategic role where I was away from the daily grind of keeping a line running and tasked with inventing and implementing big ideas that would benefit the business long term.

As part of this, I created a web based platform written in Python and Django which at its core, was a simple CRUD app that collected information from various sources, be it manually entered by operators or saved via an API request from a machine or CMM (Co-ordinate measuring machine).

In the process of building what turned into a huge project I fell in love with software engineering. I’d been programming machines and writing VBA macros for a long time but this felt like a whole other ball game. The fact that I could define a simple data structure as a Django model and some code automatically generated a user form for inputting data and a whole admin management interface seemed like pure magic to me.

The other thing that struck me was the instantaneous feedback loop. You make a change to your code, run it and see instantly whether it worked or didn’t. So much of manufacturing engineering is waiting. You have to set up a trial, then wait a month for it to be approved, then wait two weeks for CMM results to come back only to get the ambiguous answer of “it’s a little bit better”. The fact that I could make a change and know in a binary way whether that change had a positive or negative effect was like a drug.

There’s also the fact that when you got something wrong with Django you got some harmless red text in a terminal window. When you got something wrong with a machine a big chunk of metal smashed into another… and you’ve just thrown a 30 grand spindle down the toilet.

I started applying for jobs as a software engineer. This was an interesting point in my life and a classic example of “you don’t know what you don’t know”. I’d gotten pretty adept at writing Django by now, so I could do most of what was asked of me in a technical test. However, everything I’d learned up to this point was in a total vacuum. In the classic manufacturing engineering fashion I’d learned exactly as much as I needed to, to solve the problem at hand. I remember when one of my first interviewers asked me “What’s your approach to unit testing and test driven development?” and my reply was, I shit you not, “What’s a unit test?”

Somehow, I managed to convince the lovely bunch of people over at PrimarySite to hire me. I was lucky to be greeted by talented and supportive team who showed me the ropes as a software engineer, and what fascinating ropes they were! Things that must have seemed like ordinary parts of operating in a software development team were invaluable new tools to me. Simple things like using git to track changes to your code and not having my_program_v1_final_final.zip littered all over your documents folder. The idea of writing tests for your code, so you could be sure that any changes you made weren’t inadvertently breaking what came before. I felt strongly that if I’d known about and been able to employ these tools and processes as a manufacturing engineer I could have improved both my craft and the engineering business as a whole.

After a year at PrimarySite, I went on to spend some time working for Equal Experts. EE are a technology consultancy who do a lof of work in the public sector, specialising in fields such as data engineering and machine learning. it was here I got my first taste of AI. I hope to talk a little bit in future about “AI” and what that actually means, but on this project we were using a mixture of “traditional” machine learning and deep learning techniques to try and predict when a machine was going to fail, ahead of time.

Once again, I was struck by how incredibly useful this new technology would be in a manufacturing environment. A large part of my job as a manufacturing engineer was to analyse time-series measurement data or “run charts” to understand the performance of a particular machine or our capability in manufacturing a given feature. This process requires some skill and can also be quite time-consuming. Armed with these new tools it’s easy to see how you could employ some basic data engineering and machine learning analysis to automatically perform tasks such as anomaly detection. These techniques, applied to the mountains of machine and measurement data we collected at Jaguar Land Rover or Rolls-Royce would genuinely have been transformational. Imagine having a well-trained automated eye collecting and analysing your measurement data in real-time and suggesting changes to your engineers to keep machines running smoothly and in tolerance!

From working at EE I moved on to a company called Prolific, where the challenge changed again. Here we had a number of
technical issues, where the first was one of scale. Prolific has been and is growing rapidly. Inevitably we’ve found the original tooling used to create the site was no longer up to the task at the scale at which the company was operating. In this case, we had to think about the right way to migrate from an older, legacy system to a new one capable of meeting new and increasing demands while still keeping the lights on day-to-day. This is no easy task, the legacy system is not just business critical it is the business. Mastering the techniques required to migrate a large scale distributed system piecemeal to a new architecture or technology, while minimising risk to the business, is a skill I’m still learning every day.

Again, the tools and techniques used here could be employed in a manufacturing environment. The simple idea of making small, well-thought-out changes to a process in a ring-fenced environment, testing at a small scale, A-B testing your new proof-of concept to determine its performance vs the old system and building a process that is inherently scalable are all directly transferable.

My hope is that I get to use all these skills back in a manufacturing environment in the future. It would be great to see how much value you could unlock by simply embracing the tools and processes that the software and open-source communities have perfected over time. And honestly, I can’t wait to re-read all my posts from two years ago and disagree with almost everything I say, such is the way of learning and growth!