I don't know any books or course about the subject. I can only share my personal approach. This is something I've learned in the context of breaking down potential client projects into early plans and estimatable chunks.
What I do for projects in early stages and personal goals is the following.
1. Take a big piece of paper (A2/A3)
2. Write the goal on the right-hand side of the paper
3. Try to visualize what the goal looks like
4. Then I try to visualize the step right before the goal would look like
5. Write that down and draw a line to the parent goal
6. Move leftward and repeat
In my experience, the further you move to the left side of the paper, the more concrete and actionable the goals are. This will lead to a lot of sub goals and tasks that can be prioritized, revisited and continuously refined. Within the context of software projects, I find it important to work on the definition of done for the goals. I redraw the breakdown many times during the early stages of projects, until it can be put into a project management tool or similar. For personal stuff, I always just stick to the paper method and keep the latest iteration.
It is harder with more abstract goals (become an tech lead for my team; become a trusted advisor for management; be able to read and comprehend new ML research on arXiv etc.). If you are in software, breaking down semi-large projects is a good exercise. For other areas, I recommend starting with a goal that is abstract, but also attainable within months.
As someone who teaches Human-Computer Interaction in a CS program, I find it odd that there are no HCI topics on that list. Especially, when they say it's a "complete education in computer science". Perhaps it's a matter of tradition etc., but some basic knowledge about HCI might be useful ;)
I'm not surprised, but still, Bush, Licklider, Engelbart, Weiser, Kay, Victor etc. are all about HCI...
When HN goes ad hominem I usually bookmark whatever HN got riled up about to read later. It's a sign that there's something interesting to think about ;)
TL;DR: You have to reimplement the application or features to understand the "why" regarding technical decisions.