I’ve been diving into a few new technologies recently, and I’ve been heading to Google to find tutorials and documentation to help me out.
I was describing my frustration with the way these tend to be written to my colleagues. A typical example is the “Do something with x in 20 minutes” tutorial. For Ruby on Rails, it’s writing a blog engine, and for Angular, it’s a to-do list.
These are great for showcasing techniques that overcome the itches that they were written to scratch, but they don’t explain what those original itches were.
It’s a bit like being taught to parallel park, and your instructor saying “This car has power steering. Power steering makes everything easier. See how quickly and easily I can turn the steering wheel, even though I’m not moving. Power steering is the best technology ever”. For people who know how to park, and know how hard it is to turn a non-powered steering wheel while stopped, this kind of information is great; but for people who are there to learn how to park, it doesn’t give them any of the information they need to know about how to park, why they’d want to parallel park or that there might be other parking alternatives.
These newbies might stumble across a method for parallel parking, but they attribute it to the power steering because that’s what their tutor was raving on about during their lessons. When faced with a new problem, they might then say “What we need now is power-gearing, or power-acceleration” and end up using the wrong tool for the wrong job because they never understood the motivation behind the right tool.