There Must Be a Better Way
How my brain works. Why I disappear down rabbit holes, build tools, simplify complicated information and keep asking whether there is a better way of doing things.
How my brain works
"There must be a better way of doing this."
That sentence probably explains most of the things I build.
I'll be doing something perfectly normal and notice a bit of friction. Something takes too long. Information is difficult to find. A process relies on somebody remembering something. A useful answer is buried inside a PDF, spreadsheet or system that wasn't really designed for the person actually using it.
Most people probably just get on with it.
My brain tends to go somewhere else.
Why does it work like that?
Could it be simpler?
Could the information already exist somewhere?
Could I connect a few things together?
And then, quite often, down the rabbit hole I go.
The rabbit holes
I like learning things, but usually not just for the sake of collecting knowledge.
I tend to learn because I've found a problem I want to solve.
That might mean learning about networking because I want to understand how equipment communicates.
It might mean digging through engineering drawings because I want to understand what a strange part number actually means.
It might mean learning enough Python, databases, APIs or web development to turn an idea into something useful.
One question creates another.
Then another.
Before long, what started as "surely there's an easier way to do this" has become a project.
That's probably why my workshop contains such a strange mixture of things.
Netball systems.
Stock databases.
Website projects.
CCNA labs.
Photography.
Fasteners.
Equipment drawings.
Half-finished ideas scribbled down because I know they'll bother me until I come back to them.
They look unrelated from the outside.
To me, they're all versions of the same thing.
I'm trying to understand how something works, then see whether I can make it work a little better.
Making complicated things simpler
A lot of technical systems are complicated because the thing they're dealing with is genuinely complicated.
But sometimes the complexity comes from how the information is presented.
A service engineer shouldn't have to understand the structure of a database to find a part.
They shouldn't have to know exactly what somebody called a machine twenty years ago.
They shouldn't need to search six PDFs to work out whether a bolt fits.
The system should do that work.
The person should be able to ask a fairly normal question and get a useful answer.
That idea has quietly become one of the main principles behind a lot of what I build:
put the complexity underneath and keep the useful bit on top.
The Parts Desk
The Parts Desk started because finding information about parts was harder than it needed to be.
There was information everywhere.
Parts lists.
Exploded diagrams.
Machine codes.
Serial prefixes.
BOMs.
Stock lists.
Old naming conventions.
New naming conventions.
And quite a lot of knowledge that normally just lives inside somebody's head.
None of those things are particularly useful on their own when you're standing next to a broken machine trying to answer a simple question:
What part do I need, and have I got one?
So I started joining the information together.
A part could know which machines it fits.
A machine could know which parts belong to it.
My van stock could know where something is physically stored.
Site surveys could tell me what equipment exists at a particular customer.
The Parts Desk could then begin answering questions instead of simply storing information.
That distinction matters to me.
I don't really want another database.
I want something that helps.
The Fastener Helper
Fasteners are probably the perfect example.
A bolt might appear in dozens of machines.
The description might be vague.
The manufacturer part number might contain information about its size, but only if you understand how the code works.
An exploded drawing might show where it goes, but not necessarily tell you what you actually need when you're kneeling next to the machine.
So the interesting problem isn't:
How do I store a list of bolts?
It's:
How do I turn all of that technical information into something useful to the person holding the spanner?
What size is it?
What thread?
What length?
What tool do I need?
Where is it used?
What machines use the same one?
Do I already carry it?
Where is it on the van?
Suddenly a pile of engineering data becomes practical information.
That's the bit I enjoy.
Translating technical into human
I've realised that a lot of what I do is translation.
Not languages exactly.
More like translating between systems and people.
An engineering drawing into something a technician can quickly understand.
A spreadsheet into a useful workflow.
A serial number into an equipment history.
A network diagram into a troubleshooting process.
A complicated idea into something somebody can actually use.
Technical accuracy matters, but so does usability.
The cleverest system in the world isn't much help if nobody wants to use it.
AI is a tool, not the toolbox
AI has become a big part of how I work.
But I don't see it as something that magically builds things for me.
I use AI as a helper.
I can bring an idea, explain the problem, challenge an answer, test something, change direction and keep going.
It lets me explore areas where I don't necessarily have years of formal training.
I still have to understand the problem.
I still have to decide what good looks like.
I still have to spot when something doesn't make sense.
And I still have to keep asking questions.
AI just makes that journey easier.
It can help me turn the picture in my head into something real much faster than I could on my own.
For somebody whose brain tends to produce more ideas than available hours, that is quite a useful thing.
Nothing is ever really finished
I'm not particularly good at looking at something I've built and thinking:
"That's done forever."
Normally I use it and immediately notice something else.
A button is in the wrong place.
A search could be smarter.
Some information could be connected.
A process could lose a step.
A screen could explain itself better.
That doesn't mean the previous version was bad.
It just means using something teaches you things that planning it never could.
Build it.
Use it.
Learn from it.
Improve it.
That cycle feels natural to me.
The bit underneath all of it
There's another thread running through most of these projects that took me a while to notice.
They normally help somebody.
Sometimes that somebody is me.
Sometimes it's another engineer trying to find a part.
Sometimes it's a coach organising a team.
Sometimes it's a parent trying to understand something.
Sometimes it's somebody who just needs complicated information explained in a way that doesn't make them feel like they should already know the answer.
I like technology.
I like tools.
I like taking things apart and understanding how they work.
But the useful part is what happens at the other end.
Someone saves time.
Someone finds an answer.
Someone avoids a problem.
Someone understands something they didn't before.
That's probably why I keep building things.
Not because every problem needs an app.
Not because every process needs automating.
And definitely not because I think everything needs making more complicated.
Usually, it starts with exactly the opposite thought.
There must be a better way of doing this.