a personal technology profile

This page originally dates from 2009 and was substantially updated in 2026. The history is still the history, but I have condensed some of the older detail.

Where it started

I have been interested in computers and technology for about as long as I have been able to get my hands on them, and for most of that time I have been unwilling to settle into one platform. My home setup in 2009 was a fair illustration. Windows, Mac, and Linux machines were all running at once, with the Linux boxes mostly doing server work, and I used a Mac laptop and a Windows laptop side by side depending on what I was doing that day. I was comfortable in both and did not think of it as a preference so much as a range.

I also invested in my own tools well past what was strictly reasonable. For years I kept a personal MSDN Universal subscription, and later an Apple Developer Connection membership alongside it. Both were expensive for something with no immediate return, and I would let one lapse for a year at a time before renewing. Having current tools at home made learning more enjoyable, and it occasionally changed what I could do at work, since a language or platform I already knew on my own time was much easier to argue for on a project.

Consulting made breadth a habit

Consulting is where the tendency turned into a working pattern. At Geneer I could ramp up on whatever a client project needed, which meant a lot of different technologies in a fairly short span. No project there was purely .NET, but I used what I had learned on my own to get some C# onto the DowAgro work, and some version of that happened repeatedly for years afterward. At Riverside Publishing I built a deployment tool that promoted configuration data across Oracle environments from development to QA to production, exporting a structured set of tables and importing them into another database while keeping the relationships intact across changing identity values. The FTD project was mostly C++ with some C# I managed to get my hands into. Baxter Credit Union was the first position that was purely .NET.

Consulting also meant working directly with clients, not just moving between technologies. On a project for the Board of Trade Clearing Corporation, I led the daily standup at the client site with both BOTCC and Geneer developers. On another Geneer project for AT&T, our team traveled from Illinois to New Jersey for meetings with the client.

My own web site was part of the same habit. Over the years it moved through plain HTML, PHP, Kohana, WordPress, and eventually Hugo, with other experiments around it along the way. Hosting cost was one reason I spent so much time with open-source tools, but the site also became a convenient place to learn them by actually using them.

For years I kept a large library of physical technical books. When I left Illinois in 2013, I got rid of most of them and shifted largely to digital publications. I still have those, though the rate at which I add new ones has slowed as more technical material has become available online. The format changed, but the way I learn did not: reading gives me the theory, and writing the code is what makes it stick. Some books still matter enough that I buy them in more than one format; Righting Software is one of those. Kohana was a good example of the writing part. Using it gave me a different exposure to MVC than I had from C++, and once I had it straight in my own head I enjoyed explaining it to other people.

The setup now

The hardware collection did not survive. I work primarily on a Mac laptop now, with Windows and Linux available in virtual machines when something needs them. In equipment terms that is consolidation, but the reason underneath it has not changed. I still want access to whatever environment the work calls for rather than arranging the work around one operating system. A VM is simply more convenient. Several environments can be available at once on the machine in front of me, which is easier than keeping a separate physical system for each one.

The habit of buying my own tools never really disappeared either. I still keep my own Apple developer account, which I need for work like Tip Pool, and my own Visual Studio Professional subscription. The largest share of that spending has shifted toward AI tooling, mostly Claude Max, along with ChatGPT, Gemini, Devin, and Cursor when a particular task warrants it. The names turn over faster than MSDN discs ever did. The reason has not changed, though. Learning something works much better for me with direct access to the thing being learned, and wanting to learn about different things is what most of these purchases have been for.

The generalist question, with hindsight

The 2009 version of this page said that a generalist background is both a blessing and a curse, and then spent several paragraphs on the curse. Most of that was about hiring. Breadth is awkward to present, a specialist is easier to match against a job description, and years in one named technology were the thing being counted. That is all still true and I no longer think it is worth arguing about at length.

What I did not see clearly then is that the breadth was mostly a consequence rather than a plan. New technology certainly interested me, but what tended to hold my attention longer was understanding how a system behaved, particularly when the system did not agree with itself. Consulting kept supplying unfamiliar systems, and the part I enjoyed most was learning how they worked. Sometimes that meant a new business domain. Sometimes it meant seeing a different way an implementation handled a problem I already knew. The breadth accumulated on its own. Specialization has real value and I am not making an argument against it. My pattern has just been the other one, and it turned out to suit work where nobody is quite sure yet what the problem actually is.

The tendency has a cost, though it is not quite the one I would have named in 2009. When I think the wrong commitment could force expensive rework later, I may spend more time on the design question up front to reduce that risk. That is a different thing from being slow once the plan is clear. A good deal of the implementation I do now is AI-assisted and can move very quickly. What I am less willing to rush is deciding what the implementation is supposed to preserve.

