He was a network engineer. I was on the collaboration side, and to him in the most affectionate way possible that made me a leftclicker. As in, all I did was point and click my way through GUIs while the serious engineers were out there typing commands like adults.

I loved it immediately. Still do.

Because here’s the thing: collaboration engineering sounds like you’re just configuring softphones and booking conference rooms. In reality, most of it ran on Linux. You were in the CLI constantly, managing services, editing configs, troubleshooting SIP trunks, chasing down call routing issues, and occasionally getting into arguments with the network team about whose problem it actually was. (It was usually theirs.) And then you opened the GUI on top of all that.

We weren’t avoiding the command line. We were just also clicking things.

As my career moved into automation, that perspective turned out to matter more than I expected. It’s easy to build something powerful. It’s harder to build something people will actually use. And if your automation is only accessible to the person who wrote it, it’s not really automation, it’s just a script with an audience of one.

Adoption doesn’t happen because the code is elegant. It happens because the experience makes sense.

A CLI junky running your automation? Give them a CLI interface; flags, pipes, the works. They’ll love it. But hand that same tool to a general user and you’ve lost them in the first thirty seconds. They need a GUI, or a chatbot, or something that doesn’t require them to remember argument syntax. Same automation, different front door.

That’s the part that gets skipped. And it’s usually the reason good automation sits unused.

So the name fits better than my friend probably intended. Leftclicker.io built by someone who understands both sides of the screen.

I started out as a cable tech, pulling and terminating network and voice cable. From there I moved into PBX and key systems, then into VoIP, and over time deeper into networking, infrastructure, and eventually automation.

Looking back, it all kind of built on itself. Each step led to the next. What started with the physical side of connectivity turned into a bigger interest in how systems work together, how they’re designed, and how they can be improved.

That’s really why automation became such a natural fit for me. I’ve always been willing to put in more work at the beginning if it means creating something that is easier to repeat and easier to rely on later. I like building processes that make sense, save time down the road, and take some of the guesswork out of the work. After seeing so much manual effort, inconsistency, and repetition over the years, automation just felt like the right direction. Not because it was trendy, but because it solved real problems.

That said, I don’t want this blog to be only about automation. That will definitely be part of it, but I also want to write about other topics that interest me too. Some posts will probably be technical, some will be about lessons learned, and some may just be about whatever I happen to be thinking about at the time.

I want this blog to feel open. More real, less polished, and not boxed into one thing. Just a place to share ideas, experiences, and things I find interesting along the way.