Adam Keys is Thinking

I joined a new team as a staff software engineer a couple of months ago, huzzah! Some reflections:

I’m writing TypeScript and Python, after many years of Ruby with a touch of JavaScript. Types are, after about 25 years of software development, part of my coding routine. They’re not so bad these days. It finally feels like types are more helpful than a hindrance.

Thankfully, this code is not too long in the tooth, so the dev loop is fast and amenable to quality-of-life improvements. But, it’s a big, new-to-me codebase and a deep domain model. I wouldn’t get much done were it not for coding agents, their ability to help me discover new parts of the code, and having spent much of the past several months practicing at steering them. So all that Claude Code experimentation was time well spent!

The team uses Cursor. I gave it a try and am mostly onboard with it. I still think JetBrains tools are more thoughtfully built than VS Code and its forks. But, Cursor’s agent/model integration is pretty dang sweet, I can’t argue with that.

And, Cursor’s Composer-1 model is fast and sufficiently capable. I think there’s something to be said for faster models that can work interactively with a human-in-the-loop. Cooperating with the model more like the navigator in a pair programming situation than a senior developer vetting the work of a junior developer. It feels like OpenAI/Anthropic/etc. really want to show off how long their models can work unattended. But I think that only magnifies the problem of reviewing a giant pile of agent-generated code at the end.

I suspect this is going to change our assumptions about tradeoffs on ambition and risk. If we’re lucky, we can replace a lot of soon-to-be-legacy process and ceremony that was about hedging and had nothing to do with the quality of product or code at all.

I wonder: besides wishing code into existence, which costly things are now cheap-enough? Agents reviewing agent-generated code doesn’t work that well yet. But, agents can tackle refactors, documentation writing, and bespoke tool creation. All the things we’ve previously been forced to squeeze into the time between projects. The cobbler’s children can now have pretty good shoes.

A few reflections on what I’ve been building (with) lately:

• llm is great for prototyping many kinds of workflows. If you’re thinking “I’d like to build an app with some intelligence” and “I don’t mind tinkering with CLI apps”, give it a go. In particular, templates and fragments are very useful for assembling the rudiments of problem solution.
• Part and parcel with using llm, I’m tinkering with locally runnable models via Ollama. On my M3 MacBook Pro with 24 GB of total memory, Qwen3 and Mistral are small enough to fit into GPU memory and run pretty quickly. With “thinking” disabled (the open models will spend many tokens talking to themselves!), they are fast enough for development work and experimentation. They definitely aren’t at the same level as the latest from Anthropic or OpenAI. But, the future is promising for using these smaller models instead of relying on metered API access for every single token of intelligence.
• Putting those two together, I’m hacking out some tools to help with job search. My goal is to reduce the effort to see if a job description matches what I’m looking for, generate ideas for customizing a cover letter to the role, and provide useful answers for any pre-interview questions. Next step: put an actual UI on my llm-based prototype.
• To wit: I’m studying up on Python, FastAPI, HTMX, etc. by asking Claude Code to write learning projects and then asking it questions about why it wrote them that way. Turns out, this helps me with language idioms and library setup pitfalls. Wild times!

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