laitimes

How developers can fight interference

author:Not bald programmer
How developers can fight interference
Reading guide:This article is a distraction for you,You should go back to work!Isn't it?

Something is disturbing you

In software engineering, productivity killers are often referred to as "distractions." I face them, you face them, everyone faces them.

Our main working habit is to focus on the problem we are solving and turn it into code. Staying focused is crucial, and removing distractions is something to watch and welcome.

So can you identify all the types of interference that can occur? Let's break them down.

Noticeable interference

Notable interferences include the following:

  • Private call/private message/face-to-face conversation
  • Group calls/ad-hoc calls/meet-ups

Phones and social software are letting you know that someone is calling you, and that's why we use them. You can turn them off or mute, but you can react quickly to emergency calls.

It's one of our responses to distractions.

Mobile phone software allows you to organize your contacts into priority groups, mark quiet hours for those groups, or simplify incoming calls into signal levels.

  • Ring – a call from your family, you can't go unanswered!
  • Vibration – This vibe that your boss calls "enjoyment".
  • Redirects to voicemail, automated text messages, etc., which are calls from some friends, beer buddies

The workplace is a significant source of distraction.

We work in groups and teams, and we should welcome all kinds of awkwardness in working together. But you can signal to your colleagues that you're in Do Not Disturb mode. Big headphones are a sign that you're canceling the environment and focusing on something. Yes, new toys that use technology like noise-cancelling headphones are so effective that grabbing your attention means that person needs to be in your field of vision.

There's a simple rule: Out of sight = out of mind. There are no audible notifications, only visual notifications. So, minimize those damn distractions during working hours.

And there are other things #thereIsAlwaysSomething*

In my long and busy life as a software developer role, I have found that in a team-based development environment, the day-to-day workload can be divided into the following three main parts.

  • Coding – the work of the tasks you plan;
  • Teamwork – code reviews, brainstorming, helping each other, meetings, agile ceremonies, company and office staff;
  • #thereIsAlwasSomething — You're also coding, (or other engineering) tasks for ad hoc tasks, production errors, firefighting, "can we help fix the computer......" and so on.

The idea that developers are coding throughout the workday is wishful thinking, in fact, about a third of the time is spent on non-coding activities.

The main differences are in the company's mindset, which includes the following:

  • Entrepreneurial mindset — #thereIsAlwaysSomething is considered a regular job duty. It's like a "young, agile, energetic team".
  • Enterprise mindset — #thereIsAlwaysSomething considered an anomaly — you have a dedicated maintenance team that can filter out these tasks from the development team. The maintenance team seeks cooperation only when needed, and it is mostly in the form of scheduled tasks.

#thereIsAlwaysSomething tasks may be perceived as a distraction by some teams or individual developers. POs/PMs need to know how to determine when and who will do these tasks to minimize distractions.

Tossing it into the team channel at any given moment with a "can we help...... is a bad idea and distracting for others.

Agree with the team on when and how to announce #thereIsAlwaysSomething tasks in the appropriate places.

My suggestion is to have a daily stand-up meeting.

Gray area

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

  • Meetings – Managers will convince you that they are beneficial, while developers will think that time is wasted. If such a thought exists, please consult.
  • Agile rituals – some of these you might think of as distractions, and the most annoying are regular retrospectives. Agree when we need to
  • Company junk – emails, polls, acknowledgments, timesheets, etc.
  • Internal Impediments – Power/Network/Server Outages
  • Computer/Software Updates – Cannot be explained in words

Almost all of these distractions can be eliminated by scheduling them for non-productive time, postponing them or even avoiding them. As for emails, filtering and redirecting to a specified folder can be used.

Non-obvious interference

Search for information online or in-house documents

Gathering information during coding or searching for something in a document can distract you from coding. It's a slippery slope that can easily keep you away for a long time, and you might lose focus or the coding flow. Try to identify these before encoding. Gather as much information and documents as possible ahead of time and bookmark them.

Don't use tools that are effective or save time

Repetitive, boring typing instead of using keyboard shortcuts and code formatting tools can be exhausting and disrupt your train of thought and coding.

Yes, we have to learn them and get used to using them, and these productivity boosters are the best tools to combat unexpected distractions. The same applies to techniques you don't use often - a classic example is regular expressions (regex).

