I've become increasingly comforted by writing lists down. This might not seem unusual, but it's not something I used to do, so it is unusual for me.
Each working day, I write out a list that outlines what I've done in the day, not what I'm planning to do, but what I've done throughout the day, almost like a timesheet. It's not as granular as a timesheet as it's not an hour-by-hour account but merely a casual outline of what's been done in the day.
For example, I write down what progress I've made in some certain task, specifically for example, what its current status is, what's left to do and if there is anything of interesting about it, such as any observed obstacles etc.
Ultimately, I'm left with a trail of bullet points that outline my activities.
There are a few reasons why I do this, but the first is that I need to report on my progress back to my team on a daily basis. I tend to do a lot of research and investigation-type work, where outcomes and the rationale need to be documented so that I can accurately inform my team about what I've found. If I write it down, I won't forget. If I don't forget, I've got more to discuss, and ultimately having more useful information to discuss means the discussions are more meaningful when I have them. So that's the first reason.
As a side note, I have found that people are very much interested in what happened during my activities, i.e why I did what I did, what the issues were etc. I think this is probably true of any team, but something I didn't realise until recently.
Interestingly, I am usually less interested in what happened and more interested and what the result is/was. I'm not embarrassed to say, that I've learnt that people like to know what happened along the way, they are actually interested in the nuances that otherwise I'm not. I think this is an important aspect of social communication, particularly within teams that share a common discipline such as Software Engineering. Making list allows easy recall of these types of nuances that occur during the day.
It also turns out to be a useful way to account for when things go wrong, but it's certainly not primarily used for that. For example, if I need to develop a feature within an estimated time frame, say of 3 days, then anything that occurs during this time which makes achieving that less possible, must be raised immediately. Having a trail of rationale is useful to remind others (and myself) that certain things cannot be done due to entirely reasonable but unforeseen circumstances, however, if these are not reported, it will appear to indicate that you've been unable to achieve the requirement of your work, i.e that you're lacking, which is not the case in these circumstances. So that's the second reason.
As another side note: me being able to discuss obstacles or significant events that occurred during an activity, which may impede my task delivery is important, not only because it provides feedback to my team and helps reset expectations, but most importantly, it informs them about empirical circumstances of the world around me, and this brings in new information. All this information is gold because it provides context and situational awareness. Sure, it justifies not only my position (I've documented the rationale and outcomes) but provides a wealth of circumstantial evidence of the actual world around me, information that was not known during planning. This is what my team finds so very interesting, and perhaps quite rightly, i.e having more information about things they did not know before. Obstacles and nuances are such sources of delightful information.
Typically, I find obstacles all the time and they never seem significant to me because I always have them. I am so used to obstacles that they are normal and my default reaction is to circumvent the obstacle and move on. I basically discount obstacles, they are not important to me. However, in light of what I've just said about what they bring in terms of informing the wider community about the actual world around you, they are indispensable. So, the trick with writing lists down, is I can use them to inform my team of the world as it's happening around me (or to me). So, that's the third reason.
The thing about obstacles is I know they will inevitably vanish as I deal with them, so remembering obstacles, reporting on the details and informing my team about them, for me, is challenging, but is increasingly insightful to the team and recently has become incredibly insightful to me too. This is not because I find obstacles interesting (I still don't), but because they remind me how far I've come in whatever it is that I was doing. This is an important psychological feedback mechanism and makes writing lists become more than reporting to the community but reporting to yourself. So, that's the fourth reason.
With a little bit of reflection, what I have found, is that generally for me, with time (even after a few minutes after completing an activity), the degree of perceived utility or usefulness of that activity diminishes significantly. What this means is, at the end of the day I feel less productive, as the sum of diminishing utility is well, diminished utility. From a personal and psychological standpoint, this realisation is significant. Using lists provides a feedback mechanism that helps assure me that I have made progress, and that my efforts have been significant and that they are useful and important. Otherwise, this seemingly fading sense of importance can leave me feeling... unaccomplished and annoyed with my progress.
So, it brings me great comfort in recalling what I've done.
I also wonder about other aspects that might contribute to why making lists is so comforting to me. For example, it's well known that externalising thinking through note-taking relives the cognitive load on your memory, and I think that knowing that I don't have to remember something, but that there is still an artefact that represents that something, also comforts me.
I think this is the fifth reason.