5 ms·
I've thought about this often and the only solution I can come up with is to disallow myself to think quickly when solving problems, even when I believe that I
by roflmyeggo 11y ago
I've thought about this often and the only solution I can come up with is to disallow myself to think quickly when solving problems, even when I believe that I should reliably be able to do so[0].
I've noticed that when I take the time to think slowly through problems, although the initial activation energy is higher, that I end up saving time in the long run. Also, I tend to end up with a higher percentage of correct answers. This trend tends to increase with the complexity of the problem.
Yes, you probably lose some time on the easy problems, but I look at it as a method of gaining net time over days, weeks, etc.
This, unfortunately, is tough to stick with. It's tempting to skip the easy steps along the way (and let our System 1 do all the work, leaving System 2 to collect dust).
[0] - This is still a working hypothesis that I will undoubtedly go back and forth on for the years to come.
- thirdtruck 11y agoI just wish we'd learn to appreciate this in the software/startup world and stop expecting people to come up with code/answers as quickly as possible. This is exactly why whiteboard coding is so bad of an interview metric.
- logn 11y agoAt least for those problems, I don't think it's about trying to slow down. It's about trying to poke holes in your answer and make sure it holds up to some testing. The intuitive answer to the first problem is $.10 but if you take time to double check and add a dollar to that, you see it's wrong. I don't think this is too different from programming... the time you take to re-read some code you just wrote and think like a compiler and mentally execute the edge cases, etc.
- collyw 11y agoFor me it was a case of reading the question properly, rather than skimming it and assuming you knew what it was asking.