I am fan of Daniel Lemire, Professor LICEF Research Center, TELUQ Université du Québec. Love his blog.
Here’s his twitter bio
Autodidact with a Ph.D. who loves two of these three things: computer science, programming and sex on the beach.
In this recent post titled Elegance as a luxury, loved the following points about working on problems, be it software, mathematical or life.
I go slowly. Instead of rushing at the end, I try to make sure I really understand the problem. I try to see its natural components. I divide up the problems in small, manageable parts (that fit in my short-term memory).This is where my students most often go wrong. They are trying to go too fast. To try to teach them to go more slowly, I often simply ask them questions about the problem.
As much as possible, I work locally. That is, I work on parts of the problem that only require a few facts. I only move to another part of the problem once I am done with the current part.
When I was younger, I would eagerly jump from one part of the problem to another, hoping for a breakthrough. Unconsciously, I was hoping for a flash of insight. I took me years to understand that insights are more likely to come if you focus on a narrow issue.
I spend a lot of time contemplating alternatives. When I was younger, I would latch on the first credible approach I could think of. Why solve the problem in two different ways when only one way will do? I have since learned that comparing different approaches, and understanding why one is better than other, is often how you derive the most important insights.
I spend almost as much time checking my answers than deriving them. I have since learned that even “obvious” facts should be triple checked. I cannot recall how many times I got “stuck” on a problem because of a faulty assumption, or faulty derivation.
Of all the points, I need the most improvement on the last. Don’t forget to read the whole text here