Watching Myself Program

post by matto · 2021-11-29T13:44:18.268Z · LW · GW · 12 comments

Contents

12 comments

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 switch to Slack every few minutes because I see a new-message notification.
• I multi-task during Zoom meetings.
• When I get frustrated with a problem, I switch to something for a couple of minutes, like an easier task (ok) or hackernews (bad), then back to the original problem.
• When starting on a new task, I often jump around between JIRA (the task ticketing software), vim (my code editor), and Slack, all in order to piece together an image of the desired end-state.

I made some adjustments in my routines and got a few small gainz:

• Muted almost all Slack channels, giving me more quality focus time.
• Began starting new tasks by listing questions and making a plan.
• Reflected on feelings of frustration.

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.

12 comments

Comments sorted by top scores.