I originally emailed a variation of this to my mailing list and I am sharing it here in case it can help others.
As a teacher of Go, I tend to hear all sorts of feedback about the many different ways of learning to code. For instance, I once had someone tell me that video courses were more harmful than helpful because they lead to developers who couldn't think on their own and were reliant on someone to hold their hand to build anything. On the other hand, I've had students who use my video courses and then go on to obtain jobs as a Go developer.
So what gives?
How are some of the developers using courses and tutorials and becoming reliant on them while others are becoming successful developers?
I think the key difference between these two outcomes is how each developer uses the resources they have at their disposal, and in this post we are going to explore a few ways to really get the most out of the plethora of material available out there to learn programming, Go, and really anything else.
I'm going to go into more detail with each of these, but here is a rough outline of the main points I want to cover:
- Don't just copy the code in the tutorial; apply what you learn.
- Learning resources should be utilized more than once.
- Expand upon tutorials to get more out of them.
Don't just copy the code; apply it
The first point I want to discuss is that practice is a necessity for learning any new skill, and simply copying the code in a tutorial is NOT practicing. At least, it isn't sufficient practice.
Far too many developers pick up a book or a course and expect to read it and "know how to program" after finishing. The truth is, this rarely happens. Why? Because you can't expect to know how to do almost anything after just reading about it. You need to practice!
Sidenote: This is also why titles like "Teach Yourself Go in 24 Hours" are comically deceptive. At best you can expect to familiarize yourself with the language in that amount of time, but to actually learn any programming language you are going to need to actually write some code in that language.
While coding along with a tutorial can be a great starting point, simply coding what someone tells you to code is mostly mindless. You don't have to think about what you are doing or really prove that you understand the material. As a result, only coding along with the tutorial is unlikely to produce the desired results.
Instead, what I highly recommend is some combination of (a) trying to code the project on your own before using the resource, (b) using your resource as an outline or guide, but not relying on it directly, or (c) applying what you learn in other projects/problems after learning it.
What does this look like in the real world? Let's look at a few examples.
First, let's look at a developer who wants to use Gophercises to get some practice writing real Go code. How can they do that?
My recommendation would be to watch the videos where they introduce each exercise, then to stop the videos and try to code each exercise on your own. It is going to be hard; in many cases what might be possible to code in an hour could take you days. But that is okay. The goal here isn't speed, but to force yourself to read the Go docs and to try to piece together how to use the various libraries necessary to solve the problem at hand.
You might get stuck along the way, at which point it is fine to watch the video for ideas. That is why the videos are there - to show you how another developer might approach the problem - but I do think that it is important to give yourself a chance to solve each problem first.
Alternatively, or perhaps if you get stuck and need to watch a video, another approach is to watch the video first to get an idea of what you are doing and then to give yourself some time - perhaps a few hours or a day - and then come back and try to code the same exercise without watching the video. Don't worry about getting it exactly the same as the video, but just try to solve it on your own now that you've seen it in a video.
My bigger point with both of these approaches is that we aren't just letting someone hold our hand and tell us exactly what to code. Sure, watching those videos IS useful in understanding one way to solve the problem and in learning new techniques, but we can't really expect to improve our own development skills by just watching. We need to code some.
This code first approach works well with something like Gophercises which is setup to be exercise-oriented, but what happens when we want to learn from a course or tutorial that teaches us a new set of skills we have no experience with and isn't organized as exercises?
For our second example, let's look at a few ways to get the most out of my Web Development with Go course assuming that you don't actually know how to build a web application.
Sidenote: The examples I give here will be specific to this example, but the techniques we see here are generally applicable to any tutorial or course out there.
Unlike our first example, it isn't really feasible to start writing a web application without first learning how to do it. We might not know how to properly create an authentication system, and that really isn't something we should be winging. So what do we do?
In cases like these I encourage developers to watch the videos (or read the book), and to then use them as an outline. For instance, in my Web Development course we create a photo gallery application, and your first pass through the course videos it probably makes sense to build the same application, but that isn't where I would stop. I would then do a second pass through the course material (or if you prefer, do a second pass through each chapter as you complete it) and try to build something similar, but not quite the same. Maybe a Twitter clone, or a Pinterest clone, or even a mini Reddit.
The goal here is to pick something close enough to the original project that we can use it as a good guide, but to make it different enough that we are forced to think about what we learned in each video and apply it to our unique application. By doing this, we force ourselves to truly understand the material, because if we didn't we wouldn't be able to adapt what we learned for our specific project.
Sidenote: If you are an experienced developer coming to Go from another language you can often do this on your very first pass through of the material.
Lastly, there are going to be tutorials where you can't really use them as an outline and you also can't really code all of the problems without following along and learning the material first. A great example of this are algorithms, where you can't write a bubble sort without understanding what it is, but it is hard to use a tutorial or screencast as an outline without just outright copying their code.
In these cases I highly recommend learning the material and then applying it in other projects or practice problems. Going back to our algorithms example, the best way to REALLY ensure you know how an algorithm works is to find many problems that use that algorithm and to try to solve each of them.
Sidenote: Sites like Topcoder and HackerRank can be great for finding practice problems, but don't get so caught up in those that you don't learn practical skills.
I really cant' emphasize this enough, even if you are the type of person who feels like you "get it" by just watching the video or reading the tutorial. While studying computer science at university I found that a vast majority of my peers could sit through a CS class and afterwards if I were to talk to them about the new algorithm we learned about, they could explain it quite well, but if you actually asked them to code it they would struggle.
With nearly all coding concepts you need to actually put it into practice on your own project before the material really sinks in. So don't just watch a video or read book. Actually go build something or solve a practice problem using what you learned.
Use resources more than once
Another common mistake I will see is the "once and done" mistake. What I mean is that developers will read a tutorial or go through a course once and then be done with it. This is a bad idea for so many reasons.
The first is that you will very often not have all the knowledge you need to really put the entire picture together your first pass through. What I mean by this is that things we learn in programming (and in most areas of life) have these weird cyclical dependencies where we need to understand A to understand B, but we also need to understand B to understand A, so how do we ever get started?
The answer is that we start off with little bits and just ask the developer to come back to the parts they don't understand a little later.
For instance, when a developer is first learning Go we might tell them, "Don't worry about this package main part - we will learn what it does later. For now just understand that our main function is going to run and whatever code we put in there will run as soon as we start our program."
Then once that programmer understands their program we might teach them about packages, and then finally come back and explain what the special main package is for.
When we get into more complex subjects like testing and web development this gets even harder because there are so many moving parts. The truth is, it isn't really possible to understand it all the first time you read about it. So just go through the material, get what you can out of it, but plan to revisit it later once you have a solid foundation to build from.
Expand upon what is taught
Another big difference I see between those successful with courses and those who are not is that the successful ones almost always try to expand upon what is being taught.
A simple example is to take a simple tutorial that teaches you how to build a web server with a few pages and to add new pages, but this can be taken well beyond that.
For instance, my Web Development course is intentionally designed so that you can swap out the DB implementation with pretty much any implementation you want very easily, and I encourage students to do this. Many students have already taken advantage of this and have rewritten that part of the application using a different database library (eg sqlx, an alternative sql library) while others have completely replaced our Postgres database with MongoDB.
It is unrealistic to expect a tutorial for everything you will need to do in your day-to-day job as a developer. Rather than getting bummed out by this, the more successful developers take what they are learning and try to stretch it beyond its limits and then discuss what does and doesn't work with others.
This can be challenging the first few times, but with practice you start to actively think about how you might adapt a tutorial for your needs and it becomes much easier with time and experience.
What works best for you?
I suspect if anyone out there learning to code were to take half of the advice here and apply it when using tutorials, books, or video courses that they would see a drastic improvements in what they learn and retain.
That said, I'm likely missing a lot here and I'd love to know what other tips or advice you have. What has worked well for you? Let me know what works for you in the replies, or check out the #discuss post I created to help start the conversation.
Want to learn Go?
Interested in learning or practicing Go? Check out my FREE course - Gophercises - Programming Exercises for Budding Gophers.
I also have some premium courses that cover Web Development with Go and Testing with Go that you can check out, and I write about Go a lot on Calhoun.io as well.
Top comments (0)