I have always learned by building

I am a software engineer and technical leader with more than twenty-five years of experience, but the part of the job I still enjoy most is the beginning: the point where a problem is still unclear and the solution has not been decided yet.

I like turning loose ideas into something concrete enough to test. Sometimes that means writing the first proof of concept. Sometimes it means laying down the reusable foundations that help a wider team move faster. Sometimes it means disappearing into an unfamiliar technology because that is where the problem has led.

The same pattern keeps repeating

Across support, application development, architecture, engineering leadership, cloud platforms and AI, I have usually gravitated towards the problems that do not already have an obvious answer.

I notice friction. I ask whether it has to work that way. I build something small enough to test the idea. Then I follow the evidence.

That habit has led me into frontend work, backend systems, infrastructure, developer tooling, machine learning, agent workflows, mobile games and a few experiments that are much harder to explain in one sentence.

The technology changes. The pattern does not.

Leadership never replaced engineering

I have led engineering teams of up to ten developers and worked with technical leads, product owners, analysts, customer-service teams and directors.

Even when my role included line management, planning and delivery responsibility, I remained actively involved in architecture and code. I was often the person working ahead of the team: building a technical spike, testing a new approach, creating boilerplate or reference implementations and removing the uncertainty before wider development began.

I enjoy helping engineers make good decisions, but I am happiest when I am close enough to the work to understand the trade-offs properly.

I do not collect technologies for their own sake

Most of the technologies I have learned entered my career because a problem required them.

Cloud infrastructure, Kubernetes, AI, frontend frameworks, build systems and low-level languages were not separate career plans. They were things I needed to understand in order to build, improve or investigate something I cared about.

That is why my experience is broad. I am comfortable moving across layers, but I try not to confuse range with mastery. When I enter an unfamiliar area, I start by making the uncertainty explicit, building something testable and learning from people who know more than I do.

A CV can only show the compressed version

A CV can say that I solve ambiguous problems, learn quickly and stay hands-on. It cannot show the messy middle: the wrong assumptions, failed prototypes, architecture changes and small discoveries that made the final result possible.

I built Project Curiosity to document that part.

The site is an engineering notebook rather than a traditional portfolio. Each experiment begins with a question and follows the work far enough to show what I tried, why I made particular decisions and what I would do differently now.

Most side projects begin with “I wonder if...”

Outside work I am usually experimenting in GitHub.

Some projects are practical tools. Some are games. Some explore AI, physics, knowledge representation or alternative ways of building software and the web. A few have grown far beyond the original question, which is usually how I know I have found something interesting.

Building things is how I learn. It is also how I relax, although Morris has occasionally challenged that definition.

What I am looking for

I am most interested in roles where I can combine product thinking, technical depth and hands-on engineering.

I enjoy working with small, capable teams on problems where the path is not fully mapped out, the engineering decisions matter and there is room to improve how both the product and the team work.