The first bit of guidance I give to the interns I hire is, "Don't be stuck for more than 20 minutes."

"Take 20 minutes to see if you can solve it yourself. After that ask for help. We're all here to get the job done. You aren't alone. We want you to learn to work independently, but we don't expect you to know how to do that right away. Try being independent for 20 minutes, learn from that, then let someone know."

I try to follow my own advice.

20 minutes of wishing you could find the right thing to read or staring into the void hoping for inspiration is plenty. If you have the right buzzwords to feed into Google then you're most likely to find the right article to read in the first few tries. After that the odds drop off; you don't know the right magic words. I bet the success rate for technical questions follows Planck's curve - maybe better than this solar radiation graph from Wikpedia.

If what you really need is inspiration, taking 20 minutes to summarize what you already know is a good warm-up. If you haven't already thought about the problem and recalled the answer then you are better off either asking for help or setting the problem aside and letting your brain bubble away while you do something else.

Odds are someone you work with knows the right thing for you to read, can tell you something better to search for, or has already thought through some part of the problem you are working on. They can help you. Get their help. Investing 20 minutes is enough to ask a good-quality question to get that help. (Less time is probably not enough to ask the good question.)

I expected the interns to struggle with this advice. I had guessed that students would be used to working independently, following academic rules. It was never a problem for them.

Following this advice was a challenge for more experienced people joining our team, especially when one of them was the team expert on the topic. It's harder to imagine the value of framing the question well, then asking someone less knowledgeable for help, but it works really well. Early in my job at HMS I was the only person working on back-end Scala code. When I was clueless, I felt alone and responsible for finding all the answers. Talking through a problem with our front-end developer, our amazing tester, or just someone interested in the project helped me frame the question better. It often showed me what the real concerns were, and saved me from "shaving the yak." The Scala community - especially the people who eventually made up the Type Level community - were a huge help getting to concrete answers. (Help from Type Level people almost always starts with, "Oh. See if reading ... helps." It almost always does, but it takes some investment. In contrast, reading the wrong thing is really frustrating.)

I found that talking through my puzzles with an intern was magic. We usually wouldn't come up with a solution right away, but explaining got things fizzing in our heads. I would often make the inspirational connection while I was concentrating on something completely different, like niggling with some other part of the code base, chasing the kids in the park or cooking dinner. It was like my non-euclidean geometry professors from way back warned us: "Go ahead and learn everything about the problem that you can, but don't expect to get anywhere just by applying work to these puzzles. Keep a notepad on your nightstand. You are going to wake up in the middle of the night with the proof in your head, and you must write it down before you go back to sleep. It'll get better with practice, but it will never seem natural."

One of the deeper things in the Toyota Way is that the advice comes in complementary pairs. I think this 20-minute limit pairs well with the first-day plan. It's a small piece of "how-to" to match with the first-day plan's list of "what." When someone is starting a new job then the 20-minute limit sets an expectation for how to solve the problem without giving up the tempo, and gives the new employee permission to interrupt.