Who you’d actually be working with

I started taking independent contracts in 1995 and joined IBM Canada in January 1996, on project delivery and customer environments. Since then it has been the same shape of work in different industries: a business that runs on paper, spreadsheets, and one person’s memory, and a system that has to replace all three without stopping the business while it happens.

Since May 2008 that has meant Super Sonic — the equipment rental yard whose ERP I built and still run, now a white-label product for other yards. Before that, a technology lead role, an application developer and network administrator role, and the showroom touchscreen work that paid for most of the 2000s.

Super Sonic is in Edmonton. I am in the Lower Mainland, and have been for all eighteen years of it — running an Alberta company’s ERP, billing, payroll, and field apps from a province away, with no office there and no standing weekly meeting. Remote is not something I took up recently. Every system on this site was built that way.

In thirty years I have told a client something was genuinely impossible perhaps a handful of times. Ninety-nine times out of a hundred it can be done — and when someone has already been told otherwise, what they were usually told is that it could not be done with the product the last person wanted to sell them. That is a different sentence, and it is worth knowing which one you were given.

So the answer here is not no. It is what it costs, how long it takes, and which part of what you asked for is carrying the weight. Sometimes the honest version is that the thing you described is expensive, and a slightly different thing gets you most of it for a fraction of the money. That is still a yes. It is just a better one.

The distinction I do hold to: “I don’t think you should build that” is something I will say early and plainly. “It cannot be built” almost never is.

My first computer was an IBM PCjr in 1986, and I learned to code on it in BASIC. What put me there was Sierra’s adventure games — King’s Quest, Space Quest, the worlds Roberta Williams built — which I wanted to be inside so badly that I started taking apart how they were made. That dates me and I am not going to pretend otherwise — but it is also the whole point. Nobody taught me that, and nobody has taught me most of what came after it either.

The other thing those years gave me was the network. Doom deathmatch over a dial-up modem, then Ultima Online — where I did rather well — back when a persistent online world was still a genuinely strange idea. That is not just nostalgia: the instinct for real-time multiplayer, latency, and players who drop mid-session is the same one behind the cribbage game on the demonstrated page, where a dropped phone comes back to the same seat still holding the same cards.

I taught myself PHP in 1999, while I was still at IBM, because I wanted to build things that were mine. That is more or less the pattern ever since: the tool I need next is not one I already know, so I go and learn it.

The list has turned over completely more than once. ActionScript and Flash paid for most of the 2000s and are gone. LAMP carried the decade after. Now it is React and React Native, TypeScript, Node and Postgres, the AWS underneath all of it, and a model doing document extraction inside a lending product. Nobody handed me any of that on a course.

Which is the actual argument for hiring someone who has done this for thirty years. Not that I already know your stack — I might not. It is that I have learned an unfamiliar one about a dozen times now under a deadline, and I know how long it takes me.

The systems I am best at are the ones where being wrong costs money that day: rental agreements, billing cycles, payroll, fuel deliveries logged against equipment in a field, mortgage qualification against B-20. None of that is interesting as software. All of it is interesting as a business problem, and the software is only good if it matches how the business actually runs rather than how a process diagram says it does.

So the first thing I do on any job is learn the operation. Not the requirements document — the operation. What the counter staff actually type, what the driver actually does with one bar of signal, which report someone quietly rebuilds by hand every Friday because the system never got it right.

Game Art and Animation, Masters Program, at the Art Institute of Vancouver in Burnaby, 2003 to 2005 — the full game pipeline, character design through Maya and Unreal, with ActionScript alongside it. That is an unusual line on a systems CV and it is the reason the screens tend to be legible. Knowing what an operator is looking at, and in what order, is a design problem before it is an engineering one.

When I am not at a keyboard I am usually on a river. Fly fishing and gold prospecting are the hobbies that most resemble the work: you read the water before you cast or pan, you are patient with something you cannot rush, and you learn a place by standing in it — most of prospecting is just paying close attention to where the heavy stuff settles. I photograph the same country I fish — the light, the rivers, the mountains I grew up under. All of it comes from the same instinct as the animation training: look hard at what is actually in front of you, and get the framing right before anything else.

Direct. If the budget does not match the scope, or I think you are about to build the wrong thing, you will hear that early rather than at the end. If a job is not right for me I will say so and point you at someone better; I would rather lose a contract than take one I cannot finish well.

I do not disappear. Most of the systems on this site have been running for a decade or more, and the reason they still run is that the person who built them is still reachable. That is the actual product — not the code, the continuity.

Not just the application. The servers, the DNS, the certificates, the mail, the deploy pipeline, the backups. Every site and system listed on this site is deployed and operated by me end to end, including this one. It means there is no seam between “the developer” and “whoever does hosting” for a problem to fall into.

Every year a part of what I build goes to people who need it and cannot buy it. The current one is the Zero Cut Tax Disability Society in Coquitlam, who help people claim the Disability Tax Credit — twelve hand-built pages, done and handed over pro bono, with a README a volunteer can follow to change the address or the domain. Their readers are often working through a federal benefits process while unwell, on an old phone and a slow connection, so the site makes no third-party requests and has no build step.

The other half is time rather than code. I mentor developers coming up — people teaching themselves the way I did, with no degree and no bootcamp behind them, who mostly need somebody who will read their work honestly and tell them what to fix. I learned all of it with nobody to ask. That is the part worth handing back.

None of it runs as a lesser tier of work. It gets the same deployment, the same infrastructure, and the same person still reachable a year later — which for an organisation with no technical staff is usually the part that actually matters.