This blog is about how we represent ideas in computers.
I recognize that this is a pretty niche topic, and for the most part, I expect that most of my current readers are software engineers, since that’s really where the rubber meets the road of “representing ideas in computers”.
That means most people probably wouldn’t ever read this blog, because most people don’t make software.
Which is a shame! Because software is incredible. It is pure intelligence made real: diligent, patient, immeasurably fast, and endlessly malleable. Nothing like our modern world would be possible without it, and many of our current problems would be more tractable (if not solved outright) with better software.
The reason most people don’t make software is that making software is really hard. It’s a kind of focused intellectual labor that most people aren’t well-suited for, because it involves gobs of arcane and ever-changing detail that all has to be arranged just so. It’s no wonder we call it “code“: it’s cryptic, and making it is slow, error-prone work. (Which, by the way, is also why so much software in the world just sucks—it was just too slow and expensive to make it any better.)
Well, a very important thing has happened: it has gotten much, much easier to make software.
This is one of the consequences of generative AI: we now have machines that can effectively and rapidly translate between "what you want" and "how to do that in code". This means that all that effort and arcane knowledge required to create software has decreased dramatically (and it’s getting easier by the day).
So … why isn’t everyone rushing out and using AI to help them write code to solve their problems?
There are two reasons: one easy, one hard.
The easy reason is that they simply don’t know (or believe) that this has happened. I work in a prominent big tech company, and I can tell you that many of the people I work with don’t really know (or believe) it.
But the harder reason is that even with this change, the uncomfortable reality is that you still have to be smart and diligent to make software—at least, if you want it to work.
Maybe you’ve heard the phrase “vibe coding“? That’s when you use AI to write some software, but you don’t even look at the code. You have no real idea what it’s doing on the inside, or how it’s conceptually constructed, beyond what you can see on the surface.
I’m not here to denigrate vibe coding; if that’s your jam, go to town. But I can virtually guarantee that sooner or later—and probably sooner—you’re going to fall off a cliff when something unexpected happens, and you realize that the innards of the software you “vibed” are not only a mystery to you, they’re full of nonsense and inconsistency, and don’t really do the things you intended.
Making software, even in a world with AI, is still hard. But not all hard is the some. Software engineering is a craft that contains both "bad hard", and "good hard".
“Bad hard” is all the stuff I mentioned above: code is cryptic, unforgivingly precise, and full of mind-numbing drudgery, even to get boring things to work reliably. Stupid little missteps can eat up entire days, even for hardened professionals.
But there’s also "good hard"! Making useful software means thinking differently about the world, seeing everyday life with x-ray vision. It forces you to grapple with what you (and other people) really want, and gives you endless opportunities for clever, intuitive new solutions to old problems. In the moments when you connect with the "good hard", it’s the most fun, incredible feeling, like building castles out of pure thought. It feels powerful to be good and smart like that, and it's why many of us who are professional software engineers got into it in the first place.
In the past, this dual difficulty was a fact of life for software engineers: “you take the good (hard), you take the bad (hard)”. But that’s not true anymore! Because of what LLM coding assistants can do, and how fast and reliably they do it, the bad hard is evaporating before our eyes, leaving only the good hard.
Which is still hard!
If you want the incredible benefits of making your own software, and you want to rise above the precarious level of “vibe coding”, you need a basic grasp of what software even is: how it works, how you make and ship it, and what parts of it are easy or hard (or even possible in the first place). In other words, you need the knowledge that a software engineer gathers over her career, alongside all the battle scars and eye-twitches from the "bad hard" stuff. You have the benefit of speed-running this knowledge. But that doesn’t mean there aren’t going to be some very interesting and difficult things for you to learn; you’ve just got a much bigger running start.
So in service of this idea,I’m starting a new series of articles here where I’ll lay out some of those basics. More to come!