I wanted to share a simple technique that has become one of my top approaches for acquiring new technical skills. If it works for you, great!
Small disclaimer: I do not consider this method to be a shortcut as it will still require a large time investment. It does, however, provide a framework to make approaching difficult topics a little less intimidating.
This technique actually came from a professor I had during my Sophomore year of college. He was the type of professor that everyone looked up to regardless of who you were or how much experience you thought you had. There was no such thing as “too hard” or “too ambitious” in his world, and the latter part of his career was spent trying to redefine computing altogether.
If you’re just starting with programming, expect to be confused a lot. The only time this is a concern is if you actually hate what you’re studying. The thing is that you will always get confused anytime you try and take an ambitious leap into a new realm. It just so happens that for most people, beginning to program itself is an ambitious leap. Don’t let it stop you.
You can adjust this to your liking. My personal approach tries to emphasize hands-on effort while going through any sort of technical material since this helps me retain new information better.
While this method has helped me a lot, you still need to be willing to sit down and put in the time. Put in as much time as you can schedule in and you will reap the benefits later on.
Here are the steps to a great method for acquiring new technical skills:
The first step is to clearly identify what it is you want to learn. It can be broad, i.e. “I want to learn C++” or it can be specific, i.e. “I want to learn how Haskell implements lazy evaluation”. It could be that you want to build a small website for your resume. It could also be something you did not choose, for example, if your boss wants you to learn it or it is part of a class you are taking. This is all fine.
Next comes the part where you identify resources that seem good for you personally. Have more than one! I will say that I have rarely if ever, found a single resource that explained everything I wanted to know for a given topic, or explained everything in a way that made sense to me. Even if you’re following a tutorial, have some backup materials. If you hit a point where they gloss over something that confuses you beyond belief, fall back on your other sources and see if they cover something similar. See if their version makes sense to you, then return to your tutorial once it does.
As an example, back when I wanted to learn OpenGL, I had not one, not two, but four separate resources: 2 online tutorials that seemed good, 1 desk reference/tutorial hybrid, and 1 math book. Between the 4 of them, I got what I wanted, and whenever I thought one explained a topic badly, I just hopped to one of my other ones (or Google) to see if their explanation was better. Be proactive. Sometimes just reading the same paragraph 40 times isn’t your best option.
As for how I found these, Google is the main thing I use. I would first Google for tutorials on a topic, then I would Google for books. If they showed up on a place like StackOverflow and had a lot of support then I would add it to my list. The resources would very often be different as well: GDC talks from a while back, a research paper(s), or a set of PowerPoint slides from a University. I should also point out that “List of best x for y” usually brings up some good stuff: here is the top result for “List of best books for C++”.
As another example, my professor did not have a textbook for the course back then. Instead, he had a list of resources he thought were good supplements, but he did not require that you use all/any of them. This is an important step in acquiring new technical skills.
Now it is time to set up your environment. For this, you will need to create at least 1 folder to put the files for the actual project you want to complete. Then, you will create another separate folder for your scratch work. And by scratch work, I actually mean that you will treat it as if it were a piece of throwaway paper that you do side work on. It is a place for you to write little pieces of code to test something small before you put it into your real project. The code in the scratch folder doesn’t have to be pretty, but it does have to convince you that you understand a concept before you continue adding to the main project. It can also convince you that an idea you have actually works before you mess with the real code. Here is an example:
You are editing files inside of your main project file as you read the tutorial you’re following. The tutorial has already introduced you to Java arrays, and then later they say something like “But how do we get the length of an array? Easy! All arrays have a secret .length field.”
You stop. Hidden .length field? Every array has this and you don’t have to do anything for it to work? You move over to your scratch project to test it out.
“ArrayLengthScratch.java” gets created, and inside the main method you create 3 arrays: an array of characters (char charArray), an array of ints (int intArray), and an array of doubles (double doubleArray).
Next you print all of their lengths. “System.out.println(charArray.length); System.out.println(doubleArray.length); …”
Finally, you compile it, and holy crap it works, and the lengths are all exactly what you expected! The tutorial must have been right after all.
Then a thought occurs: Can you edit the length variable?… You add “charArray.length = 10;”, and when you go to compile it fails miserably because .length is final. Now you know something else.
Happy with what you’ve discovered, you move back to your main project folder and continue with the tutorial or whatever it is.
This one is more of a rule than a step. With this method, copy+paste should be avoided. By this I mean the action of highlighting code, ctrl+c, ctrl+v, compile. Even if you promise yourself you’ll read it after you paste it and try to understand it… still bad. Even if you think you already get what it’s doing after reading its explanation: nope. If you are going to do this, at least take the time to hand type every single line.
This will definitely slow down the process of acquiring new technical skills.
By this point, you have likely made a dent into a particular topic. If it was a tutorial, maybe you just finished “01. Hello, Triangle” or “03. Reading User Input”, meaning there is probably some working code inside of your main project that does what the tutorial said it should. This is when a lot of people get tripped up because they just move on to the next topic! This is one of the quickest ways to trick yourself into thinking you understand something you don’t. It is time to take ownership of the code so that it’s different from the tutorial/book example…
Let’s say “03. Reading User Input” is done and working on your machine. It starts up, asks the user for their name, prints “Hello, *name*!” and quits.
To challenge your understanding, you take it a small step further. Can I ask them how old they are? It’s ok if this step requires you to Google around or even tap into one of your other resources. Make use of your scratch section to test things you find or ideas you think of.
It asks the user their name, then their age, and then their occupation. If their age is greater than 80 then maybe it tells them they’re old or something. The point is, it now does more than the original because you wanted to challenge yourself. Challenging yourself helps tremendously in acquiring new technical skills.
This is also a good time to combine what you’ve learned previously to add to what you’re currently working on as part of the extension.
Once you’re satisfied you can move on. Just make sure to do this: I can’t tell you how many times I’ve done this only to realize I’m still way too shaky on the current topic to even think about moving on. Instead, I spend a little extra time working with the code I have by tweaking it, adding to it, etc. Maybe I’ll reread the same tutorial again a couple of times. Whatever it takes in order to take ownership of the content.
And that’s just about it! But I want to share one more piece of advice that might sound stupid: run your code. Run it often. Run it every time you make a change. If you’re working on a project that is your own creation, find the simplest path to getting a barebones version running and then add functionality from there. Even if all your methods do is throw a runtime exception saying “ADDME” when called because you haven’t implemented them yet, put them in so that it all compiles and runs.
It’s much easier to test and debug smaller additions as you make them than it is to test it later only to find multiple things that are broken at the same time.
Never have just one resource
Always have at least two folders: your real project and a folder for its scratch work
Anytime you want to test an idea or convince yourself of something someone said, switch to the scratch section and hammer out some simple test code
Copy+paste should be avoided while learning – at least take the time to handwrite it
Never be satisfied by getting a tutorial working as expected: add to it to claim ownership of the code and convince yourself you actually understand what you just did
Run your code as often as possible
I hope this helps someone! I personally really like this style and use it whenever I can. It’s a very aggressive method since you’re rarely ever just passively reading or blindly following a tutorial.
Another thing that a new programmer may want to do (depending on how they learn), takes literal notes. Pen and paper, reading through the literature, and writing things down to retain that information. This definitely isn’t a must, but is something that I’m doing and is certainly helping me so far and allows me to look back when needed. I’ve only been starting to learn programming this week (after learning a bit in high school until I started to sleep in class) and remember how hard it was for me to learn by strictly reading and typing.