30 Years In: What's Changed, and What Hasn't

cat ~/blog/thirty-years-whats-changed.md
· #career #reflections

I’ve been working in tech for a little over thirty years. I’ve never written much of it down, so this blog is my attempt to fix that. This first post is a map: where I started, where I am now, and what I’ve noticed along the way.

Where I started

I grew up on a farm in northeast Iowa, went to a small-town school and a small-town college, and liked technology before I knew it could be a career.

I spent fifteen years at Principal Financial Group in network, systems, and application roles. That meant learning how things actually connect and fail underneath the applications people see.

For the last twelve years I’ve been building and running Ruby on Rails applications in insurance (surety, specifically). These days I’m a Consulting Application Developer at Merchants Bonding Company.

What’s changed

Infrastructure became code. Early in my career, infrastructure was something you configured by hand and documented, if you were lucky. Today I manage ours with OpenTofu (AWS RDS, Cloudflare WAF), and changes ship through CI/CD on GitHub Actions like any other code. The work is the same — keep things running, keep them secure — but now it’s reviewable, repeatable, and versioned.

The job boundaries blurred. “Dev,” “ops,” and “infrastructure” used to be separate teams, sometimes separate floors. Now one developer can reasonably own a feature from the database to the WAF rules. My ops background turned out to be an advantage rather than a detour.

Languages changed how I think. Over the years I’ve explored Elixir, Haskell, Elm, and Scala. I don’t use most of them day to day, but each one changed how I write Ruby. Functional programming ideas — small pure functions, explicit data flow, fewer surprises — work in almost any language.

AI changed the daily workflow. This is the biggest shift I’ve seen in years. I recently architected AI-powered intake for claims and new business: extracting key details from emails and web forms and creating records automatically so underwriters can focus on underwriting. I also build with AI coding agents every day. I direct the work, review everything, and use them to learn new tools faster than I could alone.

What hasn’t changed

Most hard problems are people problems. The technology turns over every few years. What makes a team work doesn’t: people who are open to new ideas, who listen (and make you feel listened to, even when you disagree), and who actually want to help each other.

Understanding the business matters as much as the code. Twelve years in surety taught me that the best technical decision is often the one that fits how underwriters and claims staff actually work.

Fundamentals keep paying off. Knowing how networks, operating systems, and databases behave under the hood has helped in every role I’ve had — including debugging what an AI-generated change actually does.

Learning never stops. Thirty years in, I’m still learning — new tools at work, and outside work, the bass guitar and music theory. The habit of being a beginner again is worth keeping.

What’s next

I plan to write about:

If any of that sounds interesting, follow along via the RSS feed or find me on social.

cd ../blog
SESSION: -------- USER: guest MEM: 64K OK