Reflections on Hands-on Tutorials for Developers

Fingers to keys in codingI was remarking to my wife recently that if you’re a focused, committed self-learner, this is an amazing time to be alive. I say that because there are just so many different sources now available when it comes to learning how to do something.

Of course, while this applies equally to things like fixing your toilet and the broken heater in your Lexus (two things I’ve personally searched for and figured out via online tutorials — no joke! –), I’m more specifically thinking in terms of web development. Whether we’re talking free, fremium, or paid models, there is a wealth of how-to resources available.

I mentioned in a recent post that when it comes to learning how to code, I personally recommend a balanced diet of big-picture computer science theory mixed in with PLENTY of actual, fingers-to-the-keys coding. If you’re diet’s too focused on abstract theory you’ll never be able to turn that into actual coding productivity. And if you solely focus on coding yourself into self-respectability, you may end up with some major holes in your thinking – holes that make you a less efficient and complete developer in the long run.

Now, with that said, when it comes time to digest the second half of your diet — the hands-to-the-keys part — I really recommend following tutorials that involve someone actually building an application in real time – as close to “from scratch” as possible. There are plenty of these options available via YouTube and other sources. On my personal coding journey, in addition to more formal, paid programs like Code School, I also took in plenty of these free video tutorials.

When it came to these tutorials, here are some features I noticed tended to make the tutorial really stellar (or not). For one, as I already mentioned, you want to follow along with a hands-on, real time application build. This is important because, when you’re actually using a programming language, you want to do so in as close to a real-world situation as possible. And in the real world people build websites and applications, not articles on theory (most anyway!).

Beyond that, it’s really helpful if the person giving the tutorial shows you their screen as they see it. And while it’s good for it to be large enough to be easily legible, it’s also important for the student to be able to see everything the coder sees. For instance, if they opened a certain file, and I didn’t catch which one – or they forgot to mention it – if I can see a highlighted file from a left-side panel (for instance) that tells me what file they’re just opened, this is SO helpful. It’s really frustrating if someone forgets to mention something like this, AND there’s no way to glean that info from the contextual visual cues (tutorial makers take note!).

Next, let’s talk about speed. Now everybody will be slightly different on this. Some teachers go fast, some slow; some students like fast, some slow. So look around till you find someone that works for you and you’re learning pace. Now, of course, the more advanced you become, the faster you’ll be able to process – because you’ll already have plenty of hooks to digest material, no matter how fast it’s coming at you. So expect that the kind of tutorial you’ll want to follow will change as your knowledge grows.

Beyond speed, there’s also the issue of how descriptive a particular teacher is. Yes it’s important that you tell me how to do something, but it’s just as important for you help me understand WHY you do it that way, rather than another way. For instance, with a language like Ruby, there are always several ways of accomplishing the same task. So it’s really helpful for the teacher to take the time to explain why he/she choose one option over another.

Even if it comes down to personal taste on the developer’s part, just knowing that is still very helpful for the newbie. The sooner you start thinking about why, along with how, the better. And that’s because, at the professional level, the why is really essential. Remember the old adage: plan twice, code once.

Little side-notes about industry best-practices, personal horror-stories, and the like, are also very helpful. These contextual cues really help to fill in the gaps of the learning experience; in ways that really add to the overall experience. Beyond that, it just helps the learner feel apart of the larger community – and that little boost in itself can add to the quality of the experience, and make the student retain more information (again, tutorial makers take note!).

Once you’ve finished a great tutorial, make mental notes about why the tutorial was helpful. What made it work for you? Or, conversely, what didn’t? If you found it really helped you grow, look for more of the same. Maybe that teacher has a series of tutorials available. Or maybe they’ve provided links to other teachers they recommend. The Web is a big place, with plenty of rabbit trails and time-wasting avenues, so follow the useful breadcrumbs when you come across them.

Lastly, if you really like a tutorial, rather than rushing off to find the next one, why not try doing it again? Again? What’s the point of that, you might ask. Well, for one, since you’ve developed more hooks, you should (ideally) pick up even more nuance and detail the next time out. I probably learned more from following a really good tutorial three times (*cough*, *cough* – Michael Hart’s Rails Tutorial) than I did by jumping around between teachers and having to use time and energy to re-calibrate each time to their particular teaching style.

Remember, just because you’re doing a tutorial for a second time, that doesn’t mean the experience has to be the same. Really, it shouldn’t be. Since you’re already somewhat familiar with the material, let you mind ask big picture questions. Why is he/she doing it this way? What will he/she say we should tackle next? Do I understand how these pieces fit together? If someone asked me to explain why something was done a certain way, would I know what to say?

Take the big picture concept of MVC, for instance. Model/View/Controller. Ask yourself, how does this particular programming language tend to handle the MVC framework? Pay attention to those patterns, because 90% of coding is pattern recognition. And it’s only in understanding the conceptual why in these situations that you’ll later be able to developer your own applications, rather than merely mimicking what you’ve been taught.

That last point is most essential of all. And that’s ultimately the barometer you should use to gauge your progress. Yes, it feels good (and is good!) when you can follow a tutorial from line 1 to line 500 and actually end up with a working application. But you can’t stop there. Your learning hasn’t really become reproducible until you can dream up a new application and actually have enough practical experience with a particular programming language to build it.

If you’re not quite there yet, fear not. You’re on a journey. And that begins with understanding basics like syntax, conventions, etc. Just keep in mind the ultimate end-goal. You’re in this because you want to be able to code cool stuff. Right? So keep one eye on that distant flag, and enjoy the process as you begin to close the distance on that ultimate goal.

Posted in Musings, Web Development Tagged with: , , , ,