Software Engineer Productivity: Workflow

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:

Productivity: coding — concrete coding tips & tools
Productivity: workflow - 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.

If you are applying the 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 🤠

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 👏🏽

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:

Jason Heeris

@detly

This is why you shouldn't interrupt a programmer: twitpic.com/dj27dh

09:20 AM - 28 Oct 2013

2462 1031

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 👩🏾‍💻

How to handle incoming requests, while you are working:

If busy {add the new task on the TODO list}
If they contacted you in person {recommend them to use an async communication system like chat/email next time}.
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 👋

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.