While at university, I worked part-time as a developer and sysadmin for a web development and hosting company. I worked remotely while being on-call to visit the data centre in person.
I worked in the International Investment Management department, collecting data on European stock markets. This mostly involved writing Perl scripts to munge data from a variety of poorly defined and variable input formats before loading them into FactSet’s proprietary time-series database. Some of the data processors, and the database itself, were implemented in C++.
I did not find this role technically challenging. The people were very friendly and I had an excellent manager (who later went on to better things) but the work did not challenge me.
Maxeler designed and sold hardware accelerators: PCIe cards with one or two FPGAs and a lot of DRAM, which were used to perform numerical computations very quickly. We were a small startup — I think I was the 7th employee — and our main competitors were NVIDIA, who were trying to do the same thing with GPU-based accelerators, and Intel, who were trying to convince people to stick with CPUs (while also experimenting with the Xeon Phi). In the end, we lost — GPUs are the standard in High-Performance Computing today — but it was an exciting time and we came pretty close to redefining how HPC is done!
My primary role was as an applications engineer, which entailed profiling applications, identifying candidates for acceleration, porting them to our hardware platform, and optimizing the result. However, we were a small company so we all did at least some work at every level of the stack: I also worked on our compiler, wrote the first version of our runtime, and developed our kernel driver. At one point, I spent some time sanding heat sinks.
After 18 months, I moved from London to San Francisco to help set up our new Californian office. I worked on-site with customers, embedded in their own teams, and worked remotely with the London office.
These are some publications related to my work:
I worked on the Dyson 360 Eye robotic vacuum cleaner. This contained an OMAP 3 processor running Linux, with most of the robot’s behaviour controlled by a C++ application.
One of my main contributions was performance optimization, which included:
However, I also worked on other parts of the application:
I worked on cross domain products, which are highly-secure network gateways and firewalls. I worked on both projects for the UK government and on a commercial product.
The commercial product was IndustrialProtect, a system to allow secure networking for industrial control systems. This was used to protect power plants, oil refineries, and similar Critical National Infrastructure from cyber-attacks.
The work involved writing networking components, mostly in C++, that ran on custom hardware with stringent reliability and performance constraints.
I might have stayed if Dyson hadn’t repeatedly asked me to return to work for them in their robotics research department.
I missed robotics and Dyson promised that the issues which had made me leave had been resolved. I decided to take a risk and give Dyson a second chance.
I worked in a robotics research team, implementing computer vision and machine learning algorithms on heterogeneous embedded processors.
My main role was to take research prototypes, which were typically developed on high-powered desktops, often in a high-level language such as MATLAB, and implement them efficiently on a low-powered embedded processor.
As part of this role, I evaluated potential processors and hardware platforms. I also acted as a liaison with PhD students at the Dyson Robotics Lab at Imperial College.
It became apparent that my role as a software engineer within “upstream research” was superfluous: my researcher colleagues were, quite reasonably, not willing to be constrained by practical engineering requirements when working on proof-of-concept prototypes.
Unfortunately, politics within the company prevented the development of anything beyond a proof-of-concept: the “upstream research” team was entirely separate from the “product development” team and the relationship between the two was not collaborative.
After some time trying to find a solution to the political issues without success, I burned out. When I was offered the opportunity to work on machine learning in a different context, I took it.
Gower Street is a data analytics company in the film industry. Their primary product is a simulation of the global box office, which their analysts use to predict how much revenue films will make in different markets.
The software team performed four main tasks:
Our services ran using Docker Swarm on some AWS EC2 nodes, all managed with Terraform.
We used a variety of different programming languages, including Clojure for the web app, Go for ETL, and Python for data science models.
When every cinema on the planet closed simultaneously due to the COVID‑19 pandemic, we lost most of our revenue. The CEO told us that the company had no money and could not afford to pay us for the month we had just worked.
eporta provided an online B2B marketplace and shops for the interior design industry.
The marketplace was the original product, implemented using Django. The online shops were the result of a pandemic-induced pivot and were built using Node.js and Serverless for a backend API with Next.js for the frontend.
Though not the most technically-exciting work, eporta was an excellent company for product development. We worked in small product teams: each team contained software engineers, designers, and product managers. We had regular contact with our customers, including face-to-face sessions most weeks, and very fast development iterations. The whole company worked together on product discovery, using opportunity solution trees. I learned what MVP really means!
Shopify is a multi-billion-dollar e-commerce company, providing online stores, payments, marketing, point-of-sale systems and more.
I joined Shopify via the acquihire of eporta. By the time I left, they still hadn’t worked out what to do with all the eporta software engineers they had acquired.
I had this job because Shopify bought my previous employer. I tried to give it a fair chance but it really was not for me.
My former manager at BAE Systems contacted me and asked me to join him in his new team there, so I did.
I joined the Operational Cyber team.
The work consists of a series of different projects under contract to various customers. Some projects are undertaken in house, others involve working on‑site embedded within a customer’s team.
My projects have included vulnerability research — reverse engineering and analysis looking for 0‑days — and writing custom firmware for networking devices.
I am the line manager for four senior software engineers.
My day‑to‑day responsibilities vary according to the project. When working in house, I lead teams of software engineers and researchers. I am a technical contact for our customers and am responsible for delivering project results. When on-site with a customer, I work within one of their own teams.
