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 ;)
I don't know about the sources, but about a decade ago the first generation of ultra-high-performance office administrators, who had made the original transition from typewriters to PC's, reached maxiumum maturity before retirement.
Their leadership was consistent that no version of Microsoft Office allowed greater personal productivity than Office 97. They had worked with them all up to that point, always modernizing at the bleeding edge.
In hindsight the only reason for newer versions of Office was thought to be occasions where there was an extreme need for features not present in Office 97.
Of course it had always been too late for them to do anything about it since they were so modern they were the ones tasked with dropping earlier versions as soon as possible after a new version was released.
Naturally that depth of knowledge will never be replaced.
TL;DR: You have to reimplement the application or features to understand the "why" regarding technical decisions.
reply