Rich Hickey gave a very interesting talk on problem solving titled “Hammock Driven Development”. Rich took a much more personal (experiential) angle with this talk, so while it was sparse on academic research references it does seem to fit into at least some of what the research on brain science says. Still, while it may not wholly scientific, it was still a very thought provoking talk.
Don't code right away. Instead, start with...
- Identify the problem you are solving. The purpose of software engineering is to solve problems, and incidentally build features to solve them. Rich advocates stating the problem out loud with your team, or even better write it down (which is pretty much applicable to every step after this as well).
- Understand the problem fully.
- Facts - what do you know about this problem? (e.g. what are the business requirements?)
- Context - relevant background information. (e.g. your team uses these OS / frameworks, and there will be less friction to using something similar)
- Constraints - implicit hard requirements (e.g. must be able to scale to 10,000 concurrent users; must be 99.99% available)
- Are there things you know you don't know? (e.g. where is the data coming from? what happens when this API service goes down?)
- Are there solutions to similar problems? (e.g. an open source library addresses a related use case)
- Deeply explore potential solutions
- What are the problems in your potential solution?
- What are the trade-offs? (everything has a tradeoff)
- Question marks (what do you not know yet?)
- Flip between consuming lots of input and no input
- Feed your Background mind: Consume lots of input (read articles, look up related problems, and critique their solutions)
- Let your Background mind absorb: No input, just meditate, and focus on what you were feeding your mind
- Get plenty of sleep - your brain is doing important work!
- Get at least a night of sleep before you make an important decision
- Take the time to focus on things. You will inevitably "drop the ball" on certain things, which is OK, but tell the people important to you that you are focusing on something.
- Don't lean on the Feedback loop during development (e.g. TDD) - it's important and you will iterate it, but rely on it instead of focusing on the previous steps.
- Don't be afraid to make mistakes, requirements will change, you will come up with a better idea... it's OK