I once spent half a week designing an API. After I finished, I brought it to an experienced engineer I work with, who immediately simplified it to make it about twice as fast to implement. When I asked them how they did this, they shrugged and chalked it up to experience. Such an explanation, while understandable, left me wishing for a magic siphon which I could jab into their brain and suck up this knowledge with.
Turns out that my wish for a magic siphon wasn’t entirely unwarranted: there are in fact some forms of knowledge which cannot be transmitted or learnt effectively via words. This is known as tacit knowledge or intuition. Such knowledge is frequently required in fields where problems have too many combinations of facts and layered complexities to analyze. All of us want to build up the same intuitions that experienced engineers I refer to software engineering in this post, but the arguments and techniques could apply to any field which requires intuition. have. But if words cannot do the job, what can? One way is to leave it to time and experience on the job. For example, think of apprenticeships in fields like blacksmithing and woodcrafting. In such vocations, the apprentice works under a master and hones their skill - less by imbibing theory and more by doing. But is there a way to get better faster as Venkatesh Rao said: talent + time is one thing, but a separate talent for metacognition is necessary to develop strength ?
The first thing I turned to was the intuition-building framework outlined by Gary Klein in The Power of Intuition. What he proposes is a regimen of deliberately practicing decisions made in our jobs in order to accumulate the meaningful experiences that are necessary to build up intuition. The first step of the intuition-building framework is to find out what decisions we tend to make in our fields. I decided to start by focusing on one that I feel particularly bad at - project estimation improving project estimation is also easier to make a plan for. I will probably need a meatier plan for large-scale design . This includes estimating deadlines, breaking down work items, and forecasting different metrics.
Having identified the area for honing my intuition, Gary Klein recommends that we work on on two broad areas:
- internalizing strategies to coordinate intuition with analysis
- designing and using a specific training program for building intuition
(These two areas are not specific to project estimation and can be applied to honing intuition for any skill in general.)
Area 1: Coordinating analysis with intuition
In the field of intuition-building, any analytical tool must complement and not supplant intuition. This means that many analytical tools can work, as long as the mindset behind them is to use them to guide intuition. For project estimation, I made a list (adapted from Edmund Lau’s) of possible strategies:
- Decompose project into smaller tasks, which are easier to estimate
- Use probability distributions (e.g. there is 80% chance we will finish in 1 month) rather than best-case estimates
- Ask the person doing the task to estimate
- Use multiple approaches to estimate (e.g. Planning Poker + Historical trends)
- Keep in mind that completion speed does not scale linearly with either people or time spent
- Set an internal deadline for when I need to make a decision by
- Define specific project goals and measurable mile-stones
- De-risk early (e.g. by prototyping)
- Approach re-writes with caution
The key thing to note is that the underlying action that needs to be performed - estimation - is still an intuitive action. The aforementioned strategies merely make it easier for intuition to be applied.
Area 2: Honing intuition for estimates
Gary Klein proposes simulated exercises called Decision Making Exercises (DMX) in order to practice applying intuition. Behind the fancy acronym lies a simple idea - practicing the intuitive skill, in context, with quality feedback.
There are many ways to practice project estimation in context. Since my team follows a sprint model, one of the first things I thought of was that I can compare the items I signed up for versus what I actually completed in a given sprint. Additionally, I can also revisit planning documents at the end of a feature / project and compare the actual versus expected timelines I'm adding this to my project-completion checklist (a list of actions I do after each project I complete), recommended by Cal Newport and Scott Young .
The second point Gary Klein emphasizes is that one should review decisions and allow others to give feedback. What I can do here is to explicitly ask for comments on project estimates from my colleagues ahead of time. Additionally, during decision-review time, I can also consult the above list of analytical tools to see which I could have applied / applied better.
Lastly, I need to keep the pitfalls of intuition in mind while using it to make project estimates. This means not getting influenced by external deadlines and personal wants when making these estimates and not getting anchored by others’ predictions.
What now?
I plan to put the above plan into practice and will give an update in a few months. I am also going to make similar plans for the other skills I listed above (large-scale design in particular).