I read a book called Coders at Work by Peter Seibel before starting university. Inspired by the format of Jessica Livingston’s Founders at Work, each chapter features an interview with an accomplished programmer. The interview style of writing feels like a personal conversation, offering a rare look into the thought processes of some very impressive people.

I’m currently in my second internship at FreeAgent. Last year, I wrote a blog post reflecting on the engineering lessons I learned from co-founding a startup.

When I was looking around the FreeAgent office, a copy of Coders at Work caught my eye. While Seibel took two years to conduct 15 interviews, I thought I’d try something similar, albeit on a smaller scale. I managed three interviews, including an intriguing chat with a physicist turned CTO, a former engineer who transitioned into management, and a data scientist who was involved in experiments at CERN.

Hopefully people find this interesting. I want to say a massive thank you to Graeme, Dave and James for taking the time to speak with me. 

Interviews

• Graeme Boyd – Chief Technology Officer
• Dave Evans – Group Engineering Manager (Analytics and Data Science)
• James Bell – Engineering Manager (Workflow)

TL;DR:

Graeme, Dave and James share their unique pathways into the tech industry. Their backgrounds and experiences are diverse and interesting. Despite the threat of artificial intelligence, they all stress the importance of human judgement and problem-solving. Their insights highlight that while tools and methods might change, the core ability to understand, define and address real-world problems will always be central to what we do.

Graeme Boyd

Angus: How did you learn to program?

Graeme: My parents bought a computer when I was about five years old. I remember typing something in BASIC with my dad. I was always fascinated with writing programs and making the computer perform tasks. I’ve used many programming languages now.

When the web started emerging while I was at university, I started building websites. The first programming task I was ever paid for involved JavaScript. But to be honest, working with JavaScript in those days was quite painful.

Interestingly, I didn’t study computer science; I’m actually a physicist. But I’ve been programming for a significant portion of my life.

Angus: Was your transition into leadership intentional? Did you always aspire to be a CTO?

Graeme: Since my academic background is in physics, I wasn’t sure if a career only in programming was for me. But I wanted to build things and solve problems. 

I actually had a different career in medical research. I developed microscopes, CT systems and the accompanying 3D software. After around six years doing this, I spent a few months creating pharmacy software using Ruby in the developing world.

When I returned, I joined a little startup called FreeAgent. 

Then FreeAgent grew quickly, we reached a point where Olly (FreeAgent’s co-founder and first CTO) was managing too many people. So the engineering team was split in half, and I effectively became FreeAgent’s first engineering manager.

Later, I joined another fintech company in Edinburgh as CTO. Since this company was a lot smaller than FreeAgent, my responsibilities were similar to that of lead developer and CTO. This experience taught me a lot about what the role of a CTO looks like.

After around three years of being CTO there, I returned to FreeAgent as director of engineering before becoming CTO of FreeAgent.

Angus: Do you feel having a varied career benefited you?

Graeme: Definitely. When I wanted to be a researcher or a scientist I couldn’t really see beyond that. University often paints a picture that your life’s going to go in one direction. But I’ve now had three careers – a medical researcher, a software developer and now as a CTO. All of these experiences have given me different perspectives. What I do now (management) is very different from programming.

Angus: Do you think programming might be automated soon?

Graeme: [Gestures to the copy of Coders at Work sitting on the table between us.] I don’t think programming is going to go away, but it could look very different. Just like the people in that book were using punch cards and writing machine code by hand; that way of working feels very old-fashioned now. Programming has generally evolved over time to become more and more high level and I see current AI tools as a continuation of that trend.

I think what we’re seeing is, knowing the syntax inside out is less important than it used to be. When you wanted to do something in a language or framework, you used to go away and read manuals or textbooks. This process became faster when Google search results started returning sites like Stack Overflow.

The current systems that exist like GitHub CoPilot are impressive but they’re still quite limited. That’s not to say these systems won’t improve, but I think there will always be some type of programming needed.

Angus: It was interesting earlier that you said management is very different from programming. How do you approach major technical decisions, especially when the stakes are high?

Graeme: We often talk about “one-way doors” and “two-way doors”, which essentially means irreversible and reversible decisions. When facing an irreversible decision, you need to think very carefully about it. 

Sometimes you look back on situations and think “we made the wrong decision there”, but often you made it for the right reasons. It’s quite hard to learn from decisions without making any, though.

Angus: What are your thoughts on AI-assisted decision making?

Graeme: One of the issues with AI at the moment is you can’t determine how a model’s arrived at a decision, which makes it a bit like a black box.

