For example, consider the instruments. They run off of 5 volts, while the system voltage of the car is anywhere from 10-18 volts. How to get 5 volts? It has a sort of buzzer which is an electromagnet. When the voltage is above 5 volts, it breaks the circuit, when it is below 5 volts, it closes the circuit. It happens fast enough that the result is a rough 5 volts.
Many restorers of these cars decide to replace it with an electronic voltage regulator, that gives it a rock solid 5 volts.
Then they discover the instruments don't work.
It turns out that the (mechanical) instruments tend to get stuck. The roughness of the 5 volts keeps them from getting stuck. So now the the electronic voltage regulator needs another circuit added to make the 5 volts rough.
That little, simple voltage regulator hidden inside a can is a marvel of simplicity and effectiveness.
The mechanical-averaging voltage regulator worked for the design because it only had to work in the context of the specific model of car it was going into. It didn't have to produce 5v for any application that needs 5v; it just had to produce "5v" for the instruments in the '72 Dodge Challenger. That makes it a pretty terrible 5v regulator, but a pretty great part for the system it was designed to fit into if the mechanical-averaging version is more reliable or cheaper or more robust than the fancy electronic versions.
But if I'm designing a 5v regulator to be sold as a 5v regulator, well... I don't know what system its getting installed into so I won't have much luck selling one that, over a long enough time span, averages out to supplying 5v of power when its supplying power. So I have to design in tight tolerances, and everyone integrating my regulator has to design for tight tolerances, etc.
The good news is that now anyone can buy my regulator and get a reliable 5v - interchangeable parts! But the bad news is now every system on both sides has additional complexity for the sake of complying with our standard.
We see this _all the time_ in software, especially comparing old software to new. Why is Roller Coaster Tycoon so much more elegant and efficient than a modern game written on Unity? Sure, good tastes probably factor in - but that taste from the author was allowed to shine because it was designed as a complete system, not a bunch of component subsystems from different teams and vendors stitched together.
In 1972, the electro-mechanical regulator was also likely far cheaper than a solid state one. The car didn't have a single transistor in it outside of the (rather expensive) radio. (There was an upgrade available for the ignition to make it "electronic" - it had one transistor!) The alternator of course had diodes in it.
The rough 5V also enabled the instruments to be made cheaper.
The solution was simple and pure genius.
The nozzle was composed of tubes welded together. The liquid oxygen was run through the tubes, which pre-heated the oxidizer and cooled the nozzle. But that still wasn't enough. Then the engineers simply drilled tiny holes in the tubes, so some of the oxygen would leak out into the nozzle. The gas would form a barrier between the flame and the nozzle, and would carry away the heat. (This is known as boundary layer cooling.) If you ever get a chance to look at a rocket nozzle, you'll see the tubes and the holes.
Those mechanical voltage regulators wore out and had to be replaced periodically. They weren't great at maintaining consistent voltage so consumers had to accept loose voltage tolerances. They made noise and generated electrical interference.
Modern cars are more reliable, despite their complexity. I'll take solid state.
it really depends on the problem domain tho, doesnt it?
Would you call the fast inverse square root[0] code good taste?
[0] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...
I highly recommend checking out the clothing and fur stores to accessorize if you're in an Inuit town with nothing but "purely practical" Western clothing. A fashionable design will improve both the look and the cold weather performance.
This sometimes gets taken to the extremes of high fashion, like this design by an Inuit woman:
https://vafashion.ca/pages/the-ukiaksaq-collection-nyfw-2020
It does no I/O and has no action-at-a-distance. The float-long-float casts are the worst part.
If a coworker brought it to me with a performance justification and some unit tests I'd be pretty happy to pass it.
The starting approximation is just magic.
As an old programmer, I would write "FastInverseSquareRoot()".
It took a looong time for the penchant to write identifiers adhering to the FORTRAN limit of 6 characters to fade away.
(Yes, I know Q_rsqrt is 7.)
People will watch a ballet and remark "they make it look so easy and effortless!"
The reality is, it is easy and effortless to them, because they practiced it 10,000 times.
And then there's a class of people that overcomplicate the architecture out of boredom, perceived possible problems (like scaling) or cargo cult, and they introduce stuff like microservices or lambdas instead of just solving the problem at hand with proven and simple solutions.
But you won't find good developers if your job listing is "looking for a java developer for a straightforward CRUD application".
Just because something is simple doesn't mean anyone has the wherewithal to understand it.
The same applies to picking vendors, asking questions like "will they extort me next contract renewal" and "what options do I have if they extort me".