Dr. Neil's Notes
General > People
My Story
Introduction
Everybody has a story. That story is the combination of lived experiences, connections, relationships, successes and failures. This is mine. The story of how Neil became Dr. Neil; a journey spanning decades, continents, and an embarrassing number of lines of code.
A Child of the Seventies
Growing up in the 1970s meant black-and-white television, a great deal of running around outdoors, and the radical belief that the future was going to be spectacular. Then Star Wars arrived, and the future was no longer merely spectacular. It was a galaxy far, far away, populated by robots, lightsabers, and droids that were considerably more interesting than anything on television.
The natural conclusion, for any self-respecting child of that era, was to become a Jedi. When that career path showed limited prospects, the obvious alternative was to build robots.
I was fortunate, genuinely fortunate, that my father was a scientist with a deep interest in technology. In 1978, a Commodore Pet appeared in the house. This was not a pet you could take for a walk, but it was something of a magic box: 6502 assembler and Basic, a chiclet keyboard, and the ability to write software that could do maths and statistics. The seed was planted early and planted well.
By 1983, the Commodore 64 had arrived, bringing with it graphics, sprites, and the ability to build simple games. The future was not just spectacular any more, it was programmable.
Adventures and Misadventures
The teenage years were, in the finest tradition of the era, a spirited combination of wild debauchery and highly responsible employment. Cleaning offices and doing gardening provided the funds. Forests, mountains, and long wilderness trails provided the adventure. The debauchery provided lessons that are, on balance, best left undocumented.
I spent significant stretches living outdoors, camping for weeks at a time, often alone, sometimes with friends, occasionally as part of far larger organized group camps. There is something clarifying about being a long way from civilization with only a tent, a map, and the stubborn certainty that this was an excellent idea.
In 1986, I walked The Wicklow Way, backwards, as it turned out. Starting in Clonegal and finishing in Dublin, some 100 kilometres later. History is welcome to overlook the brief bus trip taken to skip one particularly testing section.
Two years later, in 1988, two school friends and I walked what felt like most, and was probably only some, of the Pyrenees trail from the Atlantic to the Mediterranean. Blisters, mountains, questionable food choices, and the particular camaraderie that only comes from shared suffering. A good adventure by any measure.
First Lines, First Companies
Also in 1988, a 286 PC arrived, and then, quickly, because there was software to build, a 386. With them came the opportunity to do something genuinely useful in C on DOS: building menu systems and user interfaces, and learning what it meant to ship software that other people actually had to use.
This led to Updata Software, a company building private investment software. I joined the founder as the entire development team, and set about building a Windows application in C and C++. When Windows 3.0 arrived in 1990, the world changed, and so did the application. By 1991, Updata was shipping to real customers. There is a particular satisfaction in seeing software you wrote running on a stranger's machine for the first time.
Around this same period, I started working part-time in a school, helping to run the computer lab. Somewhere in those hours of explaining things to students who genuinely wanted to understand, I discovered just how much I love teaching. It was not merely an insight. It was closer to a revelation. The act of taking something complex and making it clear to another person turned out to be as satisfying as building the thing in the first place. Perhaps more so. It was a thread I would keep pulling on for the next thirty years.
Building for the City
In 1991, I joined Synon, where the mission was to build a Windows user interface that would allow PC users to create software for IBM's AS/400 minicomputers. Visual tooling, before visual tooling was a widely understood concept.
By 1992, there were trips to the USA. The web was just starting. A curiosity to most, an obsession to a few, and I picked up contract work for US companies beginning to understand what it might mean.
This was a period of digitization on many levels, and one contract was to support technology to track public transport buses in real time in order to update signs on bus stops.
Then, in 1995, back in London, I co-founded Cognitech to build software for investment banks in the City. The search for better ways to build and ship software led us naturally toward Rapid Application Development, automated build machines, automated testing, and improved team collaboration. Ideas that felt radical at the time and now seem obvious. We built the company over five years, learning some hard and valuable lessons about what it takes to grow a software team with intention.
Becoming Dr. Neil
Running a company and pursuing a doctorate at the same time is not a strategy that any sensible person would recommend. It is, however, a remarkably effective strategy for developing a deep and largely involuntary expertise in distributed real-time software architectures.
The realization had been building through the work at Cognitech: the systems we were designing needed to be faster, more resilient, and better understood at an architectural level. The literature on distributed real-time systems was, at the time, patchy and scattered. The only reasonable response, other than sleeping, which was largely abandoned for several years, was to research the field properly, document it rigorously, and defend the conclusions in front of people whose job it was to find every flaw in the argument.
The PhD thesis did exactly that. The research informed the commercial work, and the commercial work gave the research a proving ground. This turns out to be precisely how good applied research should work: theory and practice in a constant conversation.
Emerging from the other side of a doctoral viva with the title Dr. Neil felt both genuinely earned and faintly improbable. The discipline demanded by academic research, the need to not merely assert but prove, to not merely build but understand, became a permanent feature of how software architecture problems were approached thereafter. It is a surprisingly useful thing to carry around.
Ahead of the Curve
In 1997, three things happened at once.
First, an idea turned company called Agent Task Force: intelligent agents that would sit on your desktop as personas, helping with daily tasks. The concept was driven by the recognition that neural networks were going to create smarter ways of working. The world would eventually catch up with this idea, approximately twenty-five years later.
Second, I co-founded WebPrecinct, a central online mall to enable multiple retailers to consolidate their online sales. People were still deeply wary of spending money on the internet in 1997, which meant we were, as would become something of a recurring theme, somewhat ahead of the curve.
Third, I began supporting other London tech startups with growth and strategy. The startup world has a particular kind of energy, and once you have spent time in it, staying away is difficult.
By 1998, I was working on software for phones that could connect to the internet. Smartphones, before anyone had thought to call them that. Not a guaranteed path to success at the time, but absolutely the right direction.
The New World
In 2000, I moved to Australia, began teaching and consulting, and got entangled with a small company building software for freight forwarders, called EDI. When I first walked into their office, there were perhaps six people in the room. Small, focused, determined. I worked with them to grow and ship their first full Windows application for freight forwarders in 2003, named ediEnterprise.
Watching a tiny team of six people grow into something genuinely substantial is not something you forget.
Finding Home at Microsoft
In 2004, I decided to spend more time in the USA. Brief stints working with NVidia and Intel gave way to what would become a long and extraordinary chapter. Finding my people and home at Microsoft in Redmond.
2004 also saw the publication of eXtreme .NET: Introducing eXtreme Programming Techniques to .NET Developers. The book grew directly from years of working at Cognitech and in consulting, trying to answer a question that kept resurfacing: how do software teams actually get better at what they do? Writing a book whilst simultaneously supporting a role at Microsoft is, it should be noted, an ambitious scheduling decision. It exists in no small part because of dear friends who also get mentioned in the credits, and who provided the space, encouragement, and occasional strong opinions in which the manuscript found its final form.
What followed drew directly on the love of teaching that had been building since the school computer lab in the early nineties. The work was intensely satisfying: getting deeply involved with new and emerging Microsoft technologies, teaching developers how to get the most from new SDKs and APIs, and contributing directly to the development of features for Windows itself. The scale was simply rather larger than a classroom. The list of technologies I was involved with reads, in retrospect, rather like a museum of ambitious ideas: Tablet PC, Virtual Earth (Bing Maps), Windows SideShow, Surface Table, Surface Hub, Kinect for Windows, HoloLens, Surface Dial, Azure IoT, Machine Learning, Cognitive Services, Containers, Kubernetes, and Azure AI.
Some of those became the foundations of entire industries. Others did not, and there is an honest story in each of those as well.
During this period I spoke at many conferences, often in front of crowds exceeding two thousand developers. Standing on a stage in front of two thousand people who have come specifically to learn something is a remarkable experience. One that never quite becomes routine, no matter how many times you do it.
Building Things That Matter
In 2008, I co-founded nsquared solutions in Australia. The company was built around one of the more interesting problems in human-computer interaction: what happens when you move beyond the mouse and keyboard, and start building software designed for large shared surfaces, touch, and gesture? The early products were built on the Microsoft Surface Table platform. At the time, an extraordinary piece of hardware that made natural multi-touch interaction on a large shared display feel, suddenly, possible. As the platform matured across Surface Hub and Kinect for Windows, nsquared grew with it, building interactive collaborative experiences for enterprise, education, and public spaces. The work eventually expanded from pure software into hardware: purpose-built interactive installations that brought custom software and physical display systems together into a single product. Products found their way into organisations across multiple continents. All while continuing to work with Microsoft, travelling constantly, and maintaining the nomadic lifestyle that had become, by this point, simply the way things were.
By 2016, a decision was made: reduce the travel, return to Australia, and plant some roots. In practice, handing over responsibilities and knowledge took until 2019. These things always do.
Coming Home
In 2019, the nomadic chapter closed. Back in Australia, full-time, after years of living out of a suitcase across multiple continents.
In 2020, I returned to the company formerly known as EDI, now WiseTech. The same product I had helped build in 2001–2003 was now far larger and considerably more successful. With that scale comes technical debt, and what was exciting and frightening in equal measure was discovering the same architecture and build systems from 2004 were still in place. A kind of archaeological dig through the decision-making of a company that had grown faster than its foundations.
The work was clear: modernise the codebase and technology stacks. Over time, that team grew to over seventy developers. The thread that had started in a school computer lab in the early nineties arrived here in its fullest expression yet: a developer onboarding program, named core skills training, was built to enable that growth. A structured curriculum, designed to bring new developers up to speed quickly and to distribute accumulated knowledge across a large and growing team. What had begun as a personal revelation about the pleasure of teaching had become, thirty years later, a scalable system for doing it at the level of an engineering organisation. Thirty-plus years of working with software developers, growing companies, and building and shipping software, now applied at genuine scale.
The software I helped build in 2003 was still running in 2020. That is either a testament to the original work, or a warning. I choose to believe it is both.
The Next Chapter
The pandemic years of 2020 and 2021 provided something unexpected: time. Time to start drawing and painting again, after years of not having either. Time to revisit creative writing, and to begin working on several novels. One has been published to date.
There is something fitting about a story that begins with a child desperate to build robots, and arrives at a person sitting quietly in a home office, painting, writing, and occasionally wondering what the next chapter holds.
Looking back across the decades, a few things stand out with unusual clarity. The best work has always been done with people, not despite them, not around them, but genuinely alongside them. The technologies have changed at a pace that would have seemed fantastical to the child with the Commodore Pet. The pleasure of helping someone understand something difficult has not changed at all. The most satisfying moments have not been the launches, the conferences, or the company milestones, though all of those mattered in their own way. They have been the moments when a developer grasped something they had been struggling with, when a team found a way forward they had not previously seen, when an idea that seemed impossible became a product that worked.
A career in technology is often told as a story about the technology. Looking back, it turns out to have been a story about the people all along.
As we accelerate headlong into the world of Large Language Models and software that writes code it will be the people, their ideas, creativity, and ethics that determine our future. Nothing is new.
The story, of course, is not finished.