[iepathos]

If I commission a part specified as 10.00 ± 0.01 mm, I can verify it with a calibrated micrometer without understanding the CNC machine, its software, or how to manufacture the part. Likewise, a function with a finite input space can be exhaustively tested against its specification without understanding its implementation. In these cases, I need to understand the requirement and the test, not the production details, which can actually be a black box.

Your examples show that verification is sometimes inadequate, not that it requires full productive competence. The conclusion doesn't generalize.

[skydhash]

> If I commission a part specified as 10.00 ± 0.01 mm, I can verify it with a calibrated micrometer

But there is someone that needs to design that part, specify the material needed and a few other things. The actual verification is fast because someone has compiled the list of checks. And compiling that list of checks is hard work. In other words, where '10.00 ± 0.01 mm' comes from is very important.

That's why people says typing code is not the issue. Code is merely the medium of '10.00 ± 0.01 mm' definition. The actual product is the software process. And that is already a black box as only a few developers goes on to learn computer architecture and instruction sets. Instead we deal with high level instructions like map, filter, and print. Which are the tools to say '10.00 ± 0.01 mm' instead of "this length" while demonstrating with fingers. And yes for programmers, most specs are as imprecise as the latter form.

[theshrike79]

No, the code isn't what defines it. It's the tests and specs around it.

Code should never be the only source of truth.

Another shitty analogy: baking.

Saying "code is the medium of the definition" is like saying "the cake is the medium of the recipe". So anyone wanting to make the cake or change how it's made should just dive into the cake and start analysing it.

That's why we have recipes, and even they can be modified as long as the exepectation is met: It has to be sweet, soft, covered in something white and must have strawberries inside.

Code should be the same, I should be able to toss the whole codebase in the trash and regenerate it from the tests and written specifications. If I can't there's something wrong with the process.

[skydhash]

> That's why we have recipes, and even they can be modified as long as the exepectation is met: It has to be sweet, soft, covered in something white and must have strawberries inside

How sweet? How thick should be the covering? What’s the ratio in strawberry? Even for someone taste, which is subjective, expectations may be precisely defined.

Code is the most precise form of specs. It is not what the computer runs. The computer has no concepts of functions, objects, value types, files, buttons,… We have tools that takes code and transform into what the computer can understand.

What you say is specs is merely some doodling which always need to be properly transform into good engineering drawings. Or someone’s humming that needs to be written properly in a music sheet.

[Barrin92]

the real world doesn't consist of people sitting at home measuring square metal blocks. Judgement of just about anything sufficiently complex requires discernment, a critical eye, intuition and even taste.

A codebase and its long term health is never judged by someone going down lines of code with a ruler, but with experience that only comes from intimacy with software development. If you don't have that kind of living immediate judgement (in German we have the word Fingerspitzengefühl, lit. tip-of-the-finger-felling) you end up with people measuring your progress in commit frequency or token consumption because they in some autistic sense have nothing else left but to measure and quantify random things. We end up with so many idiotic products because the kind of people who had intuition and would immediately throw the thing out were fired, and now you have people who mistake random noise and metrics for the real thing.