"skill issue" is my favourite phrase
The Friction I Don't Want to Lose
I love learning. And while the friction of solving new problems is increasingly traded for speed, the experience gained by overcoming that friction is as important as ever.
The Paradox of Perfection: When ‘Good Enough’ is Actually Better
Exploring the tension between engineering perfectionism and pragmatic delivery. Discover why striving for the perfect solution often prevents us from shipping valuable improvements and how to find the balance.
LLM Neuroanatomy: How I Topped the LLM Leaderboard Without Changing a Single Weight
ML, Biotech, Hardware, and Coordination Problems. Sometimes I write about hard problems and how to solve them.
Notes on software quality
“The absence of problems” is the best definition I can come up with for quality.
</> htmx ~ Working With AI: A Concrete Example
In this essay, Carson Gross walks through a concrete bug fix in hyperscript to show where AI helped, where it fell short, and why keeping a knowledgeable human in the loop is what kept complexity in check.
Dario Amodei — The Adolescence of Technology
Confronting and Overcoming the Risks of Powerful AI
Breaking My Own Rule (Again): AI and the Job Hunt - Jacky Alciné
I said I wasn't going to lean on generative AI but I also said I was going to leave the tech industry. Here's what I actually used to keep applying and what it did (and didn't) do for me.
A Severe Misalignment of AI in Mathematics
I am proud to be among the list of 25 initial signatories — all Fields Medallists — to the declaration below, which grew out of discussions between ourselves over the last week. We have…
You don't have to be smart if you can think clearly
When you’re on fire, problems are transparent: they’re solved simply by the act of looking at them. Even complicated layers of multiple problems can simply be glanced through like stacked panes of glass. But nobody can work that way all the time.
"Code was never the hard part" is an insult to all programmers — Senko Rašić
The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is c...
Harnessing Frustration: Using LLMs to Overcome Activation Energy
One of my biggest weaknesses as a software engineer is procrastination when facing a new project. When the scope is unclear, I have a tendency to wait until I feel I’ve “felt out” the problem to start doing anything. I know I’ll feel better and work much faster when I get “stuck in” but I still struggle with that first step, overcoming the “activation energy” required to engage with the details. LLMs have been a game-changer for me in this respect: I can just throw a couple of sentences at them with the shape of the problem. This leads to one of two outcomes: The LLM comes up with a good solution, usually in a slightly different way than what I was thinking. I realize “oh wow the solution is much simpler than I thought”. Straight away I start thinking about the consequences of implementing and improving what the LLM suggested. The LLM comes up with a solution that I intuitively recognize as “wrong”. My immediate reaction is frustration (“How could it get it so wrong”) which leads me to go back and forth with the model, explaining to it why its solution could not possibly work. But in the process of arguing with the model, my brain is churning away and generating variations or different approaches that could work. After a while, even if the AI is still on the wrong track, the debate will trigger a moment of inspiration where suddenly the solution will come to me. I’ll excitedly start up a new conversation and start working through it with the model. The key is the emotional reaction I have immediately to the LLM’s response, either excitement or frustration. By harnessing this immediate feedback loop, I get my brain out of its passive, procrastination mode. It’s almost like a jolt: either I’m thrilled because it’s simpler than I thought, or I’m spurred to action by the urge to correct a perceived ‘wrong’ answer. This forces me to engage with the problem in a meaningful way.
bliki: Two Hard Things
There are only two hard things in Computer Science: cache invalidation and naming things -- Phil Karlton (bonus variations on the page)
I work, I think? - Annotated
How AI may quietly dismantle the feedback loop that turns inexperienced people into competent ones, and why my work matters to me.
NP-overrated
If you learned about NP-hard problems in university, your takeaway was probably this:
The peril of laziness lost | The Observation Deck
In his classic Programming Perl — affectionately known to a generation of technologists as "the Camel Book" — Larry Wall famously wrote of the three virtues of a programmer as laziness, impatience, and hubris: If we’re going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We’ve all fallen into the trap of using cut-and-paste when we should have defined a higher-level abstraction, if only just a loop or subroutine. To be sure, some folks have gone to the opposite extreme of defining ever-growing mounds of higher level abstractions when they should have used cut-and-paste. Generally, though, most of us need to think about using more abstraction rather than less.