No surprises
When leading projects, in any capacity, avoid startling your colleagues. Tech leads, engineering managers, product managers, etc. need to keep peers and stakeholders informed. When there are successes, let them know. When risks are discovered, communicate the steps taken to mitigate them. When setbacks occur, indicate how it will affect the remaining scope and schedule of the project. Dig out, not up.
Stakeholders and peers are startled when they think a project is smooth sailing only to hear the ship is sinking. When things go poorly, projects slip by inches, then feet, then all of a sudden. It’s on project leaders to detect these slips, address the root causes, and let people interested in the project know what’s going on and what you’re doing about it.
This may seem obvious! But it’s easy to get so wrapped up in solving the problem that you forget to communicate the problem. To want to say, with ease, “things aren’t going great, but I have it under control.” Or, to feel like the issue is yours alone and forget you may have peers in the organization that could help if only you communicated it.
A non-obvious way to surprise people is to silently, but suddenly, succeed. Release new features or change functionality in production without any kind of internal notice or documentation, and I’ll bet you hear something from customer support, marketing, sales, etc. They won’t begrudge you for doing your job and shipping code, but they might ask you to please let us know next time so we can prepare our teams, campaigns, or update our documentation. Or, they might come at you with pitchforks, wanting to know why things are changing out from under them.
Corollary: Don’t Be Spooky. If you need to tell someone, IC or stakeholder, that a project has run into surprises, just tell them. Don’t open up with context-free messages like “can we talk?”
Have the hard conversation now, before it gets tougher.
Dig out, not up
Late projects stay late. It’s terrifically rare to “catch up” on a late project. When projects run late, it’s because you’ve missed something in your original estimate: you’ve guessed that work will take
xdays, but it’s taking1.5x, or whatever. For you to “catch up”, your estimate would have to be wrong about the rest of the project, but in the opposite direction. Even if you correct what led to the overrun, it’s terrifically unlikely that you’ll somehow make up time.— Jacob Kaplan-Moss
Don’t tell people you will get back on schedule by working harder or having better luck. As Jacob points out, there’s already evidence that your team’s capacity or luck aren’t harmonizing with your existing estimates and hopes!
Instead, talk about scope/time trade-offs that one could make to focus on what’s most important. Share the results of retrospectives.
Attempt to explain how you got here in the first place. Caveat, you’re unlikely to fully explain how a software project surprised you on the first attempt. You’re working from an estimate, a projection from wildly incomplete information. Now you have slightly more information, but still an incomplete model. (You won’t have a complete model until you finish the project, sadly.)
Share how you might avoid this surprise in the future. Caveat, the remedy is often worse than the disease. Particularly in software development, if we attempted to prevent or foresee every possible illness, the project would barely get off the ground before it was cancelled. See also: agile software projects accidentally reinvent waterfall when they seek to add more predictability and remove risk/surprises from the process.
Previously: Your estimates were wrong? Communicate!
The drums weren’t the only instrument to play with rhythmic expectation, because in funk, every instrument was used as a drum, especially the bass guitar, which also began to take on the melodic work. Funk made the bass line prime.
— Dan Charnas
Rocco Prestia and Doc Kupka of Tower of Power are great examples. Prestia’s bass lines are percussive and precise but counter-melodic. Kupka consistently plays baritone sax off the beat, in some ways more part of the rhythm section than Prestia. Tower of Power’s looks didn’t hold up, but their funk credentials remain robust.
(Sixteen-year-old Adam would very much approve of this post.)
For the love of fast (looking) machines. From the exhibit outside the Walt Disney animatronic show currently on at Disneyland.
In-memory Filesystems in Rust. Spoiler alert, introducing indirection around filesystems isn’t a test performance win, for some combination of use cases and modern hardware:
In the meantime, it seems like modern SSDs (and modern OS filesystem caches) are so fast that it doesn’t even matter. Eat trash, be free, test directly against the filesystem. Why not.
— Andre Arko
“Eat trash, be free”, ain’t that the wisdom of the times? And you can avoid a purity/orthodoxy TDD test. Take my complexity, please!
My favorite set of magic words to push this process forward is to ask: How will we know it works? Don’t accept silly answers like, “The button will be red.” That’s not what the person who wrote that ticket is looking for. They have a reason for wanting the button to be red and you need to know it.
— James Edward Gray II
You’re going to want to read about why that button is red and how that choice avoided a lot of speculative coding.
🌶️ The collected works of Motown are at least as good as Mozart’s.
Adjacent: Phil Collins’ and Michael McDonald’s albums of Motown covers are pretty dang good, if you want to explore beyond the originals.
When in doubt or staring down a blank canvas: Readme-Driven Development still exists. And, is possibly even more effective in a time when you can paste a design doc into a slot machine made of numbers and get (possibly working) code out the other end.
Finishing is a mindset
The last 10% of any creative act is the hard part. (Previously: Finishing is a skill.) You had an idea, thought it would take X days, only to find X-1 days of all these other things that have to be done. That’s functional scope creep.
Finishing, actually getting the draft or project out of your computer and out into the world, that’s a whole other list of things. Lots of work, and surprises, are lurking here. Call it delivery scope creep. Or a finishing tax. And, it’s a mental challenge, getting over the “they’re all gonna laugh at you” fear. (But not in the Adam Sandler way.)
The more steps you can remove from putting something out there, the more you can put out there. (There’s always money in the shovel stand.) Ergo, the continuous development of new systems and tools to make online publishing easier, despite the market having excited for nearly three decades.
Related, the programmers’ credo: “we do these things not because they are easy, but because we thought they were going to be easy.” So goes software, so goes any other creative endeavor.
Writing words and writing code feel similar, for me. (And, playing a musical instrument, if I go far back enough.) They are equal parts mechanical performance, exercise of taste, and act of creation. For all of them, I want to be in a flow state. I want to go as deep as I can, time permitting. I want to hold a whole world in my head. I want to work among as many details, as deeply as possible.
Finishing, whether it’s releasing software or publishing an essay, reviewing code, or editing and revising words, are a different skillset. Differently creative, but still putting something new into existence. There’s a nice symmetry there. If you can get good at editing and revising words, you can get good at editing and revising code.
Getting over the last 90% of any kind of project, whether code or words or music, is the same skill.
It’s like the last 90% of anything is just a mindset, almost a resilience of mind. If you can get good at one, the skill carries over into anything that requires finishing.
It feels like life pulls a fast one on us, at times. “What got us here, won’t get us there”. Making the software, essay, or music is different from shipping, publishing, or releasing it. But if you can get good at any one of shipping, publishing, or releasing, you are considerably further ahead on getting good at the other two.
Good enough to get going
The winning scenario for agent-assisted code, design, science, etc. is humans having more time to do creative and impactful thinking because computers/LLMs do the tedious setup, easily verified work, and gather preliminary materials that humans turn into inventions.
FWIW, I don’t think the worst scenarios are likely. The future isn’t atrophying literacy rates or people turning off their brains to tell LLMs what to do. It’s probably not Malthusian job scarcity or Keynesian leisure abundance, either.
The best outcome, IMO, is that producing almost-good-enough software, design, science, etc. is possible for more people, particularly those without specialist degrees.
You won’t have gym owners producing billion dollar SaaS companies, but they might produce software good enough to run their business without needing to contract out to a software developer.
You won’t have software developers producing the same level of design and art direction you see in major films. You might see them producing design good enough and sufficiently distinct that they can wait to bring a designer on until they’ve found their market.
You won’t have writers discovering new axioms of math and science, but you might see them correctly apply statistics and physics so that stories about finance and space battles are slightly more realistic.😉
In short: experts in topic A won’t find themselves held back by having an idea that requires expertise in topic A and topic B, where topic B is too deep for them to “just get good at”. Fewer Wozniaks will have to find their Steve Jobs, fewer Springsteens will have to find their Landaus.
It won’t exactly be you can just do stuff. But, perhaps you can get far enough along that collaborators to fill in the specialties you don’t can find you.
This is a fancier way of saying that it’s unfortunate that naps don’t make one feel more energetic afterward:
So, if you read through the Philokalia, it is very common to find the same author alternating between talking of thoughts (logismoi here referring to negative, vicious thoughts that could lead you astray) and demons. Acedia, the vice of listlessness and despondency, is called, for instance, ‘the noonday demon.’ Sometimes it is treated as an internal struggle; other times it reads as if a personified demon is the cause of these temptations; if Graiver is right, then these are merely two ways of experiencing and conceptualizing the same phenomenon.
— Jared Henderson, Asceticism of the Mind
I give them grief, but I do love afternoon naps.
💤 Midday disappointments:
- A dip in energy is not fixable by napping, and napping does not restore one’s energy
- A superb nap is restorative, but difficult to predict or consistently generate
- A short nap might make you feel better, but rarely more energetic
- Coffee after a certain hour is contrary to sustainable energy and really only papers over the problem
Multitasking with my eccentric pal
Over the course of two experiments within two half-day coding sessions, I better glimpsed what working with coding agents might look like over the next couple of years.
1. I teach the agent to build a simple Rails CMS
This is pretty unremarkable, given my experience. But, like so many lately, I wanted more reps at exploring agent coding workflows. In particular: what works for guiding an agent and keeping it on-track?
I did a bit of the upfront setup with wits alone. Executing the correct boilerplate is where our LLM assistants seem to most reliably get themselves into early trouble. Plus, Rails’ whole thing is accelerating this part of a project. If somehow it were slow-going, it would be a tremendous failing of the framework. But it wasn’t!
Next, I set up the basic models I wanted for this particular little CMS. Again, a way that an LLM often goes off the path is trying to build new models just right. So I did that part myself. Perhaps, this is also where I’m most opinionated about getting things right. 🤷🏻♂️
Finally, I made sure the app had good guardrails in place. Namely, Justfile tasks to run tests, rubocop checks, and brakeman. Claude Code seems to do really well given those kinds of guidance, so setting them up up-front makes sense.
From there, I let the machine take the wheel. I gave it brief instructions, sometimes using plan mode to build up context first, and let it go. Document and element model CRUD, done. Tweaking a DaisyUI theme to look a little more Swiss design or Bauhaus-y, done. Build up a document editor that works with the document and element models at the same time, done.
Result: taking a little time up-front to lay the right foundation and guardrails makes agent coding way better.
2. The agent teaches me about LLM evals
This one is (unintentionally) the opposite of what I was doing with Claude and Rails. In that case, I was working with Claude as the expert, guiding it towards an outcome I knew was easily within reach for this project.
For this project, I was experimenting with using Claude to teach me how to do LLM evals. My understanding is that these are super important for building AI-based apps; they are as close as you can get to a TDD-style feedback loop to verify your work when working with nondeterministic language models.
To start, I used Claude (not Code) and asked for a starting point to learn LLM evals. I wanted to get something simplistic, like a hello world of that problem domain. I would rather not set up multiple ML frameworks (looking at you, Conda), so I said let me run these models locally, and I’m fine with using Python.
Claude generated some Python code, which I pasted into a new uv project and got started. From this point forward, I was using Claude Code to restructure code, like moving code into source files out of Jupiter notebooks or putting code plus explanations back into Jupiter notebooks. I’d also ask why a particular approach was taken or what jargon means.
In this case, I was really using Claude code to teach myself something new, and it was the expert guiding me. For something like this where I’m not caught up in the specifics of machine learning and its problem domain, it’s a perfect approach.
Result: I got way ahead on a new-to-me topic over the course of a couple of hours.
3. 💥 At the same time
The big reveal is, I was working on these two projects at the same time. Two terminal tabs, two Claude Code instances. “Talk” to the first one, let it run while I talk to the second one. First one finishes, talk to it, rinse and repeat.
At first, this was like pairing with two developers working on entirely different projects. And they’re sitting on either side of me, sometimes attempting to talk at the same time. My brain hurt and it felt like I was moving slow enough that single-tasking would have been far more effective.
After 60 minutes or so, things seemed to pick up. I felt like I was doing a better job of bouncing back-and-forth between the two agents. I was quickly improving my prompts, allowing the agents to work more effectively while I was working with the other agent. However, I wouldn’t say I mastered multitasking in one hour. More like, I came to grips with keeping each agent going, like keeping a room full of eager developers moving independently despite needing frequent directions.
It’s still crucial to taste test the work frequently. Product-focused developers/managers will have a leg up here because they’re used to working this way. I think anyone who has good attention to detail and the ability to communicate what they want is going to have an advantage here.
From all this, I learned a few things:
- Working with agents is going to look similar to multitasking and delegation.
- To keep up with multitasking, humans will need to get as good at context management as agents (we both have limited context windows).
- Often, we’ll mentor agents to get the best results, particularly by giving them good guardrails (automated and dynamic context generation).
- In some cases, the agents can teach us just enough to get stuff done.
- For better or worse, there’s still much to explore, and the frontier is moving quickly.
📚Currently reading:
Ursula LeGuin, The Language of the Night. A series of essays about writing, science fiction, and LeGuin’s own works. The only novel of hers read is The Dispossesed, but I’m enjoying the heck out of her non-fiction writing and thinking. It’s pretty timely, despite being fifty years old in most cases. Bonus points for LeGuin being a longtime Portland, Oregon resident as well. And, now I really want to read essays and short non-fiction from other favorites like Vonnegut, Stephenson, etc.
James Gleick, Genius. Gleick isn’t quite Caro, but his non-fiction writing really pops. And how could it not, with a subject like Feynman?
Frank Herbert, Children of Dune. Messiah was a bit short, and felt like nothing happened, even though it rather upends the story you’re expecting to get. This one feels like a bunch of scheming and setting of the dramatic tables. Not as much world building as the original Dune. Unsure if I’m up for reading all six of these books. I’ve heard it gets even weirder though!
Craig Mod, Things Become Other Things. I’m, obviously, a huge fan of Craig’s writing. There’s less “meta” about the actual walking in this one. More of an interwoven story of Mod’s childhood friend, observations of the people and places he meets whilst walking, and his own life story. It’s a lovely bit of memoir.
The problem with liking anything besides “ahead of their time” musical groups from the 90s like Radiohead or Wu-Tang Clan:
- Everyone who was a teenager in the 90s has one or two favorite bands or albums that they hold dearly and honestly.
- The problem is, basically every musical group from that era has its legitimate detractors.
- Thus, 90s kids will have to defend their choice to others for the rest of their known lives.
(Mine are Red Hot Chili Peppers, Primus, and Rollins Band. 🤘🏻🤷🏻♂️)
Yesterday I coded with only my wits for the first time in a while. It was pretty great. Not quick, but educational. Not efficient, but full of that great feeling when challenges are tackled with one’s own intelligence and experience. Do recommend.
Coding agents create an opportunity for shorter coding times, faster iteration, and shorter feedback loops. That opportunity is wasted if we don’t solve for all the reasons a software project can go sideways that aren’t “we couldn’t type fast enough”.
“Lowering the cost of writing code was the thing that no engineering leader asked for, but it’s the thing we got.”
— Kellan Elliott-McCrea, Vibe Coding for Teams, Thoughts to Date
“The last part: once you’ve created a situation where failure is safe … you need to be prepared to let failure happen.”
— Jacob Kaplan-Moss, Make Failure A (Safe) Option
If teams are (still) afraid to slip a deadline, accidentally ship a bug, or cause an unforeseen performance problem, there’s still a problem. All the LLMs and coding agents in the world won’t fix it for you.
The more failure is a socially acceptable reality and tool-supported via feature flags, fast rollbacks, observability, blue-green releases, etc. the better your team will operate. A small part of this is building better tooling for detecting, recovering, and remediating surprises. The majority of the effort is in leaders supporting the team and the team supporting each other in stressful times. 🧠
Computers are also free to be weird:
I’m a programmer. You’re probably a programmer. We think in systems, deterministic workflows, and abstractions. What’s more natural for us than viewing LLMs as an extremely slow kind of unreliable computer that we program with natural language?
This is a weird form of metaprogramming: we write “code” in the form of prompts that execute on the LLM to produce the actual code that runs on real CPUs.
— Mario Zechner, Taming agentic engineering - Prompts are code, .json/.md files are state
This workflow, for tedious porting of animation engine code to many languages and targets, has a lot of human-in-the-loop affordances. If I were a betting man, I’d wager on human supervision entering the lexicon as context engineering and vibe coding fade in the hype cycle.
I kept an 8-week streak of writing and publishing a newsletter essay going. I love the output, but not that it absorbs almost all of my writing energy. Back to re-thinking the format on that one.
“It ships because it’s 11:30am” was useful in setting that streak. But “focus on the 2 or 3 most important things, let everything else sit sadly in the corner” is also a handy regimen. In this case: 1) job searching, 2) get a newsletter out there consistently.
Courtney and I are heads-down at furnishing and tidying our basement, so folks can visit. I’m going to count that work as a win for “building things”, even though it’s not software or writing.📈