This rings true and frustrates me as well. My entire career I get bogged down with being so disappointed with the tools that we use in the software industry, th

This rings true and frustrates me as well. My entire career I get bogged down with being so disappointed with the tools that we use in the software industry, that it totally distracts from building new things. Perhaps it is my mathematics background that spoiled me. In mathematics, you rarely are concerned with the tools that you have at your disposal. In most cases, they have been designed well, iterated on, smoothed out, etc., and above all, they just work. Aside from the most advanced, cutting-edge work, this is generally true. Of course, there's always work on foundations, different paradigms of mathematics, and more, but I think the point is clear. Maybe an even clearer point is imagining a carpenter who has to rebuild his hammer every day because it stops working, and then imagine that the instructions to build a hammer are practically undocumented scribblings on some napkins. In software, and actually in engineering as a whole, there is a large percentage of work that goes into solving problems created by other engineers. This isn't all the work, of course, but it is a depressingly large amount. In general, I am less concerned about all the constraints of software artifacts, e.g., size, slowness, etc. While those are a drag and can be frustrating, I am more concerned with two things: software that works and software tools. The tools that we use in this industry are nothing but antiquated. Software engineers equate programming to text, and thus, all the tooling revolves around text. Most so-called IDEs are simply advanced text editors. Tools like Git are beloved, and in Linus' own words, I'm surprised they made it to adulthood. Even in a text-based language, I absolutely do not care about lines that changed. I care about semantic things, like functions, modules, expression blocks, etc. I want my source-code control and comparison tools to tell me what actually changed and not what characters of changes are present. I could go on and on this topic. And part of the consequences of poor tools, we have software that works poorly and is just balls of mud stacked on top of more balls of mud that have dried out they're brittle to even touch. But that's just one component of why software doesn't work. The other is how we think about software. Thinking about software as just a thing that a person tells a computer to do is not enough. Software is about three things: (1) computation, (2) communication between humans and not between human and machine, and (3) how to think about things or encode a domain with software. We suck enough as it is with (1), but (2) and (3) are basically ignored at large. Almost all engineering problems in deployed systems relate down to communication issues and poor understanding of the domain at hand. But not only does everyone concentrate on (1), they concentrate on very narrow aspects of (1). It's almost no surprise that things are as bad as they are in software.