Instant messengers in general are a huge distraction. But if you turn them off, at some moment you will miss an urgent message from your boss, and then you are in trouble.
It seems like in theory, people should be able to exercise some self-control and properly label their messages as "urgent" and "not urgent". In practice, as far as I have seen, this quickly becomes a multi-player Prisonner's Dilemma and people gradually learn to defect. First the high-status people break the rules to signal their status, later the rest of the company joins them because "everyone is doing it".
In my experience, in one company, it was the boss who reminded everyone to turn off notifications, because the constant interruption decreases productivity. A week or two later, the same boss was angry, because he posted some urgent message from a customer, and received no response for an hour. ("But don't you understand that this is important?" Well, of course we can't evaluate the importance of the message without seeing it first.)
The most crazy situation I have experienced, each message resulted in three separate notifications. First the message appeared on Microsoft Teams. Then, if you were not currently working in Teams (like 99% of the time), you received an e-mail saying: "You have a new message on Microsoft Teams". A few seconds later, in the Windows notification sidebar, a notification appeared: "You have received a new e-mail". (These were company settings that we had no permission to modify.)
One reasonable way to handle that is an oncall rotation. Designate someone to be interrupted often, and only that person has the mechanism (often another channel, like actual phone call or special interruption/notification rule) to interrupt others on the team if they need help urgently.
The only time I enable IM and e-mail notifications is when I have "office hours" on my calendar, and I'm explicitly available to people.
We have no cultural norms around how to handle this well in cyberspace.
At the office, it's unlikely someone would start talking to you if they saw you were already engaged with someone. But on instant messengers, this information is hidden from others, so there's no reason to hold back. And, from the other side, if you're engaged with somebody, someone else can come over and wave their hands to get your attention because something is urgent. On instant messengers, they can only @ you a couple of times and pray that you're not away from keyboard.
So what we get here is a race to the bottom, where everyone has to talk more loudly to be heard above the din.
I've seen some companies handle this well by emphasizing asynchronous, long-form writing over other types of communication. I wish I knew how they shifted to that type of culture because my current job is super Slack-heavy.
I guess that many people just suck at writing. Programmers who refuse to write documentation, insisting that everything in their code is perfectly obvious. Managers who organize a meeting, without sending the agenda beforehand and the meeting minutes afterwards. I think this is the reason, because if those people are somehow forced to write something, the results are often horrible. (Ironically, they can later use this as an evidence that written communication sucks.)
Or perhaps they are not sure about something, and do not want to reveal their ignorance in writing. If I write you half page describing the problem, and I made a stupid mistake at the beginning, it will be perfectly visible. If instead I just write "hey, can we have a call?", I leave no written record. Even if I type in chat, at least I can packpedal after seeing that I got something wrong.
Former boss: you don't need comments, you can just look at the code and see what it does..
Me: you need comments to tell you why it does it...
I did the same thing for a while (I had a habit of watching a 5 minute timelapse of my screen at the end of each workday). At some point I hit diminishing returns and it became a chore, so I took a break. That said, I highly recommend trying this (not only for programming!).
BTW I implemented it in the same way as OP (screenshot every N seconds, put together with ffmpeg). Actual screen recording software was too resource heavy and didn't support very low fps well.
Nice! How long did it take you to hit diminishing returns? (Days/weeks/months/etc?) And what other activities did you try it for? I plan to apply it to writing at some point.
For a few days it was very enlightening and I cared enough to reflect upon them. Then I continued for a few more months.
In my case it also covered data analysis work, video meetings etc.
I annotated all the screenshots with time, so I could immediately see how much time I spent on things (system clock was too small and not visible in full screen mode).
For meetings specifically it helped me reflect upon how much time I spent in various kind of meetings and how useful they were. It also let me easily see how much time I spent afk (e.g. how long was my lunch break).
Nice, curious to try this!
Another program I remember doing screenshotting in a style described: http://www.loggerman.org/ (may be macOS only)
I love the screenshot tool. Could that code be adapted to other platforms – Windows/Android/iOS – or would it need to be coded from scratch?
For the three platforms you mentioned, it would need to be redone from scratch:
MacOS would probably be simpler as it's just a bash script. Only things that might have to change are the two programs invoked. Scrot for screenshots would probably have to be swapped out for something MacOS specific. I suspect ffmpeg exists on MacOS via brew so that should "just work."
Michael Malis described an interesting technique for improving his software development workflow:
One incredibly useful exercise I’ve found is to watch myself program. Throughout the week, I have a program running in the background that records my screen. At the end of the week, I’ll watch a few segments from the previous week. Usually I will watch the times that felt like it took a lot longer to complete some task than it should have. While watching them, I’ll pay attention to specifically where the time went and figure out what I could have done better. When I first did this, I was really surprised at where all of my time was going.
(It's from his How to Improve Your Productivity as a Working Programmer, which I found through Dan Luu's 95%-ile isn't that good, itself an excellent description of how getting better at small things compounds into larger improvements).
I've read that some people who play sports or games record themselves to find opportunities for improvement. But it never crossed my mind that the same could be applied to programming. After all, sports and games are designed around making players' performance legible and comparable, and in contrast, programmers' productivity is notoriously difficult to measure. My gut feeling was that something like this could never work.
But what if it could? What if it really did bestow the user with productivity gainz?
Well, I could meditate on this and do some research. But being a programmer, I could also throw some code together and experiment myself, which would be interesting and fun.
So I wrote a quick and dirty script that captures a screenshot of my screen(s) every 30 seconds and, on the next day, compiles all the screenshots into an mp4 video. (Here's the source code - it should work on any *nix system that has ffmpeg and scrot installed).
After a few days, I settled on reviewing 1-2 videos from the work week, focusing on days that felt particularly good or bad or interesting. This allowed me to avoid watching myself type Slack messages or check the weather and instead focus on periods of important work. (It just occurred to me that I should occasionally review a random day just to make sure I can notice patterns I'm not explicitly looking for). It would take some short notes on anything that stood out to me.
Here's what I found from a handful of reviews after about three weeks:
I made some adjustments in my routines and got a few small gainz:
It surprised me that all of these are about how I organize work and not the work itself--there don't seem to be any obvious improvements in how I use my code editor or approach particular types of problem.
I suspect this is the case because these problems are my biggest bottleneck. Once I improve in these areas, the constraints will somewhere else, perhaps toward actual programming.
Overall, I think this is a useful practice that I'll keep going for a few more weeks to see what other things I'll notice.