3 ms·
My intent was to compare the number of number of variables and processes that I need to understand to do my job with that of an operator in a nuclear power plan
by freetime2 5y ago
My intent was to compare the number of number of variables and processes that I need to understand to do my job with that of an operator in a nuclear power plant. And I was thinking more about how something can appear so bewildering at first, but though years of study it can become second nature. Human capacity to understand complex problems is amazing… but sometimes that complexity still gets the better of us.
I’m perfectly happy to concede that I don’t know anything about operating a nuclear power plant and that my comparison may just be the Dunning Kruger effect speaking.
But if you want to go into all the various engineering disciplines that go into building a nuclear power plant, I think it’s only fair to go into all the disciplines that allow my applications to run. Microprocessors, the Internet, etc. The apps that we interact with daily for communication, shopping, etc. are miracles of collective human engineering every bit on par with nuclear energy.
- moritonal 5y agoThat's an interesting point, but it's worth noting that coding benefits from being vastly easier to package and share. The architects of a plant would have to interact a lot more with a concrete specialist than you have to with the TCP spec to spin up an Http server. Because our industry demands a packaged product, we are quite good at it. I do however believe you are wrong. Biased from the perspective of a SE, I'd think a whilst a simple banking app involves more agreed protocols and touch points, it is less complicated than a nuclear reactor. I wonder, between the two, how many specs and manuals would you have to read to design either.
- freetime2 5y agoI’ll avoid saying more about the complexity of nuclear power specifically vs. web apps because, as I said above, I hardly know anything about nuclear power. One thing that I will say is that I think our team’s “velocity” is governed primarily by our ability to process complexity. Basically we are operating at the maximum rate that we are able to take in new information and incorporate it into our product. Sometimes we even go beyond that maximum rate and bad things happen. Definitely we make it harder on ourselves than necessary. We’ve switched hosting providers 5 times in the history of our app - each time with a non-trivial amount of effort involved. There’s a non-trivial amount of effort involved in making sure that all of our package dependencies, many of which were hastily chosen, are up to date and free of security vulnerabilities. Things like the TCP spec may not get a lot of thought when launching a new webapp, but when you’re dealing with some obscure bug it certainly can be something that requires consideration. We don’t even really read specs - we read stack overflow - because we have an endless backlog of feature requests and the focus is on delivering things ASAP. Maybe we suck at engineering and the complexity is self-imposed, but it’s complexity none-the-less and I’ve worked at enough companies to know we’re not alone here. And my assumption is that progress in a lot of creative endeavors is likewise limited by humans’ capacity to process complexity.