Blocks All The Way Down

With the right language, everything is a toy.

Two conversations I've had in the past week dovetailed perfectly. One focused on the perils of one-shot development, the other on the challenge of team building in the modern age of development. Both of these pushed my brain immediately to one of my favorite childhood toys - Tinkertoy. Let's see if I can walk this one through without stumbling over myself.

Let's start with this webpage - It's a download page for an old MS library called the Microsoft Enterprise Library 5.0. The goal of this package was to simplify the creation of standard CRUD applications with established logging, exception handling, data access, and other common capabilities needed to create your basic Admin/Ops tooling.

Most enterprise developers have encountered variations of this type of library. Many of us have built our own versions. When you're a tech team looking to support hundreds of bespoke operational processes, it's incredibly inefficient to build everything from scratch.

More than the time consuming nature of creating code bases from scratch, there's the challenge of cross-domain expertise. Enterprise developers eventually need to be comfortable across the fullstack, but there are ample examples of frameworks like Hibernate or GWT that attempt to flatten the need for domain expertise through code generation.

That leads me to this essay on what LLMs really are doing. The gist of this article, which I largely agree with, could be re-positioned as: LLMs are the Enterprise Blocks of tomorrow. When you have a known problem, where you can validate outcomes a harness can be an effective, if inefficient way to generate a chunk of code.

Now to see if I can pull this together. The two repeating problems I seem to encounter, either vicariously or through my own machinations are No One Knows What I'm Doing and What Did You Do That For. Building first and asking questions later because it's easier to automate a flow than it is to talk through where it might lead. Each of us then peering over our shoulder, confounded by the disjointed nature of what others have created.

In an era when we have chat messages triggering flows that create specs, that trigger harnesses that trigger validation flows that send chats to others that trigger... ad nauseum... It begins to feel like we're losing the ability to collectively think through problems. We don't have common blocks we can trade because a harness can spin one out in minutes.

Good teams are still breaking down applications into domains, but even with a thoughtful approach to structure our LLMs are crafting new blocks ever so slightly different than the last block. Each aspect of the process that gets automated creates one more fracture in the collective understanding of what our goals are, and how we expect to deliver it.

My plea is this. As we get further down the path of automation, I believe that we need to have an even stronger focus on play. One of the most effective team building strategies I've deployed throughout my career is making a team build something. Whether it's with Legos, Play-Doh, or with Tinkertoys the goal is to reinforce the value of human to human connection around what we're trying to do.

Play isn't a stand-in for technical ability and growth - it's a reminder that teams collectively have to align on what is being created and how it can be done at a foundational level - even if we're grabbing pre-built blocks off of the shelf. Everything is a tradeoff and healthy teams actively make choices based on those risks. Playing gives us the language we need to have those conversations and, most importantly, keep things fun.