Software wasn't where I started. I started much closer to the machine.
Before I deployed anything, I was taking computers apart, working out why they wouldn't start, installing operating systems, building machines to order, and setting up offices. When I moved into software, I assumed that was a separate career. It turned out to be the same one.
Fixing a machine is a method
A computer that won't turn on isn't a mystery. It is a list of causes, and the skill is in working through the list in the right order.
The method I learned there has four rules, and I use them on servers today:
- Check the cheap, likely thing first. A dead machine is often a power problem, a loose component, or storage on its way out. You check the cable before you blame the motherboard.
- Change one thing at a time. If you swap three parts and it works, you've learned nothing.
- Swap in a known-good part. Put a working component in and see if the symptom follows it. In software this is a minimal reproduction, or a clean environment.
- Write down what you changed. Otherwise you start fixing your own fixes.
Compare that with a website that is down. Is the process running? Is the port open? Is DNS pointing at the right place? Is the certificate valid? It is the same list, one layer up.
Building a machine around a person
Custom builds taught me something different: how to turn a vague idea into a specific answer.
Someone comes with a goal and a budget. "I edit video." "I want to play games." "I need something for coding and a few virtual machines." The work is turning that into parts that fit together and spend money where it matters:
- The CPU socket has to match the motherboard.
- The memory has to be a type that board supports.
- The power supply needs headroom for the parts it will feed.
- The case has to physically hold the graphics card and the cooling.
And then the part a spec sheet can't tell you: where this particular person's money should go. Video editing wants memory and a strong processor. Gaming wants a graphics card. Development wants a fast drive and plenty of RAM. The same budget is spent in different ways for each.
That is also what I do when I scope software for a client. You start from what the person needs, not from the parts you like.
Offices, networks and labs
An office setup is more than machines on desks. Devices need addresses. The Wi-Fi has to actually cover the space. Cables have to go somewhere sensible. Someone has to decide who can reach what.
Setting up labs taught me the habit of containment. In a cyber lab, you assume things will go wrong and arrange the network so that a mistake in one place stays in that place.
I see the same instinct in how Spluur is built, where each project's Redis runs on its own network, with its own password and its own memory cap. One project's bad day shouldn't become everyone's.
Then software
Writing software was the natural next step: instead of fixing and assembling machines, I could make them do new things. First it was websites and applications, then APIs and databases, then the part that fascinated me most, which is how software actually runs.
That led to infrastructure, and to building Spluur.
The connection
This is the part I find interesting.
A server is a computer. A deployment is a system. A network is a network.
The tools changed. Servers instead of desktops, containers instead of cases, logs instead of the smell of a burnt component. But the method that finds a faulty stick of RAM is the method that finds a misconfigured proxy, and the curiosity that made me open the case is the curiosity that made me open the stack.
I still don't trust anything I haven't looked inside.