This is nice. Once Over’s back patio annex is excellent.

When finished isn’t done

The work is done, the post is published, the code has shipped, the boxes are all checked.

And yet, it remains in my head. The bit of code I’d like to revisit, an edge I couldn’t round off, a paragraph that doesn’t fit like I want it to, a workflow we didn’t improve upon, a conversation about trade-offs that went sideways…

The work is more than the work, more than an end. It’s emotions and memories. A new way of thinking, experience and wisdom newly integrated with what I’ve done before. The start of something new, with this finished work as the prologue that sets the stage for the next story.

Previous tasks continue to consume attention even after switching. This is especially true for anything that causes strong emotions. I find it hard to concentrate if I’m opening (Slack) every 15 minutes and every time seeing that thread where someone is arguing with me and they’re totally wrong and how can they even believe what they’re saying and what was I doing again? — Jamie Brandon, Moving Faster
  1. Acknowledging and managing emotions is a productivity/go-fast hack
  2. Really, don’t dwell on people being wrong. You can’t control it. Just keep going.
  3. Absent people and emotions, completing a task doesn’t mean it’s out of our heads. Account for that in planning the day or projects.

Often, things are only getting started when I check that box.

We call it perfectionism when we hold the work back to make one last tweak, another small improvement. Perfectionism is pouring myself into one checkbox for weeks or months at the expense of all the other things I want to do. It’s not so much seeking perfect, but an inability to let go and get started in earnest.

To the contrary, every day I’m more convinced that perfect emerges from checking that first box. Putting the work out there, starting the next checkbox (of several dozen), accumulating and shaping something more perfect.

Everything finished is the start of something else.

Charles Chamberlain

An “independent researcher & developer focused on making new interfaces to create with”. He’s developing some neat low road (in the How Buildings Learn sense) ideas at the intersection of dynamic languages and web media.

red pear and walnut:

I made a new cloud programming environment called red pear! (redpear.dev) Its goal is to help you build small web apps very quickly. In particular, it helps you build 2012-era, backend-first web apps with the use of ruby and sinatra.

Much like birch, red pear has instant deploys: the code you write is hosted on a dev instance immediately and on a prod instance with the push of a button.

I made a new interface to persistent data for use in red pear: walnut. Its goal is to be easier than something like sql or graphql, especially in the context of smaller apps.

apricot: a structure editor for ui:

It's a structure editor that makes it surprisingly easy to "type" out a user interface.

I originally thought of Apricot as a prototyping tool — a place to quickly get some dynamic behaviour wired up to a UI, without worrying too much about pixel-perfect fidelity. Weirdly, a lot of prototyping tools nowadays go the other way — focusing on pictoral representation while mostly leaving out semantic behaviour.

Birch:

A cozy development environment making prototyping and scripting as easy as possible.

Watch the demos!

Think through making. – Matt Webb (by way of Matt Ward) Protocol Fiction, Desire, and Belief

Ideas in your head are shallow next to ideas worked out with craft, material, and context.

The Bear

I watched seasons 1 and 2 over the course of a few weeks. Fantastic show, no notes.

I can’t start to describe it. It’s not crime-y, not a comedy. It’s not exactly feel good, but it possibly takes the spot in my brain formerly held by Ted Lasso.

There’s often a lot of yelling. But it made me start using “heard” as a single-word sentence conveying “I have heard what you said, don’t disagree, but haven’t entirely processed it.”

It’s about cooking, craft, and running a restaurant. Maybe it’s Ratatouille’s darker cousin?

Recommended.

Shortcuts for scripting API integration

If you want to do straight-forward API scripting, Shortcuts + Actions might do the trick.

Shortcuts workflow to fetch and parse a JSON feed

Patterns in play:

  • Fetch URL (Shortcuts built-in)
  • Parse document as feed/JSON/XML
    • (not sure if this is built into Shortcuts or you need Actions to cover all three)
  • Pull out “the stuff” element/attribute (e.g. items, articles, results, etc.) (Shortcuts built-in)
  • Do something on each item.
    • YMMV depending on support in whatever app you’re integrating with.

See also: How I Sync Readwise Highlights to Bear.

Use Swift Playgrounds to sketch ideas

Before spinning up a whole Swift project, use Swift Playgrounds to sketch out ideas.

In Xcode (macOS):

  • File -> New -> Playground
  • Choose “Single View” (I’m not sure what impact picking macOS or iOS has)
  • Choose a name and location to save your playground

