Writing Software is Hard

Writing software is hard yes, but I disagree with the author: I do blame the tools. Every language since C has been created as a reaction. What I mean by this is:

> C++ was created as a reaction to OOP being so difficult to do in C.

> Java as a reaction to memory management being difficult.

> C# as a reaction to Java not being concise enough.

> Javascript as a reaction to HTML not being dynamic enough.

> Go has a reaction to parallelism/concurrency being difficult.

> Rust as a reaction to what C++ has become.

And it goes on. There are many other languages too that you won't hear of that are created as a reaction to the status quo not being good enough either, but those ones I listed were backed by a big enough majority to become known. There is also the Lisp family and the functional paradigm too, which come round again and again in popularity.

All these languages/tools are the problem because no one is sitting back, and pro-actively realising that the entirety of these languages are no good. I am not saying this to start an argument, I have happily been a programmer for 15 years. But I recognise the problems, and they are the same problems, that will repeat over and over again ad-infinitum. I actually started writing down problems I've found and possible solutions and it's already reached over 30 pages.

What it boils down to is that all languages share the same flaw; they specify the what and the how, but never the why. Until we figure out how to encode the why, we will forever be going in circles.

Writing software is hard but to me the hardest part is always taking a random abstract concept from someone's mind (or worse, several people) and converting that into something "real" in a fixed timeline and budget. There will have to be lots of tradeoffs and miscues by definition. We are always making something that doesn't already exist, it is creation and creation is hard.

I do agree that tools (and process and ....) can make it less hard but that requires real, active participation. And I think that is even harder...

I disagree, the tooling around most ecosystems is fine you just need someone who knows what they are doing to help guide people in the right direction. Technical leadership is sorely lacking in our industry, and when you are solving business problems management cares about solving customer's issues on time rather that craftsmanship. Therefore people go down the path of doing just enough to get it done rather than doing it right. If you never are forced to do something correct, you are likely never going to be able to build great products. This leads to patchwork engineering and the veritable big ball of mud that most products look like behind the scenes. It's up to us as professionals to simplify, abstract, focus, and enforce standards so that you can build maintainable products faster. Very few problems that we are working on are "difficult" from the technical side of things. Identify when you've made a mistake, think about about how it could be made better, and then apply the knowledge you've gained when building something new. If you repeat that process you will be a lot better than the majority of your peers.

> Very few problems that we are working on are "difficult" from the technical side of things.

I'd say these problems are technically difficult, just not deep. To clarify the difference:

(0) A difficult problem requires a lot of effort to solve. Example: Finding and fixing use-after-free errors in a buggy C program.

(1) A deep problem requires creativity and insight to solve. Example: Inventing and formalizing Rust's borrow checker rules.

Programmers are naturally attracted to deep problems, but not difficult ones. In fact, reducing difficult problems to deep ones is often considered progress, for good reason. After you come up with the right insight, solving a deep problem can be very easy. But solving a difficult problem will always be hard.

I'm surprised at how little DHH says here. He could have stopped writing after the fifth paragraph. Or just added the phrase "Don't blame your tools" to the headline. Like bad code, this post is verbose and most of its verbiage redundant. Good writing, like good code, is a long apprenticeship.