The Haxonomy
Spending time to master the computer is certainly worthwhile, but the process is unnecessarily difficult. Speaking from experience, it seems that most people learn about new vectors of mastery organically, usually by word of mouth or by accident on the web. We all remember our first time looking over the shoulder of a friend or colleague and being amazed at how quickly they could move around. "What is that?", you ask. They tell you, and you implement some of it, and the rest inevitably goes over your head. You slowly accumulate these experiences and after a couple of years you've built up a decent knowledge of your tools.
I think this system is passable, but can be greatly improved. This is the same system, after all, that produces worryingly high numbers of typing-allergics, command-line haters, and 30-year Emacs veterans who don't know an ounce of elisp.
In addition to organic discovery, we need a top-down view of the mastery landscape with 2 core properties:
- completeness: all possibilities are included and gathered in one place.
- classification: each possibility is scored along the most relevant dimensions, allowing for comparison.
With such a top-down view - which is really a map - navigating the mastery landscape becomes so much easier. One simply studies the map, weighs their options, and charts a new course with the reassurance that they're on the shortest, safest, or even most scenic path to their destination.
Such is the vision for the "Haxonomy", a map of tools and skills for mastering computers.
Notes:
- Above is a rudimentary first draft I mocked up in a night. In the future it should be more complete and have a better UI (interactive, 3D plot, filters, new dimensions like "fun" or "math rigour", etc).
- I consider both programming-specific and general computer mastery, because that's what I'm interested in, and I want this to be useful for non-programmers, too.
- I do not strive for true completeness. I keep a minimum bar for quality and revelance.
- This is subjective, but I strive try to be fair and evidence-based. Like you, I just want the best map possible, and I think I have a fairly unique trait among programmers in that I'm willing to set aside my ego and admit when my own skill investments turn out bad (e.g. hypothetically admitting emacs is a waste of time, etc.).
- In addition to the map itself, I strive to provide substantial arguments and reasoning for my choices. This is half the fun for me, and should be critically important for you, the reader, to convince yourself a skill is worth your time before going off and learing it.
- This is better than your average tierlist or "developer roadmap" (read: flowchart). It's smarter, better-researched, better argued, and I'm not trying to sell you anything.
- If you think I'm missing important vectors, or have come across other taxonomies, I'd love to hear about them!