Posts tagged “writing”

Speed, Fidelity, and Thickness

Three related articles, with minimal commentary:

Florian Herrengt, “AI is removing the middle class of software engineering”:

Excerpts

AI removed the speed limit

AI makes projects with weak engineering culture fail much faster.

There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.

The most tragic aspect of this way of working is that, to the untrained eye, it works.

If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.

Just like someone buying a new luxury car on a credit card. You don't see the debt. You just see the car that looks great.

“Bad engineers always existed”

The difference is the speed.

It is the difference between crashing at 30 km/h and crashing at 200 km/h. Before AI, a bad engineer would struggle to produce code that even compiled. When they did produce something, it took them a long time and the blast radius was limited. The damage was bounded by how fast a human could type.

Now a bad engineer can produce 10,000 lines of working code before lunch. The damage we can do in an afternoon used to take them months. The speed at which bad decisions compound has changed completely while the speed at which you can fix them has not.

“Will anyone actually care?”

They will care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.

This was already happening before AI. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can get there in just a few months.

Reminder: being good at software engineering isn't just about algorithms or systems design or whatever. Even pre-LLMs, it 100% definitely wasn't correlated with how fast you can put out new features.

It's about creating a system that's easy to reason about: easy to debug, easy to change, and hard to break—even when it's complicated.

Read more →

Simon Willison & John Gruber on Blogging

Simon Willison, “Simon Willison on Technical Blogging”:

My number one tip for blogging is to lower your standards! Aim to hit publish while you are still actively unhappy with what you have written, because the only alternative is a huge folder full of drafts and never publishing anything at all.

Nobody will ever know how perfect the thing you intended to write would have been. The flaws you see in your writing are invisible to everyone else.

John Gruber, “Simon Willison on Blogging”:

Me, I try to get into the mindset of playing live music, not recording a studio album. Except when I’m writing a piece where I really want it to be an album. Those aren’t rare, per se, but they’re occasional. If I tried to make every post a hall-of-famer I’d never get anything out.

I’m aiming for professionalism. I’m performing live in front of an audience — not just jamming in my garage or bedroom, fucking around. So I’m careful and concentrate. I want to hit every note, in time. But at my best I’m moving from song to song.

Read more →

Writing short docs well

Tom Bedor wrote how to write good short docs. Most of it lands. Key takeaways, with some riffing:

Optimize for short attention spans. Think in tiers: the 5-second glance (title and first line), the 5-minute skim (summary and headings). This means: clear titles — the most important line in any doc. A concise summary at the top covering what's in scope and what's not. Strong headings. Collapsible/tabbed sections where the format allows.

Read more →