The Scenario:

You think that your coding skills have leveled up, and so you've decided to "LeetCode".

Only now you're starting to doubt yourself, because you've encountered difficulty solving some of the coding challenges. Maybe you've started wondering why you ever believed this career fit you. You keep thinking that you understand the problem, and so you continue to hack away on the keyboard. You beat your head on the desk. You sigh a few times. Reach for a tissue to daub away a tear of frustration. Howl at the moon. Eat some Ben and Jerry's and watch some Friends. But by, golly, you just know you're going to get this one!

The worst of all is that you realize you spent an hour trying to hack it out. Or hours. Days, even!

🌶️ HOT TAKE 🌶️

🌶️ STOP TRYING! 🌶️

No, I'm not making a joke. Seriously, stop torturing yourself. Let me explain why you'll learn more quickly and efficiently if you break this habit.

If you're doing it this way, once again, I tell you: STOP NOW! You're doing it all wrong!

Before you say, "But you're only telling me that because I'm terrible, and you must be good at this!" I shall confess that I don't possess "natural talent" when it comes to programming. I noticed this fact pretty quickly the first time I tried to learn to code. If anything, my mediocrity may be my best qualification to offer advice on this topic. Because I have been in the trenches right where you are, knowing that I am not smarter or better equipped than 99.99999999999999999% of everyone on the planet, trust that I can guide you off this miserable shoal.

But... but... why do you say I should stop?

Let's say you only spent 2 hours on 2 challenges. At the end, you're frazzled, even if you solved it by yourself. Once you solve it, what do you feel like doing? Are you going to soak up more knowledge like the sponge you should be? Are you going to immediately copy out that algorithm to get more practice?

Nope!

You brain has been depleted of energy. Your muscles are tight. You ate way too many donuts, your therapist is dodging your calls, you're out of tissue, and you're doubting your plan. All because you didn't know how to solve a challenge which you had never been taught. All the reports and videos you've seen in which people are doing 4 LeetCode in an hour? Yeah, those folx did not take your strategy. They took mine.

Let me guess: you never learned how to learn.

If you were in a really good school, the teacher, TA, or your study group is going to solve this with you and show you how this type of problem is handled. You'll take notes, and then practice on your own. (Yes, I realize this may be a school run by unicorns and mermaids, but it's how learning should be. Doesn't it just make sense?) You're going to do this several times to prepare for a test, and then you'll show off your binary search algorithm or bubble sort on the big day.

But now let's say you didn't go to that school (and I happen to know that you didn't). You didn't get the advantages of shared knowledge, or the handholding and cheerleading of group study. If you consider that the test is the coding challenge, in which you demonstrate your know-how, would you be ready? Instead of doing all that studying, so to speak, you're just showing up to take the test. The last time you took a pop quiz or didn't study for a test in school... Did you feel relieved when you turned it in?

No!

Not a whit, not even a little bit.

So...

Instead of wasting 2 or 4 hours in your day, during which negativity and doubt soak your gray matter into oblivion and warp your perspective, I'll tell you how you're supposed to do it. Use that 2 hour window to read about the puzzle, find at least one, or maybe several solutions that you think you might ever be able to comprehend. Add the question and answer to your flashcard system, and then try it several times.

You're not done yet! You still haven't learned it. Try it again during your next session to see if it sticks.

The greatest lie programmers tell themselves and other programmers is that you should just be able to reason it out. It's only logic, right? Nope, algorithms (and programming in general) comprise an entire field in which many millions of people have contributed their clever solutions over many decades. Some people come back years later and provide a more optimized solution, maybe as part of a thesis. You're standing on the shoulders of those who've come before you, and guess what? That's how it's supposed to work!

🌶️ HOT TAKE 🌶️

Those who struggled to learn when younger probably have an easier time with learning to program, at least compared to someone like me who did well in school without much effort. And no, I haven't done any research and have absolutely no basis for this statement. I'm basically saying it to make you realize: it doesn't matter how good of a student you were back then! It's about how you do it now.

Learn how to learn!

Mindset Matters

What counts is how you approach learning: with a growth mindset. When we were kids, didn't we love gaining knowledge? We knew back then that we didn't know it all. There's no reason you should expect yourself to know it all now! To learn more about the growth mindset from Stanford alumnus Carol Dweck, check out her talk here. She convinced me that I needed to stop judging myself based on my current knowledge, like somehow I was a finished product already, and simply lean in to the work of picking up something new.

Another breakthrough came when I learned how to learn. I watched Barbara Oakley's MOOC, "Learning How to Learn". She confirmed what I'd been noticing at the start of my programming journey: I wasn't learning optimally. Spaced repetition, interleaving, formulating questions, trying to teach what you learn, and even exercising regularly will improve your retention and understanding exponentially. It's worth watching her course, which you can access for free as of this writing, just to convince you that these things are truly, truly, completely true and the Truth.

What does it all mean?

THE BIG TAKEAWAY

Don't guess at the solution! Go forth and Google it. Peek at other people's answers. Remember that some of those algorithms represent months or even years of work -- months that someone who came before you spent working up a solution.

Whatever you do, stop beating yourself up! You're wasting valuable learning time on trying to puzzle it out yourself. Those two hours that you spent on two challenges would have been better spent practicing the algorithm than reinventing the proverbial wheel!

I hope that I have convinced you to take the easy way out, and learn how to crack that challenge from someone who already has.

BONUS CONTENT: STEPS to Solving that Challenge

But, but, but... But you've told me what not to do. You've told me how to learn. You've told me essentially to cheat. What exactly does that look like? How can I possibly benefit from copying someone else first?

Break it down into steps, which is what coding is all about!

Step 1

Set a timer. Give yourself five minutes to read the description. Do you understand what they're asking? Have you identified the input parameters, the return type, and the algorithm? It's okay if you haven't figured it out at this point. It's early yet.

Still lost? Set another five minute timer. Pick out where you will need a loop, an array, or anything that looks vaguely familiar. Start to write your psuedocode down. You're up to ten minutes now.

Step 2

Feel like you can muddle your way through the problem, trying stuff until it works? Don't do that.

Step 3

Still can't solve it? Set a timer for max 20 more minutes. Break down your pseudocode into even smaller pieces. Can you solve it now?

Step 4

Spent 20-30 minutes on one problem and still can't solve it?

Google it! Ask for help!

Step 5

Type out the solution you find. If you don't understand it, that's okay. You just have to be able to parrot it. Remember how you learned a second language? Before you understood it, you listened and tried out different sounds. You probably thought you sounded like an idiot. (So did your teacher, but it's okay. That's how we learn! Babies gotta crawl first.) Eventually, some bits started to make sense. You were able to puke out some words that were actually comprehensible to anyone else. Just remember: programming languages are, well, languages. Crawl while you gotta!

Step 6

Take a break. Seriously. Take an actual, factual, get-some-sun-on-those-puffy-eyes type break.

Step 7

Get back to it. Try to type out the solution from memory. Peek if you need.

Step 8

Don't quit! You're crawling now. Repeat steps 5, 6 and 7 until you don't need to peek anymore.

Step 9

Save your favorite solution to your flashcard deck. And no, you don't have to understand it, not yet! Study those flashcards whenever you regularly do that.

Step 10

Explain the solution to your rubber duck, your dog, or a friend until you feel as if you understand it. Repeat steps 5-10. Do it for a half hour every day until you realize that you do, in fact, understand this algorithm!

Happy coding!