To be able to trust something like that I feel you need to get to a point where you can ask: “How did you come to that decision? What’s your logic?” Maybe that fits in more with me and how I like to reach the basis of understanding something. Much of my job these days involves challenging people’s assumptions or asking them to walk me through what they’ve decided. Sometimes in doing that, we pick up new understandings and things we’ve missed through our own intuition.

It’s rare as CTO that it’s me coming up with the final solution to something. You need to build trust in people and I think the same would go for anything involving AI-assisted decision making. You would need to see it has clearly made correct decisions on similar things in the past.

Angus: With fear of automation, are there any skills you feel will still remain relevant in years to come?

Graeme: Why are we writing software? Usually to solve some problem or make someone’s life better. The hard part of software engineering has never really been about the code, but rather solving the problem.

If I go back to 20 years ago when I was freelancing, the hardest thing was understanding what people wanted. The same still rings true today. Often, users give you the solution first, like “I want a system that does this”. Getting them to explain what the problem is for me is the difficult bit. Why do they need this in the first place?

No artificial intelligence is ever going to be able to replace that process.

Dave Evans

Angus: What’s your journey been like to date?

Dave: I studied physics as an undergrad then did a PhD in particle physics. As part of my PhD I moved to Geneva to work at CERN on the CMS experiment.

After that, I wanted to get a postdoc and went to UCSD. I was in San Diego for around six months before another four years or so at CERN.

It was a really interesting time. Part of the appeal was getting to travel. I got to participate in some of the first measurements at the LHC (Large Hadron Collider). I also contributed to the search for the Higgs boson. It was a lot of fun but plenty of late nights and stressful times.

When my postdoc was finishing up, I was thinking about leaving the field to do something different. The field of data science was starting to become more popular.

I spoke to a few different companies but I was impressed with what FreeAgent was doing and I liked the idea of living in Edinburgh. When I joined FreeAgent I was the only person doing data science. I’ve been glad to be able to build up the data function since then.

I got to lead the introduction of some interesting technologies, like the machine learning models that we’re currently using in production.

Angus: That’s fascinating. Did your background in physics help your transition to data science? It sounds like it was a natural progression.

Dave: Absolutely. I think there are a few different dimensions to that. When I was considering a move to the commercial sector, which is often referred to as “industry” in the academic world, a friend mentioned that there’s a stereotype that physicists just relax and drink tea all day. That’s far from the truth. Success in the academic world is hard work.

The problems you’re trying to solve in physics are typically very difficult. I was working with around 3,000 colleagues, and a very large organisation of people has its own internal structure and politics. You need to get to know people and how things are done.

On the technical side of things, experimental physics revolves around data – recording, analysing and using it to deduce information about our physical world. It involves skills like statistics, programming, data analysis and visualisation, which are essential in data science. I was also working on problems that involved machine learning; although the jargon changed and we didn’t call it machine learning back then. The same skills I gained working on physics problems carried over to my work here at FreeAgent.

Physics is all about seeing the simplest, quickest way to get to an answer in a very difficult situation. Then using that new understanding to infer something about the physical world around us.

Angus: As someone primarily focused on software engineering, I’m curious: what does a typical day look like for a data scientist?

Dave: Drinking cups of tea? No, I think it varies. The title “data scientist” is broad. Its meaning varies from one company or even one team to another. 

At FreeAgent, a data scientist typically works on building and optimising machine learning models and deploying them in production. This role involves machine learning, building infrastructure as code, and a deep understanding of our customers and their needs.

Tasks could involve selecting the right training data or choosing the appropriate technology for the desired prediction accuracy. Then building monitoring, deployment and inference infrastructures to measure the model’s performance.

Angus: Something I keep seeing when researching AI is model explainability. Why can explaining a model’s output be so challenging?

Dave: Explainability depends on the context and the model’s intended use. For example, predicting insurance premiums based on the price of a house requires a simple model that’s easy to explain. But understanding the exact reasoning behind a highly sophisticated model’s response can be much more challenging.

It’s part of a data scientist’s job to assess the importance of explainability against other factors like model accuracy, evaluation speed, and regulatory or ethical requirements. Sometimes, it might be as simple as drawing a line through data points, or at other times, as complicated as seeking answers from massive models. The key is to determine what’s most suitable for the problem at hand.

Something like linear regression, which has been used in the financial sector for decades, is straightforward to explain.

But on the other end of the spectrum, you have things like LLMs (Large Language Models) and generative AI. Now you’re talking about something with billions of parameters, trained on an enormous amount of data that’s maybe not that well understood.

I think it’s unfair to treat all techniques the same. Some models will be easy to explain and others not so.

Angus: With new technologies, there’s often an initial surge of interest, followed by a reality check regarding the actual costs vs benefits.

