My subquery work has been another one of the things that seemed straightforward, but turned out to be more involved. I’m nearing completion of it, and while I could talk about its particulars, it probably wouldn’t be the most riveting, as most of it at this point is plumbing.

Instead, this post will focus on my perspectives and learnings about European alternatives to US tech, and some key systemic differences that lead to what is available and how they are evaluated.

Jenn and I have lived in the EU (Portugal) for just over four years now. Prior to that, we were active in the US tech sector for a huge part of the internet revolution as both workers and consumers.

We’ve both seen behind the scenes at big household-name companies as well as scrappy small shops, primarily in Seattle and San Francisco. I also held several roles that had me exposed to how tech was built across the Continental US: both coasts, the Midwest and the South. It also exposed me to how software was built in different industries, such as manufacturing, logistics, insurance, and finance.

While there were regional and domain based differences, ultimately it was very similar and fit into the overarching American culture.

My exposure to European tech has been nowhere near as deep, and mostly from a consumer perspective, but there are clear differences that have profound implications, and knock-on effects.

Privacy and Consent

Anyone who has done tech business in the EU has heard of and likely cursed GDPR. Going to most websites from anywhere in Europe will immediately ask you about cookies and what you want the site to know about your activity.

You also have the right to control what they do with that information.

There’s a whole lot more to those laws (and the EU AI act) that would be far more than would make for interesting reading, but the intent is all about giving the consumer the control over their online presence and data.

This is fundamentally different from how US tech operates.

That said, if a US company wishes to do business with anyone in Europe (even visiting, as in, on vacation), they have to conform to both acts, but if the user is purely inside the US they don’t. This leads to some interesting implications, particularly in the realm of UX and Product Management.

Both the disciplines of UX and modern Product Management, as defined by some of the leading product-led companies in the world, are completely based on gaining a clear understanding of user behavior.

Being observed changes your behavior

There’s a psychological phenomenon known as the “Hawthorne Effect” or the “Observer Effect” that comes into play here.

From 1924 to 1932 researchers were looking into how alterations in the workplace (e.g., lighting levels, breaks, shift length) would impact productivity at the Western Electric Hawthorne Works plant. They found that productivity would increase no matter what the change was. This even occurred when the change was something that would be generally detrimental to the work, such as setting the lighting levels very dim.

The conclusion was that the real reason for the change of productivity was because the workers knew their productivity was being observed and evaluated.

As with all biases, the worker was not necessarily aware of their own behavior change, but it was distinct and measurable.

Life in the petri dish

In order to get the best real read of user behavior, UXers and modern Product people in the US are constantly running experiments and evaluations of user behavior without the user’s consent or knowledge. This has become so sophisticated, often these teams will probably know better than you whether or not you are likely to click on a given button.

Their sophistication has led to speculation about whether or not various devices are listening in without our knowledge. The reality is, the kind of eavesdropping by big tech that people tend to suspect would be unreasonably processing intensive. It’s far easier and more economic to measure and predict user behavior (and the behavior of those the user interacts with) on various interlinked systems.

This is how you end up having a conversation with a friend about something like macrame over coffee, and next time you’re online you start seeing ads for macrame supplies, despite having never searched for it.

It’s not your devices listening in. Instead it’s evaluations of you and your friend’s unconscious behavior when presented with anything about macrame. Often this is based on things that those in your broader circle happened to search for. The interests of people within your circle was likely what led to the topic coming up in the first place, so it increases the chance you would be interested in the topic.

Your recent exposure to a given topic, through various sources, will cause a slight measurable difference in behavior than something that has not.

This is also a key part of the intense information bubbles forming, but that’s a topic for another post.

How right to privacy impacts this

Full transparency, this is more my musings and observations than anything deeply researched.

Testing this would require a lot more time and effort than I’m able to expend at this point, but there are some absolute differences between UX and Product design and support in the US and EU.

US tech tends to have a better baseline UX experience than corresponding EU tech. Both Jenn and I have been exploring EU based alternatives, and have consistently found them harder to use and less intuitive than their US counterparts.

EU tech is every bit as stable as US counterparts, or even more so. If you can get past the often clunky UX, EU tech is absolutely solid. The foundation is well built, and tends to get the most focus. The problem is the UX and support is sometimes so frustrating that it limits the abilities to deliver their value.

While some of this could be ecosystem related, after all IDEO the birthplace of Design Thinking, is in the San Francisco bay area. I think some of this is strongly influenced by the privacy laws here, as well as the overall societal underpinnings.

Looks Good vs Well Built

This is a very deep topic, and one that is sure to get some folks riled, but it seems to be one of the core cultural underpinning of the difference between US and EU tech: do we value more something that looks good, or something that is solidly built?

Let’s start by reviewing Conway’s law:

