During reading The Power of Habit I decided to take a closer look at my habits. I classified four technical, and four non-technical habits strictly related to the programmer job.

I predict that it will be fun to revisit the list in a few years. Also, some might be controversial to you – wait for number 8!

Non-technical

1. No coffee in the office

I only drink tea and water instead. When I do drink coffee, it’s never in the office. Whenever I wish to drink some, I have to pay a great price of walking quite a way to a nearby cafe. That is usually too much for me, and I give up on it entirely.

It started as a new year resolution, but as long as it works, why not?

2. Getting up from the desk once in a while

I’ve never really measured it, but it’s very unlikely that I sit at the computer for more than an hour. Usually, it’s shorter. After some time, I have to get up and at least have a quick walk. Sometimes it’a bathroom break, sometimes I brew a tea, sometimes play PS4.

Nothing too crazy, but looking at other people I don’t think it’s that common.

3. Midday lunch break

Still nothing crazy. One thing – it’s also a break from screens. I don’t spend it on the computer or a phone.

4. Listening to the noise

How to isolate yourself from the everyday office noise?

Most of the times music doesn’t work. It distracts me too much – for repetitive tasks it’s fine, however, the more deep work, the more music is disturbing.

The solution is listening to noise. Simple and genius. It does isolate but does not distract.

Technical

5. Fixing tiny things right away

Also known as perfectionism, for example in code review.

I like doing things the right way. I can’t stand sloppiness and tyops if fixing it takes 5 seconds.

It’s really a topic for another post.

6. Git diff & self-review before assigning reviewers

Before push, I always look at git diff in the console. It allows me to catch some issues like code leftovers, poor naming etc.

Then I push & create a PR, but not assign anybody just yet. I scan how the PR looks like in the browser. For some reason,  it often results in catching even more bugs, unnoticeable just 5 minutes ago. The different angle from the browser seems to be very helpful here. Self-review is also an opportunity to annotate the PR if necessary.

Only then I assign other developers to review the code. I’m pretty sure this saves everybody a lot of effort.

7. Logging work before going home

One of those things that could become really annoying when neglected. I’ve been there. I used to have a few days gap. To fill it, I had to browse through commit messages for the last couple of days. Eventually, I got tired of it. It’s much simpler to spend 1 minute right before going home. Literally, very rarely more than a minute.

Most clients and software houses require submitting your work logs at the end of the day. Or even if they don’t, they’d appreciate it.

8. Copy-and-paste as much as possible

I mean it. I know developers that are strongly against (how are you, Mario?), so here’s a little explanation.

I like copy-and-paste development because it comes from “why”. If I know that this chunk of code does what I need except A and B, then I move the code and change A and B.

Provided that you understand the chunk of code!, you may scream at me now, and you will be right. It requires careful reading and careful adjustments but that’s still quicker than re-writing from scratch.

This may cause me to miss some benefits of absorbing the syntax or exact phrasing, but I don’t think it really matters. What’s more, learning it by heart clutters our creative space and increases our cognitive load.