Andrew Paul
Senior Software Engineer & Trainer, with a passion for education over training!
Limavady, United Kingdom
Actions
Andrew writes code and teaches people. Sometimes at the same time. Over a decade in education (schools, colleges, training professional engineers) taught him that technical excellence without communication skills creates brilliant individual contributors but struggling teams. Now consulting on architecture while training engineering teams globally, he helps developers find their authentic technical voice- the one that writes elegant code AND explains why it matters.
Area of Expertise
Topics
Deprecated: The role was redundant. Not me.
When my manager asked for "a team update", I had no idea I was about to enter one of the least-talked-about experiences in a professional career. And yet within days I discovered something uncomfortable: almost everyone I told had quietly been through something similar. The nods. The knowing looks. The "yeah, that happened to me too."
So why does nobody talk about it?
Redundancy is surprisingly common, poorly understood and almost entirely absent from any conversation about career resilience... until it happens to you. A bit like pensions, really. A few people in the loop. Most people beside it. Almost nobody prepared.
Drawing from my own recent experience and 15+ years working across the software industry, this session maps the redundancy process honestly against the Kübler-Ross five stages of grief. Because it turns out you don't go through it once. You go through it twice- first through the consultation, then again through the job search. And the second loop is the one nobody warns you about.
This isn't a session about failure. It isn't toxic positivity about doors and windows either. It's an honest conversation about something that happens to good people doing good work at companies that simply pivot. You can do everything right. The role still gets deprecated.
You'll leave with a framework for recognising where you are emotionally if or when it happens, the language to talk about it (to yourself and others) and the reassurance that end of support doesn't mean end of service.
Because deprecated isn't deleted. It's just ready for what's next.
Pride-Driven Development: What We Do With the Time AI Gives Back
Every conversation about "best practice" with engaged engineers eventually hits the same wall: time, money, business goals. Ship it, fix it if it breaks. Engineers want the ideal code. Business wants the release.
AI is now sitting on that same fault line. It's buying us back time... but nobody's agreed what that time is for. Do we review the output properly, or just enough? Does it actually speed delivery, or just move the bottleneck somewhere less visible? And what happens to the juniors we used to bring up through the work AI now does for them?
I want to propose something small, and yes, one more entry in the TDD/BDD/DDD pile some of you already roll your eyes at:
PDD- Pride-Driven Development.
Not naive idealism... the money still has to be made. But if AI is genuinely handing engineers time back, why not make it policy to reinvest some of it into the code we've always wanted to fix, the tests we've always wanted to write, the 1,000-line class from 20 years ago nobody dares touch? Code we'd actually stand behind if a peer looked closely- or if an ITV drama came asking questions.
Drawing on 15+ years as a software engineering trainer and consultant, and a lot of very engaged arguments with engineers mid-training, I'll explore what happens when we let pride compete with profit instead of losing to it by default. And why, in the "10x engineer with AI" moment, we should write some of that story ourselves before the margins write it for us.
Because right now, every saved minute has two owners fighting over it: the sprint board and your conscience. PDD is just conscience getting a seat at the table and being given a name badge.
The Algorithm That Nearly Killed Me: When Testing Isn't Enough
When my new insulin pump’s algorithm confidently delivered what it claimed were hefty doses while my blood sugar soared toward dangerous levels, I faced a terrifying reality: the software was learning, but learning the wrong things. And it was utterly convinced it was doing a great job.
This isn’t just a medical device story - it’s a wake-up call for our entire industry. As ML and AI become critical infrastructure, they’re exposing fundamental flaws in how we approach quality. We test implementation rather than behaviour, write tests that validate our assumptions rather than challenge them and mistake comprehensive coverage for genuine safety.
Drawing from 15+ years as a software engineering trainer and consultant across multiple industries, I’ll explore how traditional testing blind spots become genuinely dangerous when systems learn and adapt. We’ll examine why teams confuse feeling safe with being safe, how AI amplifies our existing quality gaps and what it really means to test systems that make decisions affecting real lives.
You’ll leave with practical approaches to testing that focuses on impact over metrics, strategies for validating both deterministic and learning systems, and the essential questions every team should ask when software moves beyond just processing data to making decisions that matter.
Because whether it’s a payment system, a recommendation algorithm or life-critical medical software, our users are trusting us to get it right.
No Time, No Budget, No Training: Why 'Learning on the Job' Is Sabotaging Your Team
"We don't really pay for training. Our engineers just learn on the job."
It sounds sensible, even empowering. But scratch beneath the surface and you'll find it's often the root cause of recurring bugs, frustrated engineers, and teams that plateau just when they need to scale.
This talk challenges the comfortable myth that exposure equals expertise, and that motivated engineers will simply figure it out.
Through real examples from engineering teams, we'll explore how "learning on the job" often becomes "struggle alone", creating knowledge silos, uneven skills, and quiet burnout that never shows up on sprint reports.
You'll leave with a clearer understanding of training as system design rather than nice-to-have, practical approaches to building learning into team workflows without derailing delivery, and the business case for why investing in structured learning isn't just good for engineers - it's essential for sustainable growth.
Because great engineers keep learning anyway. Great teams just make it easier.
The Algorithm That Nearly Killed Me: When Testing Isn't Enough
When my new insulin pump’s algorithm confidently delivered what it claimed were hefty doses while my blood sugar soared toward dangerous levels, I faced a terrifying reality: the software was learning, but learning the wrong things. And it was utterly convinced it was doing a great job.
This isn’t just a medical device story - it’s a wake-up call for our entire industry. As ML and AI become critical infrastructure, they’re exposing fundamental flaws in how we approach quality. We test implementation rather than behaviour, write tests that validate our assumptions rather than challenge them and mistake comprehensive coverage for genuine safety.
Drawing from 15+ years as a software engineering trainer and consultant across multiple industries, I’ll explore how traditional testing blind spots become genuinely dangerous when systems learn and adapt. We’ll examine why teams confuse feeling safe with being safe, how AI amplifies our existing quality gaps and what it really means to test systems that make decisions affecting real lives.
You’ll leave with practical approaches to testing that focuses on impact over metrics, strategies for validating both deterministic and learning systems, and the essential questions every team should ask when software moves beyond just processing data to making decisions that matter.
Because whether it’s a payment system, a recommendation algorithm or life-critical medical software, our users are trusting us to get it right.
Learning to Talk the Talk - finding voices before it's too late
Promoted from a junior engineer on Friday afternoon to senior engineer on Monday morning- how many of us really hit the ground running? Or how many need months to figure out how we need to respond to our new responsibilities?
One of the biggest issues at this level learning how to communicate. To our team. To our managers. To our product owners. To an audience. What’s appropriate? What’s professional? What are they saying? What do we hear? Should I be using AI to help?
Preparing the industry for next wave of promoted young professionals requires us to engage and support communication skills now. We’ll look at how to overcome imposter syndrome, how to establish authentic voices and how to engage tools appropriately to grow ability from the earliest possible opportunity.
NDC Oslo 2026 Sessionize Event Upcoming
WeAreDevelopers - Online - 2026 Sessionize Event
DevConf 2026 Sessionize Event
NIDC 2025 Sessionize Event
NIDC 2024 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top