As a developer I read (and re-read) a lot of books. I learn from them and sometimes return to them when I feel like there is more takeaway hidden in there. But I am also a critical reader — as none of the professional books contains The One Truth, I read them as guidelines, ideas and pointers, I question and examine and sometimes straight up disagree with their statements.
However whenever I read Uncle Bob’s books, I feel like he is driving my point home. Things that I have been suggesting, fiercely protecting or protesting against, he has all the reasoning why I should stick to my guns. That is, until recently.
Avoid the zone?
Reading the Clean coder was a quite amazing experience, helping me understand my good and not so good practices — until I came across this one chapter, that is tossing and turning in my head ever since, unwilling to leave.
“Let me be clear about this. You will write more code in the Zone. […] The problem is that you lose some of the big picture while you are in the Zone […]”
The zone or commonly also called flow is a hyper-productive state in which you feel like a true champion. You make huge progress, you write fast, you tackle those tasks like the wind. However Uncle Bob advises you to avoid it, because you lose sight of the big picture.
Now I know a lot of developers, who are unable to forget about the big picture — I know I myself was guilty in that more than once. And more often than not keeping your eye on the big picture will result in over-engineering or decision paralysis. I found that for a lot of people it is actually better to only have the absolutely necessary details of a task, and not the whole big picture and where their code will fit in.
Tunnel vision for the win?
In the flow, you have tunnel vision. You only see the one thing you are working on. You will only focus on that one piece of functionality. Tunnel vision done right means you don’t care how, when or where your code will be used — which makes for independent functionality that is decoupled from other modules.
Sounds familiar?
Isn’t that what we want to achieve?
Generalizing is not easy
It took me a whole lot of practice to be able to stop thinking about “how are we gonna implement this in the code base”. And while I was thinking about the final goal of my task, all my solutions ended up being very specific.
A very simple delay buffer with a customizable delay time, an item input and array output got some very specific name like AuditLogDelayBuffer — even though with 5 more minutes of optimization, it could have been a generic delay buffer, that can deal with audit logs as well as any other object thrown it’s way. All because in the big picture it was a delay buffer for audit logs.
Avoid the flow-trap
I am not saying Uncle Bob is completely wrong. I have seen people completely immersed in a small task that should have taken a few hours at most — for days. I have seen people going in the utterly wrong direction in the flow, feeling like champions for their great and super smart solution, only to be told they need to throw away all their hard work. Oh wait, that was me.
“The Zone is not where you want to be.”
Given the above examples, he may have a point. And yet, I do not think you should avoid the flow at all cost. I strongly believe you should use the flow to your advantage.
The time for the big picture
In any case, the time for looking at the big picture is not while you are coding. Once you started typing, you should focus on that one thing and nothing else. The time for the big picture is before any code has been written.
Think about the task at hand instead of jumping right at it thinking you know the solution. Split it up, tear it down, down to last building blocks — and see if those building blocks are any good on their own. Even further, some of the building blocks may already exist in the code base. Use them. If they exist but not generic enough, make a plan to refactor and reuse them.
Ask for help from your peers and/or seniors — an extra set of eyes at this stage is golden. The point is: plan. Create an action plan and split it up to small, independently executable tasks. Cooperate and ask for help, talk to the rubber duck and bounce ideas off others, ask for help creating the design of your task and finalize your action plan before writing so much as a 2 line function.
Creating an executable plan will not only help you stay on track when in the flow, it will make your code cleaner, TDD or testing easier, and the code review will be like breeze — after all you literally executed what you previously agreed upon, not much can go wrong.
Conclusion
Being in the flow is amazing — if you know, you know. But in this euphoric, hyper-productive, infallible-feeling state you can easily stray down the wrong path and get lost in the woods. All the while you think you made something incredible, but in fact all you did was make a mess.
Don’t avoid the flow, but be smart about it. Plan your tasks so there are no crossroads, no decisions to make — then use the flow to maximize your effectiveness. And if in the end you do end up at a crossroad? Stop the presses and go back to the drawing board.
