Dan McKinley says a company gets about three "innovation tokens" to spend on unproven technology. Everything outside its core problem should run on "boring" technology whose failure modes are already known. Adding a new technology should be a deliberate decision for the whole company. Over the years, running many technologies costs more than picking the best local fit saves.
A 2015 essay that still holds up: a simple framework for weighing new technology against the long-term cost of running it.
Senko Rašić argues that the AI-era slogan "code was never the hard part" belittles a hard craft. Programmers should learn both to write good code and to understand users, he says. He calls both "code is easy" and "code is art" cope.
A provocative defence of the craft; the thread mostly calls it a straw man, and that half of the debate is just as useful.
A conceptual paper argues that professional expertise works like a shared commons. Each firm that hands cognitive work to AI acts rationally. Together, though, these firms can drain the deep human expertise a profession needs to renew itself. Overseeing AI depends on that same expertise.
Moves the AI-and-expertise worry from anecdote to a structural argument, framed as a tragedy of the commons.
Sean Goedecke argues that blogging about a topic while you're still learning it is one of the best ways to learn it. Each post should argue a point someone could disagree with. You should research enough to defend that point. You should also be honest with readers about your credentials.
Practical advice on writing to learn, and on staying honest when you are not yet the expert.
Designer Itay Dreyfus says caring too much about your own creative work stalls it. His fix is to treat personal projects with the distance you bring to client work. That distance is what finally lets him finish them.
A short, humane piece on the emotional side of making things.
After a few weeks away from AI, a developer decides most of his agent use was a habit. The habit made him less curious and more anxious. From now on he wants to use AI on purpose. The human should be the loop, calling in an agent now and then instead of getting stuck inside the agent's loop.
A short, candid first-person account of what heavy agent use did to one developer's curiosity.
AI didn't create bad engineers. It removed their speed limit. Anyone can now generate tens of thousands of lines a day. Understanding and reviewing a change is as slow as ever. The author argues this pulls pay apart. The few people who know what the system does get paid more. The rest get priced out.
A pointed take on how AI could split engineering pay, backed by a thread full of first-hand stories.
The author says knowledge workers' despair goes deeper than money. AI hands their already abstract work to agents. That exposes "Workism", the habit of treating a career as the source of meaning, as an illusion. Companies that lose this talent may not get it back. His remedy is to accept that most office work doesn't matter and to look for meaning in people and community.
A long essay that looks past the jobs and money angle to what work means.
A developer learns unfamiliar subjects like chip fabrication in three steps. A coding agent writes a knowledge base and reviews it for accuracy. Then it turns the knowledge base into a low-poly simulation in the style of Rollercoaster Tycoon. He claims the result is "100% accurate and free of hallucinations".
A concrete workflow worth borrowing, though the accuracy claims deserve scepticism.