My father was the same way. I remember going home to visit and noticing he didn't seem to own a single tool he hadn't modified in some way. That's genuinely where I come by it — if something doesn't do exactly what I need, I change it until it does. A workaround just means the actual problem is still sitting there, waiting for you to trip over it again.

How I got here

A fairly ordinary start, for someone who does this.

I've been into computers since my first Apple //e, then a Compaq 8080 with a built-in monochrome screen, a keyboard that popped out of the case, and a case that genuinely looked like a Singer sewing machine. I ran a bulletin board off a 300-baud modem — for anyone who never dealt with one, I can read faster than 300 baud can put text on a screen, by about double. I've been building web pages since you could build your own web page at all, from plain HTML up through everything we use today.

What I actually love is building things that are functional — especially database-driven web apps, because they become real tools you use, not just a static page you look at. Building something that solves a real problem scratches an itch for me. Constructing something out of absolutely nothing, that millions of people could potentially use, is genuinely satisfying in a way I've never gotten tired of.

My first official IT job was at Cox Communications, after some time in the restaurant field before that. I started in tech support and quickly found I was resolving calls — start to finish, satisfied customer, sometimes an upsell along the way — in under half the time of most of my peers, a couple of minutes faster than the 7–12 minute window the call center's own numbers expected. Being faster than everyone else while scoring perfectly on every other quality metric got me dinged, because I wasn't spending enough time on the phone. I couldn't let that go, so I pushed it up three levels: "Is there anything I didn't do on that call that I should have?" No. "Was everything else terrific?" Yes. "So the only thing I did wrong is being too efficient — do you want me to waste the customer's time on purpose?"

What finally got someone's attention was the actual answer to how I was doing it: I'd built my own HTML click-through flowchart on my own time that mapped out decision-making for troubleshooting, and kept refining it as I learned. Attacking a problem in a specific order, using specific language, got customers to the fix faster — reliably. That flowchart eventually got rolled out to the rest of the tech support group, and call quality went up while average handle time dropped, both by roughly 40% company-wide.

From there it was one IT role after another, each a step up, until a former boss — who'd already left for another company — called about a month later and asked if I wanted to come with him. He'd apparently already lined up a new client he wanted me flying out to learn from in three days, so he could bring me back to build a training program around it. He told me he'd already bought the ticket. I still don't know if he was bluffing. Three days later I was on a plane, signing paperwork in the airport before I even landed. From there I managed multiple large teams across multiple shifts, covering tech support and managed services at once, and genuinely grew to love this field.

Trube Technologies itself has actually existed since 2000 — a side project building websites under that name, something I did alongside whatever the day job was. What changed was deciding to make it the actual focus, instead of something on the side, and building it into something real.