International Programmers’ Day on 13 September

I didn’t take a traditional route into programming and, for a long time, I didn’t really consider myself a programmer at all.

I spent many years in sales, primarily selling technology-based solutions. Being so close to clients meant I saw first-hand both what technology could do and, just as importantly, where it could frustrate people. I often found myself questioning why something needed to be so complicated when, ultimately, the purpose of the technology was to solve a problem.

That curiosity, and probably a bit of frustration, gradually pulled me closer to the technology itself. I wanted to understand how things were actually built and whether there was a simpler, more practical way of getting to the outcome the client needed.

Over time, that naturally led me into programming. I think coming at it from a different direction has shaped how I work today. My instinct is still to start with the problem rather than the technology: what are we actually trying to achieve, who are we trying to help, and what’s the most robust and practical way of getting there?

It also came full circle in a way, because becoming more technical made me better at the commercial side too. The better I understood what we were building and why, the better I became at explaining it in straightforward terms and communicating the value to clients.

What first attracted you to the industry?

What really attracted me was the combination of problem-solving and creativity. I liked the fact that you could start with an idea or a problem and actually build something that made a tangible difference.

There’s also something very satisfying about programming in that you’re constantly learning. You try something, it doesn’t quite work, you work out why, change your approach and gradually arrive at a solution. I’ve always enjoyed that process of breaking a problem down and finding a practical way through it.

Coming from a sales background probably influenced this as well. I’d spent years talking to clients about what they needed and what technology could potentially do for them. Programming gave me the ability to go a step further, to take an idea or a requirement and actually turn it into something that works.

That ability to move from “wouldn’t it be useful if…” to actually building it is probably what captured my interest most, and it’s still one of the things I enjoy most about technology today.

 

What problem or experience sparked the original idea for tell.money?

tell.money wasn’t founded on some grand, forward-thinking vision where we perfectly analysed the future of payments and then decided to gamble on being right.

It was actually much more straightforward than that. My business partner and I had spent years building relationships with colleagues, clients and connections who had come to trust us and our ability to understand their problems and find practical ways to remove them.

One of those problems was Open Banking. In the early days, although it was a regulatory requirement, it wasn’t necessarily being viewed as a strategic opportunity. For many of the businesses we worked with, particularly those that needed to focus their investment and resources on growth, it represented another complex requirement competing for time, money and attention that they really needed to direct towards their core business.

We listened to that frustration and saw an opportunity to take away much of that complexity and distraction. Rather than asking our clients to become experts in something that wasn’t their core business, we could provide the technology and expertise they needed and allow them to stay focused on what they did best.

That was really how tell.money began to take shape. It wasn’t about us trying to predict the future; it was about listening carefully to what our clients were telling us they needed and building the solution around that.

We listened, we understood the problem, and we built tell.money as the vehicle to solve it.

 

How did that initial idea develop into the business and technology we have today?

We’ve always believed in Open Banking and the benefits it can bring to consumers, but from the beginning our focus was on helping our clients see it as more than simply a regulatory box that needed to be ticked.

The opportunity was to take something they had to do and turn it into something they could actually use — giving them the technology and capabilities to compete, improve their proposition and ultimately grow their businesses.

As tell.money developed, we continued with the same approach that got us started in the first place: listen first, then build.

As our conversations with clients evolved, we began hearing increasing concerns around Confirmation of Payee (CoP), and more recently Verification of Payee (VoP). Once again, these were complex requirements that could consume significant time and resources for our clients, but they were also capabilities that could create real value if approached in the right way.

So we went into action.

I think that has been one of the biggest evolutions of tell.money. We may have started by solving a specific Open Banking challenge, but we’ve developed into a business that continually listens for where complexity is creating a problem for our clients and then works out how we can take that complexity away.

The technology has grown significantly, but the principle behind it really hasn’t changed: listen to what our clients need, understand the problem properly, and build something that helps them compete and grow.

 

Why do you think programming is still such an exciting industry to get into?

I think programming is probably more exciting to get into today than when I started, because the barriers between having an idea and actually being able to build something are getting smaller all the time.

When I first became involved in technology, a lot of the emphasis was naturally on the technical skills required to build something. Those skills still matter, but tools such as AI are changing what an individual developer, or a relatively small team, can achieve and the speed at which they can achieve it.

For me, that makes understanding the problem even more important. If AI can help us write code faster, the real skill becomes knowing what we should be building in the first place, asking the right questions and understanding the people who are ultimately going to use it. Writing more code isn’t necessarily the objective; solving the problem better is.

Open Banking is a good example of that. Regulation and technology have opened up access and created opportunities to build services that simply weren’t possible before. Developers can now influence not just how a piece of software works, but how people and businesses interact with financial services.

I also think it creates opportunities for people who might not come from a traditional programming background. I was one of those people myself. Today there are more tools, more access to knowledge and more ways to turn an idea into something real.

That’s what makes it exciting to me. Technology keeps changing, but ultimately programming gives you the ability to look at a problem, imagine a better way of doing something and then actually build it.

 

How do you see AI changing the role of developers?

How has AI already changed the way developers work, and where do you think it will have the greatest impact next? Do you see it replacing parts of the development process, or giving programmers more freedom to focus on creativity, strategy and solving bigger problems?

I think AI will absolutely replace parts of the development process, and in many ways it already has. I don’t necessarily see that as a threat to developers, but I do think it changes where their value lies.

Writing code has never really been the end goal. The goal is to solve a problem, and code is one of the tools we use to do that. AI is becoming another very powerful tool in that process.

It can already remove a lot of the repetitive work, help developers explore different approaches, identify problems and get from an idea to a working solution much faster. That gives us more time to concentrate on the things that require judgement: understanding the problem, challenging assumptions, thinking about architecture, security and resilience, and ultimately deciding what we should be building and why.

But there’s an important distinction between being able to generate code and understanding what that code is doing. AI can give you an answer incredibly quickly, but that doesn’t automatically make it the right answer. Developers still need the knowledge and experience to question it, test it and understand the consequences of the decisions being made.

I think the developers who will benefit most from AI will be the ones who treat it as a way of extending their capabilities rather than replacing their thinking.

For me, that’s the exciting part. If we can spend less time on the mechanics of producing code and more time understanding and solving bigger problems, then AI doesn’t make developers less important — it gives good developers the opportunity to have much greater impact.

 

What advice would you give to someone at the beginning of their career?

I think the biggest piece of advice I would give is to stay curious and never be afraid to admit what you don’t know.

I didn’t come into programming through a traditional route and, for a long time, I didn’t even consider myself a programmer. Looking back, I probably spent too much time thinking about what I didn’t know rather than recognising the value of the experience and perspective I already had.

Technical knowledge is obviously important, but you can learn technology. Some of the qualities that really make a difference are harder to teach: listening properly, asking good questions, being willing to challenge assumptions and having the determination to keep going when something doesn’t work the first, second or tenth time.

I’d also encourage anyone starting out not to become too attached to a particular technology or way of doing things. Technologies will change, and with AI, probably faster than they ever have before. What remains valuable is your ability to understand a problem, learn what you need to learn and work out how to solve it.

And perhaps most importantly, learn to communicate. Being able to build something is valuable, but being able to explain what you’ve built, why it matters and how it helps someone is an incredibly powerful skill.

If I could tell my younger self one thing, it would probably be this: you don’t need to know everything before you start. Be curious, listen, keep learning and don’t be afraid to have a go. Some of the most valuable things I’ve learned in my career started with simply asking, “Why does it have to work that way?”