Dave: Technology often follows a pattern of hype cycles. When I was stepping into the data science world, “big data” was a massive buzzword. The industry was grappling with its definition, and for many, it ended up meaning an expensive engagement with a consultancy for a tech solution they didn’t truly need.

Not every problem requires an elaborate solution, and it’s important to find the most straightforward, cost-effective method for the task at hand. While there’s undeniable excitement around LLMs right now, they’re not a one-size-fits-all answer.

Just like with “big data”, or the rise of blockchain and cryptocurrency, every few years, a new technology comes along that’s touted as the next big thing. While they may have some lasting impact, it’s often not in the way we initially envisaged.

Angus: I’m starting to accept that AI could start automating some tasks in software engineering soon. But I think challenges in search of solutions will stay. If AI can help us get through the tedious parts faster, that’s a win.

Dave: There’s a fallacy in economics which I think is called the lump of labour fallacy. To say artificial intelligence is going to take over all jobs assumes there’s a fixed amount of work. New technology changes the landscape of jobs; while some may vanish, others emerge. The key is net productivity increase, creating more opportunities and jobs. 

With the introduction of machines during the industrial revolution, there was a predicted dramatic drop in working hours that never materialised. 

The important thing is how we decide to use AI – whether we use it to benefit society or cause unforeseen harms, like the negative impacts of social media on mental health. The dangers lie not in AI itself but in how we use and shape it in a societal context.

James Bell

Angus: What was your path to becoming an engineering manager?

James: I went to university to study computer engineering. It was a mix of high-level electronics, digital electronics and low-level programming. It was the kind of degree designed to teach you about building a mobile phone and the operating system the phone runs on.

Throughout my career, I’ve always had an interest in system-level thinking. Rather than focusing on individual projects from start to finish, I’ve always liked the bigger picture – understanding how things interconnect and how people collaborate within these systems.

I spent time at Yahoo! and a few smaller companies. When I first joined FreeAgent, I worked as an engineer for about five years. Transitioning into a management role was initially daunting for me. Despite having a decade of engineering experience, I felt like a beginner again when I first became a manager.

Angus: What initially drew you to software engineering? Was it passion?

James: I’ve always liked messing about with computers. I remember building Linux machines and assembling hardware in 1996/97. I wasn’t the typical tinkerer but I enjoyed the problem-solving element, much like writing. Can I solve this problem in a unique way and express it somehow?

I also realised I have a passion for helping others. It’s not just about being grand and noble; it’s simply about enjoying the act of helping people.

Angus: Have you witnessed significant shifts or advancements in the industry?

James: While there’s always noise about new trends, a lot are just repetitions of past concepts. 

There’s been a massive shift in how people work and collaborate. The number of quality developer-friendly tools has been a big change.

Things like distributed version control. But also something like Rails, right? There’s a lot of stuff Rails does for you. You should eventually learn how this stuff works under the hood. But you can get quite a long way without worrying about it.

Angus: Do you think software engineers will be automated?

James: It might be the tools are different and the places they go to are different. But problem-solving and the ability to translate real-world processes into digital ones will always be essential.

Angus: As an engineering manager, are there things you do that you’d like to see automated?

James: While I think much of the coordination work I do is essential and hard to replace, some tasks like scheduling aren’t significant concerns. Better alerting and monitoring systems that actively work with you could be useful. Also generating reports, especially ones I find not inherently valuable to construct but useful to analyse. This would free up more time for more valuable tasks.

Angus: With automation? Do you think we should be worried?

James: I think it’s good to be cautious, but many of the widespread fears about the death of certain professions due to automation are likely exaggerated.

I think the fear isn’t really about automation but more about capitalism. People worry their jobs might be replaced by cheaper, possibly lower-quality solutions. Given the track record of the companies currently driving automation, this makes sense. There’s certainly cause for concern. However, automation could also have a lot of positives.

Angus: Does this remind you of anything you’ve seen before?

James: AI does feel a bit different. It seems more widespread, potentially affecting various sectors and professions in one large sweep.

When the second iteration of Apple’s iOS devices introduced the App Store, there was a genuine fear among web developers that mobile apps would render websites obsolete. Over time, both platforms found their balance and continued to grow.

A few years back, people were talking about cryptocurrency. People believed it was going to revolutionise databases, enable zero-trust environments and reshape our financial systems. While it made waves, I would say it’s yet to have the same impact people anticipated.

When FreeAgent launched, many accountants felt threatened. They believed we were automating their jobs. We always emphasised our goal was to remove the tedious aspects of their roles, not replace the expertise they offer.