2 ms·

That'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

That'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 ago
I’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.

freetime2 5y ago

I’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.