"Everyone should learn to code!" exclaimed the Internet in 2013. While some disagreed, services like Codecademy and Code School are making the learning-to-code experience different from the days of reading thick programming books and attending classes.
But even with these friendly UIs and encouragement from the community, learning new concepts in coding--new languages, patterns, frameworks, or just learning to code at all--can be daunting, particularly when it comes to making your new knowledge stick. Here's a crash course in how to prepare.
Even seasoned coders can relate: Sometimes a new job or project requires learning an entire new language. This often comes along with a deadline, limited learning time, and additional pressure when something big (a job! a raise! a product launch!) is at stake. Most coders prefer the "dive right in" approach to new languages, which can lead to problems if the coder is missing essential information on the new language.
This can cause frustration, particularly when the new language just doesn't seem to work the way the old one did, and programmers using new languages often follow patterns from the languages they already know, creating bad code that will need to be refactored later.
Experienced programmers do have a leg up on the n00bs, however: a frame of reference. They've hopefully already learned concepts of programming and have been thinking in if/else statements and other hallmarks of computer logic for some time, and they can apply those pieces of knowledge to learning the new language. The new online tools for learning programming emphasize the same "code first, learn later" approach that experienced coders prefer. While this approach does provide a way for learners to get over their initial fears of actually writing code and getting their feet wet, it doesn't build the new skills onto any existing knowledge, which may make it more difficult to stick in a learner's long-term memory.
In order to retain new skills, new and experienced programmers need to follow the principle of Elaborative Rehearsal, encoding new concepts by building on top of existing knowledge.
When I learned my first programming language, JavaScript, the only knowledge I already had to relate these new concepts I was learning came mostly from fuzzy memories of 9th-grade geometry class. Object-oriented JavaScript didn't fit in with the bits and pieces of JavaScript I'd previously used to add little effects to websites. I would often learn something, gain what I thought was an understanding of it, and then completely forget what I'd learned a week later and become frustrated by the experience. Even after I had a solid grasp of the language, concepts not present in JavaScript (like "compiling") would come up in conversations with the programming community and leave me confused.
The next language I attempted was SCHEME, for no other reason than my local hackerspace was starting up a group to study MIT's SICP book. At first I loved it; the book covered some of those principles of programming I'd missed when learning JavaScript. But eventually I became so bogged down trying to figure out all the math they used for their examples I couldn't keep up. I was drowning in Calculus. I didn't have the prerequisite knowledge for the information, and I found the entire experience frustrating.
The information I did manage to pick up from SICP proved useful recently when I took it upon myself to begin learning Objective-C. Not only did I understand concepts like variables and functions from learning JavaScript, but I now understood the purpose of a compiler and I'd brushed up on math I hadn't thought about since high school. Learning Objective-C was much easier than learning JavaScript because I had more information to build my new knowledge upon.
That said, some of the differences between the two languages tripped me up at times when I wanted to fall back into familiar JavaScript territory. I was still thinking like a JavaScript developer and trying to force the new language to fit into my existing knowledge, in other words, trying to code in Objective-C using a JavaScript pattern. If I'd had more experience with logical and abstract thinking, math, and communication I would have been able to attach concepts in Objective-C back to that solid framework of knowledge instead of trying to force the Objective-C shaped peg into the JavaScript-shaped hole.
I identified logical thinking, abstract thinking, math, and communication as the skills that build a framework for learning to code. Resources for learning programming languages are abundant, and resources for building a framework exist as well. You just need to know where to look. I've compiled a list of resources for each of the building blocks.
Computers are dumb. They do exactly what you tell them to do, no more and no less. Often when a computer isn't behaving the way I expect, I remind myself it all boils down to ones and zeros. Reminding myself that the computer's behavior is pure logic helps me gain perspective. Programming languages are based on logic, and understanding how an if-else statement works before attempting to code is essential. Forall x is an excellent resource for learning the concepts of logic. For more practice, play games like chess, soduku, and logic puzzles. A large portion of the LSAT includes logic puzzles, and you can find practice puzzles all over the Internet.
Programming isn't generally thought of as a "creative" pursuit and I think this is misleading and doesn't give programmers enough credit. You probably wouldn't know from the thousands of lines of monospaced code programmers produce, but there's a lot of creative thinking going on between the programmers' ears.
Programmers receive abstract concepts from managers, designers, and clients and have to turn those ideas into a working component. This usually involves breaking something down from the big picture into doable chunks, and then completing those chunks while keeping the big picture in mind.
Plus, not everything's going to work right the first time around. Sometimes your first idea doesn't solve the problem in the right way, so you have to come up with a second idea. And even a third. And then once you get it working, you realize it won't integrate with the component your colleague built so you need to come up with an entirely new concept, while reworking as much of your existing code in as possible so you can limit your rework.
One way most people, non-programmers included, regularly use abstract thinking is through idioms, and playing with these nuggets of language can help strengthen abstract thinking skills. Instead of throwing around familiar idioms, find some obscure ones and see if you can figure out what they mean. I also found an idiom-related game called Wise and Otherwise, where you make up endings to old idioms to fool your friends into thinking your ending is the correct one. You'll be "thinking outside the box" in no time.
(Bonus: Can you find all the idioms I've used in this article?)
Your teachers were right: You will use that stuff someday, if you're coding, that is. My SCHEME-learning experience made me wish I'd taken more advanced math classes, or at least paid more attention in the ones I was in. Even as a front-end developer, I sometimes find myself needing to understand a math concept to complete a piece of code. I have yet to find a programming course, book, or online learning tool that doesn't involve mathematical formulas in their learning materials. If the word "slope" only brings about images of downhill skiing, you might want to brush up on some beginning Algebra. From there, you can move on to more advanced concepts. If you're a practicing programmer and want to work on your Algebra skills, try out some of the problems on Project Euler.
Math, particularly Geometry, also relates directly to logical thinking in the study of proofs, so you can kill two birds with one stone. The first time I came across an if-else statement when learning to code, I instantly thought back to the if/then statements that make up Geometrical proofs. And boom! The concept of if-else stuck. It's a big deal in programming--you're constantly comparing things and doing different actions based on the results. Thankfully, the Internet has a variety of resources for learning about proofs, for free!
Solid communication skills aren't usually associated with being a good programmer, but the best programmers can expertly receive and understand communication from others, such as in the form of user stories, and turn them into code. The reverse is also true: Programmers know how to effectively communicate their ideas and solutions with others. They need to be able to understand what you did, how you did it, and why you did it that way. This skill can be practiced in other areas of life, even things as simple as what you ate for dinner.
I also recommend reading mystery novels: Try and figure out who did it, how, and why before it's revealed in the book. This will help you in the future--sometimes you need to read in between the lines and pick up on clues as to what the client or manager really wants. Then, explain the plot to a friend and make sure you leave them with a solid understanding of the culprit, the motive, and the method.
The idea that programmers have a unique way of thinking about problem solving, and even the world in general, isn't a new concept. Think Like a Programmer: An Introduction to Creative Problem Solving is a popular book that does exactly what it says on the tin--teaches you how to understand what it is you're trying to solve and creatively solve the problem through code. Chock-full of real C++ examples, Think Like a Programmer is for people who already have some coding experience under their belt. More approachable for the n00bs, Code: The Hidden Language of Computer Hardware and Software by Charles Petzold, goes into communication betwixt humans and computers and among computers themselves. It provides a solid big picture understanding of computers, helpful for anyone looking to build code.
One thing I cannot recommend enough for new and even experienced programmers is finding a mentor. Having someone more experienced than you available to encourage you and provide answers when Google fails is invaluable. Mentors can come from all over the place. Most of mine have been coworkers, but I met one on the WordPress support forums. The programming community is full of people who love sharing what they know and you'll most likely run into would-be mentors just by interacting with the community. That said, here are some ideas for taking a more proactive approach.
Teaching kids to code is the new hotness, and there are already tons of resources to help them learn, from robots and Lego kits to programming languages designed for kids. If your child is interested in this popular skill (or you want them to be) you can help them out by building them a foundation, too. Here are a ton of ideas for helping kids learn abstract thinking. As a kid, I loved solving riddles, and I'm sure that practice helped my abstract thinking and by extension my programming as an adult. Of course, kids learn math in school, but parents can always add to the equation. And what's more fun than doing math? Playing games with math, of course! Kids might enjoy playing these games so much they'll want to learn how to make their own.
The New Way Things Work is a well-known book that details how machines, like computers function. I should note that it was published in 1998, so its relevance to current technology is waning. Computer Science Unplugged is an online resource for teaching kids about computer science. It's aimed at teachers, but I'm certain it's totally legal for parents to utilize it as well.
Think of it like the training an athlete goes through: They are working out the muscles they'll need to excel at their sport. A football player doesn't just practice throwing, kicking, and tackling over and over again. As a programmer, you're working out your brain and getting it rock-hard to tackle new languages and skills. Of course, there's no law saying that logical and abstract thinking paired with math and communication skills are necessary for learning code, but give it a try, and see if working on these skills also makes you a better programmer.
I challenge you to spend 25% of the time you would spend learning and practicing new programming languages working on the skills mentioned here and see if your coding and your learning abilities improve. That way when you actually do get your feet wet you'll have a life jacket of knowledge to keep you afloat.