Learning Tips for Programmers

Ali Spittel - Sep 29 '20 - - Dev Community

One of the most challenging but exciting parts of being a programmer is that the field is constantly evolving and the learning is never done. Learning is a topic near and dear to my heart: I'm a mostly self-taught developer, I studied education in college, and I taught at a bootcamp for years. I wanted to write down some of my tips for learning in hopes that these may help you in your process.

Planning

The first stage of learning is the planning phase: what should you learn in the first place. For those just starting out, figuring out what you need to know will be the first step. For those more established in the field, you'll probably have a topic that you need to learn for some reason or another.

If you're just starting out, I recommend exploring first -- try writing some code, following some tutorials (here are some of my favorites), and figuring out what you enjoy. Then figure out what your learning goal is: do you want to become a professional developer, do it as a hobby, or add an additional tool to your skill-set?

Once you have a list of skills you need to learn, create a learning plan. This may evolve over time as you learn more about the topic, but having an outline of what you need to learn will help you allocate time and structure your materials. Here is a great video on how to create a learning plan.

Stay on Track!

You may be tempted to completely pivot topics, especially if your current one gets difficult. But, only pivot as an absolute last resort. There are usually peaks and valleys in learning, and you need to get through the difficult parts to really learn something.

It's also important to not get shiny object syndrome where you see a new tool come out or see someone discussing a technology and you decide to abandon everything and go in that direction. Stay steady in what you're learning, depth of knowledge in an area is much better than being able to write "hello world" in 20 languages.

Build a Habit

I feel like I bring up Atomic Habits in half of my blog posts, but it's just that good! There are groups like #100DaysOfCode that can help you build up the programming habit, or you could use a habit tracker like Done.

Don't Just Use Tutorials

I have written about this extensively in the past, but make sure to actually build things yourself. Problem solving is the most important skill to build as a programmer.

When I teach classes, I follow the format "I do, we do, you do" in which I conceptually explain something, then we do a code along where I write code on a projector and everyone follows along on their computers, finally the students do an exercise on the same topic. You could re-create this process independently by watching or reading a tutorial, following along with the code pieces, and then challenging yourself to build an app or feature with what you've learned. Then test yourself again in another context!

There are studies that lectures and reading alone are not good for making learning stick. Tutorials follow the same model. Make sure to test yourself by building applications, taking notes, and quizzing yourself on concepts.

As with learning a new spoken language or an instrument, practicing is key. When you start learning a new topic, the neural pattern for it is weak. When you have it down cold, that neural pattern will be more permanent. Practicing a bunch is the best thing you can do. Reading about riding a bike will help to a certain extent, but at some point you just have to ride it to get better. Write code as much as possible, and challenge yourself to solve difficult patterns.

Learning Styles

I'm sure you've been asked at some point "what's your learning style?" or been told to really prioritize that when you're learning something new. It turns out that the idea of learning strategies, where some people learn best visually, others through text, others through hearing is mostly debunked. It turns out, it's advantageous to learn the same topic in multiple modalities or to use the best modality for the topic. So, use strategies and resources that work well for you, but also switch things up and try learning in different ways.

Strategies

Take Notes

There is a ton of research that taking notes when you're learning is beneficial, especially if those notes are hand-written. I normally use my iPad to write my inital notes while I'm going through a course. Then, I use Foam to further organize those thoughts and make them into something I can come back to. If you're artistic, sketch notes are so cool and the drawings will help you build connections.

Put Your Learning in Context

It's much better to learn new information in context of what you already know. I remember when I was learning React, there was a tutorial showing how to do things in both JQuery, which I knew, and React. It was so helpful to see both the familiar and unfamiliar way of doing something. Make explicit links from something you already know to something new. You can use tools like mindmapping to do this, or you could just be mindful about noting links in your normal notes!

Learning in Public

One of my favorite quotes is, "When one teaches, two learn." by Robert Heinlein. One of the best ways to solidify your knowledge on a topic is to teach it to someone else. You can create resources for the public, like blog posts or videos, or you can explain your learnings to a friend or even a meetup or conference! Here's a great resource on why and how to learn in public.

Quiz Yourself

Make it Stick is an awesome book about how to solidify concepts in your memory. I generally believe that understanding is more important than memorization for most developers, but if you're studying for interviews or tests you may need to focus more on memorization. The authors of "Make it Stick" recommend quizzing yourself to build up recall. You could build up a flashcard deck on the topic you're learning or challenge yourself to create something or solve a code challenge without any resources.

Come Back to Topics

Instead of learning a topic all at once, come back to it continuously. Spaced repetition is when you have shorter study blocks with breaks in between your sessions. So, you may start learning a topic one week, then come back to it a week later, and then a week after that. This time in between will force you to review and recall your new knowledge, solidifying the neural patterns for retrieving the information. Have you been told that cramming for tests is a bad strategy? This is why!

A potential plan that utilizes spaced repetition may look like this:

  • Day one: Learn CSS fundamentals
  • A week later: Learn a CSS concept that builds on the fundamentals
  • A week after that: Build a project that uses both concepts

You don't necessarily need to re-read the same tutorial, but make yourself review topics so that they become more and more familiar. Learning something once usually doesn't make it stick.

Take Breaks

I cannot recommend the Coursera Learning how to Learn course enough. One of their main focuses is on the two types of thinking: focused and diffuse. Focused is when you're concentrating on learning something or solving a problem. Diffuse is when you're in a more relaxed state. Often times, the diffuse mode is where links are made from one topic to another and knowledge is solidified. You may have heard the trope of "solving a bug in the shower", and it holds a lot of truth! Make sure to take breaks and step away from your computer. It's so important for learning and life balance!

In addition, sleep and exercise help with learning as well -- make sure you're taking care of yourself and not just coding all the time!

Fixed Vs. Growth Mindset

Believing that you can learn something is a huge part of actually being able to learn it. Carol Dweck's book "Mindset" focuses on the fixed vs. growth mindsets. In a fixed mindset, you believe that your attributes are static and that they will be unable to learn or improve their talents. In a growth mindset, people believe that they can improve and learn. People with a growth mindset are much more likely to put the time and effort needed into learning new material, and they're much more likely to enjoy learning. There are many factors that go into a growth vs. fixed mindset, such as upbringing and educational environment, but if you find yourself in a fixed mindset work on growing a growth mindset.

Ness Labs has a bunch of amazing posts on neuroscience, and this post has a bunch of strategies for moving into a growth mindset. Some include: acknowledging the research that brain structure is not fixed, appreciating criticism, and putting a positive framing on failure.

Believing in yourself is such an undervalued yet important piece of learning!

The Levels of Learning

Bloom's Taxonomy provides an awesome framework for assessing your knowledge and expertise on a topic. First is factual knowledge, then conceptual, then procedural, and finally metacognitive.

Factual knowledge would be something like "CSS uses curly braces and text", conceptual knowledge would be "CSS is used to style web pages, you use selectors to choose which element or groups of elements to style", procedural knowledge would be the ability to style a web page with CSS, finally metacognitive would be knowing your strong points and weaknesses with CSS and being able to fit it into the bigger picture of web development.

Adding reflections into your learning process will help you progress within Bloom's taxonomy -- fit your new knowledge into context of all your learning and self-assess your progress and topics you're unclear on or haven't learned yet.

Similar Posts

There are a lot of interlinked topics to this one that I've written about in the past.

I hope these tips were helpful, if there's one thing you take away from this post it's to take breaks, learning all the time is ineffective and impractical!

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .