In my post Keeping yourself motivated I mentioned that programming is one of the most distracting jobs in existence. Recently¹ I ran into a concrete example of that. After a long day of work I went home, suffering from a cold and a inflamed nose, but being the industrious person I am, as soon as I got home I s̶a̶t̶ ̶o̶n̶ ̶t̶h̶e̶ ̶c̶o̶u̶c̶h̶ ̶f̶e̶e̶l̶i̶n̶g̶ ̶t̶e̶r̶r̶i̶b̶l̶e̶ ̶a̶n̶d̶ ̶w̶a̶t̶c̶h̶i̶n̶g̶ ̶a̶n̶i̶m̶e̶ ̶started programming. I was experimenting with using pysimpleGui, a increadibly easy to use gui library based on tkinter, in arepl. It was working great - the simplicity of use paired well with arepl's real-time evaluation. Making a gui had never been this easy. 

Until I got an error, that is. No big deal - I reported it to the github page, and he quickly responded. I continued reading the documentation and noticed it mentioned howdoi, a python command line utility that searches stackoverflow for your question. Not a very revolutionary concept, but very convenient to use. I'm in the command line all the time - using howdoi from there saves me a alt-tab and several clicks. That got me thinking - what if this was in arepl? Imagine programming and wondering how do something. Let's say, get the desktop width. Without even having to switch applications you could type howdoi('get the desktop width') and arepl would print out the answer for you to use. No losing your focus - just a question and answer, fitting seamlessly into your workflow. 

I got to work. I quickly figured out how to call howdoi programatially and verified it ran in arepl. But there's a slight problem - in real-time mode arepl runs every code change, debounced to a customizable interval, but still quite frequently. This would lead to dozens of unnecessary duplicated requests. Thankfully howdoi has caching, which skips this problem. Just to double-check I opened up fiddler and captured the network traffic:

Uh oh. What you see there is a call to stackoverflow every request - no caching at all. The library howdoi was using, requests_cache, is supposed to create a sqlite database in %userprofile%/.howdoi/cache, and that wasn't even present! I'm not going to talk about the entire issue in this article - you can read a thorough report here - but suffice to say it was a real issue and required a significant amount of work. While investigating this two days pass. Then the weekend comes, and with all the hiking and friends and other gross "outdoors" stuff I don't get any programing done. Finally on Monday I was able to get back to work on arepl. 

So what started off as a simple test of a library in arepl became a weeklong adventure. That's life on the internet - you never know where it will take you².

And that's not a bad thing. It's part of why I love the internet - that it's filled with unknowns and behind every turn lies a new fact to be discovered. But sometimes you have something pressing to do and getting sidetracked can be frustrating. Your curiosity and perfectionism conflicts with your desire to be productive and finish the work already. If you're like me you'll continue being sidetracked, possibly overshoot the deadline, and be disappointed with yourself afterwords.

But you need to make the right choice. The hard choice. When you find yourself being sidetracked, make a note of what needs to be done and save it for later. This follows the agile principle of MVP - produce a Minimal Viable Product first. Perfectionism can come later. Delivering a product earlier, even if not perfect, is better for many reasons. Shorter iteration time. Faster feedback from customer. Elimination of potentially unnecessary work. Higher ticket completion rate. It's worth it.

Now, I'm aware of the above... but I still get sidetracked 🙈. So here's some more practical tips:

• Use onetab or a similar extension to save your tabs for later
• Keep your tickets small. Less work in the ticket less complexity and risk involved. This is another agile recommendation.
• Set a deadline for yourself. For example, github milestones.
• When creating a story for researching something, keep in mind are you just going to research it or are you also going to try it out? If you also do the latter a half-hour of researching could turn into days worth of work.
• Similar to the above, try to detail each task you need to do in a ticket. Maybe even make a checklist. If the work is planned for, it doesn't count as getting sidetracked :)
• Modifying code without unit tests? You'll probably need to refactor it when adding unit tests.
• Make it easy to create new tickets. If there's a bunch of fields to fill out maybe you can configure some of them to have sensible defaults? Or if you are not in control of your ticketing system you could write a quick script to automate it.
• Set aside some time for an innovation sprint where you can take care of all the issues you've noticed.

Hopefully those help you out, do you have any more tips? And how deep down the rabbit hole have you gotten? Comment below!

1. Last year, to be honest. Look, I forgot I had this article drafted, okay? ↩

2. Including me. It was so long since I wrote the article I forgot what it linked to. ↩