At one point in my career, I was opening books in the University of Washington library to work out the mathematics for a mapping application.
I was building a globe in Silverlight, importing map tiles, and figuring out how to render them in the right places. Getting it working meant understanding how the coordinates, geometry, and imagery fit together. The answers I needed weren’t turning up in a convenient web search.
Today, I’m building Taproot with AI coding assistants. An agent can help investigate an unfamiliar system, propose an implementation, write tests, and review a change. That gives me a very different way to approach the work.
Between those two experiences are decades of building desktop applications, websites, mapping systems, software that controls physical machinery, and internal business applications. I’ve worked at every layer of software engineer, from front ends to application logic to databases, and the pipelines that get software into production.
That history informs how I use AI. It gives me somewhere to start when deciding what to ask, which assumptions to question, and how to check the result.
I earned a BS in Computer Information Systems at DeVry. The curriculum covered everything from BASIC to C++ to COBOL, with plenty in between. Moving among languages was part of learning to program from the beginning.
My first job was fixing Y2K bugs for a company that built hotel property management systems. I started in Delphi, working on software that already had a purpose and people depending on it.
Maintenance is a useful introduction to professional software development. Before changing something, you have to understand enough of the existing system to avoid breaking it. The code in front of you carries decisions made by people who had constraints you may not immediately see.
During my five years there, .NET arrived. My manager wanted to use it for the next version of our software, so I moved from Delphi into the new platform.
That was an early experience of something that would recur throughout my career: learning a technology while using it to solve a real business problem.
After that, I contracted at Microsoft on the team building Visual Studio, where I helped develop the WinForms auto-layout features.
Layout is one of those things people notice most when it goes wrong. Controls need to fit together and behave sensibly as their surroundings change. Working on those features put me on the implementation side of tools other developers would use to build their own applications.
My next role took me into web development at a company building event websites for Microsoft.
This was when jQuery was the cool kid in town and Internet Explorer 6 could consume what felt like 85% of the working day.
I became deeply familiar with HTML, CSS, and browser layout bugs. A page that looked right in one browser could fall apart in another. Getting it working required patience and a willingness to investigate behavior several layers below the feature I thought I was building.
That experience remains relevant when I work with generated code. An implementation can look reasonable but still behave badly where it actually runs. You have to exercise the result.
At a startup building mapping software for emergency preparedness and disaster planning, the work moved into a different kind of complexity.
The mapping application was written in WPF. It brought together elevation data, shapefiles, collision detection, road graphs, routing algorithms such as Dijkstra’s, and map projections.
Those subjects had to agree with one another. A route depends on how roads are represented and connected. A shape has to appear in the correct location. Elevation introduces another dimension to account for.
I personally implemented a Silverlight map viewer, including building the globe and importing and rendering mapping tiles. That was the project that sent me to the university library.
It’s a useful example of what full-stack work has meant across my career. Sometimes the next layer you need to understand is geometry.
AI gives me another way to approach unfamiliar material now. An assistant can explain an algorithm or help investigate an implementation. I still need to establish whether the explanation applies to the problem and whether the implementation behaves correctly.
Experience helps me recognize where that checking needs to happen. It also reminds me how much there is to learn.
Another role involved building software around an OPEX Mail Matrix machine to sort voting ballot envelopes. The machine had to scan envelopes, perform OCR, validate signatures, and direct envelopes into the appropriate bins for their voting districts.
Here, the output of the application included a physical envelope arriving in a physical place. The connection between a software decision and its result was quite tangible in the lab.
Later, I worked for several companies building internal web applications across the full stack. Those systems brought together the user experience, business rules, data, and processes for managing complex tasks. In my role, I was responsible for the whole process.
Over the years, I’ve built software in C#, JavaScript, TypeScript, and Go. My production web work has ranged from jQuery and Backbone through Angular, React, Aurelia, and Vue. For Taproot, I have built a zero-dependency design system, using Lit, from scratch.
I’ve also published sites using raw HTML, WordPress, Ghost, and Hugo. Those experiences give me several points of comparison when thinking about what a publishing platform should make easy.
On the data side, I’ve worked with SQL Server, MongoDB, and Postgres. I’ve built CI/CD pipelines with tools ranging from NAnt and Jenkins to Azure DevOps and GitHub Actions, with TeamCity and CircleCI along the way.
The value of that range becomes apparent at the boundaries. A slow screen may be waiting on a database query. A difficult deployment may reveal an assumption in the application. A framework that makes the first feature easy may complicate a later requirement.
Having worked on each side of those boundaries gives me depth when evaluating how to solve a problem. It also gives me alternatives to consider before committing to a particular approach.
Taproot is where I’m applying that cumulative experience to a new way of working.
We’re building a publishing platform while refining how we use AI throughout development. That includes defining work, investigating the existing code, implementing changes, reviewing them, and verifying the result.
I’ve already written about why we keep our backlog in Git. That decision helps us preserve the explanation of the work alongside the implementation. An assistant picking up a task needs the intended outcome, the constraints, and the decisions that came before it.
My experience helps me supply that context and evaluate what comes back.
If an agent proposes an abstraction, I can examine whether it earns its maintenance cost. If a change crosses the interface, API, and database, I can follow the contract through those layers. If the tests pass, I can still ask whether they exercise the behavior that matters.
There is also room for the assistant to challenge an approach I’m comfortable with. Having used many patterns for years, I am comfortable requesting suggestions from an AI assistant and evaluating recommendations through the lens of decades of experience.
I’m working out how to make this process more effective and efficient. Working fast is only helpful when it moves the project toward a dependable result.
For someone getting started, AI offers another way into work that can otherwise feel inaccessible. You can ask for an explanation, try an approach, and investigate what happened. I feel like I have learned more in the last six months working with AI than in the decade before.
There is a lot to learn in that process. Learning how to describe a problem, inspect a result, and recognize when you need help gives you a stronger foundation for the next project.
For a business owner, the same possibilities come with practical decisions: what to build first, which requirements matter, what can be kept simple, and how the software will be maintained after its initial release.
Those are the decisions I want to help with.
I bring 26 years of experience across the stack, along with an ongoing effort to understand how AI can improve the way I work. Taproot gives me a place to put those ideas into practice and share what holds up.
If you have a product or internal tool you want to build, I’d welcome a conversation about what it would take to make it useful, reliable, and maintainable.