Bridgetown2026-10-17T08:16:27-05:00https://craigtreptow.com/feed.xmlCraig Treptow2026-10-17T00:00:00-05:002026-10-17T00:00:00-05:00repo://posts.collection/_posts/2026-10-17-thirty-years-whats-changed.md<p>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.</p> <h2 id="where-i-started">Where I started</h2> <p>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.</p> <p>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.</p> <p>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.</p> <h2 id="whats-changed">What’s changed</h2> <p><strong>Infrastructure became code.</strong> 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.</p> <p><strong>The job boundaries blurred.</strong> “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.</p> <p><strong>Languages changed how I think.</strong> 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.</p> <p><strong>AI changed the daily workflow.</strong> 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.</p> <h2 id="what-hasnt-changed">What hasn’t changed</h2> <p><strong>Most hard problems are people problems.</strong> 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.</p> <p><strong>Understanding the business matters as much as the code.</strong> Twelve years in surety taught me that the best technical decision is often the one that fits how underwriters and claims staff actually work.</p> <p><strong>Fundamentals keep paying off.</strong> 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.</p> <p><strong>Learning never stops.</strong> 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.</p> <h2 id="whats-next">What’s next</h2> <p>I plan to write about:</p> <ul> <li>Putting AI to work in real business applications</li> <li>Working effectively with AI coding agents as a senior developer</li> <li>Infrastructure as code for small teams</li> <li>Functional ideas in everyday Ruby</li> </ul> <p>If any of that sounds interesting, follow along via the <a href="/feed.xml">RSS feed</a> or find me on <a href="/social/">social</a>.</p>Craig Treptow