When performing programming tasks, it is very easy for tasks to take up twice us much time and cognitive effort than they should, both which are valuable resources that must be conserved. Programming tasks, are referred to here in their plain sense as 'Problems that may be solved by programming'.
Generally with practice and trained habits, programmers can achieve great flow in undertaking such tasks. When this flow state can be attained quickly and effortlessly, great programming results can be achieved. However, all to often after a period of time away from such tasks, it can be easy to forget the learned habits. Although, without being aware of this, the out-of-practice programmer may try to continue as previously. However they may find that the systematic thought process learnt earlier is no longer followed. This can lead to wasted time and effort when undertaking the task.
In this case a checklist must be utilised, that can aid quick recovery of the systematic process. Admittedly such a checklist does risk introducing an overhead or additional friction. In that case it should be used sparingly and the process should be kept as simple as possible but no simpler. The idea of using a checklist is to consistently achieve the following:
- Identify bad solutions or options
- Promote systematic and logical approaches to task
- Avoid wasted time and effort
- Produce consistent and high quality results
- Help resist diving into task details prematurely
Required materials:
- Digital copy of below checklist
- Notes app
- Notebook with dotted pages
- Pen or suitable writing apparatus (0.7mm minimum friction, jetball preferably)
The flow:
Applicable tasks:
- Refactor
- Bug fix
- New feature
- New application
- Research Assignment
- Performance improvement
Non-Applicable tasks:
- Test suite
- Minor fixup
- Code review
- Data analysis
- Prototyping
- Minor fixups
- Minor updates for example to configuration
Checklist:
The purpose of the checklist is the help users, take the time to think about the task for just a couple of minutes, because requirements aren't always completely fleshed out before reaching a developer.
Step 1 — Analyze
During this stage focus on the what and why, resist thinking about the how or the detailed steps required.
- Classify (What?) - determines the steps to undertake
- Summary (What?) - state what the task is in one or two simple sentences. Consider here whether the task needs to be broken up into multiple tasks.
- Outline (What?) - outline the major parts involved. This list can be quickly verified with the team, to identify any missing pieces.
- Define the problem (Why?) - Define the problem or problems we are trying to solve. Answer questions such as 'why will someone use this?', 'what actual problem am I trying to fix?'. This provides a wholistic view of the problem that will aid implemention decisions, and hopefully avoid wasted effort. Further it will provide insight into the lifecycle of the task outputs and future volatilities that perhaps can be encapsultaed in the implementation design.
- Volatilites (optional) - Consider what changes could be required in the future. You may wish to make high level assumptions on what is fixed and what is not. Also while considering this, be mindful of how re-usable we anticipate the outcome of this task to be. If it's a prototype it should be strictly throwaway.
Step 2 — Interpret and Evaluate
- Clarify terms - Identify gaps in knowledge that may require some research or discussion.
- Identify the tasks (How?). Very simple summaries of each major step. This can be based on the outline from the analysis step and in some cases may be the same as the outline in the analysis step. Think about various usecases and test cases. Think about how to optimise the testing loop. You may even want to write pseudocode at this stage.
- Determine if the problem will be solved
Step 3 — Think Critically (IF required)
- Know when to disagree - Once the task is fully understood, it may provide an opportunity to critically evaluate the task.
- Know how to disagree - ABANDON task. Provide sound reasoning, and explanations.
References: