Chapter 7

Hacks and Techniques for Learning

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.

7.1 Flow
Flow1 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:
1. Intense and focused concentration on the present moment
2. Merging of action and awareness
3. A loss of reflective self-consciousness
4. A sense of personal control or agency over the situation or activity
5. A distortion of temporal experience, as one’s subjective experience of time is altered
6. Experience of the activity as intrinsically rewarding
You’ve probably already experienced this in some aspect of your life. Keep in mind that it can be very
beneficial for programmers.

7.2 Reading Ahead

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.
1
https://en.wikipedia.org/wiki/Flow_(psychology)

23
Chapter 7. Hacks and Techniques for Learning 24

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.

7.3 No Copy-Paste Coding

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 Overflow2 . 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, below. But even then, you must understand the code you’re copying 100%
completely before using it.

7.4 The 30 Minute Rule

If you’ve been stuck for 30 minutes and you’ve really tried to attack the problem from a variety of direc-
tions 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 Programs3 , 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 grok4 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.

7.5 Go 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.
2
https://stackoverflow.com/
3
https://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
4
https://en.wikipedia.org/wiki/https://en.wikipedia.org/wiki/Grok#In_computer_programmer_culture
Chapter 7. Hacks and Techniques for Learning 25

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.

7.6 Rubber Duck

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.

7.7 Write Down Questions

When poring over a problem description or learning a tool or language, there are basically two kinds of
questions that crop up.
1. 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.
2. 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 lan-
guage 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.

7.8 Build a Tapestry of Knowledge

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.
Chapter 7. Hacks and Techniques for Learning 26

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 𝑂(𝑛) 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
algorithma … wait! All you have to do is make a list of people numbered 0 to 9 in order, then
shuffle the list like a deck of cards!
It’s the same problem!
a
https://en.wikipedia.org/wiki/Fisher–Yates_shuffle

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.

7.9 Get and Give Code Reviews

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.

7.10 Join a Club

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.
Chapter 7. Hacks and Techniques for Learning 27

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.

7.11 Chapter Reflection

• 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 devel-
oper?
• What do you gain by getting a code review? What do you gain by giving one?