Our calendars are often painful because they display order (meetings) too well, but don’t display disorder (surprises and interruptions) at all.

Into every developer’s day (and managers in particular) arrives surprises, interruptions, questions, and side-quests. A bit of chaotic disorder.

Personally, in signing up for the job of engineering manager, I feel like I also signed up for the job of handling surprises and side-quests. I take them on not to protect my teams’ focus or time, but because surprises and questions are some of the best kind of information I can receive. They represent the friction points between my mental model of the organization or system and the details of the real world.

I would probably trade more interruptions and side quests for fewer recurring meetings!

Sync Engines are the Future:

So, what’s the significance of sync engines? I have a theory that every major technology shift happened when one part of the stack collapsed with another. For example:

  • Web apps collapsed cross-platform development. Instead of developing two or three versions of your app, you now develop one, available everywhere!
  • Node.js collapsed client and server development. You get one language instead of two! You can share code between them!
  • Docker collapsed the distinction between dev and prod.
  • React collapsed HTML and JS, Tailwind collapsed JS and CSS.

So where does that leave sync engines? They collapse the database and the server. If your database is smart enough and capable enough, why would you even need a server? Hosted database saves you from the horrors of hosting and lets your data flow freely to the frontend.

  1. Conceptual compression is a big deal. Even discounting for uneven distribution of technological shifts, like Docker dev environments and collapsing client/server, HTML, and CSS all into JS.
  2. Sync and local-first storage engines seem like they could be a big deal. It’s a tricky problem to solve. And, governments taking a turn for the weird lately, being able to move your data to another locality and point, with certainty at where data rests, is a useful ability!

Tina Turner covers, very slowly:

On the upside: the more I put my love of songs played slowly into the universe, the more it provides! On the downside: I may have to rewrite my laws of slow songs. 🙃

These two traits—high mental capacity and clear focus—are essential to solving all but the most trivial computer programming tasks. The ability to maintain a large “mental stack” and the discipline to move seamlessly up and down that stack without succumbing to distraction are hallmarks of many great programmers.

— Justin Searls, Programming is about mental stack management

I’m reminded that one of the most amazing developers I’ve worked with was legitimately able to multitask. I think this was due zero-cost push/pop of their context stack. Whether this was possible because of a unique brain or an excellent system of note-taking, I don’t know!

Text boxes were not meant for collaboration.

How often do you find the majority of the coordination, collaboration, and team work you do happens by typing into (sometimes unsophisticated) text boxes and reading what other people typed into similar text boxes?

And now we’re increasingly typing in text boxes to interact with simulacra of human intelligence!

Emoji have helped — teamwork is easier if people opt into leaving hints about how they feel about something. Corollary: do not try to dead-pan in a text-only or high-latency video format. It will only end poorly.

I’m not entirely sure what to make of the humble text box’s crucial role in our society increasingly built on communication, knowledge, and using the two to generate more of the latter.

On one hand, before there were text boxes, writers have used various styli, pens, and typewriters to compose basically all of human culture and knowledge. So maybe the tool-in-hand (i.e., a text box) is not the crucial element.

On the other hand, given slightly more expressive tools, musicians have created the gamut of musical culture in only a few hundred years.

Every career step is searching for the next set of collaborators. And, even in a buyer’s market like we face today, it’s a bidirectional affair. The employer and the employee have to choose each other. Granted, I’ve been at this particular job search longer than I’d hoped!

New to me diner. Old school “where people meet in TV shows” vibes. Perfect for a Friday morning.

Vibe coding is generating code with an LLM (Claude, ChatGPT, Copilot, etc.) and just going for it. No review, no tests, just prompt/reload/repeat.

Hopefully, you’re only doing this for prototypes! I’m sure some folks are not. Surely, they don’t read this website.

When working this way, I’m tempted to accept every suggestion from the robot “product” collaborator. Yeah, my humble little idea could use a two-pane navigation interface, lazy update semantics, insightful logging, robust error handling, and keyboard shortcuts! Sure, go ahead and try to implement that thousand word spec you just generated in one shot. Without automated feedback. I’ll wait.

This goes about as well a human trying to implement the entire spec in one epic commit. At best, you get a big ball of illegible mud that looks right but doesn’t quite work. At worst, it’s riddled with syntax errors or misused APIs, aka “hallucinations”.

For better or worse, an LLM can slop out as much code as you are willing to pay for, but the compiler/runtime still has the last laugh.

