Issue 43 - The Best Code You Never Wrote
5 blogs at a time, special discount
Code is technical debt. The optimal spot for engineers is to write the least code possible but still write code1.
Nowadays we might write our code with Cursor, Windsurf, etc. We even design new code editors. But we still want to write code. Not pure text in natural language.
Expecting users to primarily interact with software in natural language is lazy.
It puts all the burden on the user to articulate good questions. What to ask, when to ask it, how to ask it, to make sense of the response, and then to repeat that many times.
But a user may not know what they don't know.
A good user interface let's me iteratively and incrementally explore the problem and solution space in a variety of ways.
A great user interface guides me and offers nudges.
Couldn't a natural language interface help with that?
Certainly.
But not as the only option. Probably not even the main interface.2
Writing code is basically rendering semantics in a given syntax. The semantic is the problem to solve, the syntax is our 300 lines of SQL. The sweet spot of this journey is when our syntax is neat and close to our semantic.
And this is hard to get.
Especially since our semantics are getting blurry as everything is getting faster and wider in our problem space. And our syntaxes - interfaces - are old.
Also, our data stacks - interfaces - are planned through tools and silos. So we get tools and silos. But I come to realize that if you plan for insights and activation, you get insights and activation.
The data-to-insight-to-action motion doesn't come out of thin air. We still need interfaces. We still want to write code (again, the least possible).
But for now, the code we write is far from our semantics. The insight-to-action motion propelled by our tools sounds to be on a good dynamic: it's the dashboard, the Slack alerts, the o3-based RAG.
But the first part, the data-to-insight, doesn't feel well designed. It's too long codebases. It's not functional. It misses proper interfaces.
I long to see how new languages, new layers, and ultimately new UI, will move us closer to that sweet spot.
📡 Expected Contents
Code Fast
And so you want to write code. Welcome!
I recently wanted to move forward on my web development learning. These last quarters I ultimately failed on this: learning Next.js, HTTP serving in Go and basic authentication, etc. I learned tons of things but didn't ship anything serious.
Following solopreneurs out there, the recent course from Marc Lou hits at the perfect time. It doesn't go through days of lessons to learn all the details of React frameworks: it's 12 hours of videos and tips to learn how to ship a project - serving actual customers.
If like me you're not looking to only sharpen your coding skills but also ship something: I urge you to follow Marc and look through his course.
Ikea Oriented Development
If you have a hammer and screwdriver, you can build Ikea furniture. Everything else comes in the box. Nobody wants to hunt for a 6.2mm allen key when what you really need is a bookshelf.
[...]
In the computing world, screws are made of plaintext, HTTP, etc. Today's shells and standard libraries offer ubiquitous screwdrivers like Regex manipulation, HTTP processing, and JSON parsing.
If you can't bundle allen keys for your hex fasteners, stick to screws. Likewise, if you lack the engineering resources to support multiple SDKs, make damn sure your web API is easy enough to access with curl.
My MarioKart 64 cartridge probably won't inform me that Python2.7 was deprecated. If your program isn't designed to work 20 years from now, it won't.
Again a great post on why software should be soft.
Make it ephemeral
In the physical world, much of what we create has a natural tendency to decay and that is really useful information. A sticky note on a monitor gathers dust and fades. A notebook fills with notes and random scribbles, becomes worn, and eventually ends up in a cabinet to finally end its life discarded in a bin. We probably all clear out our desk every couple of months, tossing outdated items to keep the space manageable. When I do that, a key part of this is quickly judging how “old” some paper looks. But even without regular cleaning, things are naturally lost or discarded over time on my desk. Yet software rarely behaves this way. I think that’s a problem.
Great call on how "skeuomorphism" can be an important concept to consider when designing software and pipelines. In our digital world, legacy stuff is such a headache while the physical world just seems to roll with it naturally.
Why software only moves forward
Once you save state, your code will need to understand that state forever. This is double true for state that leaves your system and becomes distributed.
Kinda echo the previous link above - nice write-up on how data makes things only move forward in the way we design states and corresponding software.
📰 The Blog Post
Ok, I'm writing five blogs at the same time. It's probably not the best way to ship one each month. So, here we go again with no proper blog post...
Since I enabled paid subscriptions on this newsletter, I only sent posts under paywall to corresponding subscribers - I didn't want to spam your inbox too much.
Starting next year I'll try to send them to everyone here. I'm expecting some drops in subscriptions. That's fair enough :)
If you want to give it a try, here is a discount for the new year 😉
You can get a taste with this last post I wrote a few months ago:
🎨 Beyond The Bracket
As I delve deep into our daily syntax and semantics, I find myself stepping back to contemplate how natural language has evolved. Here again: semantics evolve constantly - as our world change - but syntaxes root themselves in different timeframes.
Just look at how the Latin alphabet roots itself from older syntaxes. That's a good reminder not to get caught up chasing new syntaxes just to match the semantics we want to push forward. Syntaxes move slower, so we need to find those subtle tweaks that'll actually give us something workable.
Again, SQL isn't designed for analytics, but it's still doing a great job at it. We have new frameworks and tools that improve it along the way. Same with JavaScript - yes, new frameworks pop up constantly, but the core JavaScript that renders HTML and CSS dynamically in our browser hasn't really changed.
So here we are again; using a 30 years old alphabet. A civilization try to make it move forward. A prophet3 asks good questions.
The only thing I can take action on now is to write it thoughtfully, as little as possible, but still write with it.
Here we go for 2025!
I'm personally so grateful for the things I accomplished in 2024: giving a course to final-year students, learning tons of things about product and sales motions at work, speaking in front of 300 people, etc.
2025 already looks promising!
I wish you the best for the next convolution around the sun ☀️
The syntax you use in the end is not really the matter. Yes YAML engineering is a real thing: YAML is a good high-level interface for keeping operations simple while being declarative.
https://austinhenley.com/blog/naturallanguageui.html
Benn if you read this: you get it, don’t make me wrong 😉
Woohoo, 2025 🚀
I can keep asking questions, but I make no promises about them being good, and certainly make no promises about them being prophetic or even "right."