I am not opposed to tradeoffs or temporary compromises, and plenty of future change is simply unknowable in advance. What I resist is knowingly creating structural debt when the problem is already visible. If a choice is likely to make the system substantially harder to change, I would rather that be a conscious trade than something the implementation runs into later, after it has become expensive to undo.

I am also still easy-going about how things get done. There is usually more than one way to do it, and I would rather hear the other one before defending mine. I already know why I chose my approach; listening to someone else’s gives me a chance to learn something I did not already know.

I have also found the INTP description in MBTI a useful shorthand for some of these tendencies, particularly the drive to understand how things fit together and the willingness to stay with a problem until it makes sense. I do not treat a personality model as an explanation for everything I do, but in this case it describes enough of the pattern to be recognizable.

Architecture that has to survive implementation

Over time the questions I found interesting moved away from which language or tool to use and toward boundaries, responsibilities, failure, and what happens where two parts of a system meet. That is roughly what architecture means to me, and it did not come with losing interest in the building part. What I enjoy is the whole process of designing something and seeing it built, which does not require that I personally write every line of it. What it does require is that the design gets implemented in a way that preserves what it was for. Architecture is worth something when its consequences can be followed into implementation, and the spot where an abstraction meets the thing it was supposed to hide is usually where the interesting problems are. A design I cannot trace into working code is a guess I have not tested yet.

Some of that got sharpened by IDesign training. I took the Architecture Master Class in 2017 and again in 2024, followed by the Project Design Master Class after the second one. What stayed with me was less any single method than the habit of thinking in terms of responsibilities, boundaries, interactions, and what is most likely to change, and of settling those before letting implementation pick up speed. The second one was a refresher. By then it was being offered over Zoom, which made repeating it easier without the travel.

The habit of noticing contradictions shows up here also. When a system contradicts itself, it usually means something upstream was never actually decided, and the inconsistency is just the visible end of it.

Building the tool instead

The old page mentioned that I added some functionality to the IPCop firewall project because I wanted it and it did not exist, and that I wrote up how I thought MVC should work on a framework forum because people kept asking the same question. Both were small. The pattern was already there.

It has become a much larger part of how I work. aikit exists because I wanted the mechanical questions in a repository workflow, such as what changed since a session started and what belongs in a review bundle, answered by something deterministic instead of by memory. outpost exists because I needed to run work on a machine where the agent I was using could not run, and a shared directory turned out to be enough of a transport. Neither began as a product idea. Each began as a step I had done by hand often enough to want a better way. I value efficiency, especially when the same mechanical work keeps repeating.

Reeve is the current version of that: a local orchestration and governance tool for AI-assisted software development, and probably the clearest expression of how I want to work now. It stays on my own machine, so there is nothing public to link to. I keep the architectural and design decisions, the constraints and the gates that work has to pass through are written down explicitly instead of living in my head, and AI workers implement and review inside those boundaries at a speed I could not match by hand. It has also changed how I think about design risk. A gate can catch a conflict later in the process and force an earlier decision to be reopened, along with any downstream design decisions that followed from it. That is disruptive, but it is a good deal cheaper than finding the same problem after deployment. The point is not to have the models decide the architecture for me. It is to make execution faster without letting the design drift just because execution has become cheap.

Applied AI

A lot of what I have been building recently involves applied AI, which is less of a departure than it might sound. There is a lot of ambiguity in it, which I can sit with long enough to work out, and the satisfying part is getting it resolved or reduced far enough to make a sound decision. It also raises questions I would have found interesting in any system: who has authority to change what, how a claim gets verified, what evidence a decision rested on, and what a component should do when it cannot tell whether it is right. Multi-model review, provider integration, the boundary between what an agent decides and what the surrounding software decides, and defined behavior on failure are all versions of questions I was already asking about ordinary systems. The difference is a component in the middle that is fluent, useful, and occasionally wrong in a confident way.

Unsolve It is a good illustration of the other half of that. It is a Phoenix product that is not an AI product, and the only place a model touches it is moderation. Deciding how narrow that responsibility should be, what the system does when the model is uncertain, and what happens if every provider is unavailable was more interesting than anything the model itself does.

I still enjoy the theory. It just does not count for much with me until it has turned into software that behaves the way it claims to.

Still both

I am not sure blessing and curse is how I would put it now. The same trait produces different results depending on what a situation happens to reward, and I have seen enough of both to stop treating it as a verdict. What I can say is that the work I have enjoyed most leaves room to understand why the system should work the way it does, whether that means shaping the problem first or working through the details of a design that is already sound.