A return to hand-written notes by learning to read & write – Google research on training models to recognize not just text in handwriting, but the actual strokes. So you could color or even edit-in-place the handwritten strokes later on. I hope someone is working on productizing this! A Remarkable/Kindle/Boox/Daylight tablet that recognizes sloppy handwriting and allows tweaking it later would make e-ink displays live up to the name. 🙃

Adjacent: Ink and Switch is publishing more of their programmable ink work lately.

If we play our cards right, the next couple years could be exciting for pen-and-paper sorts of thinkers.

Harper Reed, My LLM codegen workflow atm:

If you have a small or large project that you are procrastinating on, I would recommend giving it a shot. You will be surprised how far you can get in a short amount of time.

My hack to-do list is empty because I built everything. I keep thinking of new things and knocking them out while watching a movie or something.

The workflow includes: prompts for generating product requirements, technical specifications, project plans. It recommended tools for implementing those ideas into new and existing projects. CLI-friendly throughout, no need to change workflows to an AI-infused flavor-of-the-month. And, there are caveats for skeptics. It’s not a “everything is shiny and free from surprising consequences” sort of piece.

As if you haven’t heard it enough lately: it is, earnestly, mind blowing that we can go from a few sentences describing an idea to a working prototype in a few hours of supervising an LLM. Inevitably, we’ll learn about shortcomings, scaling problems, and pitfalls in the coming years. As ever! But, the cost function for software is going to change a lot in the coming years and, if we play our cards right, it will be a fun ride.

Improving Team Morale is not an Objective, Marc Gauthier:

  • Morale is a byproduct of everything going on in the company. While improving it shouldn’t be an objective in itself, there are many reasons to pay attention to it.
  • Instead of focusing on mood or morale, gather qualitative feedback on specific topics. This is more actionable and precise, and should help you address actual issues and not the resulting low morale that is just a side effect.

Morale is a second order effect of the fundamentals that managers and leadership work on. If the outcomes, process, technology, teams, and people are aligned and thoughtfully cared for, good morale is possible. If one or more are misaligned, morale and motivation can suffer.

Mikkel Malmberg makes macOS apps “for the connoisseurs,” creates lots of little web things, and has a pretty delightful YouTube channel where he shares his creation process. While you’re there, scroll to the very bottom of his webpage for a surprise.

Zed now predicts your next edit with Zeta, our new open model. I wouldn’t guess that new features in a programmer’s editor require such attention to detail in user experience and development of a specialized language model for code edits. Watching the video on how they built it show how deep they went in building this. Seems like it was worthwhile! 👍🏻

I’m delighted that there’s still plenty of room to explore for programmer’s editors. And, we’re not in a monolith corporations vs. open-source world like we have been in years decades past.

Zed is a product (and team) with big potential. It’s not yet right for me, but worth keeping an eye on.

A parable of adventures

Consider two adventurers, one setting off alone and another setting off with fellow explorers. Both in search of greater glory through software development. 🙃

One adventurer closes social media, shifts into Founder mode, and grinds out “wins” to the satisfaction of their benefactors. They move quickly, but sometimes diverge from their fellow explorers. When discarding a day’s work that solves the wrong problem is drama-free, they may have gone further than their fellow explorers.

Another adventurer has learned how endeavors succeed from experience and observation. The adventurer knows they will create something of intangible greatness by influencing a team of explorers. At times, the journey must pause. The team of explorers gathers to consider the map and decide how to proceed. These moments of collaboration and coordination are essential to the journey. The adventurer who only knows how to proceed alone will fall behind the adventurer who can rally a whole expedition crew. Thus, the adventurer does not directly produce the journey, but is essential nonetheless.

Thus, the team of explorers, when pulling together, goes much further than scrappy bands of individualistic explorers often pulling at odds with each other.

Previously, an iron rule of Aretha Franklin: she could sing anything slower and better than anyone else.

Update, a contender has entered the ring: Carole King performs “You Make Me Feel Like A Natural Woman” pretty dang slowly. Which she wrote!

So I have to relax the iron rule here. That’s okay, I have another one.

New iron rule of Aretha Franklin: no one made ‘em sweat like Aretha. In part, because Aretha contractually insisted every room she played have the air conditioning turned off to protect her vocal cords.

About a VH-1 Divas television performance:

As producers laid out the run of show and began rehearsals at the Beacon Theater an electrician called in to work on the air conditioning accidentally flipped a switch and cold air began blowing down on the stage. Now, it was widely known at the time that Ms. Franklin had a clause in her contract that there was to be no AC during her performances and rehearsals as the cold air agitated her vocal chords and prevented her from giving her best performance. It wasn’t a matter of being high-maintenance; it was her professional commitment to giving her audience her best.

