[iepathos]

This post ignores that verifying something works doesn't require you to fully understand it. This is easily observable in products we use everyday. We don't need to understand them to be able to verify they work correctly. The cost of verification is often cheaper than the cost of production.

It present delegation as absence of power/agency. While I think there is some kernel of truth in here, the claim "it's not empowering to hand off the details" quickly falls apart when we consider real examples. If it were true, it would mean any leader who coordinates an organization isn't empowered through delegation. We know that's false. The general claim doesn't hold at all. Somewhere in there is an argument for engineers losing something in the hand off, but it isn't clearly articulated.

[Barrin92]

>We don't need to understand them to be able to verify they work correctly

I don't think that's the case and it's becoming more obvious every day. From people who cannot distinguish truth or fiction on online platforms, good code from bad, to insecure software that causes supply chain attacks, to investment vehicles or fake medicine peddled that does not work, the idiotic MBA manager who does not understand the workers they manage and so on. That is why we're living on BS metrics and crappy reviews, because to the people who manage organizations their own workplace is a Blackbox. The critique that "AI" systems are semantically blind token processors is correct, it's just not bothering anyone because it already applied to most modern companies.

When people become passive consumers rather than broadly competent users how something works cannot be evaluated so by definition all they have to go off is appearance, which is why we live in the age of influencers and marketing, because that is now the only factor that actually matters.

[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.

[QuercusMax]

Blackbox software testing has been a thing for a very long time. Running manual tests doesn't require reading the source code.

For personal side projects I spend orders of magnitude more time testing than I do reading the code.