Background Threads and Rubber Ducks

Spin up a background thread in your brain and think about it. 

This quote from Grant Slatton’s recent article has been living in my head rent free for days. Which I guess is the definition of a self-fulfilling prophecy. It got me thinking about how I approach new or difficult problems. Here’s a few things I like to do.

#Use your brain’s background threads

To borrow Grant’s quote from before, stick hard problems in your brain and let them be worked in the background. I can’t count the number of times I’ve stepped away from a problem and had a breakthrough hit me while I was cooking dinner, or taking a walk, or doing anything else other than coding. I’ve heard the same from countless others as well. Our brains need time to chew on hard problems. Forcing ourselves to stare at a screen instead of spinning up a background thread for them is counterproductive.

#Fail early and often

Fail quickly so you can learn quickly. This idea, which Grant also talks about in the aforementioned article, is only tangentially related to sharing our failures or the engineering principle of “fail fast”. It’s more related to the idea that learning – in this case, exploring new or difficult problems – requires volume. There’s an axiom in the Go community (game, not language) that beginners should race to lose their first 100 games (as shared by Ben Orenstein). The underlying concept is that in a new domain, one doesn’t have the experience, context, intuition, or pattern matching abilities yet to make highly informated moves. Instead one should focus on iterating as much as possible to build up that intuition and pattern matching. The same holds true when tackling hard problems in engineering. Try approaching the problem from different angles. Write down all your thoughts on a current approach, then do it again with a different approach. Make small proof of concepts and iterate on them. Let your understanding of the problem grow as you build up a volume of work exploring the problem.

#Rubber duck

Few things bring me more clarity than having to explain an idea to someone else. Whether it’s via pair programming, meetup/conference talks, or even talking to the rubber duck on your desk, articulating our ideas forces us to see what areas we know well versus what areas we get hand wavey with. Doing this with another human is particularly effective because it gives them the opportunity to ask questions, poke holes, challenge assumptions, and provide feedback through the process. This can be done async with a written document, but I find the feedback loop to be much tighter – and my thinking challenged more directly – when I’m talking ideas out with someone.