Software Engineer Productivity: Workflow
Tags: productivity, beginners, agile
Published: 2018-12-21 23:09:56

Over the years I managed to reduce my daily coding time under 5h out of 8h and maintain the productivity using the following techniques. *And no, I cannot  scale horizontally, if I work more I don’t deliver more quality code.*

> This article was originally published on my blog: https://coder.today/6-workflow-tips-for-a-software-engineer-productivity-ba35d9f7e267

Productivity tips is a series of general purpose articles for people that code. The tips should apply to any environment,framework,language or platform.

This story belongs to a multi-stream series:

1. [Productivity: coding](https://dev.to/bgadrian/software-engineer-productivity-coding-jkp) — concrete coding tips & tools

2. [Productivity: workflow](https://coder.today/software-engineer-productivity-workflow-ba35d9f7e267) - this article


## Hourly brakes 🦋

> If you are a smoker skip this, you probably are already doing it.

A few minutes brakes for each hour are good for my health (by walking) and increased my productivity. If you have a rest area with games or other interactive stuff go there, or just walk around the office. I am a bad example 🚭, I am the biggest “passive smoker” from the office because I often make these breaks in the smoking area.

![](https://cdn-images-1.medium.com/max/2000/1*jS_MRrrwSvgsq048c51Trw.jpeg)

If you are applying the [**pomodoro 🍎** technique](https://en.wikipedia.org/wiki/Pomodoro_Technique) you are good already, just that my timer is 50m instead of 20m, at least for my current workflow.

> ”One of the best programming skills you can have is knowing when to walk away for awhile.” — Oscar Godson

> Developers type a lot but, but we need to think more and code less.

## “The Zone” is a risky addiction 🤠

![](https://thepracticaldev.s3.amazonaws.com/i/ru8ux5aq14hg68gf6zd5.jpeg)

The hourly break has another advantage, it keep us from doing **“the zone” ⏰ overtime**, that will most likely hurt the code. When you are deep inside the problem is hard to see the edge.

I think that **“the zone” is our natural environment.** You will find a developer there most often writing #happycode.

**But** there is a threshold 🚸, you can **focus “too much”** on the problem/code, as a result you will code “in a vacuum”, **“in a bubble”**. When you exit the bubble you realize you forgot stuff because your entire **attention focus had a very small scope**:

* *“I forgot we have that functionality in X module, I just wrote a new one”*

* *“I forgot that I should have talk to X for this task”* (edge cases or implementation details)

* *“I skipped the Unit Tests, I will do them tomorrow, they slowed me down”*

* “I used something that is not supported on X platform, I forgot”

Basically you are prune to do all the mistakes that usually appear **when you are in a hurry, pressed by time or when you are not paying attention.**

> Most of the times, “the zone” give us the “productivity illusion” 💨.

**I am 100% sure you will write more code, but what about it’s quality?** To really see if the code was better you have to measure the time spent writing the original iteration + time spent to fix it + time spent to debug it + the effects it’s bugs, during the entire code production lifespan. **In the “zone overtime“ you have a quick first iteration (“finish fast”), but the later stages duration are heavily increased.**

“The zone overtime” also appears when the developer uses **his brain as a Heap** 🗒, by trying to understand a piece of code (usually a rotten code to replicate a bug). *This can be mitigated in more ways, one is: refactor the code first and use a proper debugger.*

Among the years I found a few scenarios when **“the zone overtime”** is good for business:

* **When the entire project fits in your head** — more exactly when you are the only developer or the project is small. 
* When you are doing a prototype or the first version of a library. 
* When you are working on a single but complex algorithm.

Other than these cases, I didn’t found any good scenario for a developer to spend more than 40–70 min “in the zone”, without making at least 1 mistake that invalidates part of the code resulted.

PS: this is a generalization, I’m sure there are exceptions.

## Distractions 👏🏽

![](https://cdn-images-1.medium.com/max/2000/1*qmfPbxNOBvk3TeHoQF4DJg.jpeg)

Observe yourself, remember what caused the most interruptions or search for patterns. *Try to fix these, yourself if you can or talk about them in your periodical team retrospective meetings.*

> It can be the staging server crashing ,the constant social media checking or the noise of the coffee machine. The distraction can take many forms.

Easy to say than done: **don’t login** on social networks 📪.

If your colleagues keep disturbing you just print & stick this to a nearby wall:

{% tweet 394755439314755584 %}

![](https://thepracticaldev.s3.amazonaws.com/i/u2xyjbjd9w3xkgd0inae.jpeg)

## Learn to detach the debugger — your brain 😨


**If you are stuck more than 5–15 min on a single issue run away. You are in a maze and you do not realize it 🤔**. You will hurt yourself and most likely the code. By wasting time you are hurting the team/product/employer too.

> Step away 🏃🏿, think more or not at all, talk to others, detach the debugger and return later with a broader perspective.

## Use your brain as a queue 👩🏾‍💻

![](https://cdn-images-1.medium.com/max/2000/1*oXlxny_y0eIozmK5UlRlDw.jpeg)

How to handle incoming requests, while you are working:

1. If busy *{add the new task on the TODO list}*

2. If they contacted you in person *{recommend them to use an async communication system like chat/email next time}.*

3. Reconsider the **priorities** when the current task is over

For this technique to work you need to divide your daily tasks in smaller chunks and do hourly breaks.

## Notifications 👋
![](https://thepracticaldev.s3.amazonaws.com/i/2aruzqtigh6s1179txt1.jpeg)

**Good notifications:** can be used to eliminate a **distraction**, example: instead of checking the team chat every 10s you can setup @mention notification alerts.

**Bad notifications:** you received a newsletter.

Silent as many notifications as possible. Do whatever it works for you to save more time. Tip: Smartphones have DND intervals, so they remain silent during the nights and work times.

## Mobile 👩‍💻

Be mobile, use a laptop. Never mind, of course that you already using a laptop, erase this.

## Thanks! 🤝

Please send me your feedback so I can improve the following posts.

## Other resources 📚

[**The Perils of Future-Coding**](https://www.sebastiansylvan.com/post/the-perils-of-future-coding/)

[**Idiomatic Go**](https://dmitri.shuralyov.com/idiomatic-go)

[**What Is 'The Zone' Anyway?**](http://lifehacker.com/5920484/what-is-the-zone-anyway)

[**What are the 5 tips of a productive developer?**](https://www.quora.com/What-are-the-5-tips-of-a-productive-developer)

[**The Pomodoro Method for Increased Productivity, Explained in 37 Seconds 🎥**](https://medium.com/the-mission/the-pomodoro-method-for-increased-productivity-explained-in-37-seconds-ce2b135b1b7b)

![](https://thepracticaldev.s3.amazonaws.com/i/bqgkzxde9j84qpcbj7sp.jpeg)