ertrzyiks

Programming and stuff

How not to be productive


To me, it is quite clear how to be productive as a software developer. I need a plan of what to do, I need to prevent any distractions, use focused time to solve the problem and implement the solution. This is my take on the opposite perspective: How to benefit from not being productive.

No distractions

I’ve heard that distractions are bad for my productivity, that I should disable all notifications and focus on coding. The only problem is that some distractions are actually beneficial. Let’s FACE that problem!

It would be a nice joke probably, but it’s completely destroyed by the very next section title.

The hand

First of all, someone may need a hand or a rubber duck to talk to, because they are stuck with a problem. If a 30-minute session can unblock my teammate and save them possibly hours of frustration I’m more than happy to do so. It will help the whole team move forward and the imaginary counter called this-guy-actually-helped-me-thats-so-cool gets bumped up.

The eye

If they are not stuck, someone may need a review of their code to merge it. I’ve listed my 11 ways to improve code review process which, however, means nothing if I don’t have time for reviews. Focusing on an almost-done task which is under review, rather than on my own task, has a positive impact on the productivity of the whole team. At the expense of mine, of course.

The ear

Another problem with avoiding distractions is being uninformed. Being informed can definitely save a lot of time. The piece of application you are going to refactor was scheduled to be removed next month? You better don’t waste time figuring out what those a, b and c variables are then. Have you experienced some weird issue and spent an hour debugging it? Yup, those 10 people before you did that too and some of them possibly shared the solution with their team already.

Knowing what is happening around me is crucial from my perspective. It often offers at least a hint or even an instant solution to my problems. It wouldn’t be possible to know about these things without following the activity of people around me.

The mouth

Especially in remote teams, some discussions may take place not during a scheduled meeting but rather ad hoc. Being 100% focused on coding may keep one out of them. E.g. imagine that your team is looking for a framework for a brand new and shiny application. You may miss an excellent opportunity to say that the framework you would never consider for your pet project sucks big time.

How to survive then?

A list

Instead of fighting distractions, I’ve learned how to live with them. It doesn’t mean I’m totally fine with the context switching and that I have a perfect memory. Definitely not. So, to not let distractions destroy my routine I maintain a list. The list contains the major objectives I wanted / promised to deliver. Usually, it’s just a sheet of paper I carry along with me. Sometimes it’s also a digital list, just a markdown document with a few bullet points.

Whenever I feel lost, I read the list and see what I was working on before getting distracted.

Reminders

For less important or time-based objectives I set up reminders to myself, using Slack. I shamelessly snooze them until they are done.

Filter out

Well, it’s possible to filter out distractions to some extent. I wouldn’t be able to follow everything, so my main sources of information are groups focused on helping people. All your Communication-App-Of-Choice’s channels where people help each other may serve as a database of possible issues and solutions. Sooner or later, they will be back in a different form. It’s also a good source of debugging tactics or tools which may be helpful in completely different situations.

End note

It’s always good to be productive in terms of programming itself. However, I believe that supporting the total output of the team is healthier, even if it means giving up a bit of your own productivity.