How I think

Starting with the system, not the symptom

Maintenance work teaches you not to trust the obvious explanation. A machine failing the same way twice usually means the first fix addressed a symptom, not a cause. That habit — trace the problem back to its actual source before acting on it — is the one thing I bring into every unfamiliar situation, technical or not. I'd rather spend longer understanding what's actually going wrong than move fast on a guess.

Why I default to learning it myself

This is exactly how I got into Generative AI. Nobody taught me and I didn't take a bootcamp or a paid course — I got curious about AI image generation, then AI video generation, and started testing, reading documentation, and iterating on prompts until the output was good enough to be useful. That's not a preference for doing things the hard way; it's that I trust a result I've actually produced more than one I've only been told how to produce. Given an unfamiliar tool or process, my instinct is to build something small with it before reading much about it.

What kept me in it was realising the technology itself wasn't really the lesson. The actual lesson was in what came next: could this curiosity be turned into something someone would pay for? That question is what took the experimentation from a hobby to an independent freelance business — the learning, the execution, and the trust-building mattered more than the specific tool.

What running an independent practice, alone, actually taught me

Building an independent freelance practice serving international clients meant I was responsible for every part of it — sourcing the work, pricing it, managing revisions, and delivering consistently enough that people came back. None of that is glamorous, but it's where I learned that the technical output was never really the product — the process around it was. A client doesn't pay for a deliverable; they pay for a reliable way of getting what they asked for.

Why operations and systems, not just the work itself

Once I noticed that the process was the actual product, staying purely in the creative/technical side of that work stopped being the interesting part. What I actually want to get better at is the layer above it — how requirements get scoped, how delivery gets made reliable, how a small operation could run more like a deliberate system and less like one person keeping a lot of plates spinning. That's an operations and systems question, not a technical one, which is why that's the direction I'm moving in.

How I make decisions

Slowly, on anything that's hard to reverse, and quickly on anything that isn't. Before committing to an approach, I want to understand what happens if it's wrong and how expensive that is to undo — a habit that's fairly directly inherited from maintenance work, where an untested fix can cost more than the original problem.

How I communicate

Directly, and in writing where it matters. Managing client relationships from the first inquiry through final delivery meant that ambiguity was expensive — an unclear scope or an assumption left unstated turned into a revision cycle later. I'd rather set expectations plainly up front, even when that means saying no to something, than let a misunderstanding surface downstream.

How I keep improving

By writing things down and then revising them. Whether that's a maintenance SOP or a note to myself about what went wrong with a client project, I've found that the act of documenting a process is also the act of improving it — you notice the weak step in a procedure the moment you try to write it down clearly.