As developers most of us have a “multi-threaded“ approach to our work. We are constantly being pulled in different directions and working on different things which means we need to maintain some context of each task we are doing on our internal “stack” of memory.
Most of the time I feel like I’m pretty good at this balancing act, but every once and a while I get too many plates spinning and something comes crashing down. Recently this has been extremely obvious while working on an Azure Function Application which has required a lot of deployments for testing since we weren’t able to simulate the environment locally.
When we deploy our functions we currently use a simple PowerShell script that makes use of the Azure CLI tools. It does some simple work of building, publishing, compressing and uploading the function artifacts so we can test. Unfortunately, this process can take a minute or two per function so it’s very easy to just minimize the PS window and answer an email or two while I wait.
The problem is that often times that minute or two becomes 15 and I come back to my script output purely on accident to suddenly realize I was pushing something… or was I?
I usually just leave the window open which shows the output of the last deployment whether that was 15 min ago or 5 days ago. The thing is, we weren’t including any timestamps to indicate WHEN the deployment succeeded so I have found myself looking at this screen more than a couple times wondering if this was the run I kicked off, or am I seeing a run from a week ago and only THINKING I kicked one off…
So, what’s the moral of the story here? It may seem obvious, but something you should probably always include in logs or any other application output is some simple timestamps. This information is almost always going to be of use at some point so why not take the extra two seconds and log that info.