It’s been so long since we spoke, /now-page aficionados.

I’ve been moving to Portland, buying a house therein, and selling a house in a bizarre hyperlocal real estate situation. Some of these I have a lot of control over, some I am frustratingly very much in the passenger seat on.

I’m still leading engineering teams holistically, acting true to “we can go further together than we can alone”, and writing about it (more for myself than others than I’d like).

Some days, I’m just trying to ignore the recursive news screwball that is 2024.

Actually, baseball is a fair metaphor here. It’s curveballs all the way down. I’m fouling off most of them, though. 🤷🏻‍♂️

I’ve been thinking a lot about setting expectations and goals. I have an idea about setting expectations on how we practice software development in teams and four pillars thereof. They are, broadly: alignment/consensus, accountability/responsibility, transparency/visibility, execution. These seem like four useful touch-points for coaching individuals. More concretely: help teammates drive scope (down, mostly) by setting time expectations and iterating from there.

The other angle on my mind is using subjective measurements to evaluate changes to human systems. That is, don’t ask a person or team to change how they work and immediately hit a numeric benchmark. Instead, ask them how the change is going and rate it from 1-5, worst to best. If the desired outcome is “know what the team is up to on most days”, ask them to write a status report, but don’t specify a number to hit. Instead, use 1:1s to reflect on how the change is impacting their work, look for advantages or shortcomings to the change in process, and decide how to correct course from there.

Updates: LLMs are still promising, but not as much for leadership work. Working incrementally, still underrated.

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:

• Use LLMs to reduce the cost of doing things, there by increasing ambition. That is, reducing cost increases demand.
• Using LLM prompting to think through/design a new bit of program functionality. If one can manage to write a generic prompt, without proprietary information, you have given many programmers a much wiser pair than they might normally have.
• Use LLM flexible tool for thinking through problems or solving them outright. GPT4 is like rolling a REPL, a junior developer, and a conversational partner into one very flexible toolkit.
  

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.

The practice of building software/technology is going through a phase shift. We’ve worked from abundance the past few years. Now we have to figure out which developments are worth keeping and make a dividend of that exploration. It’s not clear what job roles, kinds of software, practices, and benefits¹ will persevere.

We’re going to have to ask “what would you say it is you do around here?” of software development assumptions from the past few years. It’s unsettling², but some good corrections will come of it.

I’m betting that using writing as a lever will remain under-rated and under-used. Both for asynchronous/remote work and improving all kinds of thinking about building software.

Furthermore, Poker Face is excellent.

1. Sorry, nap pods and ping-pong tables. ↩
2. And, often executed cynically. ↩

Working in small increments towards medium-to-large projects or outcomes is tricky. I too frequently find myself down a much deeper rabbit hole than I’d intended. And I’ve spent a lot of time thinking about it and practicing at it! Recommended reading: Simon Willison on productivity.

Read-only and write-only modes of accessing social media – there’s something good here. E.g., blogs and feed readers are distinct from most¹ posting software. Currently, I’m reading Twitter once a day, as a digest, without the ability to scroll an infinite timeline. If I want to post, I open up an entirely different app that nudges me towards writing instead of dashing off hot-takes. Interestingly, Typefully and Mailbrew are what I’m using for this and are made by the same team. I wonder if that was intentional or a happy accident?

Billing/subscriptions/payment projects are absolutely crucial, “undifferentiated heavy lifting”, and difficult to pull off. I have a ton of unstructured ideas about this. The latest kernel of an idea: billing projects are very likely to involve weird interactions between business goals, customer psychology, and anecdata.

The nap hierarchy – naps are probably in my top 5 list of work-from-home benefits.

1. Early versions of NetNewsWire and Userland Radio notwithstanding. ↩

How I work: what might “pairing” with a language model-based assistant (e.g. GPT-3) look like?

How I build: the tension between the web platform being more capable than ever versus the difficulty of standing up many kinds of “basic” applications. e.g. animation is better/more sophisticated than ever, but skipping ahead with building web/database applications requires expertise and a few hours to get something up and running.

How I collaborate: encouraging teams to work in issue threads, thereby improving the quality of thinking (via writing) and building ambient, asynchronous awareness amongst teammates.

Delegating: supporting teammates, delivering the right context, setting good outcomes/goals.

Not delegating: managing/mitigating risk, resolving unknowns. “Delegate downhill work, tackle uphill work.”

🤔 Compilers are at once magic and the closest thing to mechanical tools in a software developer’s experience.

✍🏻 Reflecting on using Shape Up for the past few years…

• Managing a backend engineering team at Pingboard.
• Managers can, and should, do deep work. What forms does that take?
• You can build anything from trust; how do you turn accountability into agency amongst teams?
• How can I get more writing/editing/publishing practice in?
• Meditating & reading