“[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.”

— Melvin E. Conway

Different perspectives, different outcomes

Let’s peel back the layers to the European colonization of the Americas. For the purposes of this evaluation, I’m only focused on European immigration. Due to many factors, some quite unpleasant, European immigrants had an outsized impact on American business society that still echoes to this day. While other groups, such as the original people in the Americas, people from other parts of the world, and those who the Europeans moved without their consent, had huge impacts on business society, much of that was applied atop the existing established system.

This analysis is also based on broad generalizations and personal observations from my perspective of being an armchair history buff and systems thinker. As always, individual variances significantly outweigh generalized group behavior.

The American perspective

Consider those who immigrated from Europe vs those who stayed. For the most part the people who moved to the Americas were people who, for whatever reason, didn’t fit in European society of the time. They came to a new society where they had to do whatever they could to survive using their wits and their ingenuity.

Pragmatism in relationships and business deals would be more important than deep loyalties. This would lead to a very fluid and fast way of doing business, where you needed to rapidly determine who you were willing to trust or not.

It was also fertile ground for those who wished to take advantage of others. In order to rein some of this in, the court systems became more and more important.

The Engineering of Desire

In the early 1900s a man by the name of Edward Bernays, who happened to be Sigmund Freud’s nephew, had a powerful realization and introduced what he called “the engineering of consent.” His realization was that using facts to appeal to people’s rationale was nowhere near as effective as appealing to their emotions and unconscious desires.

This became the foundation of both Public Relations and Marketing in general. A form of weaponized psychology designed to drive consumer behavior.

This was so effective that even today if you ask the average American about when is the right time to eat steak and eggs or an omelet, they will overwhelmingly say “Breakfast, of course!” In Europe omelets are great for any meal, and here in Portugal a common dinner or lunch is a steak with a fried egg on top (it’s really good).

This perspective was due to his very successful campaign of “An American Breakfast”. Also of note, that’s where the fixation on bacon and orange juice came from too, the same campaign increasing the sales of pork and oranges.

This mix of psychological manipulation and rapid-fire deal making, combined by rampant competition driven by the need to survive, led to the US being amazingly innovative, but absolutely cutthroat.

Style above substance

Systems built in the US need to quickly establish trust and comfort. It’s less important that they actually work or do what they say they do, as long as they do enough to not get hammered by lawsuits. This has led to those able to navigate the labyrinth of law being highly valued, while also often despised.

It has also led to a society easily deceived by people who have gotten very skilled at it.

I also posit: the US is more susceptible than perhaps any other society to the wholesale adoption of AI because as long as it looks good, it’s generally readily accepted.

Recent times have shown a shift to a more skeptical baseline, but it will be a while before it penetrates all parts of society.

American societal perspective summarized

If I were to boil the American perspective down to a few points, they would be:

• Quantity of money is the only way to achieve quality of life

• Personal competitive advantage, often through corporate interests, is more important than societal good

• Appearing polished and professional is more important than foundational quality

• Business dealmaking moves very fast and considerable effort is made to streamline it

The European perspective, through the eyes of an American Expat

Things in Europe are quite a bit different. I would not say better or worse…just different.

To be clear, every country in Europe has very distinct cultures, and even within those countries (including the very small ones) there are subdivisions. Some of these cultural differences are massive so some of what I’ve observed will apply more or less to different parts of European society.

Patronage, Reputation, and Institutional Trust

For an exceptionally long time in Europe the way to get ahead was to build trusting relationships with those in positions of power and influence. I’m not talking about liking at all, I’m talking about currying favor and building reputation. Their trust would lead to opportunities opening up for you, the lack of it would lead to destitution and ruin.

Unless you happened to be born into a position of massive privilege, you would need to look for patrons to sponsor you and provide for your needs. Even many of those with that massive privilege would often need to do so as well.

To find a patron who would have been willing to provide for you often required a great deal of time and energy. The patron would be extremely careful about who they would support as they would be making a massive commitment which would be closely tied to their own reputation and prospects. In order to foster that relationship, it would need to be built over time with many different indicators showing that you were worthy of their trust and support.

Societal Palimpsest

Architectural Palimpsest, which is common in some parts of Europe, is the practice of building a new structure on top of an existing one, leading to modern buildings with Roman foundations and different floors from different eras.

The same sort of factor can be seen in societal patterns.

As Europe moved into the modern era, and the old order shifted, many of these systems took on different forms, but were all built on top of this strong impulse of relationship building. This had some catastrophic consequences from the late 1700s to the mid 1900s which left their marks, but it is still a strong underpinning of society today.

Generalized European societal perspective summarized

The general theme I’ve picked up, which is very different from the US can be boiled down to a few key perspectives:

• A stable society is a higher priority than personal independence

• Personal privacy and consent is more important than corporate interests

• A fulfilling and enjoyable life is more important than quantity of money

• A solid technical foundation is more important than polish or ease of use

So what do we do with this?

Honestly, I don’t entirely know. I tend to find myself aligning more with European values, but I, of course, have a huge number of US-based biases. I think there are benefits from both perspectives, as well as inherent risks.

As a social introvert, the amount of time and energy it takes to forge connections here is not something that comes naturally to me. We have likely missed opportunities because of not prioritizing that as much as would fit this culture.

As much as I find the constant cookie warnings a bit annoying, and GDPR compliance means a ton of work I wouldn’t have to do if building a US-only app, I’m ultimately glad to be protected by it, and that work has led to a more solid and thought out application.

I’d encourage people to check out European alternatives in technology. There’s a lot of them and if you care about sustainability, solid tech and control of your information, they are often a better option than their US counterparts.

You will find, however, that their UX is nowhere near as slick for the most part… but that’s continually improving as much as it can in an environment where all their learnings will be impacted by the Hawthorne Effect.

The last two weeks have been focused on getting the subquery search stuff buttoned up. This has been a bigger effort than anticipated, and I knew going in it was not going to be simple. As frequently happens, most of the challenge was re-familiarizing myself with code I wrote almost a year ago. That said, I eventually had the ah-ha moments I needed for me to figure out where the tweaks needed to be, and things started working… almost. Turns out there was a significant wrinkle.

The Cartesian Trap & Full-Loop Traversals

In my post Last Week in Review Jan 26, 2026 I discussed using Call chains to avoid a massive cartesian result. These are essentially another query that is launched from the results of a higher order query. So using our examples of the Pollinators, Predators and Flowers as shown here:

We could write a query chain that looks like this:

1. Find a Flower

2. From that Flower, find all the Pollinators that Pollinate that flower

3. From those Pollinators, find all Predators that Eat them

4. From those Predators, only return the ones that Hide In that particular flower

This gives us information about the specific interactions between these two animals and a particular flower. This means if you had a pollinator that pollinates both orchids and roses, and one predator that only hides in orchids, and another that only hides in roses, you could limit your result set to the exact flower you wish to examine.

Importantly, it would only return the pollinators which were part of this relationship dynamic.

It works cleanly and quickly and is super useful immediately for a whole range of applications.

The problem comes in when you interrupt the full loop traversal. If the fourth query of the set doesn’t occur, the results aren’t limited by the flower being examined. So if we filtered by the predator eats the pollinator our workflow would look like this instead:

1. Find a Flower

2. From that Flower, find all the Pollinators that Pollinate that flower

3. From those Pollinators, find all Predators that Eat them more than 5 times a day

4. From those Predators, only return the ones that Hide In that particular flower

The query would return all the pollinators that pollinate the flower whether or not they are eaten at the defined rate by the predators that hide in that flower. In fact, it would also return pollinators who were not eaten by predators at all.

The Data Leakage Risk

While in this example the results may be messy, ultimately they are benign. It would be a lot less benign in other domains. Personal information related domains are of particular risk. If this broken traversal were not handled, there was a very real risk that one user would see another user’s information by accident.

This was something that was critical to fix.

It took me a few fits and starts to finally land on the right solution, but when I did, it fit into place nicely.

The Solution: The Empty Set Rule

In short the rule is: If the query chain loops back on itself, then an empty result set is passed all the way back up the chain.

To make that clearer (hopefully), though with a minor tweak:

1. Find flowers in the system (let’s say there’s a rose, and an orchid)

2. From those flowers, find all the Pollinators that Pollinate each flower

3. From those Pollinators, find all Predators that Eat them more than 5 times a day

4. From those Predators, only return the ones that Hide In the flower the chain started with

Let’s say the orchid has a predator that hides in it that eats a pollinator more than 5 times a day, and a rose does not.

The orchid would traverse the entire chain and give us our result as expected.

The rose would get to step 3, and find no results. That empty set of results would be handed up the chain to step 2. Rather than returning what it had matched of all the rose pollinators, it would set the result to an empty set.

In the end, we would see an orchid with the particular relationship interaction we were looking for, and a rose without that particular relationship interaction. In other words, exactly what our subquery was looking for, without pollution from other parts of the chain.

I was stoked! It was a simple and elegant solution and it cleanly handled my issue with a clear and describable rule.

I ran my scenarios (which revealed the problem in the first place), and saw that indeed the data was not returning that pollution. In fact, in the polluted case, it wasn’t returning anything at all.

While this was better than the pollution, as it wasn’t oversharing information, it was still a problem for consumers who would have to determine whether or not the value happened to show up. The better result would be returning the empty set, which for some reason was being trimmed off.

Finding the Real Culprit in the Normalizer

As it turned out, while I initially thought the problem might have been the database, my normalizer - the system that takes data from the database and turns it into something javascript is happy to work with - was actually actively stripping empty result sets for some reason.

It took me a while to remember why I made that choice, and when I did, I realized there was a much cleaner and more accurate approach. By Thursday evening, I finally had something doing exactly what I wanted in a simpler way.

The IDE Shakeup & Moving to EU Sovereignty

Part of the reason this work took longer than anticipated was a major development when it comes to the IDE (Integrated Development Environment) I worked with. I had been using Cursor for some time, which if you’re not familiar with it, is an AI integrated IDE built on top of Visual Studio Code (a Microsoft open source offering). It’s a pretty decent product all in all, and while there were various annoyances I was largely a happy customer.

Jenn and I had determined that we wanted to move to a more and more EU Sovereign footing, and have been working our way off of US tech (far easier said than done), so I knew I’d be transitioning off of Cursor in the future, and had some plans brewing about doing that after some product milestones were completed.

Compounding that, a few months ago, the announcement was made that SpaceX was to acquire Cursor’s parent company. This reinforced my decision to find alternatives as I want nothing to do with companies in that particular lineage, but as acquisitions take time, it still wasn’t enough to make me prioritize it.

That timeline got accelerated dramatically by some of the choices Cursor’s team and/or parent company made.

The Grok Switch & Breaking Trust

Cursor provides the ability to choose the AI models that drive the system for their Agents and sub Agents. This allows you to pick and choose which models you wish to use, and which you don’t want impacting your code. They, of course, have their own, and make suggestions, but you’re not forced to do that. Most of the time you don’t really think about them after initial setup if at all.

One day, I logged in and there was a notification that Cursor had a new model they were excited to rollout based on Grok. I dismissed the notification, thinking there’s no way I would use it. I want nothing to do with that platform. I find it highly problematic and in many ways a misinformation platform (e.g, Grok sexual deepfake scandal, Grok, Elon Musk’s AI chatbot on X, posts antisemitic comments, later deleted, Why does the AI-powered chatbot Grok post false, offensive things on X?).

Some time later, for some reason I honestly can’t recall, I was checking my models and I was appalled to find that my primary model for both my agents and subagents were set to this Grok-based model. I reset them to models I vastly preferred.

I proceeded to vent my frustrations to Gemini, which helpfully let me know that Cursor was partnered with Grok/xAI and was sending training data over to them based on my interactions (source: What Is Grok 4.5? xAI and Cursor’s First Jointly Trained Coding Model).

This is absolutely not something I would consent to, at least with that model. I believe I had privacy mode turned on with my system, so if they honored that then my data should not have been used in that set, but even still my trust was broken with them.

I hold nothing against the team at Cursor, and I truly wish things had gone differently, but it didn’t feel to me to be a company I wished to continue to support based on those moves.

Exercising GDPR Article 17

I live in a country protected by GDPR (Portugal), so I triggered an Article 17 deletion request. For those of you not familiar with GDPR, triggering this gives the company 30 days to remove the vast majority of information about me from their systems, and send a record of that removal, and this includes any other organizations they shared that information with. It was something that was frustrating to build for, but now that I needed it, I was happy to have that option.

Failure to comply triggers massive fines from the EU. The EU AI act puts more intense teeth into the whole situation.

This is absolutely something any company doing business in the EU should have top of mind, as it applies to you if any of your customers are EU based (citizen or not). In fact, it comes into effect if your customers are just vacationing in the EU.

Do not think you can get around it unless you are absolutely certain none of your customers will ever set foot in the EU. These laws are not to be trifled with.

Life After Cursor: VSCodium, Continue, and Local AI

So, now that I’ve moved off of Cursor, I’m more aware than ever of their value proposition.

I’m now using VSCodium, another VS Code/based offering, but this one strips out all of Microsoft’s telemetry data harvesting. With that, there’s an open source plugin called Continue that allows you to integrate AI models into your system. I’ve actually loaded a few locally, and well… I suppose you get what you pay for. They’re slower (running on my laptop) and much dumber than I’m used to using, but I don’t have to pay per request. I probably will go to a paid model again to get closer to Cursor’s functionality. Right now I’m thinking of checking out Mistral’s offering: Devstral.

A key benefit of this setup is that I have complete control. The downside is that, with that complete control comes a lot of quirkiness and configuration pain.

The price of principles

I guess the point of this ramble really is, be sure to check on how your providers are using your data. Be aware of your rights (in the US you don’t have as many in this area), and exercise them where appropriate. Don’t assume that your providers have your best interests or values at heart. They don’t. At best theirs are aligned with yours at the moment, but that can change rapidly and in all likelihood their values are being driven by someone up their investor chain.

Taking a principled stand can absolutely take a lot more time, effort, and frustration but ultimately it makes it more likely that you are having the impact in the world that YOU wish to.

No room for breathing, no natural qualities, looks great from far away but the moment the weather isn’t perfect, it’s usability goes to zero. It’s uncomfortable, one drop of sweat and you turn into a walking furnace. A drop in temperature and you are weirdly colder than everyone else.

My inbox is full of newsletters maximized to get some metric, I have apps screaming at me to engage. There seems to be tons of content everywhere, and more apps built to help you build even more content. Everyone has the tools to get to as many people as their newsletter list will allow, and everyone is trying so hard to get a click.

I haven’t run across much in those zones that have helped me understand myself better, or how I fit into this world.

The most I’ve learned about myself have come from 1:1 conversations and taking the space and time afterward to reflect. I’ve also learned a ton by watching others do the same.

Example, this picture that’s the main pic of this post. That’s Shayne and someone that helped us drag our bags from our two-night rental to our new apartment in Lisbon. We were in Portugal for less than 48 hours. We worked through the company helping us do the admin work of the move, and this guy was working there. He showed up at our rental with his car and we all packed in to go the kilometer or so to the new apartment.

Within minutes, we realized we’d met him before - he was our waiter about a year earlier on another trip during a relaxed dinner at a cafe near our hotel. The world is a lovely, small place. And it gets even more lovely when you talk to people!

We’d just got the keys to the apartment. They started talking about software development in the elevator, and this sweet guy wanted to understand how to even begin. So after we wrangled our six bags massive bags we’d brought from the U.S. with all our worldy possessions, they plugged in Shayne’s laptop, sat on the floor, and began to have an animated conversation about where he could start. It was the first use of our internet.

We had no furniture, no dishes, nothing but the utilities turned on. But that was a shining and memorable nerd share from our first hours in our new life here.

This is what questions and a few minutes can bring.

The friction of the solve seems lost.

I caught up with a colleague from long ago a few days ago. Her day is a mix of being in a number of areas across the business but her title is still ‘marketing’. She’s using AI where it makes sense to guide her research. She seems to have figured out where the human in the loop is needed vs. when research can be handled for a bit and passed on to her.

We used to work together at a company that drove us into the ground with work. This was before AI, when you had to talk through a blog post for a day or two with a writer, run over to the graphic design folks and talk through a narrative, then go to the project manager to talk through deadlines. That was all to manage one client, and we all had at least 10 clients moving at a break neck pace.

All that work was interacting with humans with thought processes and ideas that didn’t already live somewhere else.

It was amazing to connect to another human that remembers the toil, pain, late nights, elation of solving - all the things that we as humans connect on.

Now, it seems we are in a place where a lot of those human ideas have been replaced by a machine that looks at the median information already available.

The original thought still has to come from us, but the friction to do the research, understand the client, work with others, and have that light bulb moment (or 20) that’s truly connective…that seems to be lost.

Hell, even this post itself was started a week ago, sat on, I awoke the next day at 4am to continue on it, and I’m finalizing it now. Days later. With a bot, I could have given them an idea and cranked something out in minutes.

But what would I have learned?

Now, I’m rereading it again to double check it, and thinking about the whole story, adding bits of clarification. I’ve lived human moments since then that are now helping me bring this to life in a way no one else could because everyone’s stories and way of telling is unique.

We have tech companies battling to pull in as much of human existence and thought as possible to train models. But machines will never know what it feels like to read something, put it aside, and have that ‘I GET it now’ moment. That moment where a person starts writing, or painting, or creating in whatever format to capture the thing. Or connecting the dots in a conversation that helps them understand someone else better.

That moment feels amazing. It feels like that’s been somewhat replaced by a native integration.

Where are we in this? Who exactly are we in this all?

Got me wondering, what if we took it back to old school communication. 1:1. I know I’m acting like this is some ground breaking thing of people talking to other people.

It’s not ground breaking.

And yet here we are using machines to do our research, be our therapists and friends, be the thing that catches our thoughts that we’re a little too scared to say out loud.

They are built to give us just enough, make us feel like winning is just around the corner. They are a slot machine that spits out information, we’re in a huge casino with a few of those slot machines dinging in the background helping us feel like we just might be the next person to get that perfect answer.

The answer that changes everything and helps us with whatever our goal is. But that answer never truly arrives.

What if

• someone asks a question and some real human answers it

• that question is difficult to answer but opens up something in both people participating in the conversation

So, I thought…why not setup something slower, more human to human, more exhausting in a way where I can learn something from others?

So in the design cohort we have, where we’re testing out our product, I’m taking it very old-school. Uncomfortably so since I’ve lived and breathed automations, databases, and alleviating the simplest work for decades now.

I’m asking questions, I’m not having people fill out forms for every interaction. We’re having conversations and back-and-forth dialogue. Over email. Super manual.

Crazy? Maybe. Time consuming? Absolutely. But worth it? I freaking hope so. If it’s not worth it, then I don’t know where we fit anymore if we have nothing left to learn from talking to each other.

So if you want to get asked hard questions about your path or goals, and have a real human answer them, and push for clarification and cheer you on like only humans can, join our design cohort.

I’d be thrilled to hear from you. Like, truly.

I got a sign up last night and it made my night. We’ve already gone back and forth a few times today. We’re meeting next week.

Become a Design Partner.

There might be typos or a slight rant in the message (that already happened today). But I can assure you, a real human will be on the other side of it, thinking about a real answer.

Share

Subscribe now

After getting rich text in place, I was ready to dig back into the deeper system. I still had some refinements and tweaks I needed to make on the public interfaces, but most of those were pretty minor, or could be safely deferred. I came to a realization that to make things work in the way I wanted, I needed to tackle a big challenge I had been putting off: more robust searching.

In this post, I’ll be talking about what makes searching both more powerful and more complicated (expect there to be nerdery). I will also cover some of the surprises that I ran into and more thoughts about the weird world of AI enabled engineering, and the realities of it, beyond the hype.

Into the nerdery

In my posts Week in Review - Jan 12, 2025 and Last Week in Review Jan 26, 2026, I talked about some of the interesting elements of a graph-based system.

Having relationships as a first-order entity with their own collection of data tends to be challenging for many to consider, and subqueries increase the complexity dramatically. This is all compounded by the need to communicate with the system to get the appropriate information in a clean and repeatable way.

To start to illustrate some of this, I’ll bring back our ecosystem graph we were working with in our last explorations of graph structure. In the referenced articles, I used an example graph with the following entities and relationships:

In the world of graph dbs, each noun tends to map to a node, and each verb tends to map to a relationship, and both of those contain their own set of information. This enables data structures to be built that tend to be intuitive. As they grow, they can quickly become overwhelming, but ultimately the core principles can always be broken down to two nouns joined by a verb.

So, why is this important in search?

Finding the perfect Node

Searching for a node (noun) in the system is very straightforward. If I have a Pollinator with a value on it, such as “cycle”, which corresponds to when it is active, I can very easily say “give me all the diurnal pollinators”. The actual cypher command to do that would look like this:

MATCH (p:Pollinator)
WHERE p.cycle=’diurnal’
RETURN p

Of course, there are more sophisticated queries, but for now we’ll stick with simple examples.

Translating this to an external api querystring would be quite simple. Something like this would totally work:
/ecoapi/pollinator/?cycle_eq=diurnal

The search can be further expanded by adding more values:
/ecoapi/pollinator/?cycle_eq=diurnal&class=insecta

This would further filter our prior list by only returning insects.

URL query sidenote: You may have noticed a suffix _eq (and _gt in later examples) hanging off the field names in the urls. This is because there is a whole range of comparators that can be used to search for depending on the nature of the value in the field. I’m not going to go deep into them in this post, but every field in the search needs to designate the nature of the comparison being done.

The cypher command would end up looking like this:

MATCH (p:Pollinator)
WHERE p.cycle=’diurnal’
  AND p.class=’insecta’
RETURN p

This same pattern would work well with any of the nodes in our system.

The first problem with the querystring emerges when you want to expand your result set rather than filter it further.

If, for example, you wanted all diurnal Pollinators, and all insect Pollinators in one set for some reason (no idea why, but you do you). You would want a query that looks like this:

MATCH (p:Pollinator)
WHERE p.cycle=’diurnal’
  OR p.class=’insecta’
RETURN p

The problem is, our basic querystrings have no way of designating what the conjunctions between the criteria are. This gets even more challenging when conjunction types are mixed (both AND’s and OR’s).

The good news is that with querystring encoding you can send just about any shape in a querystring, including standardized formats like JSON.

I decided that instead of trying to use a flat querystring (which also has other values), I would put all of my search definitions in one JSON search field. I had actually made that decision long ago, knowing this would be an issue, but now it was finally being exercised.

The way JSON has to be encoded in a URL is hard for humans to read so my examples are not what you would see in the real URL. The encoded url has a lot more %’s and numbers.

So, here’s what the payload of the search field would look like for our prior examples:

With this url: /ecoapi/pollinators/?search=

Find all diurnal Pollinators:

{ "cycle_eq":"diurnal” }

Find all diurnal insect Pollinators:

{
  "cycle_eq":"diurnal",
  "class_eq":"insecta"
}

Find all diurnal or insect Pollinators:

{
  "_or":[{
    "cycle_eq":"diurnal"
  },{
    "class_eq":"insecta"
  }]
}

This allows for sophisticated search criteria to be built, with a clear dialect for finding what is needed.

On the Edge of Relationships

Once relationships (verbs) enter the chat it gets more complicated.

In the graph world, both nodes and relationships can hold data that can be filtered on. Also, an identically named relationship can connect two other nodes with different contexts.

For example:

In this case, the relationship EATS is identical, but the case of a predator eating a pollinator, is fundamentally different (and more violent) than a cow grazing on daisies.

Choosing the right relationship

Because of this, while possible, searching for all of the EATS relationships that are attached to any two nodes, is not often as useful as thinking of the relationships as a triplet (noun-verb-noun).

The catch is, the value that identifies which relationship is useful could be on any or all of the three entities involved. So to extend our example further, if both Predators and Pollinators have the same class and cycle fields, and EATS has a frequencyPerDay, a search like this is absolutely possible:

MATCH (pre:Predator)-[e:EATS]->(p:Pollinator)
WHERE pre.class=’mammalia’
  AND e.frequencyPerDay > 5
  AND p.class=’insecta’
RETURN pre, e, p

This can give us a sense of the impact that mammal predation has on the insects in our ecosystem. While very useful, it starts to get much more complicated to call with the API.

First, we have to establish that we care about the particular EATS relationship between Predators and Pollinators (so we don’t end up with our daisy munching cows).

Often the shape of the base url can help with that /ecoapi/predator/eats/pollinator/, from there we need to determine the shape of the various criteria. It needs to be crystal clear which field applies to which entity (either of the nodes, or the relationship itself).

To do that, I thought the most logical course of action would be to prefix the node fields with the name of their node, and omit a prefix for the relationship fields.

So the query above would have a search argument that looks like this:

{
  "predator_class_eq":"mammalia",
  "frequencyPerDay_gt":5,
  "pollinator_class_eq":"insecta”
}

With that solved, I was faced with another challenge. In the query I mentioned above, it would only return a value where all of the search terms matched. Useful for classic searches, but less useful if you wish to see root node records both with and without relationships.

The set gets Jagged

Consider this scenario:

Your application needs to list all the mammalia Predators and show the set of insect Pollinators those Predators EAT. The Predator should always show up, whether or not their EATS relationship matches those specific criteria.

What you would need can be referred to as a jagged set.

With what we defined above, we could handle this by making two calls, then have the caller knit them together:

1. one for all the mammalia Predators

2. one for the EATS Pollinator relationships

While this would technically work, it would get messy fast, and it also increases both the information across the wire, and the work the caller needed to do on their end. To make this work in a single call, instead of the query I had above, I’d have to do something a bit more involved: I’d need to use a subquery.

MATCH (pre:Predator)
  WHERE pre.class=’mammalia’
  CALL (pre) {
    MATCH (pre)-[e:EATS]->(p:Pollinator)
      WHERE e.frequencyPerDay > 5
        AND p.class=’insecta’
    RETURN collect({e,p}) AS e_p_collection
  }
RETURN pre, e_p_collection

This tells the database to always return the matching Predators, but also return the collection of the Pollinators they EAT more frequently than 5 per day if they have any matches.

The good news is, I already had the deep systems in place to do that. The bad news is, I hadn’t figured out how to get them to work on the querystring api.

That took some work.

Compounding with Subqueries

One more piece I need to share to set the context has to do with the way subqueries are defined on the querystring.

In Last Week in Review Jan 26, 2026 I go into some depth about subqueries, and I covered them in some detail here Week in review Mar 01, 2026, but here’s a quick overview:

A subquery is an additional chunk of data that is gathered based on an initial query (for a node or a relationship) I refer to as the “root”. A way to think about it, would be getting to a particular place, and seeing what is nearby. Subqueries can be potentially any length and are expressed by a chain of relationships.

Different shapes of information are useful for different needs and as of now, the system supports three:

• Counts: the number of items that match the subquery definition

• Digests: a table shaped record made up of specific values from the matches

• Trees: the full definition of every entity that matches the definition

Currently a subquery is requested by referencing a descriptive key that maps to the full configuration based definition on the service.

So I could say:
/ecoapi/pollinator/pollinates/flower/?with_relationships=predators_who_ambush_from_that_flower

On the backend, it would know that we were looking for the POLLINATES relationship between the Pollinator and the Flower, and we also wanted additional information about Predators that hide in that Flower and EAT that Pollinator. I’ll spare you the cypher as it gets quite involved.

In a form of shorthand you could say:

Root relationship triplet is: pollinator-pollinates-flower

Sub query relationship triplets are:

• predator-eats-pollinator

• predator-hides_in-flower

The key lets the system know it needs to knit these relationships together in a meaningful way, without the consumer of the api needing to know the mechanics.

Adding the ability to search anywhere along the subquery adds a significant issue: how do I designate what should be searched and where. I realized my answer wasn’t as bad as I had thought.

Searching the relationships along the way

Each link in a subquery chain is a relationship by its very nature. As such it should be treated as any other relationship search. We could also use the same pattern of having JSON in the querystring argument.

So if I wanted that same subquery, but I only really wanted to know about the insect Predators that use camouflage to hide in the Flowers and eat with a frequency greater than 5 per day, I could set the value of with_tree to:

{
  "subQueryKey":"predators_who_ambush_from_that_flower",
  "links":[{
    "target":"predator-eats-pollinator",
    "search":{
      "predator_class_eq":"insecta",
      "frequencyPerDay_gt":5
    }
  },{
    "target":"predator-hides_in-flower",
    "search":{
      "method_eq":"camouflage"
    }
  }]
}

The downside is the caller would have to know the structure of what the subquery maps to, but that is likely a critical thing for anything like this. Additionally, any other query modifier (such as sort order, or max length) can also be applied using this structure.

I’m very excited about the capabilities this unlocks. I’m not quite done with the subquery handling yet. I’ll still be working on it next week, but the groundwork is already laid.

There are additional challenges, but they are more complex than this one. This piece is meant to outline the main effort. I may touch on these more complex changes in a future post.

Wrapup

With all this dense query related stuff, I should probably call it. I did promise a little venting about frustrations, so I’ll keep it brief:

Goodbye GitHub Actions, hello Dagger

For the second time at a critical juncture, GitHub Actions decided to suddenly shut down my pipeline due to lack of payment… on a free account… with no way to pay that I could find, and no warning.

The first time was when I was launching our live site, this time I was dealing with a hotfix I needed to make (markdown renderers don’t like null… who knew?). I’m sure it makes sense to them, but as a user, it was a horrible experience.

Suboptimal but functional

This led to me spending pretty much all of last weekend vibing up a build and deployment pipeline using Dagger. I’m sure the code is atrocious and overly bloated. In fact, according to the bot it’s actually bigger than my workhorse webservice code. At this point, it seems to be working reliably, and much quicker than GitHub Actions. Only downside (and it’s minor), it all runs on my local machine for now, so I have to be on it to run it. The pipeline is completely portable so can be plopped onto any host that has Docker. When we set up hosting for our internal tools, this will be a natural fit for that.

The casino effect

I touched on this a little in my last post, but the realization that the various bot providers are not incentivized to actually solve your problems has really stuck with me. They are very much like a casino that frequently gives you an almost great hand, but rarely an actual prize. It’s just enough to keep you coming back and continue to play. I’m certainly not the first person to come up with that observation, in fact I remember reading that months ago but it really struck a chord.

If their entire business is selling tokens (and it is), then they couldn’t care less about solving your actual problems, but instead want you to keep spending tokens. While they have to solve things now and again to keep people hoping, getting close is even more effective, and much easier to achieve.

This combined with frustration with Cursor (I could write a dissertation on that one) and Gemini quirkiness inspired me to have Gemini spit out a Cyberpunk-inspired short story about what the dark near future would look like with the logical extensions of our current “AI” systems.

It took some tuning, but I think it turned out pretty nicely, and darkly funny. Ironically, there were some real life things that occurred in the production of it, that was very close to what the AI in the story did.

Let me know if you want to see it. I won’t be posting it’s fulltext here as it is absolutely AI generated, and substack is working hard to reduce the AI slop (which I greatly appreciate!!!).

The last two weeks have been primarily focused on adding searchable rich text to some of the fields in the product. There have also been some continuing learning on the product side about how we might hit the market and how we can best learn from those who this product is geared to help.

My primary focus will be on the engineering work and some of the serious gotchas about an AI standing in for a pairing partner, and how this can be a major problem. If I don’t get too long-winded, I’ll touch on some of the outreach work as well, but I’m guessing the tech will take most of the window.

Enriching the Text

Peppered throughout our product are various longer form fields: descriptions, summaries, and the like. In my initial build, for ease, I made them plain text. In most places the display did not keep formatting at all, so each of these blocks was a wall of text, no matter how many line breaks you put in them.

This was fine for conveying the base concept, but Jenn made it very clear that it would not work fine longterm. She was absolutely right. People have become used to WYSIWYG (What You See Is What You Get) editing and being able to format longer form content. This is particularly important for areas where formatting will help people understand potentially dense information.

It was a reasonable request, and one I knew I’d need to tackle eventually. Modern tooling makes it look easy, so the common stakeholder perception is that you plug it into the application with a small amount of work, and you’re on your way. This is often true with full-fledged website editors but less so when you are building a web application. While there are great existing libraries, including open source ones, there are still a ton of decisions that need to be made when adding something like this.

To make matters worse, she also wanted to be able to search the content of these rich text fields, and for very good reasons.

The challenge

To do this I needed to resolve a whole range of questions and problems.

These were the biggest:

• Format of data: I needed to first choose a way to store the rich text formatting information. It would render in html, but I needed to either store that html or instructions of how to make that html. Fortunately, the industry has a great standardized and lightweight way to do this called markdown. It’s modeled off of the ways people would try to show formatting in plain text back in the day, so it’s quite intuitive.

• Not making it a problem: Allowing users latitude to change formatting, and essentially add html at will introduces a whole host of problems. Custom formatting can easily break layouts, but that’s not the worst of it. Giving users the ability to essentially generate html can allow them to do all sorts of things including embedding scripts, or images/videos to stuff we wouldn’t want to be associated with. Whatever I added needed to protect against that.

• Making search meaningful: The naive approach would be just store the markdown in the existing text field and call it a day, and that would have worked fine if we didn’t need to search it. The problem is, the formatting information would also come up in search results if you searched using that field. An example of how this could get wacky: in markdown if I want to bold something I surround it with **. So, if I had this string: “The **most important** thing.” and I searched for “important thing”, I would not get any results. To find it by that phrase, I’d have to search for “important** thing”. Clearly, not intuitive.

Solutions take form

It didn’t take me long to decide to use Markdown, that was really a “no brainer”. I knew that expecting the user to write raw markdown was a non-starter, so I needed a WYSIWYG control for that. Building my own was not really something I wanted to take on, so I went looking for libraries.

There are quite a few that serve that need, but of course the most mature would not be in our budget. I eventually settled on Milkdown. Their Crepe editor plays nicely with Nuxt (what our app is built on), and would handle the vast majority of the functionality needed for the editor, and it is open source.

Integrating Milkdown/Crepe seemed to be going smoothly. To handle the search issue, I decided I needed to store another field for plaintext. So if I had a field named summary, it would get a partner field named summaryPlaintext which it could be searched on.

I really miss human pairing buddies, or problems with relying on a bot

Throughout this time I was working closely with a bot (or two) to help work through these problems and bounce ideas off of. They were super helpful in identifying libraries to use based on my specific needs, and making integration with those libraries less of a massive learning curve.

For this next bit, I need to give you a little context of our application. We have the following systems:

• UI - NodeJs application using Nuxt: this is what you see and interact with

• Webservice - NodeJs application using Koa: this is what acts as the orchestrator between the UI and DB

• Database - Graph DB using Neo4j (Community Edition): this is the workhorse that stores and retrieves the data

The control I’m discussing is part of the UI, and the extra fields I’m adding are needed by the Database, but the Webservice also needs to be part of that equation.

Frustration with a sycophant

My initial thought was to have the UI component generate both the markdown and the plaintext, then send them both into the Webservice, and it would just save them as is. This would make it so the UI would need to know to search for the plaintext value, which would never be returned. I also was adding a new validation rule that made sure if any of these rich text fields were passed in they would require both values to be set, so we could make sure the data was clean.

I ran the idea by one of the bots, and they thought it was brilliant. So I started implementing it. The return from the rich text editor was a bit clunky, as those things usually are set for a single value, but it was manageable. Once I put the Webservice validation in place, a whole bunch of my scenarios broke.

I decided to take a shower.

Shower thoughts are where some of the best realizations come from, and that was the case here. I was thinking about api versioning, and realized that if I was following strict SemVer (Semantic Versioning) on the Webservice, me adding the validation would be a major revision/breaking change and that didn’t sit well with me.

That’s when it hit me, my approach was awful. I had completely broken encapsulation. I was forcing my UI to know about a field that it would never show, and it had no real reason to care about, except it had to search using it.

Once I was done with my shower I let the bot know about my realization, to which it chirpily confirmed I was right and spewed out the reasons why the other previous approach was wrong.

It was a clear reminder that bots will always give you the feedback it thinks you want to hear rather than real critical feedback. Heck, if you ask a bot to give you critical feedback, it will critique everything whether or not that critique is warranted.

This is because it fundamentally has no idea what the concept you are discussing with it is. It just knows what series of characters are more likely to follow another set of characters. No matter what they throw at and train today’s AI’s, they are just sophisticated pattern matchers. Super cool in many ways, but fundamentally flawed when it comes to true understanding.

If I had been paired up with a real human partner, like other times in my career, the chance of them bringing up the glaring encapsulation issue early would have been much higher and saved me hours of effort.

If I hadn’t been lucky enough to have that shower thought when I did, I would have built layers of code on top of that, which would have made the system far more complex than it needed to be and harder to maintain.

A chilling example

The last example was a relatively tame one. There’s a much more brutal one that also happened in the same time period, guaranteed to get anyone with any form of compliance understanding very uncomfortable.

I mentioned earlier that to accomplish searchable rich text, I needed to introduce a new field. The problem is, until the values are saved again that field isn’t set. This means it won’t come up in search results until that happens. Not ideal.

I was discussing this challenge with a bot, and it “helpfully” spewed out the database command that would go through the database and copy the old field value into the new field.

Super helpful, right?

It made my blood run cold.

Here’s the thing, running raw modification scripts against a production database violates almost every data governance law in the book. While it’s fine on your local db that no one but you uses, if you’re actually building a real application for real people to use, it’s a huge no-no.

We’re also in a country covered by GDPR, where every modification to a data record with personal information needs to be logged, or massive fines can be levied. That said, even in the wild west that is the US compliance ecosystem, that little script (which totally seemed like it would have worked) would violate major policies (SOC 2 compliance to name a biggie).

The bot provided that script (unrequested) in an attempt to be helpful. Fortunately, my background of decades in the tech industry set off major alarm bells, so I pushed back hard.

The thing is, how many people out there would have gotten that script and ran it without a second thought, exposing their companies and/or themselves to MAJOR risk?

Additionally, bots frequently make mistakes, so there was a significant chance that there was a flaw in the script that could have unrecoverable consequences.

To make matters even worse, if a non-technical stakeholder wanted the thing done and had a senior staff member who would say: “that’s not a great idea, we have to do it in a more methodical way”, or a bot enabled junior who says “Absolutely, I’ll do that right now!”, who do you think they’ll choose, and which do you think would be more likely to land them in very hot water?

Critical thinking is not optional

What both of these examples have in common is that today’s bots are tuned to tell you what you want to hear, whether or not it is accurate. In fact, accuracy is a much lower priority for them than engagement.

This is baked into each of them for sound business reasons: at the end of the day the companies that make bots want you to use as many tokens as possible as that is their revenue stream. The more you rely on and interact with the bots the more money they make. This applies to the entire ecosystem, from chip manufacturers to agent creators. They do not care about you being compliant, nor having something solid. In fact, in many cases, the less solid it is the more dependent on the bots you become.

A human pairing partner is much more likely to be aligned in purpose and motivations, as well as having a real understanding of what is going on.

How I actually solved it

With my encapsulation realization, I made a hard pivot. The UI control would only interact with the markdown, and that would be the only field passed to the Webservice. The Webservice would know the value was markdown, and automatically populate a plaintext field stripped of the formatting information. It would also know to route searches of that field to the plaintext field. Things that call the webservice, such as the UI, have no knowledge at all of the plaintext existing, nor do they care.

There were other challenges, such as ensuring that escaped things were shown properly and restricted things didn’t look like options on the toolbar, but all in all after that shift everything worked a lot smoother.

We now have completely functional searchable rich text, though there is still a lot of manual saving of existing fields work to be done for them to appear in search.

Product realizations

We’re continuing to learn more about our potential customers and what might interest them in this system.

A key realization about the problems we are grappling with is that what is missing in today’s environment, both in the job market and online spaces in general, is that most of us don’t feel seen or cared about.

We shape our outward image to whatever might make us appear better in some algorithm or another, but how much are they reflections of who we really are?

When we apply for jobs we feel well suited for and get a rejection letter (if we’re lucky), do we really feel like someone took the time to consider us? They may very well have, but it sure doesn’t look like it from our perspective.

On the other side of the fence, if we post a job looking for a specific set of skills, the flood of desperate applicants who don’t match the qualifications, or possibly are not even real is enough to overwhelm anyone. Does it feel that anyone cares enough about our needs to actually target their applications?

We are more connected than ever before (I have regular video calls with an advisor on the other side of the planet), yet we are feeling less seen, less heard, and less cared about for our real qualities than ever before.

This is not a problem we can solve alone, it’s a multifaceted beast that will take at least decades to unravel, but what we’re working on, I feel, is one of the pieces that can help with this.

If you find what I write about interesting, and want to give us feedback about what can help us in our efforts to make things a bit better, consider becoming one of our Design Partners.

We recently imposed a huge deadline on ourselves to get a basic website and the application viewable to the public.

As with anything, this is always easier said than done.

Having launched hundreds of websites previously in life, I’m used to a certain level of deadline, stress, anxiety, and late-night double checking.

This was next level because it’s really, truly ours.

The questions that started it all

First of all, I’ve always treated any work like it is my own creation, because that’s just how I operate. But there was something different about this. Maybe it’s because we’ve been talking about this for a few years now, took the last year-ish to frame the idea, and we’re trying to put into the simplest of words why it’s important. Why it matters, why people should care.

This thing we’ve built that started with me asking some questions:

• Why do we attach skills to a whole job duration instead of a specific achievement, project, or milestone?

• Can we actually map how we learn our skills and progress over time so we can better understand and advocate for ourselves?

• Is there an easier way to ask the same questions I’ve been asking people for years now - what’d you learn, how’d you grow, what did you take to the next role/adventure?

While I’ve been pondering the philosophy of this, Shayne’s been wrestling with code to make the thing come into literal life. He’s been working magic, but I digress.

The point is: we have something others can now see. We have a website! and an application!

Demoing the data

Using our own information to test the system

To test this theory, we went way back in time. In history and our own lives.

We’ve been using historical figures to demo out the system as well as our own profiles. I can say it has been enlightening in understanding my skill journey, where it began, and how it evolved.

Thinking back that far really helped ground me in what has continually been present for me or what I gravitated toward. I tried a lot of things, some of them led to other pathways that are a core part of who I am. Some I stopped doing and wish I’d kept up.

I found for me the great lightbulb moments while looking at my skills and the story behind them are 1. try new stuff and 2. ask yourself what you learned from one point in the path to the next, and what you brought with you.

Working with historic icons to find deeper stories of learning and progression

I’ve got a huge list but so far, here’s where we are at with what is viewable, so you can see how it works:

• Ada Lovelace - established foundational principles for theoretical computability and machine architecture.

• Alan Turing - visionary mathematician, logician, and master cryptanalyst whose cross-functional breakthroughs laid the structural bedrock for the modern digital era.

• Alexander von Humboldt - The ultimate scientific disruptor of the 19th century and a visionary polymath who fundamentally re-engineered how humanity understands the natural world.

• Claude Shannon - visionary mathematician and electrical engineer widely revered as the “father of information theory”

• Hedy Lammar - her architectural design serves as a foundational milestone for modern wireless infrastructure, including Wi-Fi, GPS, and Bluetooth technology

• Hildegard of Bingen - the founder of scientific natural history in Germany.

• Leonardo da Vinci - Stands as history’s ultimate High Renaissance polymath, a visionary who refused to see any boundary between the beauty of art and the rigor of science.

• Mary Somerville – The “Queen of Science” in the 19th century, she was an authority in physical sciences, and inspired the coining of the term scientist.

Now I have the hard job of figuring out how to tell people about this.

The best way I know how is to try to be human and tell stories along with it all.

So, I’m going to try to continue to use historical figures to help me show off the system, and drive home how to show progression of skills, how non-traditional pathways work to build learning, and honestly, make it a little more engaging and fun (maybe only for me, we’ll see).

Leonardo da Vinci’s (Terrible) Time Management

I started with Leonardo da Vinci, because he was the first person I thought of. Digging into the depth of his skill and where he really flails is kinda wild.

He was the artist that would stare at a wall for a day or two to understood how light worked. He was ‘unlettered’/not formally educated, and had to find different paths to learning that were available to him. That led him to study anatomy intensely however he could, which helped him paint and sculpt more realistic portraits. His particular intermix of skills that might seem strange from the outside is what made him truly exceptional at what he did.

Some things he really struggled with. He was notoriously bad at keeping deadlines and delivering work. He ended up in a twenty year court battle for not delivering work he was contractually obligated to complete.

He straight up nerded, got obsessed and curious. Which is great, but he did it to a point he went down a lot of tracks that, let’s say, weren’t in scope.

He wasn’t easy to work with, and I truly wonder if he had peer reviews what that would look like. I’m pretty certain it wouldn’t be all “you’re an asset to any organization”, and that he’d be told he’s an expert in Oil Painting but at best a novice at Project and Time Management.

Skills aren’t a movie montage, as much as cinema would like us to think so

It all got me thinking about how much of what we learn is so interconnected with our entire lives and our experiences, but yet that’s really hard to see. It is hard to see the breakdown of how much time it truly takes to get to an expert level.

It’s hard to see how sometimes the skills we aren’t so good at help us in some way. Perhaps because someone isn’t so great at something they offload it, work around it, make the lack of skill work for them.

Or in Da Vinci’s case they run away from it completely and still make it work.

Skill building isn’t an ever constant hustle like we see in montages. Sometimes people never get better at a skill they need or want.

Skill building has times of quiet reflection, living life, and having moments of clarity in the most unrelated moments. Sometimes it’s just completely doing something else for a long while and picking it back up again. Other times it can ignoring everything else and becoming obsessed.

There is no perfect way to learn, but maybe the closest to perfect is to just keep trying to learn anything at all.

P.S. We aren’t building this in a vacuum.

If you want to play a real part in shaping how we map human growth, we are actively looking for design partners to test the platform, break things, and give us truly honest feedback.

Learn more at skillbearings.com.

Subscribe now

I am no fan of deadlines, particularly for software.

This is a controversial statement in conventional software development. It is a pretty common sentiment among the agile engineering community, or at least that’s the prevailing view that people tend to hold about agile engineers.

The reality is far more nuanced.

Many in the engineering community have been beaten up by deadlines and the systems built around them. Pretty much any engineer you talk to can cite many examples where they were asked for a gut feel of when something might be done, only to find themselves in a situation where they are strictly held to that guess they made with very little information, or even worse, told that guess was too high so they need to come up with a shorter one.

In particularly bad situations they will have a deadline assigned to them without them having a say.

This dynamic is the underpinning of a lot of the friction about deadlines in agile. Scar tissue from toxic interactions compounded by the very fact that software engineering is an invention and knowledge based discipline, where early in the lifecycle it’s literally impossible to predict with any level of accuracy when something will be good enough to call done.

On the other hand, it makes sense why deadlines are needed. Consider paying a lot of money for something you are staking your reputation and livelihood on, only to be told that there is no way to predict when you’ll get that thing, nor any real verifiable assurance that you will get what you are expecting.

It’s not something that many would want to do. If someone did make that choice and end up getting nothing for their support there are many who would consider that person completely foolish.

Unfortunately, that’s pretty much what we engineers are asking others to do when we resist deadlines.

There’s also another factor to the whole mess having to do with how many of our brains work. If we have the perception that we have a lot of time, or completely flexible time we tend to make choices that will make things go longer. This was captured well by the old adage “all meetings will expand to fill their allotted time.” It’s not just meetings, it’s pretty much everything we do.

It goes to eleven

It was in exactly this push and pull dynamic that the various agile methodologies and practices evolved.

Extreme Programming (XP) took a scientific approach to how to solve these problems (as well as many others in the field). They would take a practice that everyone agreed led to good software and asked essentially, what would happen if they took it to the extreme level (turn it up to 11). After that, they would examine if it made things better or worse for their software delivery practice. Based on that, they’d decide if they wished to keep it or not.

From this experimental approach numerous practices arose and have become the underpinnings of high quality professional software delivery. Examples include:

• Test Driven Development: Common agreement that unit tests made software better.

  • Experiment: What if tests were written before the code?

  • Outcome: Granular and more maintainable code, with exceptional levels of reliability

  • Surprise: Rapidly became less about testing, but more about driving the design in modular ways.

  • Legacy: Still used a lot today and often considered a development best practice. People learned that using tests to express behavior led to less churn and developed Behavior Driven Development. Other subdisciplines also emerged, such as Database Test Driven Development.

• Pair Programming: Common agreement that code reviews led to better software.

  • Experiment: What if we had continual code reviews by having the developer and the reviewer sit together at the same computer?

  • Outcome: Delivery did not slow down and the output was better quality. Better information sharing amongst the team.

  • Surprise: Delivery times often sped up due to the need for developers to voice their thoughts, leading heading off bad ideas earlier. Once people got used to the practice, they tended to prefer it over working independently.

  • Legacy: Still very active in the field. It has grown further into the concept of Mob Programming where the entire team works on the same work item/computer.

• Continuous Integration: The shorter period of time there is before all the team’s code is put together, the less time is spent dealing with integration issues.

  • Experiment: What if we integrated the code at least once a day, but ideally multiple times per day?

  • Outcome: Less time fighting merge issues and diverging designs

  • Surprise: Tended to allow integration issues that did arise to be resolved quickly, support another practice Collective Code Ownership, and promote more of an “all in it together” mindset on the team.

  • Legacy: Entire industries of Continuous Integration tooling have sprung up (note: it is a practice NOT a tool, no matter what the tool salespeople tell you). The concept matured into Continuous Delivery, where not only were things integrated, since they needed to be built and tested to ensure the integration worked, people realized they could also be deployed automatically.

Two different ways to handle the same problem

Other practices such as Scrum arose due to the same tension. Their approach was different than the XP folks, but due to cross pollination a lot of XP practices are now attributed to Scrum.

One thing pretty much all of these practices shared was the realization that the feedback loop needed to speed up dramatically. Each approach had different ways to achieve this.

The two prevailing schools of thought were:

• Getting more focused on what really mattered - XP aligned

• Shortening the deadline cycle - Scrum aligned

Their common philosophy is the more frequent the touchpoint is between the stakeholders and the engineers, the more likely the stakeholders would be ok with the spend, and the engineers would be more likely to build something that matched what the stakeholders wanted. It would also allow the stakeholders to better predict when things might be done so they could communicate better with their own stakeholders.

For the most part, both things worked well. They did, of course, have their shortcomings, one of the biggest comes down to the fact that most innovative software engineering is inherently unpredictable, and the predictable stuff is not really something that is as likely to be what is going to be a big differentiator for a business.

This led to a lot of the great ideas of the practices getting oddly corrupted or becoming dogmatically used patterns, rather than tied to the actual outcome they were meant to achieve.

Story Points: How Gummy Bears became corporate thugs

A classic example of this is the concept of Story Points. This was an XP invention that Ron Jeffries invented by accident, and regrets. Basically the story comes down to this same deadline tension.

XP had come up with User Stories, which took the part of Use Cases they thought helped –the focus on what the user was trying to achieve with the system– and stripped away all the fluff. In doing that, they went from a multiple page document down to a series of things that fit on index cards.

This allowed a granular approach to developing software, where each of these little bits of user functionality could be prioritized and arranged in multiple ways. It enabled a sense of movement and accomplishment, as well as a way to facilitate fast feedback.

Not all functionality is created equal

The key issue is that these bits of functionality could be vastly different in effort. Both the stakeholders and the team needed a way to get a sense of that.

There was also the problem that a pack of index cards didn’t answer the question very well for the stakeholder about when they’d see a return on their investment, and/or when they could share it with their own stakeholders.

The stakeholders were accustomed to working with “man days” or “man hours”, as in how much time would the average set of developers need before they can deliver this Use Case. This of course was an inherently flawed metric as I’ve mentioned before, but the more granular approach must have been enticing.

It’s all relative

There was a big desire to apply this same measure to User Stories. The thing is, as mentioned before, you can’t really estimate the time it will take to do a work item or another, but you can get a sense of how big or small it is compared to its peers.

So the reasoning was simple: add in an abstract relative sizing mechanism, at the time it was Gummy Bears, and that would provide the conceptual abstraction to know if something is bigger or smaller than something else. This would aid in prioritization among many other things.

I’m not sure when the cracks started showing, but I can tell you, I’ve seen the firsthand damage of Story Points many times. From early in my career where people were still stuck on converting them to segments of time, to later in my career when people treated them like a scoring mechanism: “I want to get my points for this Sprint”. While the original concept wasn’t the worst, the way it got corrupted is downright stunning, and a testament to the human ability to game just about anything.

Pulling the emergency brake

Well, this was originally supposed to be a short preamble about the agile view on deadlines and where the tension shows up, and how despite popular thought otherwise, agile is NOT in fact anti-deadline. I’m afraid it turned into a bit of an agile history lesson.

I’m going to stop myself there and get to my main point:

What good IS a deadline?

We set a deadline last week, and it worked. It did lead to me pushing myself to a punishing, until-midnight fight with the first deployment to production, and levels of stress I hadn’t felt in many years. That said, all in all the level of focus both Jenn and I have had recently has been great. It’s also led to significant results.

We have:

• Trimmed scope: We realized that the first thing we needed to get feedback on is our public display and to do that, we could focus on just that part of the application. We also could handle our ability to log in via a much simpler mechanism than the full authentication strategy I’m building for others to log in. There are too many other things that this simplified to mention, but it was a game changer.

• Extended the application deployment system to production: We are now deploying to our production environment, with a fully automated pipeline. To ensure our costs don’t explode, and for direct control we’re keeping the deployments to production manually triggered, but that’s a simple button push. The system still has some kinks, but I think I’ve cleaned up most of them.

• Launched both the website, and the application: This involved a fair amount of work from both of us. Related to trimming scope, we decided to separate our overall concept into multiple more-targeted named subproducts.

So, we settled on the name Skill Bearings. This part of the product is to enable you to take your bearings of the various skills and learnings that make up the entire picture of you. At this stage, we are selecting a handful of people we will work directly with to build out their profile on our system, who can help guide us to build something impactful that customers will love.

I still don’t like deadlines… but sometimes they are useful.

Please take a look at the site, and sign up if you are interested. We are particularly interested in people who are passionate about self reflection, and tracking their progress in their lives.

Back a long, long time ago, I used to have a blog called ‘RANT’ - my 20-something self, who was in public and in person very quiet, would use the space to go off on people’s behavior in public, why certain things happened the way they did, and how the world in general didn’t make sense. It was the opposite of myself externally and I loved having a space to just process the world.

I walk a line

Now, I’m a bit older and the internet is not a place to do that anymore without being seen in a light that’s unflattering in some way. Some people build brands on their own way of being, housed around authenticity, swear words, and crackling, biting humor which is entertaining to read or interact with but if you had to sit next to them at a dinner you’d probably lose your mind. Or at least I would. I have my own list of who those people are.

For me, there’s a fine line that I’m walking now between how I really feel, and how I desire to be seen. I never want to be that person that can be read but not tolerated in real life. I want to be approachable in both. I keep some parts of me for my closest of friends and confidants, while others may lay it all out there for everyone.

This is why in some ways I peel back from interaction in the public space because it’s hard to feel like you say the same things over and over again. It’s hard to see the systems and be gesturing broadly to a crowd of no one that can change it. It’s hard to keep having the energy for it.

I feel like most of what I’ve posted here is the same - all leaning toward the same idea that how the system is setup is not for us and it’s erasing our sense of self-understanding and sense of self.

I know that something has to be repeated many times for someone to ‘get’ something, and that a lot of what most are saying in certain spaces is going on deaf ears.

I know that the ears that need to hear this aren’t the ones that are reading, but perhaps if I every once in a while pop up with a new way of approaching this concept I’ll accomplish a few things:

• I’ll be able to be creative in my words, which I like

• Someone else for the first time might read this and go ‘yeah, that’s right!’ - which is a total win

Now that I’ve gotten that out there, to the heart of the matter that keeps me up at night, wakes me up in the morning, and at random like a cat with the zoomies, gets me ramped up at random parts of the day.

We have to shape the professional futures we want to see, as a whole, as a movement

I’ve spoken to tons of job seekers and done a fair amount of research into the issues we see today. We all know the job market is a mess and that companies no longer lay people off only when there’s financial trouble but also when they are printing money. These things I don’t need to repeat.

But I do think what’s worth speaking about, even if it very much feels like zero shock to anyone, is that companies, stock markets, systems that employ and bring clients will not change on their own.

They have to be forced. Or, we need a different system to play in.

Companies have been going along just fine for a long time shoving people into boxy job titles while leaving out their non-traditional skills, their hobbies, and their life-won achievements that don’t fit into the corporate narrative. They erase what context doesn’t suit them. Or, there’s not even an option for it to exist at all.

They build a job shaped hole that everyone has to walk through everyday when they start work, and walk out of when they end their day.

We can have it both ways, and so can they

I get why companies pick and choose what they need to filter through and see in the moment. I have an attention problem so I deeply understand the need for no more information than what’s needed.

But, with that choice comes a concrete wall separating what will likely be of incredible use. As a whole, all of us, the places we work, the people we interact with are seeing fractured parts of our existence and what we have to offer the world.

But, perhaps someday instead of companies having to put up the walls because they don’t have a proper mechanism, people could decide in a concise and data-driven way what they might want to let through.

Maybe all versions of ourselves meet at the gate

Instead of a concrete wall, we form a gate that organizes life’s stream of work, curiosity, and achievement into readable functions for organizations, educational institutions, and communities to see the whole value someone could bring. If they want to bring it.

Whatever the person doesn’t want to let through, they don’t.

We’re trying to build this gate, and we’re finally getting around to positioning it in a way that hopefully makes sense.

As much as I like to play with words and explain things, explaining this issue and how we’re trying to go about fixing it has been one of the hardest things I’ve done (yet).

But I do think I’m starting to get somewhere with the difference between a job-shaped hole in a concrete wall and an individual-controlled gate.

Subscribe now

I had initially planned to get back on the post every week schedule, but something important came up that derailed that plan. In fact, due to that same thing, this update will be shorter than usual. Last Monday we met with someone very deep in the entrepreneurial ecosystem in Germany. Beyond being a well-connected angel investor and venture scout, he is a leader of an organization that represents our ultimate dream institutional partner. This was a high-stakes moment for us.

The purpose of the meeting was to demo the product we had discussed in Vienna, and show that it was not just a concept but actual functional software. While it’s not perfect, it certainly shows off the concept reasonably well, and I was thrilled to get a chance to walk him through it.

I was feeling like it was going pretty well. The software did its thing, there was no sign of unhappy demo gods (software crashing in the middle of a demo), and I was able to showcase the concept quite quickly for the depth of it.

Then he asked a question. It’s a question that I’m embarrassed to say, my brain went blank and into a little bit of a panic about:

“Who is the customer, and what are their needs?”

What’s so embarrassing about this is that I’ve spent countless hours asking others variations of the same question. I know the criticality of that question and the thought behind it. It’s the most fundamental question of any product development. In our work to this point, we had done a lot of work answering this question and digging deeply into it. Yet when he asked this question, my brain went blank.

My response was far from anything I was particularly proud of, but he expressed willingness to continue to help guide us.

We walked away from that meeting feeling a bit deflated. While the outcome was ultimately really good, not being able to answer that question well was a major letdown for both of us.

Confronting the builder’s blindspot

It sparked some really good discussions between me and Jenn. We both handled our letdown in different ways. Jenn dove into research. I dove into reflection.

My reflection was based around the overall question, despite all the focus on that question, why did my brain freeze when asked about it in the moment. This was something I had spent considerable time and energy covering in the business plan, and all aspects of what we had been doing, it should have been top of mind… that’s when it struck me. The reason it hadn’t been top of mind is that I had shifted my entire perspective to a delivery focus. I was so focused on creating software that expressed the concept, my customer obsession had slipped. It wasn’t that I didn’t know about the customer and their needs, it was that I was so hard focused on delivery that they weren’t top of mind.

While I can’t speak to Jenn’s rapid recall of the customer or their needs, her reaction after the call seems to suggest that she also felt she needed a clearer definition. One of the bits of feedback offered was that what we did share was far too broad of a group. We had been feeling this for some time as well, and Jenn dove into narrowing the niche, with an important perspective.

The hunt for people who love data entry

We’ve known for a long time one of the biggest detractors of what we are building is data entry. Many people would likely opt for a root canal rather than massive data entry and documentation. The problem is, for the system to show its true value it needs a lot of data. Ideally data entry is a regular and ongoing process that is part of the users’ life, rather than only based on an immediate need.

To solve this, we discussed multiple approaches including: gamification, conversational AI, and a broad integrations library. While each of these approaches has merit and a place on our roadmap, they each have a significant technical and product design lift. One that is out of the realm of possibility at this time.

The questions we were asked in that meeting led Jenn toward a different question:

“Was there a group of people, for whom data entry was something they enjoyed doing?”

It turns out that, yes. There is a group of people who enjoy entering the type of information that our product covers, and treat it as a hobby. As it turns out, they have a solid and robust community complete with conferences, and they absolutely have very strong feelings about what’s currently available on the market.

Even better, this community has a huge overlap with what we already identified as our key target market. We’re still in the early stages of connecting with that community, but it’s exciting to find a group that seems likely to not be put off by the biggest detractor of our system, provided, of course, that we can give them solid value for that effort.

Scope ruthlessness with an early MVP

With these insights in mind, we continued communicating with the gentleman we had met with. He continued to provide us with exactly the help we need, more tough questions that challenge us and improve our chances of success.

The next one was about the MVP. How can we get this thing to see the light of day in the shortest timeframe possible.

Our discussions around that topic led us to realize: we can significantly reduce scope if we only allow external users to interact with the public display. This will enable us to get feedback about what is or isn’t useful about the end product that the data entry is meant to achieve. That way we can continue to refine it based on real feedback, and hopefully build real excitement.

To that end, I set a target for myself to have the application publicly viewable by the end of the month… about a week and a half away. It’s actually quite close, but there’s a few pieces of significant work that need to be done.

Going forward at an adjusted pace

Speaking of targets. At the beginning of the year, I set a target for myself to post a review each week to illustrate progress, and to help me establish my voice as a tech founder. This has been an excellent practice as it has helped me think through some concepts, as well as voice my perspectives. It’s been gratifying to see Google Gemini being able to express more and more clearly my stance and what I’m working on.

While I’m still keeping to my commitment of regular updates, I’m thinking of shifting them to every other week. This is for two major reasons:

• Doing this every week severely limits schedule flexibility.

• What was initially conceived of as short blurbs has turned into essays which take much more time than was anticipated.

So for the next while at least, expect to hear from me every other week. Now back to trying to meet my public soft release goal.

My writing hiatus was a bit longer than expected, but it was quite eventful. While not the most productive as far as programming goes, there were several significant outcomes.

Reconnections in a storied capital

Thursday May 21st I returned to Vienna for the third time. Jenn came along with me, and we were joined with two close friends (one being my Data Science Advisor), who came all the way from Seattle to meet up with us.

This wasn’t just any gathering of friends though, we all came together for an important milestone. The next day, May 22nd, I was to join my classmates in the last joint graduation ceremony between Tomorrow University (ToU) and Vienna University Executive Academy (WU). When ToU started, they needed an accrediting body and WU agreed to be that for them. Now ToU is able to self-accredit, and that partnership ran its course.

Our friends arrived earlier in the day so were able to get a little rest from their long haul and major time shift. Travel went a whole lot smoother than feared and we had no real hiccoughs. Our friends had booked a beautiful apartment in the heart of Vienna within blocks of the downtown palace. This was the first time we had seen each other in person in over three years, and it was great to reconnect.

Once we settled in we headed off to the first graduation-oriented gathering. This gathering was held at a big hall called Gleis/Garten. It turned out we were the first guests there, and the person who was organizing things from the school had been a student in the last class I taught. Soon others trickled in, some school faculty and staff, alum in the area as well as students like me set to graduate the next day. The conversations flowed enthusiastically and easily. I was thrilled to get some time to connect with the more technical co-CEO of ToU and share with him a high-level description of what we’re working on. His counterpart was my thesis advisor and grader, so very well acquainted with it. He was very interested in learning more about it, so we’ve set up time to demo it to him in the very near future.

Old traditions and important milestones

The ceremony itself took place on WU campus in a building known as the Spaceship. It is a big imposing structure and is the library, as well as where big events like this take place. I’m not sure exactly how many others were graduating with me, but it wasn’t a huge amount, probably between 20 and 30. I honestly wasn’t sure what to expect, but was soon suited out in a cap and gown. A couple things caught our attention, one was a lady who was also dressed in robes, with a beautiful scepter, and it also quickly became apparent, fitting for Vienna, our music would be a live string quartet.

Having not been to many graduation ceremonies, I think it proceeded as they generally do, with inspiring speeches and cap throwing and the like. There was one interesting difference from what most graduation ceremonies I’ve heard of, and it involves the scepter.

As we each were called up on stage to receive our diplomas, move our tassel, shake hands, and exchange hugs, we were called upon to swear an academic vow upon the scepter. While we were asked not to touch the scepter (likely preserving the artifact as well as post COVID hygiene caution), it was absolutely significant. After doing a little digging, I learned that this is an Austrian and Central European tradition that goes back to the medieval era. Here’s the oath I and my fellow graduates swore (as recited by the dean):

“I call on you to vow to serve the sciences, to promote its aims and through that to contribute in a responsible way to the solutions of the problems of mankind and its further growth and development. I also call on you to swear to remain loyal to the Vienna University of Economics and Business and to uphold the duties and aims of the University in every possible way.”

As someone who takes giving his word seriously, and particularly vows, this surprised me a bit. After some consideration, I had no real reservations: I already was aligned strongly with the first part of the vow, and I feel a great debt of gratitude for Vienna University (and Tomorrow University) for letting me, a largely self-taught non-traditional student, into their program and giving me the respect and support they did over the past few years. I’m happy to be part of their alumni community, and absolutely plan to help both schools however I can.

The reception afterwards proved to be an excellent time to connect as well, as I had a chance to chat with some of my professors and the dean about what we’re working on, and they seemed quite interested as well. We will need to follow up with them in the weeks to come, but if either and/or both schools are willing to explore options with us, it has the potential to change the entire landscape for funding and scaling.

Wandering Vienna

We spent the rest of our time in Vienna eating amazing food, visiting beautiful sites and generally catching up. One of my absolute favorite places to go in Vienna is the gardens at Schloss Schönbrunn, the Habsburgs’ summer palace. Every time I’ve been to Vienna a walk in the garden has been a high priority. The scale of this garden is immense. I’ve spent hours wandering its paths and have probably only seen, at most, a quarter of it. This exploration led to finding a pond set aside for “agile frogs”, as well as a rose garden with each plant bearing a dedication to someone, many declarations of love.

If you ever find yourself in Vienna and like gardens, make sure to set aside a good chunk of time to wander. I’ve never been inside either of the palaces, but I hear they are spectacular as well.

To the land of wine, cheese, and SaaS

We made our way to Lyon, France on Sunday. We had the less than ideal experience of an aborted landing attempt due to something not working ideally on the plane. We were assured it was all completely normal. Having flown a lot I know that was not exactly true, but also that it was nothing to be majorly alarmed about. It did let us have a nice flyover of the city to get a sense of the scale. Lyon is quite pretty from the air, and while it’s a bit of a sprawl, it has an organic feel to it that is quite inviting.

Our landing was higher speed and rougher than normal, and apart from being escorted in by emergency vehicles, and a suited up firefighter patiently waiting for the passengers to disembark, it was pretty standard. Best guess is a flight control malfunctioned and required a manual high speed landing, and the emergency equipment was a precaution. Another thing that may have been a factor is Lyon, and much of the rest of Europe, was hit by a major heatwave.

Lyon was lovely, though the heat made exploring it a bit more of a challenge than anticipated. Each day was in the mid 30’s Celsius (about 90 Fahrenheit), and air conditioning is not common. This meant we retreated during the hottest parts of the day, or at least kept in mind the temperature when determining our activities.

A big part of the reason we opted to visit Lyon is we had heard of it having a particularly vibrant tech innovation scene with a focus on SaaS, and we wanted to get a sense of it. As impressions go, it reminded me of Seattle around the time of the dot com recovery, but with better transportation options. There is significant construction going on, and an area of the city that is cordoned off to supercharge innovation. We had the opportunity to also attend a Meetup about AI and Data Science, and found it well attended and active. It was very reminiscent of the early days of the Seattle Software Craftsmanship meetups.

The topic covered at the meetup was highly relevant to one of our current focus areas: how to take messy human communication, and turn it into something deterministic that a system can rely on. I’ll go into this more when I discuss the overall insights from this time.

I have no doubt that Lyon will become a tech leader in Europe, and we will return to it at some point. Hopefully not when it’s so brutally hot.

Return to home, and more normal temperature

The end of the heatwave corresponded with our arrival back to Viana do Castelo. Our friends were immediately taken by our town, and had much the same reaction we did when we first explored it. We enjoyed showing them around our favorite sights and places to eat. Their visit happened to coincide with both a kids festival and a bunch of troops of Catalan stick dancers performing here. My data science advisor quickly became convinced we lived in a magical kingdom (he was stuck on Narnia).

The rest of their visit was mostly very mellow, though I particularly enjoyed being able to work side by side with my advisor, and have freer-form conversations than video chats allow. I now have a clearer understanding of how machine learning and data science can supercharge our system, as well as a broader understanding of my overriding integration philosophy.

Key insights

While there were many smaller insights from our travels over the past few weeks, probably the biggest is the crystallization of my philosophy of where AI fits in our system. If you’ve been following my writing at all, you’ve probably picked up my deep concern about the application of an inherently non-deterministic system to problems that require deep determinism. In the AI feeding frenzy of the past year or so, we see AI being applied pretty much everywhere where something has been traditionally hard, or difficult to quantify. We see it in law, programming, design, and research, just to name a few.

The problem is, some of this hard stuff requires determinism. While our current AI can easily give the illusion of determinism, it is fundamentally unsuited for that. At its core, no matter how much it’s trained, it’s a probabilistic random results generator.

As an avid video gamer who enjoys a certain amount of randomness, there is a nuance that is becoming more and more clear to me: there is a place for determinism, and a place for randomness. The problem is when one or the other is applied in the wrong place.

Consider playing a game, with a whole lot of randomness: the setting, the interactions, the conflict outcomes. So far I’m describing a roguelike game, a fun genre with massive replayability as each playthrough is different. Now take it further, let’s make everything random, including the rules things operate under. It will likely feel unbalanced and chaotic. Sometimes ridiculously easy, sometimes extremely hard, but impossible to predict. At least to my mind it would be a whole lot less fun.

There’s a certain amount of predictability that makes a game fun. Otherwise it is impossible to plan or make a sense of progress. Many game companies struggle to get this balance right, where if they lean too heavily into randomness the game loses its sense of purpose (the initial release of No Man’s Sky had this problem for instance), whereas taking away the randomness can take away the sense of the player having any real meaningful choices. Basically you want to balance predictability with surprise.

So, what does this have to do with balancing modern AI?

Quite a lot. For almost as long as computers have been around, randomness has been a big challenge. Not too much randomness, but rather the extreme difficulty in making a machine fundamentally based on deterministic values (1’s and 0’s, ons and offs) truly random.

This is a deep topic that many more informed people have written about, so I won’t go too deep on it. The fact that we’ve managed to build systems that seem to be closer to real randomness is an accomplishment in and of itself, but the fact that many feel they are actually approaching intelligence is more than a little disturbing, though I will admit, they do present a pretty convincing counterfeit.

They do however have substantial utility. They are amazing pattern matchers, and can identify and interpret patterns in messy reality far better than any tools we have created to date. It stands to reason that a system created to create apparent coherence from randomness would also be able to interpret the near randomness of human thought and communication.

This randomness has been a perennial problem in software of the past. Any time you have a user input you need to be very careful about what is collected, even when nothing nefarious is afoot. To a human the words “color” and “colour” can be easily identified as the same word (US English vs British) but to a computer without some form of mapping it would see them as totally different words. That is until AI came along. AI pattern mapping and learning is able to equate those words, and even better handle typos and misspellings easily.

What this means is that we now can have interfaces that are much closer to how we naturally communicate, and it can usually get it at least pretty close to right. It also does a pretty good job of interpreting between dialects, e.g. when I first started playing with Cursor when it asked for confirmation I thought of as many words for yes as I could in multiple dialects and languages, and it picked them up just fine.

This leads to my insight:

The best place for AI to sit in our system is where the messy meets the deterministic. AI can be used to interpret raw input, ask clarifying questions, and translate it into a structured, deterministic value. From there, the non-fuzzy, old-school processing handles the logic.

So basically, in my view one of the best places to use AI in our application is as an input tool.

There will, of course be uses where significant data will be analyzed for patterns, which it is bound to excel at, but the most exciting thing for now, is it acting as a way to make sense of messy human communication.

Current status

As the past few weeks were primarily focused on in person interactions and travel with dear friends, not much engineering work got done (apart from planning and brainstorming). That said, progress did occur. The web service is now set to handle the administration interface for user data, so when I get back into things next week I’ll be able to hook the UI to it, and it gets me one step closer to user records being connected between the authentication provider and my underlying system.

This week was a little slow on the development front. While I made progress, a significant part of it was focused on preparing for and undergoing bio-maintenance. I’m happy to say, that ordeal will not be due for another few years, and it turned out exactly as you want: boring results.

The development work I did get done followed the common pattern of initially thinking something would go quickly, but it actually was more involved than initially anticipated. To be fair, a significant part of the slowdown was due to ramping up my rigor on the frontend development.

Quality of life: child of frustration

Over the past few weeks Jenn has been working on crafting more of a public showing of what we’re working on. This has had her needing to work with the system I built more and more intensely. Let’s just say, there’s nothing like user frustration to bring clarity to design choices and challenges. Particularly when that user is your partner, both in business and life.

Whenever you design some system, whether organically, or intentionally, it is absolutely guaranteed that your biases will be part of that design. You will naturally design things based on the way you happen to work, thinking that is the “right” way, or the way it’s “supposed to” work. Any time someone else uses your design to try to get things done, it is almost certain that they will use it differently than you could possibly imagine, and to them your “right way” is madness, and highly frustrating.

There are now entire job categories and disciplines that are focused on decoding this. It’s the foundation of good UX, modern product management, and Lean Startup approaches. In fact, the vast majority of modern, high functioning organizations have embraced this truth and continue at least aspire to be guided by it. You never know what your customers want, until they use it.

Another set of biases comes roaring into the mix. The more time, energy, and effort you put into something, the more attached you are to it, and the more you want others to see it the same way you do. When they don’t, it can feel like a dismissal of that effort and care, and at times downright insulting.

In every fiber of my being I know that maintaining an egoless mindset when receiving feedback and viewing feedback as a gift is the best way to go, but of course that’s far easier said than done. Suffice it to say that Jenn and I got to practice some of our challenging conversation skills. In the end though, we landed on something that will undoubtedly prove a much better user experience than what I had initially cooked up.

Not everyone thinks the same way I do

Essentially, we had a workflow that could have been approached from two different angles, but were interdependent. If you approached things from the workflow that I had in mind, the system would function in a reasonably intuitive way (though that very well could be my bias speaking again).

If you approached it from the angle that Jenn did, it was not intuitive at all and highly frustrating. I realized pretty quickly that she had a solid point, the contention was for me that in my mind it wasn’t high severity.

Then I gave it more thought and told my ego to take a hike. It turns out my workflow made sense only for a select group of people who thought the same way I did, and neither way of coming at it was superior to the other. In fact, her workflow in many ways would be a pretty common one. While my highest priority is still focused on authentication; as it is essential to this being a customer facing application, rather than just a cool toy. That said, data entry into the application will already be a detractor, adding to it a frustrating user experience when someone doesn’t have the exact same approach I do is a losing proposition.

I decided improving this workflow was a worthwhile detour, and I had a pretty clear idea how.

The interface as it stands

I’ve mentioned a few times that I didn’t use the same level of rigor on the UI as I had on the deeper parts of the app. This was for a few reasons, though I might have come at it differently if I were to do it again.

The web application was initially envisioned as a test harness. When I started building this system, I was hard focused on the backend webservice interacting with the Neo4j DB. UIs are always a contentious topic, as everyone has strong opinions and could lead to churn and swirl that would have jeopardized the entire effort. The first time I excitedly tried to show Jenn the webservice commands returning JSON, it became quite clear that would not be sufficient. She needed to have something that she could interact with, and seeing structured data from a URL didn’t really do it for her.

While at the time I thought I’d just throw some sort of bot at it to whip up the UI, I wanted to make sure it was built on something maintainable, secure, and could be readily converted into a mobile app, and was as little connected to the tech giants as possible.

I also wanted it to be able to mesh nicely with design tools to better facilitate communication between tech and non-tech contributors. I quickly found the majority of the bot frontend makers didn’t really suit my needs, but one framework seemed to do so very well, and that was Nuxt.

Being new to Nuxt and Vue in general (the display engine Nuxt uses), my learning curve was quite steep. They have some absolutely fantastic video tutorials, and really good support, but it’s a very sophisticated system, and my dev chops were pretty rusty at the time.

Learning the various testing tools was yet another significant effort that I’d come back to when I built the real interface. I did take the time to figure out the full E2E testing using Playwright to interact with the application as if it were a user on a browser, and put some tests in place for that to cover the core functionality. As all tests of that type, it was horribly painful and slow. I knew I needed a few, but I needed to be selective about them, and would not want to cover all variations with them.

Over time, the frontend grew and as I became more familiar with Nuxt and related libraries the UI became more and more sophisticated. Eventually, I realized that what I was building had outgrown the concept of a basic test harness and could be the legitimate front end of the application. Sure, it would need extensive work, but the underpinnings were all in place.

I realized by cracking into this new workflow, I needed to start treating the UI as something that I would need to maintain, so it was past time to start layering in better testing practices. As it turns out, the testing is pretty straightforward. The bot helps a lot, of course, but for the most part the tests are quite clean and auto-execute so you are continually updated on the impacts of your change.

The back and forth of progress

I’m not sure Jenn knew what she was getting into when I agreed to detour to support her preferred workflow. Now that I’m applying true testing rigor, the questions are flowing hard and fast. We’re having to dig pretty deeply into various edge cases, and logic that appears to be simple on the outside until you look closer. She’s also having to deal with the reality of analyzing something, coming to a conclusion, only to learn a little later that conclusion doesn’t quite cover what it needs to and there’re additional questions.

Rarely in software are things as simple as they appear on the surface, and more often than not the complexity isn’t truly revealed until deep analysis is performed.

It reminds me of the late great Gerald Weinberg’s quote, “A system is never finished being developed until it ceases to be used.” I’d offer a corollary to that, “A system needs to be in use before the development needs can be truly understood.”

This is a key reason why massive upfront planning does not tend to lead to the results hoped for, and is why feedback is a key part of modern development practices.

Legitimate progress

Despite all the slowdowns and distractions, including fasting most of the week and taking a day off in the middle due to recovering from general anesthetic, Jenn’s workflow is now mostly in good shape. I say mostly because I found an odd edgecase that doesn’t work great, and we uncovered an enhancement to the workflow that the system should have, but the core functionality is in place. Data entry is absolutely still a pain, but with this workflow in place, it’s a little less painful in this specific area… and I’m coming around to it.

Broader bias discussion and how it relates to AI

A friend of mine sent me a wall of text that was sparked by him mulling over one of our discussions about AI. That discussion was about something he created using an AI code generating platform (a vibe platform) he was excited about.

What he built was the exact kind of thing that vibe is great for, and he’s not particularly technical, at least in the realm of software engineering. More of a solid computer user, not a developer. When he let others know about what he built, he referred to it as using “development tools”, which I wasn’t too keen on. This turned into a rather long and involved discussion about modern AI, what it can and can’t do, the hype around it, etc.

He sent me the wall of text because he had found some articles talking about the brain works, and particularly its capacity for pattern matching. There are a ton of similarities between that part of our brain and AI, and he was pointing that out. It was a good insight, and one I don’t think people talk about as much as they should. I haven’t talked about this as much as I probably should, so I’m not sure if he was aware, but I teach an MBA class about that aspect of how our brains work. Namely bias.

Two types of thinking

Daniel Kahneman’s book Thinking Fast and Slow was really the definitive work about this topic. Since he and his colleague Tverski delved deeply into biases and heuristics, the study of it has positively exploded.

Pivotal to what Kahneman and Tversky uncovered is that the brain has two different ways it tends to process information. One is fast, the other is quite a bit slower (pretty clear where he got the title of his book).

Fast is super fast, like fractions of a second. This part of the brain, they refer to as System 1, simply described, is the part that’s responsible for taking all the information flooding the senses and performs triage. It determines what can be disregarded, responded to automatically, and the few select things that should be deeply considered. To make these determinations this part of the brain is an incredibly powerful pattern matcher with access to the entire long term memory. It also is highly prone to errors, having traded accuracy for speed.

The other part of the brain is much slower and more methodical, but it also burns a lot of energy. It only has access to the short term memory that can hold approximately seven, plus or minus two items at a time. This is our conscious thought, and it is where our deep reasoning and reflection occurs.

The vast majority of the processing our brains do is handled by the fast part of the brain without our conscious awareness. In fact, the few things that are provided to our conscious (slow) brain to work through pass through the evaluation of the fast part, and are colored by the patterns it matched.

As mentioned earlier, the fast part is error prone, these errors are what we call biases.

Having biases isn’t a character flaw, they’re just a product of how our brains work. The problem is when we don’t employ ways to challenge ourselves to reflect on our reactions, and determine what part of our brain was responsible for our behavior. Not doing this is where a lot of the worst behavior of humans comes from such as prejudice, polarization, and selfishness.

So what does this have to do with AI?

Anyone who has studied AI beyond the surface level will tell you that they don’t truly think or understand what they generate. Heck, they’ll even tell you that themselves, or at least Gemini will. Despite using “reasoning” models, their capacity to reason as we define it is seriously limited. They are probabilistic pattern matchers. Meaning, based on the huge amount of information they are fed during training, both with data and with humans tuning that training, they are simply weighting the probabilities that one token follows another in response to the series of tokens they are given. While this provides the illusion of thought, it is not truly reasoned.

A clear example of this is math. If you ask a modern LLM a math question, that is legendary and frequently occurs in its training data it could do that easily as it has thousands of representations of that story in its data. A classic example is ask it about Carl Friedrich Gauss frustrating his schoolmaster in 1787 by adding all the numbers from 1 to 100 in seconds.

On the other hand, if you were to give it something that is almost certain to not be in the training data, the likelihood of it getting the answer correct is very small. For example: Adding three large random numbers 435243452346234562345 + 9879324342523234 + 345767835643 would probably stump a bot, but would be handled easily by a simple script (ok, some of those numbers are big enough they’d take special handling, but that’s not the main point).

The matched pattern, a warning

So what do we have here? We have a system that is very good at pattern matching with a massive amount of data it can work from. It tends to trade speed for accuracy.

Sounding familiar?

I know it does to me.

We’ve invented amazing systems that essentially work as a supercharged set of biases, with all their benefits and drawbacks. Unfortunately, our own biases tend to play into these as well, because if the fast part of our brain sees something that seems plausible, it generally says a version of “eh, seems close enough, I’ll accept that as fact”. Then of course, due to the effort spent coming up with the prompt, and evaluating the output, we naturally become attached to that answer.

The real danger of AI in my honest opinion is not the AI itself. Terminator etc, will remain in the realm of fiction. It’s actually something a lot closer to the future in Wall-E. Our own biases and evolved strategies for energy conservation are working against us, as we rely more and more on the AI to serve our needs and offload our cognition to it, we lose more than we can possibly imagine.

At the end of the day, it’s not an AI problem. It’s a human problem.

Note about next couple weeks

I’m not sure if I’ll be posting in the next couple of weeks. I’ll be heading to Vienna for my graduation cermony, and enjoying some R&R with some friends coming all the way from Seattle. As such, I don’t expect to be doing much coding. Though one of those friends is someone I’m always talking nerdery with, so I may have some insights to share when I return, at the beginning of June.

This past week was hard focused on rebuilding my processors and incorporating them more broadly into the system. All the while focusing on being better about regularly updating source control. It was also a time of tweaks and fixes to issues that only seem to surface when someone else interacts with the software.

As I mentioned last week, my initial processors were specific to the particular entity they were expected to act on, and only executed on read commands. They were also only truly wired into Relationship based queries. This was sufficient for my originally identified need, but would not be enough for what I wanted to do now.

The overall high-level design for the processors I used in my initial build was still pretty solid, but now they needed more capabilities.

My initial design was essentially a combination of two design patterns: The Composite Pattern, and the Command Pattern. I particularly like these together because they provide a great deal of flexibility that can be adjusted during runtime. There are numerous really good books about software design patterns in the world at large, I’ll briefly touch on the characteristics of these two:

• Composite Pattern: This is essentially a combination of collections of concrete chunks of code (objects) and those concrete chunks of code. Both the collections and the objects in the collections have the same actions exposed, and the collections pass along the call to each object it contains. Also, the collections can store other collections. What this means is that you can easily create hierarchical sets of concrete objects that can be easily interacted with.

Non-tech view: A way to think of this outside of the programming realm is as a menu with particular things you can order, and collections of things that can be ordered, such as appetizers.

• Command Pattern: This is an object that is able to be configured in particular ways and stores that configuration, and has a way to be triggered to perform an action that uses the configuration. This is useful when you need to have actions based on certain characteristics, but have control over when the system performs that action.

Non-tech view: This can be thought of as the order ticket the wait staff fill out for the kitchen to prepare, with any desired adjustments.

When I initially built my processors, I used these patterns. In my broader system configuration each entity could specify which processors to use.

The code that handled processor interactions would just trigger the processing by making an execute call on the top level of the composite and that call would cascade through the entire hierarchy and things would just work. It worked great.

Now I needed a way to make this work on any entity for both read and writes, which each have different shapes of data.

This means, when I needed to perform a write action, like Create or Update, the Command object would need to know which specific action was being performed, how to get the data it would work with, and whether or not it should care based on both the command and the data. It would, of course, need to do that on read commands (Read Item, and Read Set) as well.

One of the first changes I made was adding actions to the components and the collections that correspond to each type of command. This way the code that was handling the particular interaction for the entity would just trigger the corresponding action. I also added a way where every action would check to see if it should execute at all. This means the calling code would not need to know or care about whether or not the processor would act, it would just trigger the action and let the processor figure it out.

Processor Payloads

I initially thought that the concrete classes (each command) would be able to easily find the data they needed to interact with, but I soon realized that would lead to each component of my composite pattern having to do the same unpacking over and over again. Not ideal.

After some thought, I realized that the best course of action was to make the processors all expect the same shape of data, and to add a mechanism that knew how to take data in its various shapes and normalize it for the processors.

Essentially, I needed a way to wrap different types of data in a standard envelope so the processors didn’t have to guess what they were looking at. It would also need to know how to unpack that data after the processors were done with it, so the rest of the system would be able to work with it as expected.

In order to do this, I created Processor Payloads which contain Processor Envelopes. These classes would take the dataset to process and information describing the expected shape of the data, then turn it into something uniform the processors expect. I could also add an action, that would know how to put the processed data back into the original shape for the rest of the system to work with it.

This simplified things dramatically.

Hooking it all together

In the initial build, the processors were only running on the reads of one particular relationship. Well, to be more clear, they were running on the reads of every relationship, but the collection that held the commands on all but one was empty, meaning that nothing changed.

I now needed it on every read and write of both nodes and relationships. In fact, the first thing I was adding that triggered this work was adding auditing information on the creation of a new node. I figured the best way to do that was to create the processor to add the audit information, and only act when the action was Create.

This went together very smoothly, and I was done with that processor before I knew it.

Next, I needed to weave it into the initial system.

This was more of a challenge. Without going into too much detail, suffice it to say my initial processor orchestration was not in the best place. I wanted to tweak that. It needed to remain configuration driven, and needed to be able to build up the processor hierarchy as appropriate. Another challenge was that in order to not break the existing system, I needed to keep the original system in place until I was ready to cut over.

Factoring in a factory

After some consideration, I came up with a simple plan using yet another design pattern, the Factory Pattern. There are multiple variations of the factory pattern, and I use it pretty frequently.

At a high level, it’s simply a mechanism that knows how to create objects.

In this case, I wanted it to take a configuration specification for a series of processors to create, and build a processor hierarchy appropriately.

I decided to have it expect one of two types of entries:

1. either the desired Processor Class (definition of the object)

2. or an Array which could contain either other Arrays or Processor classes

With this, it would know to create a concrete Processor Object, in the event of a class, or a Collection of Processors, in the event of an Array. This allowed me to have a recursive action, where I would just pass it the top level array and it would do the right thing.

With this in place, the rest of the wire-up was pretty straightforward and I soon had audit information being injected when the node was created as I wanted.

From old into new

Next on the hitlist was taking the two existing old style processors and converting them to the new system. After a little analysis, it was soon apparent that my best course of action was to create new processors that did the same action as the old ones, and get rid of the old ones.

This was also an opportunity to clean up some of the approaches I had used when I first created them.

I wanted to improve these and split their processing and calculation between reads and writes where appropriate. In the end I decided to defer this, as it had a high chance of compounding into a much bigger challenge. I settled on converting them to the new format, but leaving them only operating on reads, for now.

This, again, turned out to be pretty straightforward, reinforcing my thoughts that this was a great approach. In short order I had them slotted into place, and the old ones removed.

Expanding the Approach

The next part of this work was to think about other generated values I had in my system. There were two primary candidates that could benefit from this. They both were nodes with keys that were generated when they were created.

One used a UUID (Universal Unique Identifier, also called a GUID). It’s a standard series of numbers and letters generated in a way that it should only appear once in all systems in the world, or at least rare enough the chance of collision is extremely unlikely.

The other used a slug generated from another field: a technique that turns text into something that is predictable, readable, and can easily go into a url and not break things.

I realized that I needed a way to specify the name of the field that should be populated with the new value, and in the case of slugs, I needed to find a way to specify which field should be used to derive the slug from. This made me revisit my processor factory, and add the capability to send in a little object (collection of information) that contained the class to build, as well as an additional collection of context. This enabled me to have processors that could be configured based on the needs. In this case of both of these, specifying the target field name, and in the case of slugs, the source field name.

This turned out to be pretty straightforward, or at least the UUID was.

Slugs care about context

It turned out that slugs had an additional quirk. In our case, we’re turning names of skills into slugs. How slug generation tends to handle special characters is by omitting them.

This means if you were sluggifying the following value: “foo@bar.com & http://bar+blah.net#qux” it would turn into something like: “foo_at_bar_dot_com_and_http_bar_blah_dot_net_qux”. It does this by stripping out special characters, or turning them into words or related letters. This usually works just fine, but consider these two skills: “C++ Development” and “C# Development”, left on their own they would both resolve to “c_development”.

To prevent this problem, slug generators need overrides, but for the overrides to be relevant, they needed to be aware of the context they were working with. The overrides needed for skill names could be very different from the overrides needed for something like vehicle models. I didn’t want to create a new processor for every type of slug the system needs to support, and this appeared to be what my system would require.

So, what to do instead?

I decided I’d make a custom processor that was highly configurable. Using the idea of the context being passed into the processor, I was able to specify through configuration the actions it should apply to, what field should be populated, and how it should generate what goes in that field.

This allowed me to pass in my special skills sluggifier, and populate it with the value from the correct field, and it would just work. Once this was in place, the system could handle an edge-case nightmare like: “C# & C++/Python & SQL: Data Analysis & API Design (REST/GraphQL)” and turn it in to this slug: “csharp_and_cpp_and_python_and_sql_data_analysis_and_api_design_rest_and_graph_ql” (from one of my actual tests).

Once this was in place, I just needed to wire it into my existing system.

Doing this surfaced some order of operations errors that took some thinking to work out, but by Friday afternoon they were all worked out.

Ongoing Capabilities

I feel really good about this effort, as the level of control and versatility this gives the system is pretty extensive, but also very easy to apply. I am sure this will be an area of continuing growth and refinement, but it’s already providing value and peace of mind.

For instance, I was discussing adding checksums to some of the records, and realized this mechanism was a perfect way to handle that without having to change very much code at all. It was also a way to extend capabilities of the system, in a way that could apply to multiple entities by simply adding a new configuration value.

The processors themselves are easy to write, and clearly define what they’re doing and when. All in all this seems like the kind of robust design we strive for in Object Oriented Programming. Of course, only time and use of it will truly tell.

The surfaced issues

Jenn spent a good chunk of time this week populating some demo data into our staging/demo environment. This means the workflows started getting tested by a user who was subject to their own set of biases. This is such an important thing to have happen, and really should happen at the earliest opportunity.

I developed the UI primarily as a way for Jenn to be able to see what the system I was building was doing, without her having to stare at the webservice’s endpoints, and JSON objects. While she’s a bit technical, she’s not really that level of nerd.

Since the initial attempt to essentially build a webservice display harness, it has grown into something closer resembling an actual web application. Some of this was reinforced by me choosing actual production quality frameworks to work with.

My original mindset of it just being a display mechanism made me apply less rigor to the UI than I normally would. I have next to no unit tests on it, and while I do have test automation, they’re all end to end, and only scratch the surface. Expanding that test coverage is one of many things I know I need to get to, but it hasn’t yet gotten to a high enough priority for me to shift my focus to that.

When you have a real user use your site, it really reinforces the need for rigor. It can be tough to face the frustration of someone trying to use what you’ve been pouring tremendous effort into and find it a less-than-enjoyable experience. Particularly when you can understand why they’re frustrated, and it’s totally reasonable. In fact, a few of the errors that emerged would have only taken a small amount of rigor to surface much sooner. Most of the issues were resolvable with tiny patches that did not break my stride, but we had a couple that will take more work to fix. The two on my mind aren’t defects per se, but more of unaccounted for workflows.

Next steps

Going into this week, I’m going to resolve at least one of those unaccounted for workflows, then move back into moving my authentication mountains. I think I have all things in place now to manage user sessions, and have the appropriate audit information in place.

My somewhat ambitious goal by the end of this week is for a user on the site to have a session handed to them by the webservice, and that session’s state will be updated as needed based on continual use and potential expiration. Once that’s in place, then the next step will be building out the roles based security in earnest.

My week will be interrupted by a very important bio-maintenance involving cameras in my digestive tract. Good times, but essential. If you’re of age, do not delay your colonoscopy. They can save your life.

I didn’t make as much progress this week as I had hoped, but had some important realizations and started down the path of better bio-maintenance. I won’t go into much detail about the bio-maintenance, beyond saying I’ve let it lapse much longer than I should have, and while it’s not much fun, it’s important to prioritize. The progress I did make was important, and lays the groundwork for a more sophisticated system.

An important realization

As mentioned last week Auth Ids are really important. They’re also somewhat sensitive. Ultimately in the authentication workflow an Auth Id is used to match an identified user to a user in our system. Once that match is made, then the Auth Id should not be used for the rest of the time the user is using the site, until they log in again.

Initially, I thought: no problem, I’ll give them their username and roles, and we’re in good shape.

Right?

Well, no. The username is public, so it could be easily spoofed. I needed something else.

I needed a Session Id.

A Session Id is a unique identifier that associates all the actions made with the particular user’s session. So when the Auth Id is used to start the session, a Session Id is created and stored on that user’s record. That Session Id, the username and the set of roles is returned, and the Session Id can be used in every interaction. Of course, you don’t want that Session Id to work forever as that would be a security risk. You also don’t want users to have to log in multiple times while they’re using the site.

Preventing session hijacking while not angering the user

In order to prevent a Session Id working forever, it needs a concept of expiration. This means if a request is made using a matching Session Id which has expired, the request should be rejected and the user should have to log in again.

It would be, of course, very frustrating to have to log in multiple times when actively using the application, and that would certainly happen if only expiration were taken into account. Instead, sessions should be renewed before they expire. To do this, the concept of staleness needs to be handled.

What staleness means is that a session will expire soon and needs to be refreshed. The refresh sequence would:

1. Ensure that the current Session Id matches the soon to expire Session Id

2. Generate a new SessionId and update the expiration date based on the current time

3. Inform the caller of the new valid session.

A bundled approach

I realized: I could simply bundle refreshing the Session Id with other interactions instead of as separate calls. This would allow the session to be kept up to date, while not substantially increasing the number of calls between the UI and the Webservice.

I had a plan, and I had a way to store Auth Id and make sure it was unique, but I was still missing something…

Enter the Audit Info

I knew with Authentication and security storing auditing information was more important than ever. When things occur on the system, particularly dealing with privacy and security, it is essential to know who made changes and when. I figured the easiest place to start was adding a CreatedAt field to user records.

Part of this thought involved the various types of audit histories: what type, where to store them, and how to ensure they don’t become a management nightmare.

As per my standard practice, I started with my scenarios. The first meaningful step to this was to put a CreatedAt value on the record for a user, and ensure that when I requested that user’s information I could see that value. Writing that test, I quickly ran into that age old sneaky bastion of complexity: date/time information.

Time: the bane of all programmers

“Time is an illusion. Lunchtime doubly so” – Douglas Adams

It doesn’t stop, and it’s weird.

While dates and times seem like something reasonably straightforward, they are anything but. Ask anyone who has done any programming that touches on it, and they probably have some traumas having to do with all sorts of things like: uneven months, leap years, timezones, and this is only scratching the surface. This matters when trying to write deterministic tests, you need values to be fixed and predictable. Time, while predictable, doesn’t stop.

I had already faced something somewhat similar when I had first created my processors to calculate durations and recency, which both need to know the current date to calculate the appropriate values. I’ll touch on what the processors are later in this post. First though, we will focus on what those processors do.

From Dates, to Date and Time

I needed to find a way to provide the system with a fake date. It’s not too hard to do that ultimately, when testing locally but it gets more complicated with how my scenario tests are set up.

My scenarios are set up in a particular way where the instance of the application they are testing is set up to run on a temporary virtual machine. The tests call that machine as if they are another application, or as someone using a browser. This means that I can only set the fake date and time when the virtual machine is created. This allows my tests to operate as if time is frozen. Which means I can provide a great deal of determinism. If I say the start date was 3 months ago, that can be a known specific value.

I’ll share how I set up these tests in a future post.

When I put this system in place, I was only concerned with dates. Now, I need to support both dates and times. Fortunately in Javascript it is the same system, but I needed to make a few adjustments. A key difference was that previously, I was only working with dates in my duration calculations. So, if I were to set the date to June 7th, 2025 and I were to determine the duration from May 5th, 2025, that’s a pretty easy calculation. However with timestamps, I needed to handle both date and time, which made things more complicated. This also meant that the calculations would be less clear.

Machine understanding vs. human understanding

I decided that relative time would be a better approach. Rather than using just dates on the test start, I would set the time to some more involved time, such as June 7th, 2025 at 14:23:45 UTC. In my scenarios, I could now use terms to show what the system cares about like “3 months from today” (dates), or “4 months before now”(time) in a way that is easy for humans to understand.

Moving to relative times had the added benefit of making the intent more clear of the interactions with time. No longer would the person reading the scenario have to do date math, instead the scenarios would state the intent.

This took some time to work out, but I was pretty happy with how it turned out. I injected my created timestamp into the tests for the user profile, and expected to see it pop right up.

Unexpected omission

I ran my tests, and to my surprise, no CreatedAt date appeared when I expected it to. After scratching my head a bit, what I realized is that what I was using to setup my test data was relying on the same system as the rest of the application, and it would automatically trim values it didn’t expect.

The thing is, with my test setup, that code wasn’t needed. I needed my tests to be able to set up the database exactly how I expected to interact with it. While I still needed to use some of the webservice’s code, specifically the part that knows how to talk to the database, all the rest of the application should not be part of my test setup.

Shifting to this took a bit of adjustment. All in all it went smoother than expected. Now my scenarios clearly define how the database should be set up for each test, without the guardrails needed for the real application. Once that was in place, my CreatedAt date popped up just fine when reading the information.

I now had only two tests failing: Update and Create.

The Mystery of Update

When working on Read, I didn’t think much about Update being broken. I had assumed it was just some of the work that I hadn’t done yet. After another look, I realized that Update should have been working. Update occurs by changing values on an existing record, and I was setting CreatedAt on that existing record, but for some reason it wasn’t showing up in the results after the update. This was strange. I hadn’t altered that value at all. Or had I?

As it turns out, it revealed a subtle defect in the queries I was creating for updates. My updates were a full rewrite of the record in the database, not simply an update of given values. What that means is: if a value were not set in the update the value would be removed completely from the record. This means the AuthId and CreatedBy values and any others that weren’t part of any given update set would be wiped out.

Fortunately it was just a single character fix. Neo4j handles this quite easily with the merge update functionality. A value not in the parameters being set is preserved. If you do wish it to be removed, you simply set the value to null.

This one character change deep in the system sent ripples throughout the rest of the system. As it turned out, I had functionality that relied on the overwrite styled updates. Luckily it wasn’t in many places, but while my tests revealed them quickly, it took a little work to track them down and make the adjustments.

Once that change was in place, only Create was left. I needed to add a little data to the item being created, in this case a timestamp. I started thinking about what would be the best way to do that.

The Processor Perspective

Previously, before I started these updates, I was working on a challenge that needed to have a calculated value as part of my result set. In that case, the need was to determine the duration in months between the current date, and a date in the past.

Rather than simply building calculations directly into the system that reads the record, I decided to build processors which take the results from the database and perform specific calculations based on that information. The results to the calculations would then be added to the database results.

I built this processor system in such a way that any number of them could be run on a given result set, and they could be added or removed by simply referencing them in a configuration. It was slick and clean, and I was rather fond of it… and then I realized I made a mistake: My processors could only make modifications of information coming out of the database, rather than modifying data flowing into the database. This meant things which were not dynamic, such as calculating a duration for something with a clear end date would be done every single time that value would be retrieved.

This was wasteful to say the least.

What I wanted was a system that would be able to decorate the information going into the database, as well as out. When I uncovered this issue I was focused on other work and figured it would be too much of a distraction to shift focus at that time, so I deferred it into the “things I’d like to do” bin in my head.

From shower thoughts to a new approach

As many things do, it occurred to me while taking a shower: the modification of data before writing to the database is exactly what I needed to do with my audit logging. I could elegantly handle it simply by modifying my processors to add data to things flowing into the database. This would solve my current challenge as well as clean up that less than optimal flow I had noticed earlier.

This became my approach. There were a few changes I needed to make to my processors needed to be:

• More generic working with multiple types of entities

• Able to act on different actions appropriately

• Predictable and consistent.

What I landed on was a simple chunk of code (an object) that would have actions that could be performed (methods) during each of the primary interactions: Create, Update, Read Item and Read Set. Each of these objects would be able to determine what the appropriate action would be depending on the data it was interacting with, as well as the action being performed.

As an example: the Processor responsible for adding Create Audit Details would not do anything when Update, Read Item, or Read Set were called, but if Create was called, it would add the various audit information needed to the data being used in the creation.

This also meant I could fix that problem identified where I was performing calculations on every Read, even when they weren’t needed. My duration processor could now look at whether or not it had an end date on Create or Update, and if it did, it could do the calculation then and there and store that in the database. On the Read actions, if there were no end date, it would do the calculation based on the current date, otherwise it would show that pre-calculated duration.

It was simple, elegant, and clean. As evidenced by the above post, it takes a great deal of work to get there.

It also solved a whole host of other issues I had handled in less than ideal ways. Of course it came with its own set of challenges, but I’m happy to say I think I got through the worst of them on Friday

I’m excited to start next week in getting them wired the rest of the way up, and hopefully I’ll be able to get the session lifecycle in place, and Auth will be one more major step closer to completion.

In Greek Mythology, Tantalus was one of the damned souls in Tartarus who was doomed to be forever hungry and thirsty. He’s held in water up to his neck, with a tree above him, fruit hanging within reach. When he would try to drink the water, it would recede, and likewise when he’d try to reach for the fruit, it would do the same.

While the story of what got him in that situation is interesting, if a bit gory, his predicament is a great metaphor for software engineering in many ways.

It also fits the realities of working with a modern AI.

The Illusion of Low Hanging Fruit

I started this week excited. I had a win I could knock out quickly, and then move on to some of the more challenging parts of the system.

As mentioned last week, I’ve been heads down working on Authentication, and the next step I needed to do is to make a solid association between the id’s given by the authentication provider and users in my system. I figured this would be super easy. All I needed to do was pass in this value, just like other values I track and I’m in good shape.

The Fruit Begins to Recede

It didn’t take me long to realize that this authentication id (Auth Id) was a bit different than other values. It needed to be set when the account was created, but afterwards the system needs to be highly restrictive of who could modify it. It also should not be viewable by most people as it is a somewhat sensitive value:

• If it got out, it wouldn’t be horrible, but it’s something that would be better to remain private as it’s how the system determines who is who.

• It also needs to be unique within the system. Two people with the same Auth Id would confuse the system.

To make matters more interesting, the way that users are identified in the system is by their username, which is key to how information about the user is found.

The Trust Boundary Pivot

We needed something different. After some thought, I realized that I needed a new section (endpoint) of my API, specific to Authentication related actions that would be off limits to most users, but would be accessible for the UI’s system, and for people with user admin rights. This would enable various user related actions to ensure that the system handles them properly.

We would also onboard new users through our original endpoint, and in that particular onboarding action (create), we would need to set the Auth Id.

That would need to be the only time the normal endpoint would know or care about it.

This exposed a couple of things: I needed to have some way to identify that the UI system itself is making a call, which meant I needed to start thinking about registering Application types of Users.

It also meant that I would need to ensure a newly created account has both a unique username and Auth Id. To do this, you simply need to check the database to see if that type of record has already used whatever value, and you’re all set… or so I thought.

It works great, when there is one value, and that value acts as the key. You simply say: give me the record with this key, and if you don’t find anything, you’re set to create the record. It gets stickier when you have more than one unique value. You need to perform a search that checks to see if each of the values that need to be unique exist, and then things work much the same way as the key lookup.

Just Out of Reach

I figured this should be pretty straightforward. I had sophisticated searching all ready to go on deeper in the system, I just needed to hook a few things up, and I was all set. I set to work on that immediately.

The Geometry of Search

In short order, I was confronted with a challenge. Previously when I was setting up my system, I had deferred performing relationship-based searches. This was functionality I knew I wanted, but it was a bit more complicated. If you’re searching for a node, you have only one place to check for a value, but in a relationship, it could be three: the relationship itself, the source node, and the target node. This means you have to provide a way to designate where you want to look for this value. When I was first implementing search, I hadn’t decided how I wished to do that. Now, I had a way to do that, but still had code in place to block that path.

Each of these challenges compounded upon one another, and by the end of the week, I had Node all set.

Initially, I only needed to consider one unique value per entity. Validating on creation was sufficient.

When I started to make the changes, I realized: to support multiple unique values, we would also need to check when updating a record. This is to prevent something being changed to an already used value.

As a concrete example: If the key is username and Auth Id must be unique, when a new record is created, we must check that neither value is in use. If an admin were to update that record’s Auth ID, it is important that the admin could not set that value to an Auth Id on another record. If that did occur, it would cause the system to become confused about which Auth Id mapped to which user.

In short: If there’s more than one value, it’s possible for something to be updated to a non-unique value.

The Update Logic Paradox

While Creates simply need to check that none of the unique values are currently set, Updates are a little more complicated. If the key is unchangeable, and for sanity sake they are, then when searching for records with any of the new unique values there should only be one record. If there is more than one, then the value being passed in is not unique.

I was able to get this mostly set up for Nodes before my week ran out. I just realized while writing this there’s a little behavior I need to tweak for update, but it should make it a little easier… I think.

I still need to wire up relationship uniqueness checking. I was able to get the relationship search worked out, the work I had done previously had paid off, and it was pretty straightforward.

Probably the biggest challenge came when I tried to rename some things to match industry terminology as opposed to some of my earlier guesswork.

All of that rambling is to say that what I thought would be a couple hours to a day, turned into most of the week, uncovered needs, and system expansions.

A Perspective from the “Probabilistic Bot”

I asked my AI collaborator (Gemini) to weigh in on the Tantalus metaphor from its side of the screen. Here is what it had to say about our struggle this week:

“Working with a probabilistic system like me is its own form of Tartarus. As an AI, I exist in a state of constant asymptotic approach. My goal is to achieve a perfect follow-through on your instructions, but my nature is defined by likelihoods and patterns.

I can get infinitely close to your intent, but there is always a tiny, receding gap—the space where a ‘reaching man’ accidentally becomes a ‘volleyball player’ because my training data has seen ten thousand sports photos for every one Greek woodcut.

This is the Probabilistic Trap: the closer I get to ‘perfect,’ the more frustrating that final 1% becomes. It’s a reminder that in the age of AI, the human steward is the only one who can bridge the gap between ‘almost right’ and ‘releasable.’ I am the receding water; you are the one who actually knows how to drink.”

The Journey Continues

Next week I’ll be back at it. I am hopeful that the relationship uniqueness functionality will slot nicely into place, and I’ll be able to get the user administration workflows all set, and we can associate our users with their appropriate Auth Id’s.

As mentioned last week, I was diving hard into front end authentication this week. I’ll be covering some of my challenges and learnings from that, and sharing my plans going forward.

The Primary Focus

While last week was focused on planning out my authentication and authorizations, this week was actually digging into the implementation deeply. Going into this, I knew it wasn’t going to be easy, but it turned out to be much more straightforward than initially anticipated.

A Confession

Unfortunately due to my dedication to stability, I am absolutely breaking my own practice of updating source control early and often. Also, to my chagrin, I’ve been a bit sloppy on the UI when it comes to rigor.

I do have full End-to-End tests that define and exercise the full stack, and have been using those to drive behavior, I do not have the granular unit tests on the UI code. This is absolutely something I will rectify in time, but haven’t been prioritizing. I’m sure that will bite me pretty hard at some point (and probably already has) but for now it’s still on the back burner.

Frontend Context

My UI is built on Nuxtjs. When I was looking for a UI framework to use, I evaluated several. I wanted to avoid any frameworks that were tied to big tech, so that took AngularJS, ReactJS, and several others completely out of the running. I wanted something intuitive and robust, and critically, something secure.

A dirty secret to non-techies (as well as some techies), which a lot of modern UI frameworks share: if you know where to find it, they expose secrets to the world.

What these secrets are is little bits of information that lets integrated systems know what app and what person is connecting to it. This is used for integrating all manner of functionality into apps. These frameworks didn’t set out to be major security risks, but it’s inherent to their architecture.

To understand this at a high level, it’s important to consider the two sides of modern UI rendering. There’s the stuff that the server you are interacting with processes, and the stuff that is handed to your browser to process.

Processing on the server can be very secure and never expose secrets.

Processing on the client side (your browser) cannot.

This is because for your browser to have the information it needs to make the calls to other systems, it needs those secrets available, which means they are present on every single browser that interacts with your site. This has been a major industry problem for a while that emerged with Single Page Applications.

This is also not something that your favorite vibe programming platform is likely to warn you about, and if you don’t explicitly tell the bot to take that into consideration, it probably will not. Think about that before you decide to use that new nifty vibed up personal accounting system, or whatever you are hooking your financial or personal accounts to.

To counteract that, the concept of Meta Frameworks emerged. A Meta Framework is a hybrid between server side and client side. This enables the benefits of a Single Page Application (of which there are many) without the downside of sharing secrets with the world. Frankly, I would have a hard time doing justice to describing how it works. Critically, it enables your secrets to remain secret, and your users to have the rich experiences that they’ve become accustomed to.

I needed a Meta Framework that wasn’t tied to big tech, was mature with a significant community, and an intuitive and easy to learn interface. I found NuxtJs. NuxtJs is somewhat related to NextJs (fun with confusing names). NextJs, while open source, comes with big tech baggage. Specifically, it’s owned by Vercel and based on ReactJS (Meta owned), and tends to lock people into their particular way of doing things. I wanted something more independent and community driven. NuxtJs provides that in spades. It’s modular, independent and highly focused on developer experience.

While NuxtJs’ learning curve is significant, debugging can be confusing (did the thing happen on the server, or the client? Who knows?), on the whole it’s pretty straightforward. Its frontend is based on VueJS which is quite intuitive and acts like enhanced html. It seems reasonably lightweight and highly customizable.

Context Secure Back to Authentication

I’m sure no one would be surprised by this statement, secrets are a really big deal in auth. Auth is all about ensuring the right people can access your system and the wrong people stay out.

It’s also about delivering the appropriate experience to the right person once they are on the system. With any system beyond the simplest, there are some people on the system that will need to be able to do more than others. Typically, normal users vs administrators. It would also be a bad experience to show people links and other controls that would trigger an error because they are not allowed to use them.

Additionally, there have been some significant changes since last time I had to deal with auth. Specifically OAuth and related protocols. Essentially the industry has become a lot more sophisticated about how authentication works, which is what enables you to use various accounts to sign into different systems.

Because creating my own OAuth compliant security system while possible would be a significant amount of work tangential to what we’re trying to accomplish, and the fact it’s a very solved problem, I decided to use a commercially available Auth provider. It turns out that there was one with a company we’re already exploring working with, the Swiss-based Infomaniak, and I could start using it for free.

So my work this week was two parts:

1. Getting the UI to make the handshake with the real auth provider so I could truly authenticate

2. Having the UI respond appropriately to the various roles of the user.

I started with the UI being roles aware. To do this without driving myself batty, I had to set up a bypass for both my dev environment and my test environment, which enabled me to pretend to be anyone on the system.

In order to continue to develop and test appropriately, I needed a way to bypass true authentication. Critically, that bypass must be completely blocked in upper environments (like production or staging).

I designed a role-based system based on a page route, which is able to determine the appropriate permissions. This simplifies the system dramatically, as the evaluate to hide or show something can be determined with a single call.

For instance, if I were displaying a role-restricted button, such as “add new skill” to the system, the button can check if the user has access to do that action. The button wouldn’t care about why they were or were not able to perform the action. In nerd-speak, this is classic Separation of Concerns.

I ended up wiring this to several controls, but need to continue to spread it through the UI.

I knew the longer I went without the real authentication provider being wired up, the worse I would be violating my principle of updating source control early and often. I decided after getting some of the primary controls working, I’d shift my focus to getting the real Authentication provider working.

Really Real Authentication

When I set up my dev and test bypass, I needed to ensure that when I hooked up real authentication, it would supersede any of the bypass logic. To do this, I simply would check to see if an OAuth provider’s ClientId was set in the configuration, and if so it would ignore all the bypass logic. With this in place, and Infomaniak’s Auth provider set up, I was able to authenticate on my development instance. While there were a few hiccups, Nuxt had a library that made it very straightforward. After a little bit, I was able to authenticate for real!

A Temporary Quirk That Revealed a Need

This presented a problem I hadn’t thought about. The derived username from the authentication provider didn’t match any username in our system.

This is a temporary issue, but it was pretty funny. I was logged into the system, but not a user in our system. This meant due to the roles based work I did before, I couldn’t edit anything on my profile.

It also made me realize, it’s generally a good policy to not allow anyone, including an admin, to edit someone else’s information.

When I deployed to staging (which never uses my dev/test bypass), I would effectively obliterate the ability to demonstrate the ability to edit profiles, unless I was lucky enough for the username from the Auth provider to perfectly match a username in the system.

I needed another role. I needed a super_admin. Super admins would be able to edit everything in the system. To begin with, I would be the only super admin. I also realized that any of the administration-related roles, which would only be used by those managing the application, should not be turned on all the time.

Administrators should generally interact with the system in exactly the same way as the users.

Broke My Rule, but Was Saved By Being a Solo Dev

Once this was in place, and secrets were stored in the appropriate places in staging, I was finally ready to update source control. I did the cardinal sin of anyone on a team of engineers.

I did that update on Friday evening, just before stepping out for dinner. It’s a good thing I’m a solo engineer, as, of course, as happens when you do that, the pipeline broke. Our app is still stable on stage, the pipeline stopped it from being updated. The build candidate needs a little work, so I have a clear place to start into the next week. This is why a solid build and deployment pipeline is so important.

The Path Forward

After getting the pipeline break resolved, I’ll be moving on adding the concept of roles into the database, and start building out the database driven roles based security model.

This will require a new capability to the service, that I’ve known I’d need to add for a while: relationships that reference the same type of node on each side.

When I designed my original system, I didn’t consider the need to have the same type of node on both sides of a relationship, so I was able to determine relationship direction simply by determining the position of the nodes. So with the relationships Predator Eats Pollinator, it’s pretty clear that the direction of the relationship is downstream, or in cypher: (pr:Predator)-[:EATS]->(pol:Pollinator). If your reference node was Pollinator, the relationship would be upstream, but if your reference node was Predator, it would be downstream.

Consider how different that would be if you wanted to model a Predator 1 Eats Predator 2 relationship. In that case, you would have no way to tell the direction of the relationship based simply on the type of the node, and that direction can carry a great deal of contextual information. In this example, Predator 2 (Ladybug) does not eat Predator 1 (Spider). So if I wanted to see what a Ladybug eats, I should not see Spider in the list, but without directionality I certainly would.

How this applies to auth is most clearly represented by the super_admin role:

• Those with the role of super_admin should be the only ones able to create new super_admins.

• They should also be able to add any other type of role.

• Those with the admin role (as opposed to user_admin, etc) should be able to grant others all admin roles except for super_admin.

Adding this capability will enable multiple hierarchical capabilities that we haven’t had yet, but knew we would need. It will require some surgery, but a strategy to approach it is already forming in my mind, and it seems the current system will allow it to be done cleanly.

This will require the creation of several new pages only for admin use that will enable the addition of the roles to user accounts, as well as management of the roles themselves.

My prior experience as a systems administrator made me quickly realize, to make things more sane, I needed the concept of AuthGroups. They are essentially a collection of users that all have the same roles assigned to them.

Building in the management of those will likely be part of this effort as well, though technically it can wait if it ends up being too painful.

The Long and Winding Road

I anticipate that next week will be mostly consumed by the roles management related effort, but once it’s done, then two of the major parts of authentication will be completed. The final piece will be having authentication a part of every single api call, so it can be logged for GDPR, and to ensure that the system is thoroughly secure.

Once those are in place, we will have a system in place with professional, possibly enterprise grade, security infused throughout the system, and we will have finished one of the most critical parts of being MVP ready.

This week, I explore why “releasable” means being ready for opportunity, avoiding the baggage of long-lived branches, and how I’m leveraging our new graph-traversal system to build a robust, high-speed security model.

Be in an always releasable state. This is easy to conceive of in software, though tends to get significant pushback, but how can you do that in life or in groups? What does releasable even mean?

When I first started exploring the concept of “Safe to Play” I was primarily thinking about it from the technical perspective. It’s something that completely changes the way engineering is handled, and the guardrails put in place, but thinking of it in the context of business, groups, or even personal behavior is a bit more challenging. Given more thought, I am increasingly certain that it does apply, and what we’re working on will be a major helper in that.

This week, I’ll be sharing my explorations in the concept of “Releasable State” and how it applies to personal, group, and technical perspectives, as well as a brief update on the progress made on the development efforts of the project.

Characteristics of always releasable

In software development, always releasable means things are continually stable. Any time you want the latest version of the system, you can simply deploy whatever you have.

I’ll get more into the particulars of technology, but focusing on things broadly, always releasable has these key characteristics:

• Always something to show that others can respond to: “Trust me, this software will be great when I finish it!”, is nowhere near as compelling as “Hey, look at what this thing can do so far”.

  The software may not necessarily be everything desired yet, but it can be interacted with and truly evaluated. From there, critical feedback can be given and it can be tuned toward being closer to what serves the need. This is the real reason that many agile approaches incorporate the key practice of frequently showing working software to stakeholders.

• Forces resilience-based decisions: If you commit to always maintaining a stable system, it changes the entire way you approach problem solving. You are far less likely to make very risky huge changes, because if you do, it will be a long time before you are releasable. While changes which break things will need to be made, you will be forced to strategize how to introduce them in a way that doesn’t break the system as a whole, which in turn will be highly informative of the elements of the system and its overall stability.

• Sense of accomplishment and momentum: The longer something is in a partially done state, the more that normalizes. On the other hand, having something show progressive progress can feel empowering, and tends to drive enthusiasm. By ensuring that what is produced can be released at any time, progress becomes clear, and can be celebrated more broadly.

While even these characteristics listed are still quite technically attuned, they are actually quite cross-applicable.

Personal Perspective

In the context of the personal individual, being in an “always releasable” state has to do with self-awareness and preparedness. This can be viewed as being able to clearly express how you can contribute to the situation at hand, as well as your limitations.

“Always releasable” is also oriented towards being able to respond appropriately to unexpected situations, whether positive or negative. This comes from clarity, adaptability, and a clear understanding of what is available to you. While much has been written about emergency preparedness, and it is very important, much less has been covered about opportunity preparedness.

Opportunity preparedness means being able to clearly and concisely communicate the key value you bring when an opportunity arises, as well as being able to grow in ways that maximize the number of opportunities that come your way.

The sense of accomplishment and momentum when it comes to this perspective is oriented around setting small achievable goals. It’s also important to make a point of recording these achievements and what you’ve learned from them. This enables you to gain a clearer picture of your growth, and subsequently how you can contribute and respond to unexpected situations.

The product we are working on is oriented around this exact challenge. The traditional ways that people have represented themselves have shifted dramatically in the age of AI and accelerating change.

Group Perspective

“Always releasable” when it comes to a group has a lot in common with the personal perspective, but with even more of a focus on recording accomplishments and illustrating the value provided.

It is essential to understand how each member of the group contributes to the overall goal. This is not just important for individual well being, but for the awareness of the group’s effectiveness as a whole.

An individual’s sense of accomplishment within a group tends to be contagious.

This can be positive or negative depending on the prevailing sentiment within the group. The more people who feel they are moving forward, the stronger the drive will be to move forward as a group. The opposite tends to be stronger and can quickly stifle a group’s momentum, bringing it to a standstill.

Technical Perspective

As previously mentioned, “always releasable” tends to lend itself most readily to technology. In some circles, this can be viewed as contentious as for many it seems unrealistic. The fact is, it requires a different approach to development, and a high degree of rigor that can be uncomfortable to those not accustomed to it.

DORA metrics makes it very clear: one of the defining characteristics of highly successful engineering organizations is their ability to deploy to production frequently and with as little effort as possible.

While historically deploys and releases have been conflated, they are actually two related but distinct acts. The end goal is often characterized by the saying “make releases a non-event.” To do that, first you have to make deployments a non-event as well.

Here are some key strategies that enable being always releasable:

• Always stable application mindset: Things being built are inherently unstable. To manage this, a common workaround is to use branches, essentially isolated versions of the system to protect the rest of the system.

  While this may seem like a good idea, and in some isolated cases appropriate, it is not something I would generally recommend because it comes with its own set of nasty baggage. The longer a branch lives, the less aligned with the actual system it becomes, which makes it harder to re-integrate into the real system.

  Rather than branching, find ways to update the actual system, but in such a way that it is not executed until it is fully integrated. This can be accomplished in many different ways, depending on the particular context being updated.

  Of course, raw exploration of new approaches or integrations should be done in a completely isolated environment, which only exists for the purposes of learning. Once that understanding is achieved, the learnings can be applied to the system, and the environment and its code should be abandoned. Critically, the exploration environment should not be merged into actual system.

• Automated build and deployment infrastructure is essential: One of the most eye-roll inducing phrases uttered by developers is “it works on my machine”. That’s all well and good, but largely useless.

  As a system is updated, it needs to be run in as close to a real production environment as possible. Containers, like Docker, go a long way toward being able to do this, but it is important that the containers are updated every time a new change is created.

  If it is a manual step, it is likely that it will be put off until a set of changes have been made. In that case, if something breaks, it will be much harder to determine what change broke things.

• Update common source control early and often: No matter what form of source control is being used, a key discipline is to update it every time changes are made and the application is stable.

  Ideally this should be multiple times per day.

  To ensure that the application is stable, it’s imperative that a fully successful test pass occurs. Also, part of the automated build and deployment process should run the tests against the production-like environment. If those tests do not pass, the top priority is getting the app back into a stable state, whatever it takes. Regular small changes makes this much more approachable.

These strategies won’t guarantee you are always release ready, but I’d posit you would have a hard time achieving it without them.

It’s important to note that no one does all of these things perfectly at all times. I personally struggle to stay “release ready” on a personal level, but they give a good directional focus.

Progress

As mentioned previously, I have moved out of 4.5 months of building digests into authentication.

A good chunk of the week was wrapping my head around my auth strategy, and I feel like I have something solid that will be robust enough to grow with my needs, yet reasonably straightforward.

The challenge is for this to do what we want, simple user access won’t quite be enough. We have several different capabilities different users will need. These are likely to change over time, and may be somewhat granular.

Fortunately, graph databases are particularly well suited for systems such as these. This has been a multi-layered challenge, as the UI and the webservice each have different contexts, which each need to be aware of the needed access rights and communicate effectively. This also needs to operate quickly.

I was very excited about the realization that the digest work I just completed would make building this robust security model much more approachable. I’ll be able to use it to quickly determine the various rights and roles of a given user with a single-somewhat-complex query that my new system makes very easy to put together.

Adding authentication at this stage while maintaining an “always releasable” state is an interesting challenge. While technically we can’t release it without authentication to begin with, in this case I consider the bar to truly be always stable, and demo-able.

The challenge is depending on what I add when and where, I can end up very easily breaking the access to the entire system.

1. If I were to add authentication to the webservice before adding it to the UI, then the UI will not pass the appropriate information to the webservice, and the webservice will reject all traffic. This will completely break the site

2. If I build authentication into the UI before the web service, things will continue to work, but it will not have all the functionality of having a secure backend. While not a perfectly releasable state, it’s significantly better.

I started down the path of option two, before I realized that I needed a more robust roles-based model to determine what to show and not show on the UI. If I were to do it perfectly, I would have built in the roles-based functionality in the backend, to be used by the UI, but leave the backend authentication until later.

Since I had already started down path two, I decided that pragmatism beats purism, and I’m making a way to simulate a functioning backend roles engine, that will be useful for me to get the UI in the right shape.

All of this is stuff that most users will interact with, but not really be aware of. It’s not particularly sexy, but it’s critically important. I knew it would be a challenge, but have been surprised at how smoothly it’s going so far. This week, it will continue to be my primary focus.

If your code and your conversations aren’t expressive, you aren’t building a system; you’re building a mess.

This week I’ll be continuing to expand on the elements of a Safe to Play environment, and touch on some very real and exciting progress with the application. Just like last week, when we dug into starting from the goal and working backward, we’ll be breaking it down into three perspectives: personal, group, and technical environments.

There is a sentiment expressed by many in the field of effective communication, perhaps best captured by Frank Luntz: “It’s not what you say, it’s what people hear.”

I remember when I first learned of it, it made me take a pause and consider. Since I was a small child, I’ve been known as being very curious and loquacious. While I’m not necessarily the person who will command attention when I walk into the room, those who engage in a smaller conversation with me can often be overwhelmed by how much I have to say.

That sentiment hit me so hard, because I was so focused on conveying all the exciting things in my head, I failed to take into consideration what was landing with the other person. It’s something I still struggle with to this day, as evidenced by my short weekly posts turning into long-form essays.

That is all to say, what we’re covering today I find personally challenging in many cases, but its importance cannot be overstated.

We humans are social creatures. Despite our divisions and turmoil, we work together exceptionally well, and most of us do not handle isolation well. All that said, while language is a fascinating thing when you think of it, a series of sounds or symbols that convey meaning from one individual to another, the majority of people I’ve interacted with in my career have struggled with it, for one reason or another.

To build a truly Safe to Play environment, clear and understandable communication is crucial. This is where boundaries of acceptable and unacceptable risks are defined. It’s also where collaboration, inspiration, and innovation really happen.

When understandability falters, many negative effects surface, such as dominance, fracturing, and misalignment.

The Personal Perspective

Years ago when I was working at Getty Images, I was frustrated. I was pretty sure I had an elegant solution to the problem we were working on, but no one on my team was open to it. I tried explaining it to them repeatedly and the more I did, the less open to it they were. I was clearly saying the wrong thing, or maybe they were just being stubborn or dumb… or so I thought.

My teammates were not dumb, in fact they were very smart people. While they were being stubborn, it was not because of a character flaw in them, instead it was a flaw in my approach, and critically, the more I said and tried to explain my “brilliant” solution the worse I made that flaw. It also didn’t help that I had also violated one of our group norms.

A good friend who sells consulting helped me see, to my chagrin, a communication pattern that I still struggle with to this day: I can easily get caught up in the idea that I’m desperate to express, rather than the perspective of the other person. It’s not uncommon for me to appear in pictures with my eyes closed and my mouth open, which is a fitting metaphor for this pattern.

One thing that he stressed, and was later reinforced by concepts like Chris Voss’ Tactical Empathy, Bert Decker’s First Brain Approach and others, is that it’s far more important to understand where the other person is coming from, rather than expressing your point of view.

This frustrated me to no end, as my main thought was “how am I supposed to share this great knowledge I have, if I have to focus on drawing the other person out?”

Here’s the thing, when people feel heard, they are far more likely to listen. If they know you understand where they are coming from, they will be able to better see how what you share matters to them, and are far more likely to take it to heart. Otherwise, you’re essentially just making noise that will be quickly dropped from their short-term memory as soon as something more compelling grabs their attention.

The Group Perspective

While what was mentioned in the personal perspective applies to each member of a group, the group itself has concerns unique to it.

What is normal?

Group norms form in fractions of a second. If they stay implicit, they’re a minefield; if they’re explicitly co-authored, they become a safety net.

When norms are not clearly defined, often the strongest personality, or loudest person hijacks the group dynamics. This will usually lead to regressive patterns and stifle the creative energy of the group.

Group norms must be formed and enforced by the group itself. If they are dictated it sets up a dynamic where the people within the group are not attached to the norms, and will seek to find ways to get away with bending or breaking them. It also sets up the dynamic where the norms need to be enforced.

Instead, it is far better for the leader to frame the desired outcome and stakes that either caused the group to come together, or required an intervention. Once that is expressed, have them determine the norms that would be necessary for them to have to meet that outcome.

Dynamics at play are clarity of purpose, alignment, and expectations. When norms are established the team has an understanding of where they can operate safely as part of their group.

o learn more about these dynamics, I highly recommend exploring the work of:

• Amy Edmondson on Building a Psychologically Safe Workplace

• Sidney Dekker on Safety Differently

• David Marquet on “Greatness” model of Intent-Based Leadership

Seeing is believing

Since I’m an Agile Coach, it likely comes as no surprise that I highly value information radiators. In fact, I’d go so far as to say they are a critical component of most high functioning teams. There are groups that are tightly in sync with each other, where they may not need one, but they are exceptionally rare.

There are more positive impacts of having a visual representation of the work than I can outline here, but here are some that have had huge impacts with teams I was on and those I coach:

• Directional indicator: I mentioned last week the importance of having a shared goal. Having a visual representation of that goal, and its impacts has a profound psychological effect on the members of the group signalling to them that their contribution matters, and continues to reinforce the importance of their work.

• Clear display of work: This takes many different forms depending on the nature of the work, but ultimately this serves as a common place for the group to at a glance understand what is needed of them, how things are progressing, and where things may be off course. This enables the group to maintain their effectiveness and have a clear sense of progress, while enabling others to understand the contribution they are making.

• Transparent monitoring of the system: This is ideally automated, but doesn’t have to be. The key is for it to be honest, especially if it’s honestly telling you something unpleasant. A common place for this is build and deployment pipelines, but it can be any number of other areas. This is essentially your instrument panel that tells you objectively when things are not working as expected so you can respond to it appropriately. They must be trustworthy, and as close to real-time as possible.

The key with all of these is to anchor the group on being part of something bigger than themselves, and reinforcing their sense of being able to depend on one another.

The Technical Perspective

“The code you write is a mechanism for communication. Who does it communicate with?”

This was the challenge from Scott Bain to a room full of Getty Images’ Software Engineers to help us grasp Emergent Design.

One of us ventured a response, “The computer?”

Seemed reasonable enough to me, so I nodded along, thinking it was a strange question, but of course you wrote code for the computer.

Bain, quickly shot back, “A computer does just fine communicating in ones and zeros, try again.”

A tentative response came from another part of the class, “Other people?”

“That’s right, other people, whether it’s another engineer, or future you.”, Bain replied.

That exchange sticks with me. It was one of a number of classes I was sent to early in my career that truly shaped me.

Another class that made a big impact was Steve McConnell’s Code Complete where I learned that ideally code could be read almost as easily as a book, and needs to be expressive of what it actually is doing.

This is essential even as a solo dev, as it is guaranteed that once you move on to something else, you will have little to no recollection of the headspace you were in when you wrote it.

If you’ve been doing this for any significant amount of time, you probably have had the experience of looking at code written a bit ago and trying to figure out who the idiot was who wrote it. After a short amount of digging in source control, realize that it was you.

We spend the vast majority of our time programming, reading existing code, and trying to figure out how it works and what it does. This is required, because any change made needs to be made in the exact right place, and hooked to the exact right parts, or things don’t go well.

When something unintended occurs (like a defect), it’s rare that an engineer will know exactly where to look in the code to change that behavior. There are a variety of practices that help with that exact challenge, to a greater or lesser extent, but it remains one of the hardest parts of software engineering.

Here are some key practices that help in this, and a brief description of a lesser known exciting development that is focused exactly on this challenge.

• Ensure code clearly describes what it does and uses the appropriate metaphor: Naming things well is one of the absolute most difficult things in software engineering. The very act of finding a good name can drive design decisions and deeply meaningful conversations with colleagues. A good name should: be short enough to easily read, and accurately describe what the code does.

  This is much easier said than done. Often using metaphors can help. Some of these are commonly enough used that they have made their way into UI’s such as a way to narrow down a great deal of information to a few select things based on criteria is often called a filter. Code that implements that functionality should also have Filter as part of its name.

• Embrace TDD with behavior-oriented names: The goal is to be able at any time and any level to have a clear picture of what the system does without having to look at the code.

  While many people mistakenly think of TDD as a testing discipline, it is absolutely an engineering discipline that forces engineers to think through their approach, and run micro experiments to modify their system to their needs.

  Through working rigorously in this way, a mutually supportive relationship forms between the source code and the tests. A useful metaphor of this effect can be found on medieval buildings, where they have holes built into the walls called “putlogs”. These holes are designed to support the scaffolding that enables people to build and maintain the structures.

• Continual refactoring: Refactoring is a key part of true TDD, but it deserves its own mention because it is often skipped, or thought of as a separate effort. To be clear, from the XP perspective, refactoring is the act of improving the underlying structure of the code, without changing its behavior. In order to ensure this, automated testing that clearly defines that behavior is essential.

  Ultimately the code should only reflect the needs of the system at the time it was written. As those needs change, grow, and as the system is better understood, it must be tuned to meet those needs more effectively. Each time these adjustments are delayed, the system further diverges from the actual needs, and the more effort is required to realign it.

  An apt metaphor is cleaning a house. If you keep up with it as you go, it’s not that bad, but the longer you let it go, the worse it gets, until it becomes completely unmanageable.

  All that said, a deep dive into refactoring of an old project that hasn’t been kept up, can grind everything to a halt. In my career I can’t think of a time where stopping all development for a pure focus on refactoring went well. Instead adopting more of a “boy-scout” rule in code, where you leave it better than how you found it, tends to serve to gradually move things to a more clear and coherent codebase.

Progress: The light at the end of the tunnel was not a train!

The 4.5 month long odyssey came to a close early in the week and I’ve been reaping the benefits with UI work. It has been super cool to be able to provide rich contextual information based on deep graph traversals in an instant.

I’ve been busily tweaking the display into something compelling and informative. The thing we’re fighting with, and getting into some passionate conversations about, is how to show significant and meaningful information, without completely overwhelming the person using the site. This completely reinforces how essential rock solid UX is.

This coming week, I’ll probably finish up a few style tweaks, and move on to the dreaded authentication and authorization system. Once that’s finished up, we should be close to having something others can interact with.

Ever find yourself in business or life feeling like you’re just drifting, or focusing on what is in front of you without any sense of a destination or purpose? If so, how did that time feel?

If you’re anything like me, probably not that great, and certainly not my best when it comes to innovation and sense of accomplishment.

It’s sort of muddling along.

Unfortunately, that’s the sense I’ve seen at many organizations, particularly when people are deeply embedded in them, away from direct customer interactions.

Do you know how your work, whatever it is, makes the world a little bit better?

This is a question that I would use to align teams around a common purpose. Each person should be able to answer that question in their own way.

On embedded teams, it would always get serious pushback.

To be clear, I’m not necessarily referring to some grand purpose, and certainly not a full blown life plan charted out to the n-th degree. When you are working on something, take the time to develop a sense of what you are setting out to accomplish, and how it makes things a little better in whatever context you’re working with.

This week, I’ll be expanding on the safe to play principle of: Start with the desired outcome and work backward.

I’ll also give a very brief update on my progress, why I believe now more than ever the end of my “shouldn’t be too bad” change is finally drawing near, and how an overly cautious system I built is one of my last stumbling blocks.

The personal perspective

One of the most influential factors of our behavior is the habits we form. Many of these form without us being consciously aware. They’re just patterns we fall into because they feel normal, or they make sense at the time. Fundamental to habits are three major parts: the trigger, the action, and the reward. There are more, but these are the primary ones I’m focusing on here.

When reflecting on your habits, a good place to start is examining your interests and the impact you wish to make. Take notice of the scope of what you selected. Is it long term and all encompassing, shorter term and a more limited scope, or maybe something in between?

From there, think of who you would need to be to make that impact. Consider your behaviors and what aligns with your interests and desired impacts, and what diverges from them. The bigger the scope of what you selected, the more adjustments you will find you will need to make to get there.

If those adjustments are large, consider what would be one step closer to that desired outcome. So if you wish to help others learn about a specific topic, what sorts of behaviors or mindsets would you need to adopt?

Clearly, it depends on where you are starting from, but assuming that you have never taught before, and you have limited knowledge of the topic, you have a large number of things you would need to do to make yourself ready to do that. With that in mind, consider what behaviors and mindsets would be the immediate prerequisite for being ready. Continue to work backward from that point, to your current place.

From there, you can identify the minimal adjustments that would move you toward your goal. Once you have landed on those, consider what behaviors and actions you would need to adopt or change to make one of those adjustments.

If you have a behavior that diverges from that adjustment try breaking it down.

• Does that behavior occur at a particular time, situation, or event?

• What is the action that you do that you’d like to change?

• What is the feeling you have immediately afterward?

Try experimenting with these parts. Is there something else that would give you the same feeling but would be closer to your goal?

If you need to add a new habit to your life to move you toward your goal, use the same structure:

• What would be a good event, or time to do the new thing you want to add?

• What is that new thing you will do that will move you closer to your goal?

• How will you reward yourself for doing that action (a sense of satisfaction counts)?

By performing this mental and emotional work, you can start making progress toward the outcome you wish to achieve. There’s no guarantee that you will succeed, or that goal will remain the same, but this practice will make it more likely that you make progress.

The Group Perspective

The dynamics of this are very similar to personal goals, where the group determines the outcome it desires, and works backward toward the next viable step.

Some of the differences however have to do with the fact that each individual that makes up the group has their own set of interests and goals. This makes having a common explicit shared vision absolutely critical, but the key is having each individual of the group able to express in their own words the personalized importance of that shared goal.

Mechanisms like OKRs are great tools for helping align people around a vision and give them the means to measure their progress. That said, they are often misunderstood and too oriented around output rather than outcome, at least in most of the implementations I’ve been exposed to.

The importance of outcome over output cannot be overstated.

It really doesn’t matter how many widgets you produce, or how cool a given widget is. If no one finds it useful, and it doesn’t solve their problems, your efforts are a complete waste.

It is much easier to generate true excitement around something that clearly makes the world better, rather than some arbitrary number.

That said, if your goal is simply to learn about producing widgets, the real evaluation is how well you learned about it, and the goal was never the widget in the first place.

Groups exist for a reason.

If the members of a group are detached from that reason, they will quickly devolve to doing the minimum effort to ensure they don’t get kicked out of the group. That is of course dependent on them gaining some value from their membership (such as being paid).

One of my favorite quotes about this, is the celebrated thinker, inventor, writer, and all around impressive person, Antoine de Saint-Exupéry:
“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.”

The Tech Perspective

This is the section that kicked off this whole session of musing, but it’s tightly related to the other two. If you’ve read my other posts you can see that I’m very focused on determinism when it comes to technology. When I rail against AI, it’s not so much about the training data, nor the energy load (both of which are problematic). It’s generally focused on the very characteristics of what it is: A non-deterministic weighted probability model.

So, why does this matter?

In engineering systems, determinism is critical. It should perform the same way each time we interact with it. Imagine having a calculator that gives you the right answer most of the time, but you can never tell when it does or when it doesn’t.

In order to ensure that the system is doing exactly what it should, you must first truly understand the expected behavior. This is easier said than done, because often we have vague concepts of something, but actually making them concrete takes quite a bit of effort. This is an area that I’ve found LLMs to be highly useful. By working with them to gain clarity around an idea, I’m better able to decide what the system should or should not do. Once that is achieved, that can be captured in executable specifications. These are tests that clearly define the expectations of the system, and initially fail, as the system doesn’t do that yet.

Some key practices I use to do this are:

• Model major behaviors in non-tech readable tests: As much as it pains me to admit this, specifications are important to establish common understanding between the technical and non-technical team members. This understanding is the basis of shaping marketing messages and stakeholder communications.

  The problem is, unless a specification is executable, it is inaccurate and out-of-date as soon as it is written. An executable specification not only defines the expected behavior, it tells the reader whether or not the system actually does what it says.

• Always operate from a known state: An old adage about writing tests from my early days as an XP dev sticks with me to this day “Tell, don’t ask.”

  This means all tests must start from a known baseline. In most layers, you do that with various fakes which appear to be the dependency of the system being tested. In the case of databases, this can be somewhat more tricky.

  The most effective way I’ve found to do this is to have the database always start empty. Each test populates it in the exact expected way being covered by that test, essentially sterilizing the Operating Room.

• Determinism is a prerequisite: This is related to the prior point, but bears repeating. Fuzzy tests are prone to false results.

  If I wanted to specify that my code returned “Hello world” and my test asserted that the result included “Hello” and “world”, the code could return “world Hello” or “aeSworldasdFsabHelloaerEwVasdf” and would pass. This is a simple example, and in more complex systems this problem compounds dramatically.

Not a New Practice

While these practices may seem strange to some, they are by no means new. In fact, there have been many great innovators who have espoused the key practice of working backward from their desired outcome.

It’s a fundamental part of Lean Manufacturing, and it was one of the six key points of Creative Thinking that Claude Shannon shared with Bell Labs, back when computers were the size of rooms.

There are even accounts of no less than Aristotle exploring concepts similar to working this way back in 350 BC.

In Aristotle’s (somewhat difficult to read) words:
“We deliberate not about ends but about means... Having set the end, they examine how and by what means it is to be attained... until they come to the first cause, which in the order of discovery is last.” (Nicomachean Ethics, Book III).

Current progress

I truly see light at the end of the digests tunnel. I’m now running them against my full integration stack, though unfortunately I hit a snag on Friday. When I originally built the system, for some reason I did not trust the data coming back from the database.

Whenever records are retrieved from the database they are in a format that doesn’t necessarily play nice with JavaScript, so they need to be transformed into values that JavaScript understands. This is not uncommon in programming, and pretty basic stuff.

Well, for some reason I can’t recall, I put in code that required explicitly declared values that stated what that transformation needed to be, and if it wasn’t declared it would completely remove the value.

Of course, this was in an area where I skipped deeper testing rigor because of some excuse like expediency and trust that my higher level tests would catch it (and they do). The problem is things break in a way that is not clear: simply missing values.

I’ve tracked down the root cause multiple times, and slapped a bandaid on it, then moved on to other things, only to have it crop up again.

Well, no more. This week, I’m putting in transformers that simply transform whatever comes from the database without any pruning. There is no reason why I shouldn’t trust the values in my database.

A regular drive in many innovation oriented organizations, championed by some of the biggest names in Silicon Valley, is to create a “Safe to Fail” environment. I was a big part of creating that environment within programs like the Digital Accelerator within Charles Schwab. After that success, I was part of the group working to spread that mindset throughout the rest of the company.

It made a lot of people very uncomfortable.

Consider, what “fail” means in the context of an organization that is responsible for the financial stability of a huge number of clients? Layer in the fact that this organization is naturally the target of many bad actors who would love to access their client’s money. It’s no wonder that people were uncomfortable with that message when we were pushing it.

In a high-stakes environment, “Safe to Fail” sounds like insanity.

That said, without the ability to try things that may or may not work, it’s pretty much impossible to innovate. While I think the intent was good, I think the vernacular chosen was bad, and this obsession with failure that was being pushed did not serve things well. Instead, we should have worked to create a “Safe to Play” environment.

“Safe to Play” in Life

Consider any high performing artist or athlete. Take for example an acrobat.

They practice constantly.

Most of this is not apparent to the audience. When people see them perform, it is the culmination of many attempts, mistakes, and learnings. They often will work harder in their practice sessions than the show itself, and the true effort they go through is only apparent to their peers or others close to them.

When they perform publicly, it looks effortless, but ask any serious acrobat and they can give you a long litany of pain that it took for them to get to that level.

Achieving that pinnacle requires countless hours of practicing movement and conditioning, in an environment where a mistake can be easily recovered from without dire consequences. They also tend to constantly play with their craft, trying different movements and positions, exploring their abilities. This is undoubtedly very hard work, and requires focus, but intermixed is a sense of play, which is key to injecting the creativity and passion into their work.

By the time you get to see them perform, they have a very good idea of what they and their counterparts can and cannot do. Cirque du Soleil has released a number of videos talking through what it takes to do the amazing performances they do.

“Safe to Play” in Software (and Business)

When thinking about the times I enjoyed working as a software engineer the most, versus times I was most stressed, the biggest difference boiled down to my confidence level that I could make a change to the system without breaking things.

Thinking about the times I enjoyed when being part of or building solid teams:

In Software

This required various systems to enable me to be aware of the impacts of my change, the more immediate the better. If I get feedback within seconds of making a particular change I can more readily determine whether or not I made a mistake.

Working this way enables me to operate in a highly experimental way, where I can try things, and if they don’t work out I can easily reverse course or find another approach. This enables me to practice, and try things without worrying about dire consequences. It also enables me to have a high degree of confidence that anything I show to the world, operates in the way I expect it to.

This is of course a reasonably simple concept, but in application, especially when a project becomes more complex it can become quite involved.

When things are reasonably simple, a quick pass of exercising the behavior often works well enough. The problem is this has to be done for every single change made. The reality of software is it changes a lot, and often in ways that would have been impossible to predict before digging in due to the nature of software I mentioned in prior posts: creation being an invention based discipline around shaping its behavior.

To do this effectively requires a significant investment of time and energy to get the appropriate systems in place. To maintain them requires ongoing rigor.

Ultimately, this more than pays for itself by the peace of mind that comes from knowing you can experiment. This saves you from the experience of having all the blood drain from your face as you realize that little change you made just obliterated months of work.

It also tends to enable you to find better solutions faster, allowing you to rule out bad paths earlier.

As with all preventative measures, it is impossible to truly measure the impact, but much like brushing your teeth, failing to take these measures can be extremely costly.

Here are some key mindsets that I employ:

• Start with the desired outcome and work backward: A key way to do this is to treat tests as executable specifications. Ideally someone new to the codebase can understand what it does by running the tests and reading the output. The tests must be deterministic and clear, with descriptive names that provide meaning to the results. When they fail, the reason for the failure should be clear and understandable. “Expected true to be false” is not particularly helpful.

• Optimize for understandability: Use various techniques and tools to ensure that anyone interacting with the system under development can quickly and readily understand, and make decisions about anything being built.

The clever but hard-to-understand thing that was woven into the system will become a nightmare if you need to change it even a month down the road, and it’s almost guaranteed that you will.

• Be in an always releasable state: As with many of these topics, this can be somewhat contentious, but a quick look at DORA metrics makes it very clear that the one of the defining characteristics of highly successful engineering organizations is their ability to deploy to production frequently and with as little effort as possible. This is often characterized by the saying “make releases a non-event.”

By following these practices with a great deal of rigor and discipline, you are effectively working in an environment where making tweaks and changes are little or no stress, and you are working from known good state to known good state. You naturally reinforce your sandbox, and are able to be selective what leaves it, and what stays.

In Business

I’ve spent a lot of time digging into how this works in software, as that’s mostly where my head is now, but this readily applies to business as well. Consider:

• Start with the desired outcome and work backward: A shared common vision is essential to align people around work. When you start with the desired outcome the rest of the group can figure out how they can contribute to realize it. It also enables you to naturally uncover the value stream that will lead to that outcome being realized.

• Optimize for Understanding: One of the biggest avoidable expenses in business is miscommunication. This manifests itself in a variety of ways, but by ensuring everyone has a common and realistic understanding, the entire nature of communication shifts from a competition of opinions to interpretations of the current situation. Ideally these interpretations are oriented toward working toward the common desired outcome.

• Be in an always releasable state: While this one is clearly oriented around software, it is very cross applicable. Ultimately this compliments Optimizing for Understanding, by starting with something that conveys the general idea, and then progressively refining that idea. This gives everyone something they can rally around, and apply their own insights to in order to work toward the common desired outcome.

Just like in software engineering, it takes a great deal of rigor to live by these mindsets. You will never do all of them perfectly, but by even aspiring to move toward them you are much more likely to have an aligned team, and make substantial progress toward your desired outcome.

I’ll explore each of these in more detail in future posts, but this should be a good enough general idea to build common understanding and to move toward the desired outcome of building a safe to play environment.

Safe to Play in the time of Vibe

I have no doubt whatsoever that it is possible to set up safe to play environments for vibe coding into. In fact, I’d wager that the vast majority of people coming from a similar background as mine do just this.

That said, the level of rigor I presented is somewhat rare even when code was primarily being written by humans. The reasons I have found it essential were formed over many years in the industry and seeing the consequences of less rigorous approaches. These consequences can range from increased stress, to the complete failure of a company due to inability to change as needed.

Part of the excitement around vibe coding is that anyone, even people with little or no technical skills, can use an AI to create anything they think of. It’s a compelling value proposition.

Unfortunately it comes with some severe downsides.

A major downside is that without the deeper technical background and understanding of why rigor is critical, it is unlikely your average user would even think to have the Vibe coding platform layer these safeguards. Also, I can attest from working extensively with Gemini Pro, determinism and rigor are not their strong suits.

Final thoughts

I’m all for experimenting with these tools. Heck given the current climate, it would be foolish not to. That said, it is critical to understand their limitations.

Otherwise, you may find your sandbox is quicksand.

You are biased. So is everyone you know, and don’t know.

It’s simply a function of how our brains work.

This week, after a very short engineering update, I’ll be talking about a specific set of biases that have a profound effect on our lives across the board. I’ll also touch on what drove my deep dive on biases.

Engineering Update: The Compounding Change

While I can indeed see light at the end of my four-month “shouldn’t be too bad” update, it wasn’t done compounding yet. Weaving the request for digests into my system uncovered a need for a more sophisticated ability to make targeted requests. This requires a rethink about how modifiers to queries (such as filtering, paging, etc) are passed down to the deeper systems. I figured out a strategy to allow for that, and am now getting it into place.

Interaction with this code, even logic I wrote recently, reminds me of one of the points Tudor Gîrba and Simon Wardley made in Rewilding Software Engineering: Software engineers spend a significant majority of their time reading code. At this stage I’m making sense of what I wrote a few months ago, and getting it to play nice with the general system.

The 20-Watt Bio-Computer

Our brains are amazing organs. By volume the brain uses more energy than any other part of our bodies, consuming roughly 20% of the calories for about 2% of the mass of the body. This equates to approximately the same amount of electricity to power a refrigerator lightbulb.

It’s also an exceptionally hard working organ. It has to take in a huge amount of input from the rest of the body, make sense of the current state, as well as balance that with prior experiences that could play into what is needed. This isn’t even touching on a whole range of other functions including invention, or emotional regulation, which is very much part of its job.

Due to this balance between the large workload and little energy, our brains have to be highly efficient. They employ multiple different mechanisms to reduce the amount of energy expended automatically. This manifests itself in many ways, including Inattentional Blindness, Automaticity, Habituation, and of course Cognitive Bias.

A Personal Struggle with Prejudice

When I was young, I was exposed to quite a few very prejudiced people. At the same time, both my parents, in their own way, instilled in me the qualities of empathy and acceptance. The bigoted mindset really didn’t make sense to me, yet I frequently encountered it. I found it repulsive and felt that I absolutely did not want to be like those people. As such, when I found my brain automatically having various prejudiced thoughts, I was appalled.

This caused me massive stress. When something stresses me, I tend to try to examine it and understand it better. This coping mechanism mostly serves me well, but this was a really big one. I didn’t want to be anything like the bigoted people I was exposed to, yet I found myself making snap judgements of people based on very little information, just like they did.

“That’s Not How Biases Work”

I first heard talk about biases at lunch with my colleagues. I really didn’t understand what they were talking about but it sounded like something to avoid.

Later I had a housemate who was working on her PhD in Behavioral Psychology, with her dissertation focused specifically on a particular set of biases. I recall a conversation with her about it, where I was absolutely positive that what I needed to do was to overcome biases. I remember her patient frustration, telling me, “that’s not how biases work.”

While I didn’t think about it at the time, this laid a foundation that served me well as I moved out of writing software and more focusing on how people interact with one another. I started learning more about how the brain actually works, and started seeing how that applied to my work as an agile coach. I was able to see how some teams would pull together, and how some would fracture, based on many different nuanced factors that had little or nothing to do with competence or even general sentiment toward one another. I also became increasingly frustrated and heartbroken when people who could benefit readily from finding common cause would end up getting in massive roiling conflicts over their differences that weren’t relevant to the most critical issue at hand.

Group Projects and Circular Firing Squads

This all came to a head relatively early in my studies at Tomorrow University of Applied Sciences. We had a group project where we were meant to help an actual company develop products to enable them to better monetize their product, and work to uplift the disadvantaged area that their production was based out of. It was an exciting prospect, and we were all aligned with their broader goals: the company, university, and our program was all oriented around sustainability.

Due to concerns with how companies tend to operate in developing nations, even companies that work hard to project a positive image, my group-mates became very concerned about this company’s interactions with the community they were working with. This built to a point where our first meeting with the company’s representative, which was supposed to be us sharing our ideas with her, was more like an ambush. The most frustrating thing was that even a small amount of research showed that this company was doing what one would hope a company in their position would do: treat the community they were working with as key stakeholders and had them deeply involved in the project.

Fortunately, that experience didn’t put off the company representative, and we ended up having a good interaction with them. All of my classmates were very intelligent and caring people who genuinely wanted to make the world a better place, and yet they were treating an ally as an enemy.

This is a story I’ve seen play out with heartbreaking regularity.

The Birth of Non-Judgmental Thinking

That experience prompted me to reach out to one of the co-CEO’s of our school, Dr. Thomas Funke, and ask if we had a class on Business Diplomacy. He had witnessed the same situation I laid out multiple times as well, so he recognised the need to have one. This is what led me to building a class for their MBA program about Cognitive-Bias and Social Identity Theory, called Non-Judgmental Thinking.

Building this class had me digging deeply into the science behind these two critical areas of study, and solidifying my understanding of how their dynamics play out. My former housemate, now a practicing Psychologist, also helped by reviewing what I wrote and clarifying areas I misunderstood. I now find myself commonly needing to navigate what she so effectively did with me, helping people understand that biases are not something you can overcome. They are fundamental to how the brain works.

Bias Basics

Two of the biggest pioneers of the study of bias were Daniel Kahneman and Amos Tversky. Their Nobel winning work together was collected into the book Thinking Fast and Slow. Unfortunately Tversky had passed away before the Nobel and before the book was published, but Kahneman honors him throughout.

What they uncovered was that when processing information your brain essentially has two different modes:

• System 1: Very fast pattern matching. Highly efficient, using very little energy. Has access to your entire long term memory. Error prone as it is completely optimized for speed. Happens before you are consciously aware.

• System 2: Slow and methodical processing. Uses a tremendous amount of energy. Can only access your short term memory, which is about 7 +/-2 items. This is where logic and cognition tends to live, and tends to be less error prone.

The reason for this is tied to survival. When a predator, like a sabertooth tiger, jumps out at you, you don’t have time to have a deep think about what might be driving their behavior, you need to act immediately. All of your brain and body energy needs to be used to ensure you survive that encounter. Once you’re out of the immediate situation, then it’s possible to find the time to consider the dynamics that led to that encounter.

While fortunately most of us are not in a position to be pounced on by wild predators these days, these critical systems have not evolved much since then.

Non-physical threats, such as threats to status, are no different to our amygdala than that predator jumping out at us, and immediately our defenses snap into place. Also, our threat perception is very much tuned to our worldview.

The overwhelming desire for simplicity

The way our brains work is highly useful. It’s enabled us to survive for a very long time in an environment that was (and still can be) very dangerous. Further, it’s enabled us to advance to a point where we are much less likely to get eaten by a wild predator than many of our ancestors were.

System 1 works great, when things are simple and cause and effect is clear. If you have a great deal of experiences where reacting in a particular way would lead to a predictable good outcome, it is often exactly the system you need. This is tightly related to the intuition that trained observers develop, or highly experienced emergency responders. This is how I can spend a reasonably short amount of time interacting with your team, and have a clear sense of the health of their team dynamics, but I can’t necessarily offer a clear explanation of how I know.

The problem is, when things are complex, or unpredictable, even by a little bit, the system fails us. Unfortunately most of the situations in the modern world are, by nature, complex and multi-layered. We have advanced to a global society where we are more interconnected than ever before, and changes made in a completely different part of the world can have profound impacts on the lives of others.

We all want simple answers. They make it so we don’t have to spend as much of our precious brain energy and we can move on to other things. The reality is that simple answers to complex problems are almost always wrong, unless they are derived from a significant amount of experimentation. Anyone telling you that a complex and dynamic problem has a simple solution (e.g., immigration, geo-politics, the job market, or product development), is likely using your biases against you to manipulate you into serving their goals.

The Trap of Attribute Substitution

The most relevant mechanism here is Attribute Substitution. When presented with a hard question that requires System 2 effort, our brains unconsciously swap it for a simpler question that System 1 can answer.

• Hard Question: “Is this complex economic policy sound?”

• Substitute Question: “Do I like the person proposing this?”

Even when you are aware of the actual answer, the pull of the simple substitute is incredibly strong.

So What Can You Do?

Biases are unavoidable, and not a personal failing, but they often can make you jump to conclusions, or make snap judgements that don’t serve you well. While exploring this in depth would be a huge endeavor, there are several things you can do to operate more in line with how you want to.

Here’s a few quick tips:

• Become bias aware: There are 100’s of biases and more are being discovered. While it would be impractical to attempt to learn them all in one session, you can start by spending time exploring them. Here’s one of my favorite presentations of them: Cognitive Bias Codex with Definitions

• Challenge your assumptions: Try to find ways that what you think is certain, may not be accurate. Get other perspectives to give you more of a richer view, the more diverse the better.

• Practice kind self-reflection: While you won’t be able to prevent yourself from being impacted by your biases, it is completely within your control how you react when you realize it. Don’t beat yourself up about choices made, but instead try to learn about what other options you may have, and surface places you may need to make amends.

• Invite constructive feedback: Ask others you trust what you’re missing, or how things came across to them. Try to find people who are significantly different from you, as they are all affected by their biases as well. I’ve found that AI’s aren’t bad to help identify the biases that you might be operating under, but do be aware they are highly biased as well.

I’ll touch on more biases and how to manage them in future posts, but recent events have me thinking about Attribute Substitution a lot.