Next time you’re watching a live performance, look at how much Aretha, and everyone else in the room, is sweating. It’s not just the stage lights. She’s the queen for a reason!

A field guide to exploring rabbit holes

You’re deep in eldritch code, a product problem, or a cross-functional issue that is affecting your team. Hours have passed, and you feel like you’re only starting to get your bearings with the issue. Finding a solution, let alone considering its consequences, seems further hours away.

You’re down a rabbit hole. You need to explore a very open-ended concern, but you also need to maintain a bias toward action.

Don’t go without a time box or teammate. Set a time limit. Or, ask a colleague to keep you accountable. You want a constraining mechanism to pull you out of the hole if you get lost.

“Rubber duck” the issue before you start. Explain it out loud or write a summary in your notes. You may activate a different part of your brain and talk yourself out of the rabbit hole entirely.

Keep notes. Track every conceptual tunnel you explore. Note the dead-ends and red herrings. Show something for your effort, even if you don’t find what you were looking for.

Tell teammates what the rabbit hole is and why you think it’s necessary. Ideally, you can explain this in a sentence or two at most. Think about how long you think it’s worthwhile to go down that rabbit hole. Don’t spend more than that in the rabbit hole!

When you encounter black boxes, rabbit holes in rabbit holes, note them and keep moving. You’re already distracted by this rabbit hole, don’t get distracted from your distraction! Not all rabbit holes are worth exploring – some lead to deeper problems without payoff.

You never stop growing as a project leader.

Hurry up and flub your first fifty projects; the sooner you learn from stumbling, the better. Get a taste for all the technical and interpersonal ways a thing can go sideways. Grow past trying to use process to block all the ways projects have punched you in the face. Develop your sense for a project that is drifting off the golden path. Experiment with and develop your moves for bringing the project back.

Accept that people will always ask for estimates. Find peace in a way to provide them honestly. Help your team use estimates as planning and research without feeling like they’re setting themselves up for failure.

Most importantly, give your team the freedom to solve meaningful problems instead of grinding through a backlog of tasks and epics.

Perfection often manifests as procrastination. But, we imagine our work with more perfection and grandeur than we could hope to achieve in reality. By definition!

Something—our limited talents, our limited time, our limited control over events, and over the actions of other people—will always render our creation less than perfect. Dispiriting as this might sound at first, it contains a liberating message: if you’re procrastinating on something because you’re worried you won’t do a good enough job, you can relax—because judged by the flawless standards of your imagination, you definitely won’t do a good enough job. So you might as well make a start.

— Oliver Burkeman, Four Thousand Weeks

Better to get a bit done today, no matter how small or imperfect. Over the days and weeks, what’s done will compound. That compounding effort yields a better idea of how to realize what you imagined, and opportunities to reach for the perfection or grandeur originally imagined. 📈

🔊Recently listening, mostly jazz

“Puzzling Evidence”, The Talking Heads. Somehow I’ve just noticed this song. It sounds like if the E-Street Band helped write a Talking Heads song. Which is not a thing I would expect of The Talking Heads.

Get Up With It, Miles Davis – I missed this in my deep dive. It’s real good! Very clanky.

Naked Lunch soundtrack – Howard Shore, Ornate Coleman, London Philharmonic Orchestra. Another fantastic discovery. Jazz/bop film soundtracks - I did not realize this is a sub-genre!

The Birthday Concert, Jaco Pastorious – like the opening of SNL was a whole album. Also, a curious preponderance of steel drum solos. This was an extremely formative album for 16-years old Adam, but I recently revisited it and still love it.

The Great Concerts, Dave Brubeck – another favorite of 16-year old Adam. Most notable: in the liner notes, the drummer noted they took every song way too fast. I think this worked out.

Mercy, Mercy, Mercy, Cannonball Adderley Quintent – “the” soul jazz album. More traditional Joe Zawinful, great contrast to the Weather Report stuff. Could you pull off the name “Cannonball”? I could not. The title track is one of the only songs I taught myself on piano, but I can only play one hand at a time. 🤷‍♂️

A few weeks ago at work we had a talk where senior developers (including me) were invited to spend around five minutes each talking about our personal software development philosophies. The idea was for us to share our years of experience with our more junior developers.

– qntm, Developer Philosophy

My favorites: “Aim to be 90% done in 50% of the available time”, “It is insufficient for code to be provably correct; it should be obviously, visibly, trivially correct”, “Write code to be testable”.