There is always something: Fighting distractions as a software developer

For more content like this subscribe to the ShiftMag newsletter.

_This article is a distraction. You should get back to your work! Or not? _

1. Distractions

In software engineering, we generally call productivity killers distractions. I’m facing them, you are facing them, everybody is facing them. Our main working habit is to focus on a problem we are solving and turn it into code. Maintaining the focus is crucial, and keeping away distractions is welcome. But would you recognize all types of distractions that could come your way? Let’s break them down a bit.

1.1 Obvious distractions

• personal calls / DM / in-person *conversations *
• group calls/ad hoc calls/huddles

Phones and messaging software are designed to let you know that somebody is calling you, and that’s why we use them. You can turn them off or mute them, but there can be a commitment to react on urgent calls. This is a type of distraction we agreed to respond to. Modern phones and software allow you to organize your contacts into priority groups, mark non-disturbance hours for those groups, or ease incoming calls to various signaling levels.

• Ring — your mom calls — don’t dare not pick it up!
• Vibrate — your boss calls — “enjoy” the vibe
• Redirect to voicemail, automatic SMS, etc. — friends, beer buddies calls

The workplace is an obvious source of in-person distractions. We work in groups and teams, and cooperation is welcomed. But you can signal your coworkers that you are in DND mode. Big headphones are a sign that you are canceling the environment and focusing on something. And yes, use technology toys – noise-canceling headphones are so effective that getting your attention means that person needs to enter your visual field. Or shoot a Nerf gun at your back.

As for Slack and MS Teams, there is a simple rule: Out of sight = out of mind. There are no audible notifications, just visual. So minimize that damn hive of distractions during productive hours.

1.1.1 #thereIsAlwaysSomething*

During my long and prosperous life as a software developer, I found out that in team-based environments, daily workload can be divided into three main parts.

• Coding — your planned work on tasks
• Teamwork — code reviews, brainstorms, helping each other, meetings, agile ceremonies, company and office staff
• #thereIsAlwasSomething — is also coding! (or other engineering) — ad hoc tasks, production bugs, firefighting, “can we help with…” tasks, etc.

The idea that developers are coding during the entire working day is wishful thinking. Roughly a third of the time is spent on non-coding activities. The main difference is company mindset.

• Startup mindset — #thereIsAlwaysSomething is considered a *regular working duty. * You know the phrase “young, agile, and dynamic team.”
• Corporate mindset — #thereIsAlwaysSomething is considered an anomaly — you have dedicated maintenance teams that filter out those tasks from development teams. Maintenance teams ask for cooperation only when needed and mainly in the form of planned tasks.

Why I’m comparing this? Because #thereIsAlwaysSomething _tasks can be recognized as distractions by some teams or individual developers. It is PO/PM mastery to identify _when and who to approach with those tasks to minimize distractions. Throwing it into the team channel at any given moment with the words “Can we help with that…” is a bad idea and a distraction. Agree with the team on when and how a proper place to announce _#thereIsAlwaysSomething _tasks. My advice — daily stand-ups only.

* it is a buzzword and meme in Slovakia — #furtDačo — literary “always something” — mug and origin in the TV show. Full citation: Always something! Always something. Always. And it would be such a good job if there wasn’t always something to do! Always, always, always.

1.2 Grey area

There is also a grey area of distractions. For some people in organizations, it is their job to push them, but for many developers, it can be seen as a distraction or a waste of time.

• Meetings — managers will persuade you they are beneficial, and developers will see them as a waste of time. Negotiate if your presence is needed.
• Agile ceremonies — some of them you can see as distractions, most hated are periodical retrospectives — agree when we need it
• Corporate crap — emails, polls, acknowledgments, timesheets, etc.
• *Internal impediment * — power/net/server outages
• Computer/software updates — words can’t explain how much I hate this banner!

Fortunately, almost all those distractions can be tamed by planning them into non-productive hours, postponed or even avoided. As for emails — use filtering and redirecting to folders.

1.3 Nonobvious distractions

1.3.1 Searching info online or in internal docs

Gathering info during coding or searching for something in documentation distracts you from coding. It’s a slippery slope that can easily drive you away for a significant amount of time, and you can lose focus or coding flow. Try to identify those before you code. Gather as much info and docs as you can in advance, and bookmark them.

1.3.2 Not using effective or time-saving tools

