There are few things nicer than seeing a PR with a lot of red!

I think you're probably right. However I attribute the lack of upfront design in software is due to the relative ease of changing it after the fact.

I would argue that the technical limitations should be considered during the creation of the design doc. In my experience, writing design docs can help me simplify the implementation because I've through through a lot of the headaches ahead of time.

But I will say I've seen many projects get ended by customer request or reorg. I think it's a cost-benefit analysis where you should consider the size of the project (and how long it will take to implement) vs. how long it will take to write the design doc. If it's a 2 day task, that is easy to change after the fact, then no need to write a design doc. But if it's a 2 month project that will have public endpoints that other teams or products will use, it likely is worth a 2-3 day design doc.

I think the design doc still has some value after it has been created. For me it almost acts like a checklist of things to be completed, and it's nice to have it in one place in bite-sized bits. My design docs will also have links to external resources and it's nice to have them in one place so I don't have to track them down later.

But I 100% agree that the majority of the value is gained in the writing of the design doc, and the decisions/tradeoffs that have to be thought through during that process. Which is why I strongly push back against suggestions of using AI to write design docs. Since delegating the writing to AI causes over half the value of the design doc to be lost.

Simply send your cable through the center of the earth and boom, latency reduced by ~1/2. Remember me when you make billions of $ from my idea.

It'd actually be about 36% shorter :)

My processing power is also weak :(

My processing power was weak before LLM era, now it is extra weak.

At the very least, should be a 429

I heard they can't figure out how to fix it with ChatGPT down.

I think you can similarly reduce humans. For example, all humans do is contract muscles. This doesn't fully cover all of biology, such as replicating cells, etc. so not exactly comprehensive, but hopefully that helps get the idea across.

LLMS: Receive text/binary input, process it, and output text/binary input Humans: Receive various inputs, process them, and output muscle contractions

Or maybe generalized to "get good at problem solving." I've found building software systems has a lot of parallels to working on physical things such as carpentry/DIY and working on small engines. The concepts of breaking down a problem into a bunch of smaller problems, and identifying what can be independently tested/built remain the same.

the problem solving aspect is great too, but I mean specifically "this is what it means for a computer to know something, and this is what it means for it to do something" expressed in terms of data stored in memory, and algorithms that read to and write from that memory, and "this is how computers think" in terms of control flow and if tests, is a form of literacy that everyone should at least be exposed to.