Iain Davis

I set out last week to begin the work of creating an automated release process for Docodylus. At first, I thought I'd end up with something similar to what's used at Intuit, which isn't a defined standard or anything, but does tend to come as sort of variations on a theme. My goal was more or less to decide how to learn how to implement an existing process, and adjust it for the needs of my project. That remains true, but the needs of my project seem to be best served by a strategy of abandoning git hooks, almost entirely.

Trying Out Estimate Variance Reflection​

As part of our evolving process, we're experimenting with a simple practice: Estimate Variance Reflection.

What We're Exploring​

Estimations are hard, and that's okay. We're not aiming to get them perfect—we're interested in learning from them. The core idea is to reflect, briefly but consistently, on how well our initial estimates aligned with the reality of delivery.

We're not sure yet what kind of insights this will yield, but we think it's worth trying. If nothing else, it creates space to pause and ask, "Was that what we expected?" And sometimes, the answer is the most valuable part.

How We’ll Use It​

Reflections are captured directly on Jira tickets. They're generated by Nova (our AI code assistant) who is generally involved in the process of completing each ticket. Once in place, these become a pool of data we can analyze over time.

We're particularly interested in using AI to extract insights:

• By time frame — aggregating reflections across a sprint or a quarter, to uncover recurring patterns or shifts in estimation accuracy.
• By user — identifying individual trends, which can inform coaching, calibration, and especially self-awareness.

This may evolve into something automated or visualized down the road. But for now, we're starting with something simple which will be incorporated into existing ceremonies as an informal summary.

Maybe this practice sticks. Maybe it doesn’t. But for now, we're giving it space to prove itself.

📌 First example: IDDEV-2

📘 Captured in our ADR repo: Estimate Reflection Format

I've been pretty lax about working in a structured and organized way in my personal projects. Some of that has to do with life just kind of being a bummer lately. Unemployment is hard. But it also has to do with I just got into some sections of work that felt very unstructured and exploratory. I knew roughly where I wanted to get to, but I didn't know how to get there until I did a lot of learning and made a bunch of mistakes. Now, arguably, that's exactly the kind of stuff I should have been documenting. But doing it took a lot of my time and energy. Today, we're where we are, and there's no use pretending we're somewhere else.

It's been a long while. I haven't been posting, and virtually nothing has changed here at IainDavis.dev. But I haven't been idle either. Since I last was regularly updating, I made several decisions that have taken a good long while to carry out, and I abandoned some structure and communication while I was doing it. In retrospect, it was maybe unwise, but at the time it felt like quite enough to be dealing with all the things I was dealing with and also be doing the learning I needed to do to implement the changes I wanted.

Brief update to indicate some of the work I've done here in the last few days:

It's been a while since I posted here!

Actually, I posted here about a week ago about some of the things I was working on with Nova, but I wrote it in a bit of a rush, and I hated that blog post. It was disorganized and the content didn't really relate to the title at all, so I deleted it.

Since then, this week and a goodly chunk of last week have been all about producing content for this here website.

Streamlining the Deployment Pipeline​

Today, we took a major step toward automating the deployment of this site, eliminating manual steps and reducing the risk of errors.

Now, every pull request (PR) generates a preview build, and every merge to the main branch automatically triggers a production deployment. This new setup speeds up the process, ensures consistency, and minimizes the chances of mistakes.

Today, we focused on streamlining our automated preview deployment process for PRs, ensuring that each pull request includes a live preview of the Docusaurus site, Storybook components, and test reports.

The Challenge​

The main goal was to automate the deployment of a fully functional preview for every PR, complete with Docusaurus builds, Storybook, and test results. This meant dealing with dynamic URLs, managing build artifacts, and ensuring everything worked in harmony.

Why This Matters​

Automating the preview process means changes to the site are instantly available for review, speeding up development and reducing the chance of bugs. This allows us to deliver updates faster while keeping quality high.

It's been a few days since I posted. That's not because I haven't been busy, it's because setting up unit testing turned out to be much harder than I anticipated.

To be fair, I was trying to achieve a somewhat complex setup.