A developer, some radioactive drugs and a lot of curiosity
From 15 years of .NET development to AI, Python and the never-ending list of things I want to learn.
I probably should have started this years ago
I’ve been writing software professionally for around 15 years, and somehow this is the first time I’ve properly decided to document what I’m learning along the way.
Better late than never, I suppose.
I’m Josh, a lead C#/.NET developer whose career has taken some fairly unexpected turns.
I’ve worked on EPOS systems, desktop applications, web services, laboratory automation, AI and distributed systems. I’ve written software that interacts with equipment handling radioactive pharmaceuticals, spent months travelling to install and support applications, and found myself demonstrating software to scientists and senior executives in places I never imagined development would take me.
And more recently, after spending most of my career happily living in the .NET ecosystem, I’ve somehow become someone who voluntarily opens Python projects.
I’m still coming to terms with that last one.
But if there’s one thing that’s remained consistent throughout my career, it’s that I’ve always enjoyed figuring out how things work.
And increasingly, figuring out how they could work better.
A slightly unusual development career
Like many developers, my career started with relatively conventional business applications.
Over time, though, I found myself working on increasingly complex software, eventually moving into laboratory automation within the pharmaceutical industry.
For a number of years, I was heavily involved in developing systems that controlled and coordinated laboratory equipment used in the quality control of radioactive pharmaceuticals for cancer diagnostics.
These were complex applications with plenty of moving parts, both literally and figuratively.
There were multithreaded processes to coordinate, instruments to communicate with, data to capture, failures to handle and regulatory requirements to satisfy.
Much of the software was developed using C# and .NET, particularly WinForms, Web APIs and later Blazor.
Working in regulated environments also meant dealing with requirements around Good Manufacturing Practice (GMP), 21 CFR Part 11, electronic signatures, auditability and data integrity.
It taught me to think carefully about reliability, traceability and what happens when software doesn’t behave as expected.
Because when your application controls real laboratory equipment, an exception isn’t always just an inconvenience displayed in a log file.
One of the more unusual aspects of the role was how involved I became in the entire product lifecycle.
I wasn’t just responsible for developing features. I was also travelling internationally to install systems, demonstrate functionality, train users, troubleshoot issues and work directly with customers.
That meant spending time in places including Los Angeles, New York, South Korea, Egypt and Norway, occasionally living on-site for months at a time.
I worked with scientists, engineers, laboratory teams and senior executives, sometimes switching between debugging code and demonstrating a system to people responsible for making significant purchasing decisions.
Those experiences shaped how I approach engineering.
They made me appreciate that building good software isn’t simply about choosing the right design pattern or writing elegant code.
It’s about understanding the problem, the people using the product and what happens when that product leaves your development environment.
Falling down the AI rabbit hole
My interest in artificial intelligence didn’t begin with ChatGPT.
I’d been curious about machine learning for years, especially after Microsoft’s introduction of ML.NET made it possible to experiment with machine learning without abandoning C#.
But when ChatGPT launched, something clicked.
Initially, it was interesting more than anything else. You could ask it technical questions, generate snippets and occasionally get some genuinely useful code.
You could also get some absolute nonsense delivered with impressive confidence.
But I kept experimenting.
Over the next few years, I watched coding models improve at a remarkable rate.
What started as a tool that struggled with relatively simple methods gradually became capable of navigating large codebases, reasoning across multiple files, interacting with development tools and implementing entire features.
I’ve spent a lot of time exploring that evolution, both independently and in professional environments.
What’s interested me most isn’t simply how much code AI can generate.
It’s how we can integrate AI into the way we actually develop software.
- How do we give models enough context to make useful decisions?
- How do we establish consistent coding standards?
- How do we use tools and guardrails?
- How do we review and validate generated code?
- And where should we deliberately keep a human involved?
Those questions interest me far more than seeing how quickly a model can produce 5,000 lines of code.
After all, generating 5,000 lines of rubbish isn’t particularly impressive. We’ve been perfectly capable of doing that ourselves for decades.
Discovering there’s life outside .NET
For most of my career, I’ve been very comfortable working with C#.
And I’m still a huge fan of the language and the ecosystem surrounding it.
However, getting more involved in AI forced me to explore technologies I might otherwise have happily ignored.
The most obvious was Python.
I’d always known how popular it was, but it wasn’t something I’d felt particularly compelled to learn.
Then I started exploring AI frameworks, models, libraries and research projects, and quickly realised just how much of the ecosystem revolved around it.
At first, I approached it reluctantly.
I missed Visual Studio. I missed certain aspects of the .NET tooling. And I had some fairly strong opinions about Python’s approach to structure and syntax.
But the more I used it, the more I understood its appeal.
The libraries are fantastic, experimentation is quick and the amount of support available across the AI ecosystem is difficult to ignore.
I now find myself using Python regularly for AI-focused work, often alongside C# applications.
Starting my own consultancy also exposed me to a broader range of software architectures.
I began working more with distributed systems, Angular front ends, messaging systems like RabbitMQ and Azure Service Bus, and event-driven applications.
These technologies introduced different ways of thinking about how applications communicate, scale and handle failure.
They also reminded me of something I really enjoy about software engineering: there’s always another layer to understand.
You learn one technology, which introduces another concept, which leads to another framework, which makes you question something you’ve been doing for years.
Before you know it, you’ve lost an entire weekend investigating a problem you didn’t even know existed on Friday.
Why I’m finally writing things down
The idea behind this blog is fairly simple.
I want somewhere to document what I’m learning, how I’m learning it and, most importantly, how I’m actually applying that knowledge.
I’ve spent years experimenting with technologies, building proof-of-concept applications, researching unfamiliar areas and figuring things out through trial and error.
But unless that work ended up in a production system, much of the learning simply stayed in my head.
And my head isn’t always the most reliable long-term storage solution.
Writing things down should help with that.
I also believe that being able to explain something clearly is a good test of whether you really understand it.
It’s easy to follow a tutorial, get something running and convince yourself you’ve mastered the subject.
It’s another thing entirely to explain why it works, what alternatives exist and when you might choose a different approach.
That’s what I want this blog to encourage.
I want to go beyond simply getting things working.
Having 15 years of experience doesn’t mean I know everything. If anything, it’s made me increasingly aware of just how enormous this industry is.
Some articles will draw on years of professional experience. Others will cover technologies I’m only just discovering.
I don’t intend to pretend otherwise.
What’s next?
I expect much of the content here will revolve around .NET, Python, AI, distributed systems, software architecture and the tools we use to build applications.
There’ll be experiments, comparisons, code samples, practical implementations and probably the occasional questionable architectural decision.
I’m not particularly interested in writing another article explaining what a technology does based purely on its documentation. I’d much rather build something with it, discover what works, find out what doesn’t and share what I’ve learned along the way.
Wherever possible, I’ll back that up with a GitHub repository containing something tangible that people can explore, run and experiment with themselves.
I want to document not just what works, but what doesn’t.
What surprised me. What I misunderstood. What I’d do differently. And whether something is genuinely useful or just the latest shiny framework everyone seems to be talking about.
Some experiments will probably be more successful than others, but that’s half the fun. And if I can save someone else a few hours of head-scratching by documenting where I went wrong, even better.
Ultimately, this blog is a personal record of trying to become a better engineer.
If other developers happen to find something useful along the way, even better.
So, 15 years into my development career, here’s my first proper Hello World.
About time, really.