Tech junkie that thrives under pressure.

My LinkedIn profile still says it, verbatim, as of July 2026: "Tech junkie that thrives under pressure." It is a little awkward. That is probably why I still like it.

It says the thing faster than a cleaned-up bio would. I like strange tools. I like taking things apart. I also tend to be the person people contact when a problem crosses too many boundaries to fit neatly in one job description.

The request might be about an Archibus environment, a workspace that needs a better support path, an editor integration, an identity problem, an AI feature, or a release that needs to stop depending on one person's shell history. The technologies change. The work usually comes down to the same question: can I turn what I learn into something the next person can run, inspect, and repair?

The oldest local pieces I can still find are from 2024. I do not trust every file date because I moved the work between development environments several times. The order is still obvious enough. The first pieces are scripts and small experiments around work that was easy to get wrong by hand. They made me faster. They did not unload anything.

Me

The first serious Archibus research environment began as a hosting question. I needed to know whether the application, database, identity layer, ingress, certificates, and backups could live together in Kubernetes. This was early research, so I worked through most of it directly: Bash scripts, Helm commands, manually applied manifests, and a lot of log reading.

That was the right way to learn it. When I had to create the certificate, apply the manifest, follow the login redirect, and repair the deployment myself, the dependencies stopped being boxes in a diagram. I learned which step needed the previous step and how each layer failed when an assumption was wrong.

The first deployment loop was a script: build the image, tag it, push it, change the chart value, run the upgrade, and check the result. It was faster than typing each command from memory. It was still a personal interface. If the script stopped halfway through, I knew what it had done because I had written it. That did not mean the team did.

That was the pattern for a while. Learn the failure, write a helper, remember what the helper did, and become the person who could explain it when it stopped. I was automating the work while keeping most of the responsibility.

A script can repeat my steps. It does not automatically make the process belong to the team.

Too many doors

There was no clean jump from shell scripts to the current platform. I still have a folder called authentikhelm. It is basically a junk drawer for the middle. It has early identity work, Kubernetes manifests, chat prototypes, workspace templates, small tools, and abandoned paths sitting next to things that eventually shipped.

The ism-dev.us domain came out of that phase. I needed real addresses for identity, dashboards, APIs, application environments, Git, chat, and later workspaces. Giving each experiment a stable address made it easier to use and share. It also gave me a hallway full of doors.

I tried an Archibus command-line tool that could generate, list, push, and delete Coder templates. I also tried a desktop-shaped React interface with a Go backend. That version mostly knew how to provision Docker containers. There were terminal chat tools, Streamlit screens, editor experiments, and several attempts at giving the model enough Archibus context to be useful.

None of those became the final interface. They did tell me what the interface needed. The CLI named the operations. The builder exposed the choices around source code, runtime, databases, backups, and editor setup. By spring 2025, those choices were becoming reusable development environments instead of a pile of setup commands.

We started using the infant platform as an internal testbed on several projects in September 2025. We did not wait for it to look finished. Real project work gave it the version mismatches, odd repositories, database restores, interrupted assignments, and support questions that a clean demo would miss.

The early Console grew out of that use. At first it was closer to a template builder. As the platform picked up more services and more users, it needed one place to create a workspace, find an existing one, manage a backup, see what failed, and continue. The domain gave every experiment a door. The Console became the front desk.

Here, take this ArgoCD

I was still holding too much state, so I started handing it away. Here, ArgoCD, you keep the application pointed at what Git says should exist. Kustomize and ApplicationSets gave the environments a repeatable shape. Branches mapped to deployment lanes. Database restore, migrations, identity, and application startup became ordered parts of the same system instead of notes spread across terminals.

The difference was practical. A teammate could read the repository and see what should exist. The controller could report whether the running environment matched it. A review could show what would change before the cluster changed. Recovery had a source to return to.

GitOps did not remove the hard parts. It made ownership visible. Later environments moved from ArgoCD to Flux, but the important change was not the controller name. It was the discipline around desired state, ordering, review, recovery, and proving what actually reached the running system.

One change in that period captures the direction. The pipeline stopped restarting the workload itself and started asking the deployment controller to reconcile the declared state. It was not a perfectly pure GitOps system yet. It was a useful handoff: CI asked for convergence, and the controller owned how the environment got there.

Delivery

The first pipelines mostly automated commands I already knew how to run. Build the image. Run a check. Submit a deployment. That helped, but the early pipeline history is full of the kind of work every delivery system needs: fixing branch assumptions, improving failure output, keeping jobs inside their intended scope, handling database setup, and proving that a deployment finished instead of assuming it did.

Over time that turned into a release path with a contract. Validate the source. Build an immutable artifact. Update the Git-owned release reference. Let the controller reconcile it. Check the running deployment. Exercise the narrow product behavior that changed. Each step leaves evidence for the next one.

Shared CI came after that. The checks stopped belonging to one product repository and became a versioned contract that downstream repositories could include. The shared path could create or attach to a workspace, run validation near the application, focus review on changed files, and return evidence to the merge request. Repositories kept a thin entry point instead of copying the operating logic.

The release side followed the same direction. A dry-run-first helper could identify the affected images, limit GitOps edits to known files, reconcile Flux, and verify the rollout. It kept two claims separate: the desired state changed, and the running product was checked. The Console added another layer by making workspace and review state visible without requiring someone to watch a terminal.

Training

In June 2026, I led an internal training session for the development team. I did not start with the architecture. I started with day one: pick a repository and branch, pick the runtime and a known database baseline, create a workspace, and get to work. The point was to stop setup from being tribal knowledge.

The questions were practical. What survives when a workspace is deleted? Can developers use their preferred editor? What happens if someone tries to push from the wrong branch? Can the system reset a database, reapply the checked-in changes, and test from a clean baseline? Can a team put its own review rules into CI instead of asking everyone to remember them?

I answered from the system in front of us. A part of the live demo failed to open. I used the error as the next input, explained the likely cause, and kept moving. Another control was not ready for everyone yet, so I said so and added it to the work. The session was training, but it was also a fairly honest product review.

The useful proof came from the other developers. They described using separate workspaces for separate assignments, saving team rules in the repository, resetting test data from source, and handing a running environment to someone else for review. The planned hour ran long because the questions kept coming.

It was not finished. I said that too. But I was no longer explaining how I personally set up a machine. I was teaching a shared way to start work, preserve it, check it, and hand it to the next person.

Meanwhile

This progression happened while the rest of the work kept moving. Managed workspaces and the Console were one stream. ArchibotChat was another. Editor tooling and Archibot View Studio kept moving too. Deployment, recovery, onboarding, and documentation did not wait for any of those projects to finish.

Moving more development into agentic workflows increased how much I could take on. It also made discipline more important. Five fast work streams can become five piles of private context just as easily as one manually operated cluster can. Isolated work, narrow tasks, explicit checks, handoff notes, and a final verification pass are what keep the speed useful.

The best productivity improvement was not one tool. It was reducing how often the next task had to begin by reconstructing the last one. A repeated support question became a diagnostic. A repeated deployment became a release path. A repeated setup became a template. A repeated review became a gate with evidence attached.

Pressure

I do not think of pressure as chaos. Most mistakes are ordinary. Most fixes are too. The pressure comes from taking in work from several directions, deciding what matters now, and keeping enough structure around it that progress on one project does not erase the state of another.

That old LinkedIn line still fits. Not because I want every problem to become an emergency. It fits because my default response to a recurring problem is to learn it by hand, fix the immediate issue, and then make the next version less dependent on the person who already knows the ritual.