Image by Pexels from Pixabay

“Sleep on it” problem-solving method while coding

Matej Meglic
4 min readSep 17, 2020

--

A fully-fledged disclaimer at the beginning: I’m not an expert and I don’t know enough about lucid dreams and other fancy terms, research, and studies conducted — this is a mere story of what works for me when I stumble upon a problem I can not solve immediately.

I figured out that whenever I needed to do a piece of work, a presentation, public speaking, more than 2 pages of text or whatnot, I would get the best results if I did it on the fly, e.g. to mock a presentation and wing it with the Pareto 80:20 principle, or to keep it on my mind for a couple of days, not actively thinking on the problem at hand.

Good enough is the new perfect

I always true-heartedly defend the good enough principle, because I can fully acknowledge the benefits of fast iterations it offers. Basically, if you have a task, dedicate one hour on it and then perform a report, check the progress. Based on that evaluation, think if you really need to put in more work. This may lead to hackish solutions, but for the majority of cases, these scrappy prototypes will be good enough for almost all audiences and there is no point in making them pixel-perfect, to polish them until eternity, just because you can.

Let it “toast” for a while

On the other side, if the problem is bigger and you are taking a serious plunge into the unknown, the longer you keep the toast in the toaster, the better the crust. I figured out that the best results from just about any work I performed were if I slept on it. I would literally read something about a problem that I needed to solve just before I would go to bed, and then have a solution at hand in the morning. I can not correlate this to the dreams I may or may not have. I also cannot really say that I would sleep worse if I perform the problem-discovery session right before bed.

I would sit on ideas for days — plan ahead

It’s crucial to plan well ahead. If the presentation is next week, my method would be to start thinking about it at the back of my mind at least a week ahead. I try to give my brain leeway for creating their version of the masterpiece, but I am still cautious about any potential problems that might lay ahead. I try to be prepared at least one to two days ahead of my own deadline as the randomness factor can occur. Sometimes you have to return to the good old grind and stick it through to get desired results.

Work only when well-rested

Things can wait. There is hardly anything as important as your deteriorating mind when you are desperately trying to make things work. I understand the hormones pumping your blood, “I just need to finish this and I’m done”.

What happened when I applied my principles to coding?

This would show to be extremely problematic as I would deep-dived into my hobby-art coding projects. I usually code in the evenings after the world doesn’t expect anything from you anymore (I wish to be a morning person, but find it way too hard) and I would persistently find myself in the same situations. I would pitfall into the threads on Stack Overflow, trying to find the solutions, just to see my attempts fail again and again. And again. Then I would look at the clock and figured it’s way past 01 AM and I would just pack things and go straight to bed.

In the morning, I would get up, do my routine, and when I would sit in front of the computer, I would usually already have fresh insights on how I could solve the problems. These ideas would often turn into working code blocks on the first try.

Walk it off …

I had noticed the same effect if I stumble upon an unsolvable problem. I had to go away, but for the first time, I caught myself not thinking about the problem at all, and just occupy myself with some other task I had to do. I would always chew things inside, but when stepping away from coding, my thoughts seem to wander off. What is more intriguing is, that blankness of the mind seems to improve my sensibility in the right direction as I would return to the computer. As I would sit down at my desk and look at the screen, I would question myself “Ok, what should I solve now” and I would start looking at the code, not at that problem that caused me to wander away.

As I keep observing myself when I code and the project manager inside keep estimating, evaluating, and comparing past outcomes, I have to admit that I like experimenting so far. Coding did bring a strange calmness in my behavior, a different view on problem-solving and I love the process so far.

What are your conclusions and go-to ways of solving problems?

--

--