There are a number of tips and tricks for maximizing your speed of durable learning. Devs know these help, and yet we stubbornly ignore them all the time.
But just in case you want to get faster at learning, here are a few things that work for some people. No guarantees; everyone’s different, and you might have your own path that works better.
Music is one of those things. Some people swear by silence or white, pink, or brown noise. Some people listen to classical music, or electronica, or metal. Do what works for you.
Flow30 is a mental state you get in where you’re focused and ideas are connecting freely. There are no interruptions.
Programmers like to get in flow for maximum productivity.
Here are the characteristics of that state stolen directly from Wikipedia:
You’ve probably already experienced this in some aspect of your life. Keep in mind that it can be very beneficial for programmers.
I know when I was a student, if something was due on Sunday, I’d commonly read about it for the first time on Sunday. Anyone else do that? Yeah.
But here’s another idea: read the assignment as soon as you get it. Maybe you don’t know enough yet for it to make sense, but that’s okay. Just read it, maybe not even that closely.
And another idea: read the assignment when you’ve done some of the other reading and lecture, but days before you plan to start working on it. Again, just read it, not worrying about solving it. Maybe read it right away and partway through the week!
What this does is prime your brain with the information. You won’t retain it or understand it all, but your brain will start chewing on it in the background and will make the project easier to tackle when you finally get around to it at 9 PM Sunday night.
And when you do start the four-stage problem solving process, the material will seem less foreign and more approachable.
A powerful variant of this is to complete the Understanding phase early. Don’t need to Plan or Code it up yet.
You need to solve a problem, and look right there on the Intertubes! There’s a solution! Time to break out the ol’ CTRL-c/CTRL-v skills!
It used to be that people frequently found this solution on the programming site Stack Overflow31. And still do. But nowadays they tend to punt to some AI.
Beginning developers should not do this. Remember the main goal: develop excellent problem-solving skills. Copy-paste coding does nothing to further this goal.
One exception to this rule is if you already struggled with the problem for some time, as mentioned in the 30 Minute Rule section, above. But even then, you must understand the code you’re copying 100% completely before using it.
If you’ve been stuck for 30 minutes and you’ve really tried to attack the problem from a variety of directions and have still come up dry, it’s time to reach out for help.
Yes, you can go longer than 30 minutes without help (we all do), but 30 minutes is a good balance between working hard and bring productive with the limited time you have for schoolwork.
Here’s a story. One of my favorite books for learning about programming is called The Structure and Interpretation of Computer Programs32, or SICP for short. (I particularly like the Scheme version—really helps you learn recursion.)
The programming problems in that book can be really challenging. But I gave myself a six hour time limit per problem. (I didn’t do all six in a row, usually.) After the time was up, I looked at the answer.
And here’s what that does and why it’s important: while you work hard on a problem, you’re busy building a mental framework around it, trying to support it. And if you get the answer, great! But even if you don’t, you’ve still built that framework.
So when you give up after your time limit, very often the solution you read fits neatly into the framework you’ve already built. It’s just a tiny step from your framework to the solution, and it’s way easier to take that little step to the solution than to try to grok33 the entire thing.
Contrast that to when you just look up the answer immediately without building the framework. The solution has nowhere to “sit” in your brain, and doesn’t connect to anything else. And it’s a much bigger step to achieve understanding.
The struggle is vital! Don’t skip the struggle! But at the same time, don’t keep it up forever. When you timeout, ask for help from a peer, a tutor, an instructor, or (if allowed) an AI.
Also, maybe follow this up with going for a walk.
Yes, I’m serious. You’re stuck, and nothing seems to be working, and no additional plans of attack are coming to mind. What do you do?
Go for a walk.
As you try different approaches to a problem, it’s like you’re leaving ruts behind in the road, and your brain tends to focus on the existing ruts rather than trying something new. You’re locked in on the approaches you’ve tried but aren’t working. “If only I could just tweak this one thing that almost works…” but you’re not seeing how.
Stand up and stroll. Maybe you’re at work and this just means you’re making laps in the hallway. Or maybe you can go outside on a balcony, out front, or on the roof.
This frees your mind to get out of those ruts and explore new approaches.
There have been times where I’ve decided to go for a walk and have gotten two steps out the door when a new approach to the problem has occurred to me.
This method of getting unstuck is tried-and-true.
Talk to someone about the issue. This is such an effective technique that it even works if you’re talking to an inanimate rubber duck, giving rise to the name rubber ducking.
The basic idea is that you’re going to lead the other person through the problem-solving steps, effectively teaching it to them. Get them to understand the problem, and have them help with a plan.
Here’s the really amazing thing about this: it works even if the other person (or duck) is non-technical.
One of the reasons is that to understand a problem and come up with a plan, you really don’t need to know anything about programming. They can still help.
And here’s the really amazing thing: they don’t even have to say anything. The mere act of teaching someone about the problem is very often enough for you to find the answer on your own. Maybe it was a piece of understanding that you missed, or there’s a non-obvious hole in your plan. Talking it through can help you find these things.
One time, in a combination of going for a walk and rubber ducking, a coworker of mine walked up to my cube, raised his hand as if to ask a question, paused a beat, then said, “Never mind, I figured it out.” That was all it took.
When poring over a problem description or learning a tool or language, there are basically two kinds of questions that crop up.
Blocking questions are questions that you need an answer to right now because they’re blocking your progress. You can’t do anything else until you get the answer.
Non-blocking questions are things that come up of the course of development that are interesting, but you can keep going without knowing the answer right now.
I like to write down non-blocking questions and get answers to them later. Things like, “Does this language support destructuring assignments?” or “Can the library also provide random numbers in an integer range?” or “What other networking protocols are built into the standard library?”
They were things that I was curious about, but didn’t need to know the answer to immediately.
Coming back and getting the questions answered later can help build a more complete picture of the systems you’re working with and make you a more effective developer.
This is where it all comes together.
When you first start coding, you’re in the middle of the vast unexplored world of knowledge. You’ve learned how to print Hello, world! on the screen, but that’s it.
So you start mapping it out. You see that there are functions and variables and I/O operations and you see how those are connected. And you learn about networking and see how that’s connected to the I/O system in the OS, and you connect them on the map.
As your map grows, you draw connections between many of the things you’ve learned, and you gradually see that the world of development is more interconnected than not. A lot of problems are very similar to a lot of other problems.
And when you know a lot of problems like that, that’s a lot of power you can bring to bear on new challenges you face. “Oh, this problem x reminds me of problem y. Maybe I can solve it in a similar way.”
You have a group of 10 people numbered 0 to 9 and they are all lining up at a bank window. Your simulation needs them in random order with no repeats in \(O(n)\) time. How do you code this up?
Maybe earlier you’d written a program to shuffle a deck of cards using the famous Fisher-Yates algorithm34… wait! All you have to do is make a list of people numbered
0to9in order, then shuffle the list like a deck of cards!It’s the same problem!
Beginning developers solve programming problems through sheer logic and reasoning.
Experienced devs also use logic and reasoning, but they primarily rely heavily on pattern matching. What coding pattern do I know that best solves the type of problem that I’m currently facing?
In short, they rely on their interconnected tapestry of knowledge they’ve built up over their years of programming.
As you learn to code, look for ways that the thing you’re learning about now connects to the rest of the programming world you’ve already explored. Make those connections so you can exploit them later.
It can be really hard to put your code out there and ask someone to give you advice on how to make it better. It’s easy to take that advice personally.
But fight that urge, and treat every code review you get like a gift. Someone was willing to spend their time helping you become a better coder, usually at no cost to you.
Be nice during code reviews no matter if you’re the reviewee or the reviewer. Be supportive with your feedback, be modest, and don’t take negative feedback personally.
And if you can’t find a human to help, feed it to an AI chatbot and ask it to review your code.
Even if you’re not well-versed in the subject matter, that shouldn’t stop you from giving a code review if you can. Just reading other people’s code exposes you to different coding styles and algorithmic patterns that you might not have been aware of.
But remember to always be opinionated about the feedback you get, and use critical judgment when deciding whether or not to incorporate it.
Coding has historically and generally been a solo endeavor—at least the part where you’re sitting at the keyboard typing things. And even during the Understand and Plan phases it can be tempting to work alone.
Joining a like-minded group of people where you can bounce around ideas (or even just vent) can really help your brain get unstuck from ruts and help you approach problems in ways you hadn’t considered or even been aware of.
It’s also good for networking, and lots of clubs have interesting presentations you can attend. Or even better, present at!
Clubs can make the fight feel a lot less lonely. We’re all in this together.
What do you (personally) do to get into flow?
What are the advantages to reading an assignment way before you intend to work on it?
What are the disadvantages of working on a problem for too short a time before asking for help?
What are the disadvantages of working on a problem too long before asking for help?
When is it acceptable to use copy-paste coding? What happens if you use it unacceptably?
Why is going for a walk a good idea when stuck?
How can an inanimate rubber duck be a good programming partner?
What does the author mean by tapestry of knowledge and how does it relate to your skill as a developer?
What do you gain by getting a code review? What do you gain by giving one?