How to Properly Use a YouTube Coding Tutorial
If you’ve spent any time online attempting to learn software development you’re familiar with the YouTube tutorial. Whether you’re trying to write “Hello World!” in Javascript or build a full instagram clone there is no shortage of YouTubers out there trying to help tutor you to improve [their place in the YouTube algorithm and get eyeballs to their videos] your software development skills. However, just as prevalent as the YouTube tutorial is the concept of ‘YouTube tutorial Hell.’
Tutorial Hell is the act of endlessly completing “projects” by following YouTube tutorials. One can often get great results (anyone can build and publish an Android app in just under 4 1/2 hours with freeCodeCamp) but at the end of the video it’s also possible to have no idea what just happened. How much of the process is retained? What were the core concepts? Is process or product more important? A possible answer to any of these queries is to dive right back into another tutorial — go ahead and build “15 Vanilla JavaScript Projects” in just over 8 hours.
Now, to be perfectly clear, I’m not trying to be snarky about the content these creators produce. I’ve spent a fair amount of time on YouTube — check out my favorite YouTube instructors — going through various tutorials and I’ve enjoyed it. It’s great to follow along with someone who has a real understanding of what they’re doing. After all, it isn’t often that an amateur gets what essentially amounts to direct access to a professional.
I’m also currently studying software development with General Assembly, so YouTube is not my primary source of content and skill refinement. I’ve also spent the better part of two decades as a professional educator so I have a keen understanding of how to learn, which has served me well as I’ve supplemented my formal studies with YouTube content — without finding myself trapped in YouTube Hell. Here’s how I approached a tutorial I recently found, “Creating a better todo app — the HTML and CSS,” which is a collaboration between Kevin Powell and Kyle Cook.
First, follow along with the creator, but use the ‘pause’ button. It’s tempting to speed up the video to maximize those learning minutes, but the creator has more than a few advantages. First, he or she has prepared everything in advance. They’re rarely coding off the top of their head — in fact, there’s a good chance they’re using a reference monitor and re-typing code they’ve already worked out. Second, they’re good at what they’re doing. With repetition comes expertise, which novices lack, so stop the video often…very often. Kevin’s video I’ve linked to above is just under 40 minutes long; however, I believe I spent the better part of 3 hours making my way through it. Why pause, one might ask? Because of reason #2.
You should be commenting…all the time. If you’re just starting out, HTML, CSS, and JavaScript each have unique formatting for inserting comments in your code. These comments won’t be read by the computer: they’re for human eyes. Below are examples of each format.
<!-- This is an HTML comment -->/* This is a single-line comment in CSS *//* This is
a multi-line CSS
comment */// Any text on this line will be ignored by JavaScript/* This is
a multi-line JavaScript
comment
*/
Here is an example of my CSS from the tutorial:
/* The * selector selects all elements.*/
/* The ::before selector inserts something before the content of each selected element(s).*/
/* The ::after selector inserts something after the content of each selected element(s).*/
/* inherit means that the element inherits this property from its parent element.*/
/* When you set the width/height of an element, the element often appears bigger than you have set (because the element's border and padding are added to the element's specified width/height). The box-sizing property allows us to include the padding and border in an element's total width and height.If you set box-sizing: border-box; on an element, padding and border are included in the width and height*/
*,
*::before,
*::after {
font-family: inherit;
box-sizing: border-box;
}As often as possible, I pause the video to insert comments so I’m not typing wizard code (that’s code that magically and inexplicably works). It’s crucial to understand what you’re actually doing, much more so than it is to just continue doing. As soon as you get to an unfamiliar element or property, pause and head over to MDN Web Docs or W3Schools to look it up. In this way, you’re valuing the process over the product: your goal is to learn while you’re working, not just to produce something with no understanding as to how it came to be. So, feel free to hit pause and insert your own understanding into your code.
Third, have your own learning goal(s). The best learning happens right at the edge of chaos and frustration. Too much discomfort and the learner just feels lost: there’s no way of telling up from down or right from wrong. There are stages of understanding through which one inevitably goes:
- Unconscious incompetence: a stage during which you don’t know what you don’t know. Blissful ignorance, one might call it.
- Conscious incompetence: a learning stage during which you’re acutely aware of how much you don’t know. You’ve now encountered enough information it can be overwhelming — this is the stage that can be the most daunting to overcome.
- Conscious competence: You have enough skill and understanding to know what you’re doing. You can’t do it all, but it’s less like drinking from a firehose and a bit more like sipping from a garden hose.
- Unconscious competence: You’re now capable enough that it might be difficult to remember what you formerly didn’t know. This is related to the idea of the threshold concept: once you’ve learned to ride a bike it’s really challenging to remember what it was like to not know. This is a great place to be; however, it’s always important to monitor your own understanding so that it doesn’t stray back into unconscious incompetence.
To monitor your own understanding, have your own measurable goals when working through a tutorial. As I watched Kevin work with CSS, I was just as interested in his workflow and how he bounced back and forth amongst classes as I was in the actual code he was writing. I paid attention to how he visualized the page as he drafted his HTML. In this way, I’m learning about the process of software development as much as I am about setting up global color variables in main.css.
Lastly, debug your own code. Many creators on YouTube are happy to share their GitHub repositories so their viewers can work with completed code. This can be great as a reference, but debugging is a skill that needs developing, just as much as writing. For instance, I still have a nagging problem in that my placeholder text in the To Do app’s list creator section is hardly visible, see below:
I’ve been working on making it more visible, while knowing that, at any moment, I could just go to Kevin’s repo and copy all the code I need and it would magically work. However, the frustration of debugging is a part of the process, not a bug. Work the problem.
As Milton wrote in Paradise Lost, “Long is the way and hard, that out of Hell leads up to light. ”If you’re working through tutorials, or unfortunately stuck in YouTube tutorial Hell, I hope this helps you navigate what can simultaneously be the world’s greatest trove of knowledge and the world’s greatest crutch. Enjoy!
Check below for the To Do I’ve been referring to throughout this article:
