The Arrogance Of Software
All the successful people that made it in software seem to think that the world needs changing, that they have the ability and the means to do it.
They fall for the same problem they had in the software world. A team of people comes up with big, audacious ideas that sounds amazing on paper that gets delivered over budget and way past the deadline without meeting half the initial expectations. Any attempt to undo it might be harder than building it.
Failing to realize that the software world is infinitely easier to change than the hardware world because software changes in the background while hardware changes in the foreground. The size of software change has no impact on the ease of deployment.
A bug fix, a performance improvement, a complete refactor are all a deployment command away. Now try fixing a few potholes on a highway and you will see you much disruption there is. Try adding a lane to a highway. Try closing a two six months old bridge because it has grown its initial use case. And forget about abandoning projects mid way - you can just delete some files and the software project is gone, try dealing with a half built office tower in midtown. Almost any product recall can bankrupt a company.
Let's not forget that software benefits from almost infinite power which makes the need for highly specialized skills a rare need that can easily be compensated by running the software on a more powerful machine. You just can't compensate skills with a stronger materials when building a dam.
Solving problems in the hardware world always comes with boundaries attached to it. There is no way to escape the limitations of the context in which the project is built. The first building on a plot will condition the rest of the buildings. One software project places no constraints on the next software project. There is no terrain composition nor environmental hazards that will impact how the software runs or influence it behavior over time.
Working behind a curtain until the product is ready is the defacto modus operandi when writing software. Starting with the API and building backwards from it while other teams build on top of it to speed up things and having the ability to fit it al together whenever you feel like, no matter the size, is way more difficult to do for hardware. Doing this while also preserving the ability to change anything you want, even the underlying wiring to course correct while keeping the engine on is an unimaginable feat for hardware.
Continuous learning means something totally different for each side. In hardware you learn of new constraints or variables that you didn't account for at the beginning. In software you have that and you also have the ability to learn about the fundamentals of the field while building the project. Since changes are cheap and have almost no impact in operations you can always go back and improve once you have learned some more while also making it available to all your customers, not only to the future ones.
Quality assurance is a delight to do, pass it once and it will work the same each time you spin up a new instance. There is no such thing as a batch of poor quality materials that might a affect a few instances.
When hardware goes into production, it must to the result of the best work possible at that moment and very few minor incremental changes that will fix complaints from the first customers. When software goes into production, is more of a step in the right direction than anything resembling a final product.
Cheap, unlimited iterations made available to all customers is what makes software to be more polished than hardware. A good fortune the hardware world doesn't have and for which we should all have some grace when criticizing it.
Since there are no practical limitations in software, solving problems has more to do with each person attitude towards moving through or around obstacles than anything else. The arrogance is the result of always being right in the end.
Keep yourself in check, remember how many fuck ups took you to get there.