thisoneisreal

The point about task variability being normal, and attempts to reduce variability being destructive, is explained exceptionally well in "The Principles of Product Development Flow." Metrics folks want software engineering to have units of work so that it can be measured like an assembly line, or sales, or any other number of things that make sense to quantify. But the reality is that we build and make adjustments to interconnected systems, and that just can't be reduced to arbitrary units. Tasks are heterogeneous and work on different scales. When you try to cram them all into the same sized box, you are actually creating friction and making the problem worse.

I got hooked in a similar way. Wrote an Excel macro to automate an operational thing I did in my real job, and then asked myself, "Wait, how did that work?"

My experience as a self-taught dev too. I managed to get employed as an SE without a real computer science foundation, but then I just kept teaching myself details of networking, operating systems, memory architecture etc. and learned other topics as-needed.

Strongly recommend "Amusing Ourselves to Death" if you're interested in exploring this question further. It has a strong bias towards reading but does a very thoughtful comparison of various media. We don't need to consume content of any form, of course.

I think the dream is that business requirements are contained to one artifact and everything else responds to that driver. In an ideal world, it would be great to have databases care only about persistence and be able to swap them out based on persistence needs only. But you're right, in the real world the database is much better at enforcing constraints than applications.

I think it's both actually, and you're hitting on something I was thinking of while writing that post. I'm reading "The Perfectionists," which is about the invention of precision engineering. It had what I would consider three aspects, all of which we should care about:

1. The invention of THE CONCEPT BEHIND THE MACHINE. In our context, this is "Programming as Theory Building." Our programs represent some conception of the world that is NOT identical to the source code, much the way early precision tools embodied philosophies like interchangeability.

2. The building of the machine itself, which has to function correctly. To your point, this is one of the major things we care about, but I don't agree it's the only thing. In the code world this IS the code, to your point. When this is all we think about, though, I think you get spaghetti code bases and poorly trained developers.

3. Training apprentices in both the ideas and the craft of producing machines.

You can argue we should only care about #2, many businesses certainly incentivize thinking in that direction, but I think all 3 are important. Part of what makes coding and talking about coding tricky is that written artifacts, even the same written artifacts, express all 3 of these things and so matters get very easily confused.

I think this is going to look a lot like the same problem in education, where the answer is that we will have to spend less time consuming written artifacts as a form of evaluation. I think effective code reviews will become more continuous and require much more checking in, asking for explanations as the starting point instead of "I read all of your code and give feedback." That just won't be sustainable given the rate at which text can now be output.

AI creates the same problem for hiring too: it generates the appearance of knowledge. The problem you and I have as evaluators of that knowledge is there is no other interface to knowledge than language. In a way this is like the oldest philosophy problem in existence. Socrates spent an inordinate amount of time railing against the sophists, people concerned with language and argument rather than truth. We have his same problem, only now on an industrial scale.

To your point about tests, I think the answer is to not focus on automated tests at first (though of course you should have those eventually), but instead we should ask people to actually run the code while they explain it to show it working. That's a much better test: show me how it works, and explain it to me.