Experience matters. So does staying curious.

Sometimes that has meant software, networks, servers, electronics, or communications systems.

Sometimes it has meant repairing an appliance, rebuilding a car, working on a house, or solving some mechanical problem that really had nothing to do with computers at all.

The tools change.

The underlying curiosity really hasn't.

I've always been fascinated by systems: how the pieces relate, why something behaves the way it does, where the real problem is hiding, and whether there might be a better way to approach it.

That curiosity eventually became a career in technology, a business, a lot of software, and a rather broad collection of projects I probably could have left alone.

I'm glad I didn't.

From electronics to software

My interest in electronics goes back to the 1970s, long before computers became ordinary household objects.

By the 1980s, personal computers had become a major part of that fascination. The Apple II was especially formative for me, and programming it in 6502 assembly language gave me an appreciation for computing at a very fundamental level.

Later came x86 assembly, higher-level languages, operating systems, databases, networks, web applications, automation, and all the layers modern computing has accumulated since.

I appreciate those abstractions enormously.

But I'm also grateful that I learned close enough to the hardware to understand what many of them are hiding.

I have worked professionally in information technology since around 1990 and founded CyberLogix Innovations in 2002.

Over the years, my work has included software development, servers, networking, security, web systems, communications, telephony, automation, infrastructure, and plenty of things that don't fit neatly into one category.

What interests me most isn't really the technology itself.

It's the problem underneath it.

I like building things that solve real problems

One of the questions I ask frequently is:

Are we solving the right problem?

The most technically impressive solution is not automatically the best one.

Sometimes a complex system is justified.

Sometimes the best solution is a small change that removes the problem entirely.

I tend to approach technology holistically: understand the environment, understand the people using it, understand how the pieces interact, and then decide what actually needs to be built or changed.

When an existing solution fits, use it.

When several systems need to be connected, integrate them.

And when the thing I want doesn't exist…

That's usually when things get interesting.

The hands-on part never went away

Despite spending decades working with computers, I've never thought of technical work and hands-on work as particularly different disciplines.

I still repair appliances.

I work on home renovation, electrical systems, and plumbing.

I enjoy electronics, embedded systems, Raspberry Pi and similar platforms.

And I've rebuilt several cars, including frame-up restorations.

A car restoration and a software project may look completely unrelated.

To me, the thought process is remarkably similar.

Understand the system.

Identify what is actually wrong.

Preserve what still works.

Repair or replace what doesn't.

Think about how today's fix affects everything downstream.

Then test the whole thing rather than assuming the individual pieces add up correctly.

Sometimes the tool is a compiler.

Sometimes it is a multimeter.

Sometimes it is a torque wrench.

The problem-solving part feels very familiar.

Curiosity has a habit of expanding the project

I also have a longstanding inability to leave an interesting question unexplored.

If restarting something fixes a problem, I want to know why restarting it fixed the problem.

If an API behaves differently from the documentation, I want to capture the traffic and find out what it actually did.

If an astronomical calculation is already quite accurate but a newer model could make it substantially better…

Well, apparently I now need the newer model.

That last example describes Astrolabe, one of several HomeSeer plugins I've been developing.

It began because I wanted more astronomical information than ordinary sunrise and sunset.

It has since wandered into planetary and lunar ephemerides, eclipses, occultations, satellites, atmospheric refraction, Earth-orientation data, and weather-aware observing conditions.

There was probably a reasonable place to stop somewhere along the way.

I seem to have missed it.

What ties it all together

Whether I'm writing software, designing a network, rebuilding something mechanical, integrating an automation system, or learning an entirely new subject because a project wandered into it, the underlying motivation is much the same:

I like understanding systems well enough to make them work better.

I prefer evidence to assumptions.

I prefer thoughtful design to unnecessary complexity.

I prefer systems that remain understandable and maintainable after the excitement of building them has worn off.

And I believe technology should ultimately serve the people using it, not demand that they reorganize themselves around the technology.

After all these years, the part I still enjoy most is that there is always something new to learn.

Another protocol.

Another problem.

Another machine.

Another idea.

Another question that begins with:

“I wonder how that works.”

That's usually where the next project starts.