Doing repetitive, dull typing instead of using keyboard shortcuts and code formatting tools can exhaust you and disturb your train of thought and coding. Yes, you have to learn them and get used to using them, but those productivity boosters are the best tools to fight unexpected distractions. The same applies to techniques you are not using too often — a typical example is regex. Use specialized regex tools and generators; AI is also helpful here.

1.3.3 Waiting for some dev process

• Provisioning dependencies takes time — you may be lured away
• building project takes time — you may be lured away
• Deploying projects takes a lot of time — you will definitely be lured away

Some of the above can affect you during coding, especially when you need to try some early code version. But those are predictable. Plan ahead for those actions, ideally at the end of your working cycle or before you take a break. A break will also help you think and understand what was wrong when some steps failed.

2. Corrective Measures

2.1 Get used to prioritizing

You will never have a distraction-free environment. New tasks always come. Learn to prioritize them. An excellent graph (borrowed from here) divides tasks that you can consider as distractions (but in the eyes of a manager or a coworker can be seen as a matter of life and death). We can divide them from two perspectives:

• urgent/not urgent
• important/unimportant

My two cents to this graph — I have added a fifth action in yellow. Sometimes, doing nothing is valid (“let them rot,” as we say). You will be surprised how many “problems” turn out not to be problems at all and are solved “automagically.” If the problem prevails, they will hail you again.

Prioritizing distractive tasks is a social skill. Remember that you are not the only person in the company who can solve them. Negotiate, and learn to say no if you are not confident with incoming distractions during your current work. On the other hand, don’t be arrogant; try to understand why others consider the task urgent. And, surprise — a task you considered a distraction at first sight can turn out a pleasant joyride that gives you a break from your current task.

2.2 Daily routine

The best way to handle distractions is to have a daily (working) routine.

2.2.1 Find your most productive hours

Identify hours when your brain works best and correlate it with team routines and duties. My most productive hours are 10 am –1 pm and 3–6 pm. Set up your environment to minimize possible distractions — headphones, silent mode of notifications, away/dnd mode in Slack, etc.

2.2.2 Plan your procrastination

Instead of being lured away by some distraction, randomly plan them! Software engineers are eternal students ; they learn every day. Consume the tweets and blogs, and read the news and Slack channels during your non-productive hours. I do it when I arrive at work and usually finish when the daily scrum begins. Then, the next phase is to chill out a bit after lunch and browse them again. You do not live only to work — it is a life balance tool, but use it wisely.

2.3 Additional recommendations

2.3.1 Take a break

Programming can be exhausting, mainly because software developers are often faced with long hours of sitting in front of their computers and coding. It could be unhealthy. We need to take regular pauses in between tasks. I take a tiny 1–2min break every 30 minutes and a longer break 5–7min every hour. A break means standing up and doing some walking! The toilet, snack, coffee, check phone, etc. A longer break is welcomed in fresh air if possible. You can use a popular “Pomodoro technique” of working for 25 minutes and taking 5-minute breaks.

2.3.2 Do-nothing day

Sometimes, you know that you won’t do anything creative that day. Embrace those days and use them to do simple routine tasks — clear your desktop files, reorganize work folders, update software, clean your hardware, update documentation, add unit tests, etc. No one needs to know.

2.3.3 Flow day(s)

Sometimes, you know that 24 hours will be too short that day, and you feel potent to code far longer than 8 hours. We call it coding flow. It usually happens at the beginning of a new creative part of the project when you are full of ideas and want to turn them into code. Again, exploit that opportunity, break all rules and routines — code during the night, on weekends, and feel the flow. You are an artist now.

2.3.4 Good habits when coding

• Code the most exciting or challenging parts first
• Simplify dull pieces as MVP or mocked functions, mark them as TODO, and return to them later.

// @TODO - there are 3 places where to find it and 2 possible fallbacks...
function generateConversationTopic(/*conversationId: string*/): string {
    return 'Talking with ???';
}

• Steal and/or refactor similar code; don’t reinvent the wheel.
• Writing single-purpose and less complex functions is faster and brings less fatigue. Three single-purpose functions are better than one universal, even if they occupy more lines of code.

This article is a subjective blog post on identifying and fighting distractions. Only some things will work for you, and there is obviously much more to say, so feel free to add more tricks and ideas in the comments.

The post There is always something: Fighting distractions as a software developer appeared first on ShiftMag.