Problem solving technique #1: Taking a mental break

Developers are modern day artists whose masterpieces are not hung on walls but stretched out thin on web servers all over the world, yes that is very poetic, but I really try to look at developers as artists and puzzle solvers. To become better developers your skill-set must include creativity and problem solving skills and of course a artistic touch.

Writing a piece of code is an ever evolving process and never ending, its a puzzle. Let’s think of it in modern terms, writing a code is like solving a level in Angry Birds, your primary objective is to get it done and working, i.e. solve the level and go on. But it does not stop there, you often do not get it perfect on the first try, so you need to go back and do more work on it, make it perform better, use less memory, its like going back to that level in Angry Birds and trying to get a 3 star rating.

Somewhere along this process you will run into every artist’s greatest fear, the mental block. Once you hit a problem you often get to a point that you have so exhaustively thought of why and how to solve it that it simply becomes impossible to find a solution while still looking at that code. This is where the “mental breaks” come in. A different activity, to most its the simple act of going to get coffee or water, taking a stroll outside in the fresh air, some like sports, some like games.. everyone has their escape valve.

I once worked with a good friend and an incredible developer and problem solver, he went simply by the name of “Chester”. It was really interesting to see how he worked a problem mentally and I had some of my best whiteboard coloring brain jamming sessions discussing architecture with him, but his block solving strategy was even cooler. Whenever he got stuck and brain crunching failed to find the solution he simply stopped and picked up a bucket of lego blocks. He sat there building whatever came to his mind until he came to that Eureka moment and the solution came up.

This strategy is something I see more and more in various development companies, like Google, Microsoft and so many others. The colorful rooms with beanbags, video games, or just plain outdoor places, little parks, sport courts and toys. Nerf guns, lego, desktop catapults, iPads with games these are just some of the examples that are out there. All of these have the same purpose as that bucket of building blocks my friend used, get your conscious mind off the problem and let your subconscious take a whack at it.

While this may not work for everyone or they may not be responsible enough to handle it, I believe advanced and competent developers are a perfect match for this, why? Firstly, the developer needs to be mature and responsible, otherwise all of the above are distractions from work, not breaks to solve problems. This is very crucial, if your developer is working to have a break and not taking a break to be able to work more, you have a team with low productivity or even worse with crappy code quality. Their minds are not in it, the code is now an obstacle in their way of the “free time”. Be careful to understand your team and select the right distraction, maybe lego’s will be productive and video games disruptive, or maybe its the other way around, there is no recipe, its all about knowing who works with you.

I truly believe in this process and have had some of the best professional years of my life in companies that understand the importance of this break and the flexibility of time in the office, right now we have a Lego NXT and an iPad and they work great for me whenever I hit a wall in my code. Does it work for you? Is your company in on this? Leave your comments.

comments powered by Disqus

Related Posts

The Pitfalls of the Big Rewrite: Why Evolution Often Beats Revolution

The Pitfalls of the Big Rewrite: Why Evolution Often Beats Revolution

  • April 16, 2025

In many conversations about how products and systems evolve within companies, a recurring theme emerges: the pitfalls we encounter. One of the most significant is the pattern of the major rewrite, sometimes called “building off to the side.” Now, don’t get me wrong – a well-executed strangler pattern can lead to amazing transformations of codebases and products. However, embarking on a major rewrite can also be the first step towards building a company’s own tombstone.

Read More
Apache vs. LightHttp: função echo

Apache vs. LightHttp: função echo

  • October 29, 2006

Na versão em inglês do meu blog recebi um comentário estes dias que me deixou, “boiando”. No artigo sobre RSS onde eu apenas echoava o conteúdo do RSS usando a função “echo” do PHP. O usuário “BrokenToy” relata que teve alguns problemas utilizando a mesma solução no servidor Lighthttp, pois um “lixo” sempre aparecia no final do arquivo, evitando a validação do XML.

Read More
The IDEs of March

The IDEs of March

  • March 15, 2012

Last Year, Chris Shiflett started the “Ideas of March” movement, and Jon Tangerine quickly coined the “Ides of March” twist and some people followed him. This year, here we are again and while reading my twitter feed I saw Cal Evans’ post with Jon Tangerine’s line. Of course it was early and I read “IDEs”. Since last year I defended the Ideas of March with why you should blog, and I still believe the reasons stand, this year I’ll just make my own twist and talk about IDEs. Yes, its a shameless sorry attempt at a joke.

Read More