This essay is the second part of a two-part series on my journey in software development. This shorter, get-up-to-speed slice covers early 2019 to the end of 2024, except for the following paragraph, which occurred in 2017, shortly after I departed from my first engineering job. Should take be about a six minute read, vs nine for part one.

Continued from: Part 1

After and in between some restoring mountain and travel adventures, the rolling rock collected no moss. I picked up on attempting a minimal viable service addressing problems of configuration management and deployment that I saw in my professional experience. This effort interleaved with my parting efforts at the makerspace, so I used the early prototype to remotely deploy and configure new versions of the access control system. Ultimately, I was underqualified to enter the secrets management market. Something notable about this system is its one-to-one mapping with secrets to version control. Similar management techniques are possible today, but it takes multiple config locations and attention to mutability. The deployment philosophy was counter to typical practice in leaving continuous integration to the pull request process and automatically matching a deployment to a version control branch. This mapping meant that role-backs could also fix config errors, and team members would understand the state of associated deployments. Of course, this has some practical challenges. Still, it was better than what organizations could do without foreseeing the issues involved.

Things became exclusively mountainous as I pursued more athletically oriented goals in nature. I quickly felt the need for balance and schemed about what that might look like. In the meantime, I built a personal website. One that just happened to have a contact page that let visitors leave an email or take a video call with me. I used no third-party services other than a popular cloud provider to achieve this. Probably overkill. I have since taken the contact page down so as not to need to maintain it, but the learning was invaluable. Self-awareness crept in around my dismissive attitude towards trendy web technologies. Instead of potentially making the sentiment a swan song, I got curious. Sorting the interesting bits from the hype dove into type safety, componentization, and reactivity. I knew type safety was helpful from my strict static typing origins. Still, I enjoyed the freedom from thinking about types. At my experience level, I learned that the advantage of carefree typing was trivial compared to the advantages of catching interface mismatches on the spot. Getting more exposed to trendy front-end tooling generalized the idea in my mind. I can now pick up and use whichever one a project requires.

As hiking adventures cooled down, the search for balance became an ironically full-time endeavor when I decided to take on a new venture. After some soul-searching, I established stricter requirements. I needed to create a product I could use daily as soon as possible. Most of my projects thus far have touched on an issue I had first-hand experience with. Still, none of the solutions were immediately executable or regularly used enough to solve the problems meaningfully. So, I started where most web devs begin at the beginning of their careers. Six years in, I finally built a to-do list! I chuckled to myself while thinking about the more significant problem. Knowing it was just the first step in getting it out the door. Before the app I was about to build, I used a combination of three productivity applications instead—all to carry out what I retrospectively see as my homegrown discipline. Something I later learned has a more specific audience. At the time, I pinned the market as “ambitious entrepreneurs” and rooted the problem target in estimating time. I hypothesized that knowing how much time you spent based on objective measurements relative to your subjective estimations would yield a velocity number, which you could use to adjust future estimations to reality. This concept is less my hypothesis and more something I got from a book about a popular development process. The difference was in building a calculator that did it automatically for individuals instead of a team. One problem: It can be in a book and be wrong. It wasn’t hard to codify the equation and start testing. I was already in the habit of constantly recording my time performance on tasks. I was actively working on an ambitious project. I immediately generated test data as soon as it was ready. Just as fast, I found how useless this was, specifically when consistently faced with unknown unknowns. Garbage in, garbage out if predicting how deep the rabbit hole goes is a shot in the dark. Projecting velocity is not helpful for professional rabbit hole divers. In retrospect, it seems obvious. That failed test brought me back to the drawing board. I took inspiration from another software tool I used to budget money. I saw its effect in empowering me to direct my finances instead of vice-versa. I figured I could enable the same thing with time. I’ll make a long story short and say that it didn’t work either, but because I was making the app more useable all along the way, it replaced my three prior tools.

Eventually, I needed to step away from the project to fulfill my wife and I’s ambition of building a more suitable camper to make a last trip as a family of two before we started a family. Suitability before was another naive premise. I had written about 21k lines of code in a year at the project’s end. Going off my problem-first script, I made some solutions based on personal interest, such as building privacy features in the app like peer-to-peer sync, end-to-end encryption, and metadata privacy. I even rolled my own misguided conflict-free data replication implementation for the p2p sync before understanding that it was an intense field of academic study.

After spending a few months building a slide-in camper for our truck and taking it for its shake-down trip, I took a software engineering position with a DevOps focus. There, I worked on automating disaster recovery and improving integration run times to make development faster. Partway through, generative chat blew up on the scene. Amidst discussing replacing devs and inaccuracy, I saw something uniquely suited to accelerate my ability. Less concerned about the hype topics, I started using it to generate research start-off points, the exact documentation I was looking for, translate concepts from familiar programming languages to unfamiliar ones and create one-off scripts that aren’t worth my time and have no consequence.

Becoming a father put the 2-hour commute and long hours into perspective. An opportunity found me where I could work part-time and revisit my prior ambition of creating a makerspace. About three years had passed since my involvement in the other space. I thought it would be a perfect fit, and so did they. I made my motivations clear and talked to every board member beforehand. No one had deceptive intentions. Still, there were misconceptions about how I wanted to approach fostering a center of learning. My timeline and focus for what I had in mind was too aggressive for the org, regardless of any promises about intention alignment. With inflation and changing budgets, I also unwittingly walked into taking the job at a loss after expenses with no room for hours or pay adjustment. At that time, the loss was eating into a down payment we were saving for a house. I had to cut this opportunity short.

With the promise of a house nowhere in sight and lingering travel ambitions, I refitted the camper to suit a baby. We left life’s things all behind in a storage unit with a tentative return date. Five months after leaving, we returned. I never had a scarier job in my life. The wife and kid loved it.

I missed working on my time management app. Other than a few minor fixes and a feature, I had last worked on it three years prior at this point in the story. I was still using it day to day. That was a great success, and because of my daily familiarity, I was very keen on a new direction I wanted to go. With 21k lines, it was tough to know where to start. If you’re going to improve something, I heard you might begin by removing all the unnecessary components by at least 10% more than you’re comfortable with. After doing that calculation in my head, I figured I’d have so little app left that it wouldn’t be worth the effort of the refactor. The effort wasn’t going to be a rebuild for another framework. It was a variant of the original with a new premise. I realized I was using the app for time awareness through consistent use. Building exactly to that use case bore the potential promise that someone would understand it other than me. Plus, it would alleviate me from all the papercuts of a sprawling interface, dead or unwanted concepts, and lack of key features like offline availability.

In four months, with some generative assistance and my experience, I wrote 12k lines of code, which is now my daily driver. Retrospectively, rebuilding was the only way because almost nothing was the same except key concepts, time constants/conversions, and general database access patterns. Ultimately, I carried over only a single-digit percent of the original code. There are still papercuts to address, and educational content should accompany it. Still, given the resources, I could push this to the market.

Alas, resources are always tight, so I’m typing this long-winded two-part story of my programming journey breadcrumbs from there to here. I appreciate your interest if you’ve gotten this far. I write all this in hopes of finding a team with whom to share the success of my efforts. In review, I’m reflecting on my maladaptive patterns and positive trends. Soon, I’ll be able to produce polished, ready-for-market software in short order under my effort. I can’t deny aspiring to that ability level, but it won’t be alone.