UIKit is the iOS default for a single-view playground. Storybooks are the default for macOS. To replace those with a SwiftUI component:

import SwiftUI
import PlaygroundSupport

struct ContentView: View {
  var body: some View {
    VStack {
      Button("Tap me!") {
      }
    }
  }
}

let contentView = ContentView()
PlaygroundPage.current.setLiveView(contentView)

🤔 I haven’t yet come upon a good heuristic for:

  • when to spin up a project for tinkering vs. a playground
  • to what extent one could use TDD in playgrounds
  • how to import files from a playground inside a project and use project resources

In the meantime, if you’re not into the world you live in, you can build your own world around you. (Now would be a good time to put on your headphones and cue up the Beach Boys song “In My Room.”) Surround yourself with books and objects that you love. Tape things up on the wall. Create your own world.

– Austin Kleon, Steal Like an Artist

Put up the walls you want in the world. Look past the walls you dislike. (Ed. As a metaphor, this works for sure. Literally, in the case of oppressive regimes, not sure how to carry this idea forward.)

In the moment

Is pessimism about the past, present, or future? If it says, “we can’t get there from here, based on where we’ve been”, it neglects the present and maybe the future.

Does optimism favor the future over the past or present? A smart optimist might use the past as a trend-line to the future, and seek to make the most of the present.

Fruitless activities and hobbies are important!

Anything you do that doesn’t make you money or help others better be something for your own damned amusement. – Austin Kleon

"If this isn’t nice, I don’t know what is"

Kurt Vonnegut:

And I urge you to please notice when you are happy, and exclaim or murmur or think at some point, ‘If this isn’t nice, I don’t know what is.’

It’s a kind of way to go about life. Find more activities, people, places that lead to this kind of thought. Find more reasons to say it in regular life. Spend more time doing all those things.

Monk and Robot: very enjoyable chill-future vibes

Monk and Robot, A Psalm for the Wild-Built, Becky Chambers. An optimistic, non-space/techno sci-fi short novel. For me, it’s a welcome departure from the Very Serious Ideas of Stephenson, Asimov, Gibson, etc. No big bad, just a nice world and great interactions between a person and a robot.

Highly recommended for a vacation/beach read.

Notes on narrative for engineering leaders

Alex Reeve, 22 Principles for Great Product Managers:

You have to own the narrative. When there’s a narrative vacuum, people will “creatively” fill in the blanks themselves—and you might not like it. Losing control of the narrative can be incredibly disruptive to your team’s ability to deliver.

– (Alex Reeve, 22 Principles for Great Product Managers)

Same goes for plans & projects. If you don’t have a plan, someone else will. You may not like their plan.

Telling the story of a goal/project/initiative isn’t manipulation1, it’s setting the vision.

All narratives compress out important details and trade-offs as an expense of clarity and noteworthiness (i.e. an un-memorable narrative is not a particularly good narrative).

Narrative is is a fantastic skill to have as an engineering leader. The more you can convey your ideas, goals, projects, and initiatives as a narrative, the more you can get people on the same page. It’s also a fun skill to acquire. It’s all around us in culture. It’s one of the few things where you can improve in your profession by paying attention to how movies, television, or fiction are structured. (Highly recommended: Every Frame a Painting)

  1. Bad-faith narrative construction exists, please don’t act in bad faith. ↩

"It sounded like the kick drum was played by a drunk 3-year old, and I was like ‘Are you allowed to do that?’”

WONKY – pudding.cool analyzes what makes J Dilla special. Particularly good if Dilla Time (previously) is still in your to-read list.

Albums is a great app and The Best App for Albums is a great review of what makes it good for music enthusiasts and/or organizational hobbyists. I don’t want to jinx it, but Albums checks a lot of boxes for me that Rdio did, back in the day.

TIL Jenny Lewis covered the Traveling Wilburys’ “Handle With Care”. 👍🏻

Don’t zero out the margins

Efficiency is the enemy, Farnam Street:

It’s possible to make an organization more efficient without making it better. That’s what happens when you drive out slack. It’s also possible to make an organization a little less efficient and improve it enormously. In order to do that, you need to reintroduce enough slack to allow the organization to breathe, reinvent itself, and make necessary change.

The good stuff happens in the margins. The scribbles in books, the breath between notes, the five minutes before meetings start when folks are real. Driving a car for the sensation of driving fast, rather than driving fast to achieve the best possible time.

