Comment by alanbernstein
5 years ago
A few thoughts while reading this:
In addition to a deeper understanding of engine manufacturing considerations than I even knew I cared to learn, this article helps me appreciate why people are into engine work.
The perfect tolerances and synchronization of these machines makes me a little ashamed to use the word "engineer" in my title of "software engineer". There is no real comparison of the quality of the result.
And then I skimmed the source, and it makes me think the author deserves that title. It also validates my belief in vanilla javascript.
edit: And later it occurs to me that Mr. Ciechanowski is a true craftsman of software; handmade and built to 1) Be beautiful (and informative), 2) last for years. (The open web standards are the ones that seem to stick around the longest, for better or for worse. (I'm ignorant of the shader world though))
> makes me a little ashamed to use the word "engineer" in my title of "software engineer". There is no real comparison of the quality of the result.
I think that's because the barrier to entry is too low and anybody is being called a "software engineer" these days.
But think about a system which makes proper use of synchronization primitives, like an OS kernel or a robotic control, or a CPU design like the other guy commented too, or maybe a 3D game with tricks like that of John Carmack. Those things can be as complex as an ICU engine.
To make an analogy: in the physical world there are the engineers, and the mechanics.
In the software world everybody is a software engineer.
When I took "Software Engineering" in University, the prof was very careful to explain in great detail, and frequently, that the field was not mature enough to really be called engineering. Then he would talk at length about things like software for airplanes and spacecraft. It is impossible to call yourself an engineer while looking someone in the eye after taking his class. I am a software developer. Maybe an analyst. But mostly a developer.
The word engineer is used by anyone who 1) has an engineering degree or 2) works a field where most new practitioners have such a degree. Most of these people don't know shit, and design terrible systems that barely work (or don't work at all). Trying to elevate the word to a non-existent Plutonic ideal where it means "great engineering" is just ... pointless and faux-humble.
3 replies →
> Those things can be as complex as an ICU engine.
From a complexity perspective an ICU isn’t nearly as complex as even something as simple is a script scraping a webpages for links and queuing them up for further crawling. I’m not sure if “complex” is the word you are going for but even the TCP state machine has significantly more complexity than an ICU and that’s just a fragment of what it takes to transmit some data.
The composability and abstractions we have in this industry allows you to quickly dwarf any regular mechanical system. There is a reason this is a whole new era beyond the industrial revolution.
Quantifying complexity really depends on the level of abstraction though.
Scraping a static webpage is simple when examined at the level of abstraction involving Python and ready made packages. An ICE is similarly simple when examined from the perspective of basic mechanics, as in the article under discussion.
As you note, scraping that static webpage is no longer simple when you include as part of your assessment the TCP state machine, kernel interface, NIC firmware, and similar layers that had previously been abstracted away. Neither is the ICE though once metallurgy, machining, oil chemistry, and the physics of combustion are included.
Granted, pursued to the logical extreme software eventually drags in everything the ICE did and more due to the physical hardware. But then modern engines are controlled by computers ...
2 replies →
Well that’s just because we understand internal combustion engines well enough that we can abstract away a lot of the details. Software engineering is nice because by design it is at a level of abstraction that we can grok it. We’re basically manipulating structural concepts of pure thought. But never forget that reality has a surprising amount of detail. When we interact with the physical world, we rely on abstractions at our peril.
http://johnsalvatier.org/blog/2017/reality-has-a-surprising-...
I don't think you can compare both. It's abstractions all the way down, for both. Modern ICE are made from metals compounds that were unknown a few years ago and are the reason they are efficient. Just as you can send bytes over a wire without TCP, you can build an ICE from pure iron. But both then have just very low fault tolerances and break rather quickly.
I kinda wish my title was simply “Systems Administrator” which is probably the closest thing to a “software mechanic” that we have. Most of our titles have been inflated however.
Thank fuck fluff titles like "Happiness Engineer" have gone away though.
That's why I often joke that a big part of my work is as a software mechanic! Which is still highly technical and necessary but the engineering part happens less often.
I _am_ a computer scientist, but also had a course "Gasoline and Diesel engines" at university. (Belgium before Bologna)
Excuse me, but modern CPUs are way more complicated than this, even if you only look at "arranging events in time". Like several orders of magnitude more complicated. Anyone who has touched VHDL/Verilog knows how delicate signal propagation is, and how crafty you have to be with the clock.
And even if you never tinkered with transistors surely you've at least looked at assembly code, and the amount of painstakingly detailed data layout orchestration that is going on there. A simple printf("hello world") is magical if you know what happens under the hood.
It's easy to dismiss the difficulty of something when all you see is a webpage explaining things very well and simply with some cool graphics. That webpage looks really cool, but this is just a front page of the result. The backend of all the math, equations and thoughts involved wouldn't be so visually appealing. This is just the pretty part result. If you would delve into the actual math and physics that was required for this I'm pretty sure you'd reconsider that statement. Just the study of vibrations alone is probably as difficulty as whatever you're talking about. And that's just one of several areas of study that needs to be considered when making a machine like this. Then you need static mechanics, dynamic mechanics, thermodynamics, fluid mechanics, knowledge of manufacturing processes, materials, among others. And each of these topics is HUGE in itself. You probably have no idea because you're a software engineer? It's easy to defend our own realm and dismiss others, when we know little about others' or all we know is based on some cool animations we saw on the web once.
Well, Electrical and Computer Engineering is an extremely precise discipline, and while the line between hardware and software can be fuzzy in many cases, web software is an entirely different world from VLSI design, and even from instruction set design. And of course, some software, at all abstraction levels, is extremely well engineered as well. But it doesn't seem to be the norm.
Most importantly, I'm talking about my own ability more than the best in the field.
I doubt most of the readers here on HN ever wrote anything in assembly. It is like comical interaction of Marc Andreesen and Mark Zuckerberg and how Zuckerberg had no idea on the Netscape browser (let alone Mosaic or Gophers).
https://www.businessinsider.com/when-mark-zuckerberg-met-mar...
https://en.wikipedia.org/wiki/Gopher_(protocol)
The vast majority of people on this site have never written a line of C or Assembly in the past 12 months
Most people who write software do not know/care how circuits work, as they shouldn't. Car engineers similarly don't need to know how bridges are built.
Correct, but it can be a fun exercise, if for nothing else than the curiosity alone. Learning basic circuit theory leads you to diodes, which then leads to transistors, which then leads to op-amps, logic gates, etc. which leads to computational logic units like the ALU, etc. Before you know it, you have a very, very basic computer going on.
Either way, it's the core process of engineering - applying theory, and breaking up complex parts into more manageable chunks. Same goes for the car engine - it's a complex piece of machinery, but still a sum of its parts.
Achievements in other disciplines can often look like magic (and some are but it usually takes experts to tell which). I think fundamentally engines are engineered like software- by solving one problem at a time. And after having gotten a distributed consensus algorithm to work with a perfect dance of elections and voting etc I feel like there is magic in software too.
I have had the same thought, software can often feel messy and unpolished. But to be fair to ourselves, we simply don't require the same tolerances in most software.