> I think the most important thing in any project you’re building...is how completely and accurately you articulate exactly what you want.
That's what code does.
I think he really wants to be having a debate about whether we ought to be using different coding languages, more based on natural languages, more declarative.
I think the law provides an interesting perspective. It has a technical, formalized language, built out of a natural language. Since laws and contracts can be very high-stakes, the technical/formalized aspects arose out of a need to express hard constraints using a language whose complexities seem to be built more for story-telling.
>Say you want to draw a perfect picture of an owl. You have this beautiful image of it in your mind. But you can’t draw very well, and in this analogy the drawing is the code. So what comes out is a stick-figure owl that’s barely recognizable as an owl.
>In the code-is-the-source-of-truth version, that stick figure is now the authoritative artifact. We analyze it, document it, take notes on its proportions, and spend a whole bunch of time iterating on it. We’re running in circles around a bad drawing.
My only disagreement with the post is over whether articulating is is the main bottleneck. Right now, there are still issues and oversights humans would tend not to make even if you have model context and documentation accurately and clearly capturing your full intent.
Each year will decrease the rate of this, but software engineering will probably need until maybe 2030 until we've crossed a threshold towards solely being product managers/designers. This advice still applies today, but you do need more wrangling on top.
There's no one true answer when it comes to the perspectivity of the mind, of which language is a part of. For some people, writing is closest to thought. For others, code is closer. Others still might find mathematics a better means of expression. YMMV with any one idea here.
Why not use gherkin given/when/then stories, and build E2E runners and maybe also unit tests for them? I don’t understand why a new spec format is necessary, which forever binds you to using agents for evaluation. Deterministic tests also have the advantage that they are harder to cheat on. If they are green, they give me a strong signal I can trust.
A full spec is indistinguishable from code though.
That's the bottom of the problem. You can think all you want in your spec doc, you won't fully solve all the problems that you will face during implementation.
That's why ports are easy with LLMs, cause the code implicitly carries all the spec.
Sure, there may be a gap between the code and the idea behind the spec, but it can be argued that the gap between the spec as a document and the idea behind the spec is just as wide, and in fact doesn't take into account the constraint of reality.
LLMs generally suck at taking the initiative. Tell it to build a report, it's going to do it, but then you'll have to iterate a lot to make sure it's producing it the exact way you want it.
> I think the most important thing in any project you’re building...is how completely and accurately you articulate exactly what you want.
That's what code does.
I think he really wants to be having a debate about whether we ought to be using different coding languages, more based on natural languages, more declarative.
I think the law provides an interesting perspective. It has a technical, formalized language, built out of a natural language. Since laws and contracts can be very high-stakes, the technical/formalized aspects arose out of a need to express hard constraints using a language whose complexities seem to be built more for story-telling.
Good post. I like this example:
>Say you want to draw a perfect picture of an owl. You have this beautiful image of it in your mind. But you can’t draw very well, and in this analogy the drawing is the code. So what comes out is a stick-figure owl that’s barely recognizable as an owl.
>In the code-is-the-source-of-truth version, that stick figure is now the authoritative artifact. We analyze it, document it, take notes on its proportions, and spend a whole bunch of time iterating on it. We’re running in circles around a bad drawing.
My only disagreement with the post is over whether articulating is is the main bottleneck. Right now, there are still issues and oversights humans would tend not to make even if you have model context and documentation accurately and clearly capturing your full intent.
Each year will decrease the rate of this, but software engineering will probably need until maybe 2030 until we've crossed a threshold towards solely being product managers/designers. This advice still applies today, but you do need more wrangling on top.
There's no one true answer when it comes to the perspectivity of the mind, of which language is a part of. For some people, writing is closest to thought. For others, code is closer. Others still might find mathematics a better means of expression. YMMV with any one idea here.
Mel the real programmer would disagree.
[1] - https://users.cs.utah.edu/~elb/folklore/mel.html
"If a program can't rewrite its own code", he asked, "what good is it?"
(BTW, the poem like formatting was a happy accident.)
Why not use gherkin given/when/then stories, and build E2E runners and maybe also unit tests for them? I don’t understand why a new spec format is necessary, which forever binds you to using agents for evaluation. Deterministic tests also have the advantage that they are harder to cheat on. If they are green, they give me a strong signal I can trust.
A full spec is indistinguishable from code though.
That's the bottom of the problem. You can think all you want in your spec doc, you won't fully solve all the problems that you will face during implementation.
That's why ports are easy with LLMs, cause the code implicitly carries all the spec.
Sure, there may be a gap between the code and the idea behind the spec, but it can be argued that the gap between the spec as a document and the idea behind the spec is just as wide, and in fact doesn't take into account the constraint of reality.
LLMs generally suck at taking the initiative. Tell it to build a report, it's going to do it, but then you'll have to iterate a lot to make sure it's producing it the exact way you want it.
Someone has yet to write emotions in code.
You haven’t been reading my comments, pal.