This year’s Uphill Conf started out with an entertaining talk about How to Think by open source freelancer André Staltz. Based on the assumption that humans are actually “bad at thinking” and mere “monkeys in clothes”, he wonders how they can accomplish complex tasks like programming. André shares his insights on why we are such bad thinkers and what techniques can be used to overcome our limitations.
Biases and Limitations of Humans
Luckily for us, the brain can be trained, just like a muscle. Also, there are many tools that help us structure our thoughts to make them more tangible. Sometimes, however, natural biases still keep us from thinking:
- We tend to imitate others to get approval or out of fear of rejection
- We have feelings
- Our working memory is very limited
How can natural biases be overcome?
- Do not blindly imitate others but rather honor all ideas and give each one at least ten seconds of thought
- Acknowledge your feelings; let them come and go, take a break, take care of yourself until you can start again with a fresh mind
- Improve your memory with tools (e.g. a mind map), or use pen and paper to write things down
Only after you get past these distractions will you be able to see the structure of your thoughts and start to think about programming.
Most people assume that programmers write code most of the time, but they actually spend a lot of time reading code and trying to understand what is going on. Unfortunately, our thoughts are usually just an optimistic simplification of the complex problems we are facing. Thus, we often try to force them onto the computer without a profound understanding of the matter.
Instead of “squeezing” our ideas into the computer, we should try to learn what’s inside it by using the following techniques:
Or investigating, as André rather likes to call it. He suggests using the debugger to study code, not only for finding bugs.
When using deduction, you try to rule out hypotheses with zero percent probability that do not need to be analyzed further. You can use a tool like git bisect to find the commit that introduced a bug or find the problematic part by commenting out some code.
Induction, on the other hand, means to pick hypotheses with a high probability. Make an educated guess about a problem and try to verify it, but avoid quick conclusions. Always remember that it’s just a guess and the problem might lie somewhere else entirely.
Question everything! Just by asking about the goal of a certain requirement, you and your customer might find out that it’s actually not needed anymore. This might save you a lot of time.
State a problem and list all possible solutions to it. Then, list the problems for those solutions. Then, list the problems of the latter. Go on until your initial problem is solved. Do not stop after the first step like we typically tend to do.
See documentation as code that instructs humans as opposed to programming. Programming is code that instructs computers and should not be done in isolation. It’s a knowledge exchange between the computer, you and your colleague.
- Think slowly and methodically
- Be aware of your biases, feelings and limitations
- Specialize, but keep learning
Become a specialist by doing the same thing over and over again, but don’t become a specialist to do the same thing over and over again.
- Don’t become a compiler
Programmers are humans that understand computers, not computers! They are in the unique position to simultaneously be capable of communicating with humans and understanding computers.
Although the talk did not provide anything surprisingly new, it still made me think. The next time you’re stuck on a problem, check if any of the listed biases apply and if some of the suggested techniques could help you out.
The complete talk can be watched here.
More on thinking
- Thinking fast and slow by Daniel Kahneman
How we think by John Dewey
- Mind Mapping: Improve Memory, Concentration, Communication, Organization, Creativity, and Time Management by Kam Knight