A concise and tactical guide to learn to code.
Learning to code is hard. Many people are trying to learn to code, and many of them are frustrated with their progress not matching their expectations. Developer bootcamps have emerged to monetize this frustration.
People who are:
- Still beginner programmers
- Short on time
- Frustrated with the process of learning to code
Writing substantial code requires more knowledge and practice than most beginners realize.
Let's say learning to code is like climbing a hill. Beginners start at the bottom. You can see the top of the hill, and you want to climb up the hill, in a straight line, up to the top.
Learning to code requires conquering unforeseen obstacles every footstep along the way. The path up the hill becomes less straight and predictable as it looked when you were standing at the bottom of the hill.
The core problem of learning to code is that you don't know what you don't know. You can't see all your obstacles from the bottom of the hill, and the path becomes much longer and more difficult than it initially looked.
Unfortunately, you can't just learn how to write Ruby or Python or JavaScript syntax and then suddenly know how to code. In addition to your first programming language, you have to learn the language of programming, of computers, and of the internet.
There is a chicken-and-egg problem when it comes to the vocabulary of code. You need to know the vocabulary to understand fundamental concepts, but you need to understand fundamental concepts to understand vocabulary.
Beginners will see an inflexion point in their progress once they understand the technical jargon.
The typical beginner wants to build web or mobile apps. Definitely not all beginners, but I'd say the majority do. Building apps is different from computer science. Unfortunately, most programmers advise beginner programmers on becoming better computer scientists, not better app builders.
For many beginners, learning to code is a means to an end. The end goal is not code. It's building apps. Most people advising beginners fail to realize this.
Just-In-Time learning is when you acquire knowledge to apply that knowledge immediately. Just-In-Case learning is when you acquire knowledge without any tangible, pressing need for it. Most of us were educated in a Just-In-Case manner for many years of our lives. However, Just-In-Time learning is a much faster way of learning than Just-In-Case.
Beginners struggle to learn because there's usually no tangible, pressing need for programming knowledge, so all their self-study reduces to Just-In-Case learning.
Text editors feel clunky and unproductive for beginners. Text editors usually require customization and learning before they're helpful, which makes them even less beginner-friendly.
Worse is the terminal.
Nobody likes the terminal when they start using it.
- Jason Laster
Sadly, there's no getting away from the terminal. You're stuck with it.
The main objective for a beginner is to break the vocabulary chicken-and-egg problem. I think the best way to do this is immersing yourself into the language of programming by reading it and by speaking it.
When you start breaking the vocabulary chicken-and-egg problem and you start grokking the technical jargon, you'll know what search terms to google. Using search engines is a primary Just-In-Time learning tactic.
99.99% of programming problems you'll experience were already solved publicly on the internet. You can find their solutions for free.
As you google more, you'll start recognizing specific websites as reliable sources, which will help you find your answers faster.
When you're writing code, most of your time is spent fixing code rather than actually writing new code. You must learn to debug broken code. Not a single beginner ever realized how much time would be spent debugging.
The first way people learn to debug is usually with print statements. Print debugging is the most basic form of debugging.
Debuggers are an alternate method, a tool specifically for debugging. If you have access to a debugger, use it! Even as you get comfortable with print debugging, a debugger will always find ways to be useful for you.
The lessons you learn from debugging are also Just-In-Time lessons. As you improve at debugging, you'll learn more and more.
Pair programming is when two programmers work together on the same computer. Pair programming can be a tremendous way to learn to code if you happen to match with your partner.
Some programmers are better at pairing than others. I'm not entirely sure what makes the difference, but I think it's communication and empathy.
I encourage you try pair programming with an experienced friend. If you learn a lot with them, great! Try pairing with them more. Bribe them with food if you want. If you're not learning with them, or if they make you feel uncomfortable with your inexperience, stop. Don't take it personally. It just means that your friend is bad at pairing, not that you're bad at learning.
The most helpful books will:
- be written primarly for beginners
- be about a topic that the beginner is particularly excited about
- have great reviews
Books are great for speeding up your learning because they are targeted towards both your interest and skill level.
I general I like the idea of this essay existing as I feel like I've not exited this beginner stage myself.
PS this is *the best Unix/Linux primer I've ever seen: http://www.ee.surrey.ac.uk/Teaching/Unix/ (i tell people tutorial 7 is optional)
All in all, great thoughts thus far Broseph (@dillonforrest) . ^_^