It started with a Sinclair ZX81.
My grandparents went abroad and brought back a small computer. They didn’t understand how it worked. They just knew it would make me happy.
They were right.
I was a kid writing BASIC, and the thing that hooked me was making the computer do something. Then do it a bit better. I was searching for perfection. Rewriting, debugging, testing — I wanted it to do what I intended.
That obsession never went away. It just got a job title. Then several.
Twenty-five years. Three phases. One thread.
In 1997, at my first real job at Bio-Rad, I was asked to write a unit test plan as part of my first design document. I didn’t know what unit tests were (hey, JUnit was invented that same year). I didn’t know about TDD (that would take a few years, and I was lucky to be one of the first to try it).
While, like most people, I didn’t like writing documents, trying to think about the expected behavior before writing a line of code was intriguing.
It also changed my career since then.
Over the next ten years I’d go from developer, to team lead, and manager, and finally cross-R&D methodology implementation. I saw quality from every seat in the room.
I learned and started teaching people: quality isn’t a stage in the pipeline. Everyone has responsibility and the ability to contribute. It’s a team sport, and when everyone contributes — it’s a winning team.
In 2007, I joined Typemock, a startup built around unit testing and TDD. I went back to writing code after years of management. Then support. Then testing. Then team leading. Then product development. At a startup, you do everything.
Once more, I did something different — I started working with customers, leaving my cubicle behind. Customers who needed better development practices.
I worked out what teams really needed. Which wasn’t always what they said they needed. That’s where the consulting instinct was born, years before I went independent.
In 2014, I took everything I’d learned and started TestinGil. Clean code, API testing, web automation, integration testing — the breadth came from real client problems, not a curriculum I designed at a desk.
Every engagement taught me something. Every team had a different version of the same underlying gaps.
And now, with AI reshaping how code gets written, I’m learning again. Not from a distance — alongside my clients. Helping make use of AI speed, basing it on the practical knowledge I already carry. Some of it holds. Some of it needs updating. All of it needs someone asking the hard questions.
That’s been the constant. The tools change.
One question doesn’t: Does the code do what I intend?
Everyone’s calling AI a revolution. But it’s an evolution.
I’ve watched this industry fall in love with every new thing, and every time, it’s X killed this and Y is dead.
It happened with Agile. Then with DevOps. It’s happening now with AI.
But you know what? In my 25 years of going through revolutions, one thing always remains: teams that remember their foundation are the first to make effective use of the new things. They build new knowledge and skills based on their experience, not throwing it away.
The rest just get bogged down, and go back to wait for something else to kill X.
25+ Years
In software, from BASIC to AI
1 Book
Everyday Unit Testing (2016). Still works in the age of AI.
15+ Years on Stage
Agile Testing Days, Nordic Testing Days, ExpoQA, Test Automation Days, and dozens more. Keynotes, talks, workshops and tutorials.
I’m not a vendor. I don’t sell a platform. I’m one person who’s spent 25 years learning what makes code work. And the last few years learning how to use AI for that.
If you’re leading a team and something feels off about your AI strategy, or you’re a practitioner who’s tired of being the human patch for heaps of generated code — let’s have a conversation.
I read every message. Personally.
And I’ll get back to you. As soon as I get rid of this zombie horde.