Links
Social media is where you’ll find the most sublimely interesting and entertaining people in the world. Right next to them are people with so many bad takes and shallow enthusiasms. Of course, all the clankers, some masquerading as human and some transparent in their toaster-ness.
You may think it’s where your people are, but the whole point is to mix your people with the Havers of Takes and the Obviously Artificial. And the advertisements and Calls To Action. You’ll come across your people every once in a while, in between frequent run-ins with people who can’t possibly think that (right?) and obvious ads claiming you’re missing this one thing in your life (click here to subscribe).
Of course it’s The Bad Place!
The big blur – Brian Bailey nailed it. Wish I’d thought of this framing.
We’re living through the big blur. Product, design, engineering, mobile, web, QA. Roles are fluid. Previously clear lines now fade at the edges like lines in an Agnes Martin painting.
I’ll yes-and this: not only are roles and activities blurring, but time is as well. A day spent discussing code in reviews, grilling a feature with an agent, steering another agent to focus on what’s important, keeping projects on track, providing feedback, and monitoring Slack channels leaves the brain feeling like a page full of great ideas all smudged out by the wet hands of an automaton toddler.
Within you are many wolves writing code
One wants to implement this feature to the best of your standards, regardless of the surrounding code. Another aims to fit in with the standards of the existing code, as it is. Still another hopes to write it so that it’s easy to delete and rewrite it again later when more is known about how it should actually work. Still another just wants to get it done.
They’re not wrong, but none of them are right.
There’s one mistake I see more often than anything else, and it’s absolutely deadly: ignoring the rest of the codebase and just implementing your feature in the most sensible way. In other words, limiting your touch points with the existing codebase in order to keep your nice clean code uncontaminated by legacy junk. For engineers that have mainly worked on small codebases, this is very hard to resist. But you must resist it! In fact, you must sink as deeply into the legacy codebase as possible, in order to maintain consistency.
– Sean Goedecke, Mistakes Engineers Make in Large Established Codebases
Interestingly
Three modalities of creativity I am keen to explore: dirt, screenshots, monk-like.
1. Dirt, metaphorically
Take something worthless (e.g., literal dirt, metaphorically non-working code), put great effort into it, get something nice in the end:
Sometimes things don’t go as planned and the product that comes out the other end is really not what I wanted or needed. At that point, the right thing to do is usually to start over from the original specs (and possibly the wrong code) and restart the spec and design process. Then implement again from scratch. There are absolutely projects that I’ve run through this process five or six times as I figured out what I actually wanted or the right way to explain what I was going for.
Dorodango is, essentially, the process of polishing a ball of dirt into a beautiful, high-gloss sphere. The result is genuinely amazing.
— Jesse Vincent, Dorodango
2. Screenshots
Knowledge workers are all taken with our text files, spreadsheets, or design files. We invent ideologies and workflows, have very specific opinions about how to do this thing, know all the keyboard shortcuts, organize them just so, or not at all!
And then, there are eccentrics who have these giant collections of screenshots, thousands of them. Of order screens and login flows and memorable conversations and receipts and profound quotes on the web and sports scores and seventeen iterations of one document/screen/logo.
During the opening of the conference, Omar honed in on the subversive nature of the screenshot. In popular computing, it circumvents the app siloes that define our contemporary digital ecosystems. A screenshot doesn’t need a log in, bypasses DRMs, and is interoperable between practically every single computational device. Even in the “high-culture” of computing, where text is dominant, screenshots prove subversive. The screenshot is unstructured information which must be parsed to offer the tidy data best suited to computer hacking. They are seen as verbose and unwieldly, despite universal adoption. The Tao of Unix is text files, not bitmaps.
— Cristóbal Sciutto Rodríguez
3. Monk-like devotion to the craft
Deep, monk-like devotion to the craft of software development and its output, the application. I love an in-depth, illustrated essay on decisions that go into a carefully considered application.
The initial vision for Paper was simple — build something that has the core tricks of iA Writer, but in a package that feels even more elegant and minimal
…Have people noticed the effort? Most — probably not… but some have.
I don’t have a big connection to make here! Deep attention to detail, knowing when to polish and when to start over, trying to make different media work – that’s it. Make interesting things, interestingly.
Patrick Dubroy, Fast is better than slow:
Think about it — if you’re fast, you get data more quickly. That helps you make better decisions, sooner. It also means you learn faster, and over longer periods it means you learn more. Being fast also means you can try out multiple approaches to a problem and pick the best one.
Fast is more learning is better execution.
Don’t worry about looking dumb. You probably already know that you should share your work early and often. But it’s uncomfortable, so it’s easy to put it off while telling yourself a story like “I have a high bar for quality.”
You’ll get results much faster if you learn to push through that discomfort.
If I’ve learned anything from working with coding agents on a team, it’s to worry less about that one code review where someone points out a howler of an issue with my code. Whether a coding agent generated that code or I typed it in by hand, acting on my teammate’s feedback is an opportunity to show that I care about quality, I listen, and I follow through.
That’s what (still) makes great coders. And, fast fingers.
Frozen 2 should be rated R (Interconnected):
Frozen 2 in which the entire city is almost destroyed by a tidal wave… It is SO LAZY.
While we’re piling on lazy writing here: LOST, and most American television, is particularly lazy about generating consequence and tension with lines spoken with characters holding guns at each other. Do we need the cheap escalation of a gun to know that the character really wants to coerce the other to action? To paraphrase Laurence Olivier, did the writers consider letting the actors act?
(Granted, firearms warp most parts of American culture, but this one is difficult to unsee once you recognize it.)
If the clankers have you down, I recommend: read your favorites, write like that, discover new favorites, write and edit like that, rinse and repeat. It would seem, at this moment, only a human can produce liveliness by chaining words into language and narrative.
Writing is how I build. That’s why I write.
So what had happened was, my daily reading sort of tailed off. Distractions and all that. Then my writing dropped off. And then, the web hit me with three great ideas hit me right in a row. The web provides energy for reading, the reading transforms into energy for writing. Suddenly, here we are, posting the links again. The web is good.
Mandy Brown, Umyazu:
Nor do we read when we slip through the stream or flick through the feed. Reading is an awakening of attention, not a deadening of it. We read to come alive to ourselves, not to forget who we are or what we are doing, or what is being done to us without our consent. We read to encounter the world, to connect what we know to what we do not know yet, knowing all the while that such understanding is always temporary, lovely precisely because it is transient. The suspension of disbelief that a reader brings to a text is an openness to becoming someone new, to shedding old selves and wriggling into new ones. It is an invitation to change.
Austin Kleon, Problems of output are problems of input
When I stall out, it’s time to start taking things in again: read more, re-read, watch movies, listen to music, go to art museums, travel, take people to lunch, etc. Just being open and alert and on the lookout for That Thing that will get me going again. Getting out the jumper cables and hunting down a battery.
First installment of this could-be-a-series of monthly reading notes. I thought I haven’t been reading much lately, and there goes my self-awareness.
You (almost) can’t do too much reading. Lovely thing, that.
Exploring the Rich History of Funk and Soul Music: A Journey Through Rhythm and Emotion:
Funk and soul music aren’t just sounds; they’re vibrant threads woven into the fabric of musical history. Emerging from the rich cultural tapestry of African American communities in the 20th century, these genres have become a cornerstone of musical innovation. They blend gospel’s fervor, jazz’s complexity, rhythm and blues’ groove, and rock’s edge to create a sound that moves both the heart and the feet. Here, we’ll dive into their roots, evolution, and the enduring influence they wield, keeping audiences captivated across the globe.
I couldn’t have introduced the funk better myself.
Related: Maggot Brain is highly rated but still underrated. That album could stand against any of Stevie Wonder’s “classic period” albums.
Fits on a floppy, great idea:
Software has lost its way. Apps that once shipped on a single floppy disk now demand gigabytes of your storage, minutes of your time, and far too much of your patience. We accepted this gradual bloat, but that’s not progress.
Software should be as small as it can be. Not as a gimmick, but as a discipline. The floppy disk is the measuring stick: 1.44 MB. If the software that ran entire businesses could fit in that space, then a modern, focused, single-purpose tool certainly can.
Yep, these criteria make the good stuff:
Launches instantly. Faster startup, nothing unnecessary to load.
Does one thing well. Focused features, fewer bugs, software that lasts.
But, I disagree on some details:
Native only. No dependency bloat, every line of code earns its place.
I usually don’t feel like “native” is crucial these days. Whatever your definition of native is, it’s not a prerequisite for building great software. Even for desktop/mobile platform development using the vendor-intended language and frameworks, the downsides are…a lot, lately.
You can create software that is fast and focused with any language or stack if you’re careful. So, I might replace this one with something about attention to details and care for the craft.
Runs on older systems. Older devices deserve love too.
I love it when this happens. It’s easier to make it work outside native environments, too!
I think the applications are less important than the data. I’d change this one to something about the ability to store one’s own data on a floppy-sized local file instead of in an opaque cloud or a row in a SaaS database somewhere.
Maybe the big idea is that the application and data should fit on the floppy. 🤔
git-spice – stacked diffs, but without another (SaaS) tool to provision and pay for. Excellent ergonomics, if you’re comfortable with the git CLI as-is. I’ve tried this for one project so far, things went as hoped. Moving between commit ‘stacks’ is easy, and rebasing changes from the main branch is straightforward. This is the quality of tool I’d hope to see in git in the first place. But maybe that’s a 2026 expectation. 😇
When you’re stuck or uninspired, reach for your spark file:
This is why for the past eight years or so I’ve been maintaining a single document where I keep all my hunches: ideas for articles, speeches, software features, startups, ways of framing a chapter I know I’m going to write, even whole books. I now keep it as a Google document so I can update it from wherever I happen to be. There’s no organizing principle to it, no taxonomy–just a chronological list of semi-random ideas that I’ve managed to capture before I forgot them. I call it the spark file.
Steven Johnson, The Spark File
It’s a productive trick that doesn’t have an ecosystem of applications, courseware, and influencers wrapped around it. I dig that.
Adjacent: swipe files and commonplace books.
Behind every guitar god there is, literally, a drummer making the odd 7/8 or 5/4 bar sound like 4/4. Paraphrasing Einstein, true guitar gods don’t play at dice or outside of a strict 4/4. (Inspired by: what the heck even is “Black Dog”?)
Squeeze out the trickiest part of the problem, another part of the problem becomes the trickiest. A tale as old as time.
Today, it seems like the biggest opportunities will be in the third of my opening statements. Building systems remains hard. Can I assume you’re familiar with Amdahl’s Law? That’s what’s going on: a massive speed up on a portion of the problem, but as that portion speeds up it becomes less and less of a contributor to the overall speedup. Lowering the costs of the rest of the problem is work that remains to be done. It’s going to take a long time, because the real world is fully of sticky problems, surprising feedback loops, human stubbornness, and the occasional adversary.
– Marc Brooker, You Are Here
You squeeze out coding time, you’re still left with open problems like:
- Running software in isolated, trusted environments (sandboxes) and coordinating work between programs (agents, databases, etc.).
- Human think time, which generates things like taste, and deciding to include this feature instead of that feature because intuition says it will improve the software.
- Coordination and collaboration between humans, which generates recurring meetings (no, thanks) but also great ideas out of nowhere (that’s why we’re here!)
- Verifying what you’ve built and vetting that what you’re proposing to integrate (merge) into the software is any good.
Be careful not to squeeze out the costs that are actually valuable. Otherwise, you might end up with inversions like banks that operate vast airborne transit networks at a loss.
I love when/what Matt Webb builds:
It should be SO EASY to share + collaborate on Markdown text files. The AI world runs on .md files. Yet frictionless Google Docs-style collab is so hard… UNTIL NOW, and how about that for a tease.
We need more “this (thing) should be as easy to collaborate on as Google Docs” sort of things in the world. Granted, I’m not a fan of writing in or using Google Docs! But the collaboration model is right and people know how to use it. May many more bloom.
Dave Rupert, Write about the future you want:
There’s a lot that’s not going well; politics, tech bubbles, the economy, and so on. I spend most of my day reading angry tweets and blog posts. There’s a lot to be upset about, so that’s understandable. But in the interest of fostering better discourse, I’d like to offer a challenge that I think the world desperately needs right now: It’s cheap and easy to complain and say “[Thing] is bad”, but it’s also free to share what you think would be better.
Co-signed.