A Different View
a_tool_walked_into_a_bar - why_does_the_o_go_around_the_outside
I'm sitting here after church, facing the side of an old brick building, nursing another large Americano - and writing. This is still a bit new for me, I'm starting to get used to it. How to get my thoughts out without letting the floodgates open. Save that for my teddy bear ;)
The idea of tooling is front of mind today. The result of an accidental conversation while I should have been paying attention to the sermon.
The question was:
How would we see the possibilities of software work for people if we had goals of
human expression rather than production?And my reply:
Those of us that can, should be building the tools to allow that to happen. Those
of us that can, should be teaching those of us that can't how to use them.
Once everyone sees the possibilities that are unlocked when the barrier between intent
and reality falls, maybe that transition won't be so challenging.
I think people need to learn to let go of their traditional view of software though
before that happens.oh_no_hes_talking_again - kindly_calmly_rationally_this_is_the_way_we_go
When you can't let go of the idea that software is something that has to be, that it has to be carefully designed, planned for - made real through a process of careful structure and rigid implementation, then you get software that doesn't work well for anyone.
The average pilot does not exist
When you let software become something that is, let it tell you what it wants to be, then you get software that works amazing... for you.
I spent years designing systems to help me work, to work with my natural tendencies not in spite of them. I built them one piece at a time, as a way of enabling me to be more effective. Close every ticket with a tool in your pocket for next and and pretty soon you've grown an entire garden. Build a substrate for them to all grow from. Don't write a shell script, use a CLI framework. Grow a library of smart resources to represent your infrastructure and at some point throw an API on the other side of it. Now you're distributed...
distributed_man_distributed_man - look_at_me_brain_the_size_of_the_universe_and_all_im_doing_is_running_this_lousy_platform
It's an amazing system. A distributed graph that's ticks over and over, tracking the slow crawl of fresh baby software as it grows through development, on through qualtity and performance gating and finally springing forth into the wonderous light of production. (or at least manages the distributed context of hundreds of delivery pipelines through a collection of YAML files and some wonderous things that happen when your mind slips off into entity space).
And no one else got it.
For years, we kept hiring engineers to help me tend the garden I'd grown and we just couldn't. Internally, we'd had a bit more luck. As long as I could walk engineers through the process, someone of them seemed to get it.
- find a pipeline that does what you want yours to do
- copy it to your project
- change the names of things
- copy the Jenkins job
- change the names of things
The ones that got it, got it wonderfully. Some of our development teams went off and built gloriously complex orchestrations, they occasionally check in for help. When there's been a storm and the garden needs some care, when they're workig greenfield and we need to grow new capability.
And no one else got it.
It's always been all or none, and until recently I didn't know why.
theory_of_mind - unknown_unknowns - oh...
I didn't know how differently I approach things. I didn't know why I could never get people to see why they just needed to know the why and to stop focusing on the how.
I have a better idea now.
After a rather Lemony Snicket summer forced a month long hyperfocused dive into the nature of empathy, it's a much better idea.
let_me_get_that_for_you - no_no_ill_come_round_to_yours
It's not exactly a secret that tools built by engineers look and feel like tools built by (and for) engineers. They make a cold logical sense, exposing the implementation through a macabre dance of "I need a variable, where should I put it" design theory and optimizing efficiency.
For engineers, they work brilliantly.
It's not exactly a secret that tools built by designers look and feel like tools built by designers, for the widest audience possible. They are thoughtfully put together, with features gradually making themselves known in a way that has been carefully planned for optimal ease of use, and are layed out in a way to ensure that the user's attention is directly focused where the designer wants, when they want.
For most people, they work brilliant.
For me, they both just... don't
the_unix_way_is_my_way - can_i_pipe_my_brain_to_dev_null - never_ever_forkbomb
My mind is a system of moving parts, some work better some days than others. On those days, the rest chip in to help out. You have a job to do, you find another way to do it. You find things to help, rules to live by.
Break the problem down into small parts, solve them one at a time so you don't get overwhelmed by finding the perfect solution immediately.
If you always put things back in the same place, you don't have to find them later.
And they help, over time the rules start to compound, when the basic primitives become embodied the next layer emerges. Over time, the graph grows as more understanding is found - what should have been automated response becomes a near approximation - until a rich web of internal and external scaffolding is built up in support.
And you build systems the same way and to do so, you need tools that work a bit differently. You need tools that are built for you.
the_teddy_and_the_taco - the_spectrum_sees_all - its_turtles_all_the_way_down
If you can use a tool, you can build a tool - you just need to understand why you're using it.
Understanding the problem you're trying to solve is the first step. If you can't effectively describe the problem you're trying to solve, you'll struggle to describe its solution.
Next, break it down into its component parts. Try to find the smallest change that's required to steer the entire thing in the direction you need to go. Implement it and review the new constraints, adjust as necessary.
When you're done, you'll be left with just what you need and nothing more. Go do your job. Put the tool back on the shelf when you're done. If you need it again later, it'll be there for you. If not, you only changed what you had to, did the minimal amount of work necessary to accomplish the task and you completed it - if nothing else a job well done and something learned along the way.
The next time you pick it up, it may morph again. Pick it up enough, and it might turn into an API. A few years later, it might be hanging out with a bunch of friends running a few hundred million in software delivery.
Or not, it might never see the light of day again.
the_empathy_is_the_interface - how_do_i_turn_this_thing_on
Systems designed from small composable parts are deeply empathetic. They can be mixed and morphed into whatever form the user needs at the time they need it. They can react to mood, to the environment or just because it's autumn and someone felt it would be nice if the odd leaf trickled down the page.
I spent years not understanding why no one understood my system. I spent years not understanding myself.
Now I'm building substrate, the tools that power creativity. I want everyone to be able to experience what I do, the ability to grow tools on demand to solve immediate problems immediately. And composable systems unlock the ability to do so... with a little help.
A couple of weeks ago, I made a major change. I went splitscreen on my emacs workspace, giving up a full 50% of my vertical screenspace - something I would have thought illogical even a month ago. What made me give up give up side by side editing?
A teddy bear.
This is my new dashboard, it replaces an old org-mode agenda.
I grew it one day so I could do this.
# Alice in Wanderland
## Bookmarks
:::channel-index title="Useful Pages" compact="true"
1. [Infrastructure](infrastructure) ← Priority - System health
2. [Deployments](deployments) - Release tracking
3. [Alerts](alerts) - System notifications
:::
## Recent Activity
:::channel-query title="Latest Updates" limit="5" sort="updated" compact="true"
:::
## Caseload
:::drawer-view title="Active" layout="compact" status="active"
:::
:::drawer-view sort="priority" sort-direction="asc" limit="5" title="🔥 Top Priority" layout="compact" status="parked"
:::
:::drawer-view tags="urgent,blocked" title="🚨 Needs Attention" layout="compact" status="parked"
:::
:::drawer-view sort="created_at" sort-direction="desc" limit="10" title="Recent Cases" layout="compact" status="parked"
:::
:::drawer-view sort="created_at" sort-direction="asc" limit="10" title="The Wasteland" layout="compact" status="parked"
:::
<!-- DevOps timeline -->
:::drawer-view tags="devops,active" title="Current DevOps Work" layout="compact" status="parked"
:::
:::drawer-view sort="label" sort-direction="asc" title="All Cases A-Z" layout="compact" status="parked"
:::
:::drawer-view starred="true" title="Daily Queue" layout="compact" status="parked"
:::
<!-- Personal checklist -->
:::drawer-view tags="personal" case-type="idea" layout="checklist" status="parked"
## TimeSheet
:::daily-timesheet
:::I need to know what I'm working on - the current case, it's right up at the top and yellow and glowing lovely.
I need to know what I'm working on - all those other things too, just not at this very moment, until I am...
And when I switch focus, we all switch focus. The system attracts attention of all of the agents to the same detective case. They're capturing context as case notes as we work along.
Look Watson - I've built a wonderous machine
What's it for?
Abductive reasoning Watson, abductive reasoning
And we navigate through it as one should, one go east or go north at a time while we're off solving a whole slew of detective cases... er ahem Jira tickets...
Or just learn something...
And I know that metaphor doesn't work for everyone (the detective one should though... seriously... frames the context perfectly for the work ;)). But the substrate does.
Don't want a teddy bear called Watson on your screen? Change it up - here's the source.
Can't convince your team to come look at your Stuffy (it's a long story...) put it up on Confluence? I grew that capability into the system in about 25 minutes the other night.
The pieces are all there. It's the idea of the system that matters, understand the component parts and the solution will become obvious - to you. Your solution becomes your tools, because if you can well and truly understand your solution, you can describe it. And if you can describe your solution, a teddy bear powered intent to reality engine may well bring it to life :)
I do this because I need to, and because I want to. These days I feel like The Doctor, running maniacally around the TARDIS wiring the thingamajigger to the whatsit. A mad mix of Hatter and Hare, always early and never knowing where you are because of the capability that becomes apparent once the substrate has formed.
AI isn't a think for you machine. AI is a think with you machine. You do the thinking, let it do the talking. They're called language models for a reason. Show it the shape of a solution formed from a place of understanding and let magic happen.
It's wonderfully weird in here, come see :)