It’s the difference between enjoying a hobby and making a profession out of a hobby. Efficiency is the adversary of fun.

Three meditations on wins

Leaders (and managers) are successful to the extent that their teams and peers notch wins. Former Intel CEO Andy Grove calls this the “output” of a manager, and wrote the book on it1.

Easier said than done! What is it for a lead to create wins (aka output)?

1. Choose games that are winnable

Only play games you can win.

  • Warren Buffett or the Beastie Boys (probably)

Our time is highly constrained. Saying “no” is an underrated and under-discussed leadership skill. Saying no on behalf of my team, peers, or organization, I’ve created focus on a (potentially) winning effort.

Some great reasons not to play a game2:

  • The opportunity, as presented, is not yet small enough in scope to notch a win in the time available to work the opportunity. Find a smaller win in the presented opportunity that will give you a hint as to the real potential of the bigger project.
  • The calendar time necessary to run the project or ongoing effort to completion (notch the win) is dominated by process, coordination, and bureaucracy. That is, try again when there is a way to realize the impact with less overhead/organizational drag.
  • There’s a gap between the desired/supposed outcome and the project(s) that could realize that outcome. The immediate win is to research/brainstorm/write your way to connecting outcome with action(s).

Pro-tip: provide feedback on not-yet-winnable games in the form of “I don’t yet know how to win that game, let’s start by fixing that”. No one likes pessimism, cynicism, or shutting down all the project ideas. That said, it’s fair to provide constructive feedback that will improve the idea or bring it closer to action/win-ability.

2. What counts as a win?

Once something is out in the world, it’s a win. Publishing an article, releasing a feature to your customers – those are definitely wins.

Getting something out of your team or head, that’s a sort of win. Rolling out a new process or tool is some kind of win. Worth sharing! But it doesn’t directly improve what customers are paying for, so focusing entirely on this kind of win doesn’t count.

Wins have to change your company’s world in some tangible way. The change need not be objective or quantitative; a subjective/qualitative survey is enough!

If what you’re recognizing as little wins doesn’t yield bigger wins, then it’s time to reflect on what you’re encouraging.

3. Avoid short-term thinking, build momentum with little wins, build big wins

A culture of thoughtfulness about outcomes, potential, impact, and trade-offs makes 1 and 2 happen.

Loud voices may try to convince you that un-winnable games have lots of promise. Urgent voices might tell you counting something as a win and moving on is the right move.

Moving the goal-line closer, so you can recognize a win, is expedient and productive, occasionally. Other times, moving the goal-line is self-defeating.

It is often difficult to stick with long-term projects. There is so much other stuff to work on, all of it intriguing. Other folks in the organization will want to know how much of “all of it” we could produce in the current and next quarters.

The challenge is to stay the course, believe in the purpose, and stack all those little wins, every week, until the big win takes shape. Tell your colleagues about the big win’s emergence…

In short

  1. Choosing what to work on (or not) is of crucial importance.
  2. Recognizing the right kinds of progress makes it easier to stack little wins on the way to big wins.
  3. Exercising the discipline to stack meaningful progress (wins) is the engine for generating big outcomes.
  1. High Output Management. See also, GitLab’s notes on the same. ↩
  2. Would a whole post on indicators of losing/un-winnable games come off as too cynical? ↩

Improving when you can’t rinse and repeat

You can’t practice at some things. Putting the cat back in the bag or the toothpaste back in the tube. The undoable, the things that you can’t unsay. The measure twice cut once stuff.

In those cases, a little preparation and reflection go a long way. I think about what's important to say or verify before I say/do the undoable. Afterward, I reflect on how things went, if I learned anything surprising, and how I can improve the process next time. Ideally, I write all this down, so I don't lose any wisdom for the next time I'm faced with a similar challenge.

I'd normally say rinse and repeat here. But the point here is there is no rinse! There is only setting myself up for success when I find myself facing a one-way door.

Top of Mind No. 5

Like everyone (it seems), I’m exploring how large language model copilots/assistants might change how I work. A few of the things that have stuck with me:

My take right now: GitHub Copilot is the real deal and helpful, today. On the low-end, it’s the most useful autocomplete I’ve used. On the high-end, it’s like having a pair who has memorized countless APIs (with a somewhat fallible memory) but can also type in boilerplate bits of code quickly, so I can edit, verify, and correct them.

I don’t expect the next few products I try to hit that mark. But, I suspect I will have a few LLM-based tools in my weekly rotation by the end of the year.