The topic of our own context switching is discussed in many places, even here. It is clear that you can either avoid such situations or improve context reconstruction techniques to handle multiple tasks. One question however remains: is our context always private?
We are rarely working only on our own – and even in such cases the only chance to validate our progress is via feedback received. And almost each interaction requires – to be fully understood – to provide our context to someone else. Simple as that: our context is not always private.
This is clear in case of direct communication, as we are able to spot lack of understanding. Things are a bit trickier in case of written communication, due to asynchronicity. Request for context requires at least two additional messages (request and response), so usually it is better to create the first message with all important details. Not to mention that such fully described, single, message is much easier to be found in the future.
Peer-to-peer communication is one thing but what about larger audience? Giving presentations is another aspect to consider, as, depending on the audience, you might or might not receive request for context. This may result in lack of full understanding and the outcome will be less-than-perfect reception of your performance.
Mentioned situation concerns realtime, in general. And there are scenarios, where by definition your message is targeted for the future. In case of development three scenarios comes to my mind, where context (or lack of it) can be a real problem.
Firstly: source code changes. Any source code version control system requires description of change. This description by definition is immutable and targeted for the future. The best recipe, for me, to create a perfect commit message is to follow rules listed on the Chris Beams blog.
Second scenario: logging, especially log messages that indicate problems. It is important to create meaningful log messages to reduce incident resolution time – and this meaningfulness implicates that someone reading these logs will be able to recreate context of a problem. Of course possibility of having some kind of logs tracing helps, as we have context created from multiple log entries.
Last, but not least: bug report. There are many things that seems to be obvious by the time a ticket is created, but are not-so-obvious – even for the creator – then work on the ticket begins. So in general it is better to provide everything related at once than starting from an attempt to reproduce issue later. Not to mention it improves quality of search.
In one sentence, especially if you happen to be an introvert-intuitive type, choose wisely when to provide room for interpretation and when to avoid it.