Use specialized regular expression tools and generators, and artificial intelligence can be very helpful here as well.

Wait for some development process

  • Configuring dependencies takes time – you might be lured away
  • Project design takes time – you might be drawn away
  • It takes a lot of time to deploy a project – and you're bound to be lured away

Some of the above factors can affect you in the coding process, especially if you need to try out some of the earlier versions of the code. But these are all predictable. Plan these actions in advance, preferably at the end of the work cycle or before taking a break.

Taking breaks can also help you think and understand what went wrong when certain steps fail.

Corrective and Adaptive Measures

Habit prioritization

You'll never have an environment free of distractions.

New tasks always come, learn to prioritize them. A good diagram divides up tasks that might be considered distracting (but can be seen as a matter of life and death in the eyes of a manager or coworker).

We can divide it from two perspectives:

  • Urgent/non-urgent
  • Important/Unimportant
How developers can fight interference

I've also added a fifth action to the two quadrants of this diagram – "Do nothing".

Sometimes, doing nothing is also effective (as you might think, "let them rot"). You'll be surprised how many "problems" aren't problems at all, but are solved "automatically". If the problem persists, they will "salute" you again.

Prioritizing distracting tasks is a social skill. Keep in mind that you're not the only one in your company who can solve these problems. If you don't have confidence in the distractions that arise at your current job, negotiate and learn to "say no." On the other hand, don't be arrogant and try to understand why others think the task is urgent.

And, surprisingly, a task that you might seem distracting at first glance can turn into an enjoyable journey that gives you a break from your current task.

everyday life

The best way to deal with distractions is to have a regular routine (work).

Find the most productive time

Identify the best time for the brain to work and relate it to the team's day-to-day work and responsibilities. My most productive hours are 10 a.m. to 1 p.m. and 3 p.m. to 6 p.m. Set up your environment to minimise possible distractions – headphones, notification mute mode, away/DND mode in Slack, etc.

Plan your procrastination

Don't be lured by a few random distractions – plan them!

Software engineers are eternal students; they learn every day. Read tweets and blogs outside of business hours, read news and Slack channels. I do this when I am at work, and it is usually done at the beginning of the daily meeting. Then, the next stage is to relax after lunch and go through them again. You don't just live to work – it's a tool for balancing your life, but use it wisely.

Additional recommendations

Take a break

Programming can be exhausting, mainly because software developers are often faced with sitting in front of a computer for long periods of time coding.

This can be unhealthy.

We need to pause regularly between tasks. I take 1-2 minute breaks every 30 minutes and 5-7 minutes every hour. Rest means standing up and walking!toilets, snacks, coffee, checking the phone, etc. If possible, take a longer break in the fresh air.

How developers can fight interference

You can use the popular "Pomodoro Technique", which is to work for 25 minutes and rest for 5 minutes.

Nothing to do on a day

Sometimes, you know you're not going to do anything creative that day. Embrace those days and use them for simple daily tasks – clean up desktop files, reorganize work folders, update software, clean up hardware, update documentation, add unit tests, etc.

You don't need people to know what you're doing.

Flow days

Sometimes, you find that 24 hours in a day is too short, but you feel like you have the power to write code that is longer than 8 hours. We call this coded flow. It usually happens at the beginning of a new creative part of a project, when you're full of ideas and want to turn them into code.

Again, take advantage of this opportunity to break all the rules and conventions – code in the evenings, on weekends, and feel the flow.

Well, you're an artist now.

Good habits when coding

  • Write the most exciting or challenging parts first
  • Simplify the boring parts to MVPs or mock functions, mark them as TODOs, and then go back.
// @TODO - there are 3 places where to find it and 2 possible fallbacks...

function generateConversationTopic(/*conversationId: string*/): string {

      return 'Talking with ???';

}           
  • Copy and/or refactor similar code, don't reinvent the wheel;
  • Writing single-purpose and less complex functions is faster and less tiring. Three single-purpose functions are better than one general-purpose function, even if they take up more lines of code.

epilogue

This article is a subjective article on how developers can identify and combat interference.

There may only be a few things that will work for you, and obviously there is a lot more to say, so welcome to add your better tips and ideas in the comments.

Happy coding!

Read on