Programming Tutorials — Good or Bad?
Recently I’ve decided that I needed to brush up on my web development skills after graduating. As many others do, I decided to take a course on Udemy.com. The course was using the MERN stack and building an eCommerce application by a reputable teacher. About halfway into the course, I found myself sort of scatter brained. It made me wonder, how much am I really learning by taking this course?
This is not necessarily a result of the teacher, in fact, I believe the teacher was great. But many of you have heard the term of tutorial he** (h-e double hockey sticks) before. If you’re unaware, it’s the idea that you can continuously be watching tutorials and learn next to nothing. To avoid this, here’s three tips that I recommend you take when following a tutorial.
Arguably the most important and easiest thing you can do is simply take a break. I recommend this for programming in general, but especially tutorials. Tutorials by nature are very matter of fact, and allow you to follow along in a sort of zombie like fashion if you are not mindful of it. When this happens, you lose out on the value of the tutorial. The goal with the tutorial should not be to simply follow along, but to understand the problem and logic behind the solution being used.
Understanding the problem the code is solving is absolutely crucial to learning from a tutorial. Programming in essence is simply coming up with a solution to a problem, and if you don’t understand the problem then you are missing out on a valuable learning opportunity. Once you can contextualize the problem, it’s easier to start understanding the logic that the teacher is implementing.
It’s easy to skip over this in tutorials if you simply just let the videos roll on and on mindlessly typing code. Don’t do this if you really want to learn. Be present and make sure that you are taking breaks to rewind yourself mentally.
Q&A — Ask Questions
The underutilized portion of courses is the Q&A section. Many times the creator of the course is answering questions in the comments, or they have someone else actively engaging with questions. Don’t miss this opportunity. Many people don’t use it, or they only use it rarely.
If you don’t understand the underlying workings of a piece of code, you should ask a question. This will help you get the most out of the course (you probably paid for it, get your money’s worth).
While in the process of completing your course if you are asking yourself, “Well, why did she use an arraylist and not a linkedlist”, it’s time to ask a question.
This is a good habit to develop generally, but along your programming journey it’s good to ask questions!
Change the Code — Break It
It’s very easy to just follow along with the course, only writing the code that the creator is also writing. However, one of the best ways to learn what is actually going on is to change the code yourself.
I recommend doing so after a section with a couple videos or when you move on to a different feature. Quite simply, break it. Go crazy. By breaking the code it helps to raise potential questions that you otherwise may not have thought of. The code won’t bite, hopefully.
Of course, you can also go the less glamorous route of changing certain features. Change margins perhaps, or add an extra little functionality for one of the features.
By doing so, you help to break the mental barrier surrounding code. You can’t be afraid of it, so break it every once in a while.
Best of luck on your journey, and remember, do not get stuck in tutorial h-e double hockey sticks!