Cet article est également disponible en français.
If you read articles about IT around the internet lately, you may have come across articles explaining how bad it is to interrupt developers in their programming job. A but like putting water on a Gremlin after midnight: the world collapses as soon as the poor guy (or poor girl, but there are not that many among us programmers, and I never see them complaining like that) is interrupted.
A super-natural, almost mystical, state of “flow” is supposed to progressively surround the developer, who is going to be able, his concentration full, to perform miracles of programming speed. No question about code quality, but does he care…
In case you missed this, here are a few links, but there are so many others :
Of course one needs to have some quiet time to efficiently write some code, but this is true of any other type of activities. Same as for reading a book, falling asleep, writing a blog article, etc. Most activities (particularly executed by men, who were born monothread) need that their author does not have its attention broken to be performed correctly. Trying to make people believe that it is more important for developers is behaving like a diva.
Moreover, this is quite revealing from a way of thinking that is, in my humble point of view, the source of many problems.
Problem #1: some think coding is the main activity of a developer
OK, I will pleade guilty about this one. I have done my fair share of pure-code programming, on personal projects realized at night for the only sake of being able to code without analyzing anything or writing any documentation. Hey, I even published some code in open source forges despite an extremely limited use for others (as attested by the low number of downloads).
Thinking about it for some time (OK, for quite some time: I have been coding for 28 years), I now know that coding is only a quarter, maybe 30%, of the work of a developer if one wants to be efficient at it.
Problem #2: is it the right way to program?
If you need 15 minutes to get into your project, there are good chances that it has not been decomposed enough, and that the complexity of each portion is still too big to be dealt with without incorporating many bugs while doing so.
If that much time is necessary to rewind your developer brain clock back to where it can go ahead again, that means your subject of thinking has not been modeled enough. Frédéric Lordon talks about a “technical frontier”, where concepts and specialized vocabulary can be used to quickly reach a state of mind where progress are easier among people understanding those. Maybe our discipline, however full of technical expressions, lacks intellectual tools and semantic shortcuts?
Problem #3: “flow” is a great invention…
… but there are good chances that, when you feel you are in it, you may simply experience the power of… routine! A bit like when one plays Five Dots and ends up simply erasing dots without looking at the score, in an hypnotical way.
Same for the coding: we all have experienced this moment where, taken in the “flow” (or any other way you name it), we end up adding unplanned-for functionnalities or thinking about technical possibilities that do not correspond to any documented customer use case.
Not convinced? Next try you hit this so-called “flow”, try this: erase everything you just coded. Really, do so and start again. You will notice that second time goes much quicker, does not need and particular concentration (since this time, you have made the effort of decomposing the problem before throwing yourself into the code), and most important, the resulting code is cleaner and more compact.
Problem #4: a fair part of fatuity
My personal feeling is that a lot of developers hide behind this so called “flow” to make others believe they are great coders. And this way of insisting on the capital importance of not interrupting them (see all links above, and you can find many other similar ones) smells a bit like taking advantage of people not understanding our job to make them believe anything and go on quielty do our own coding business without much attention to quality.
Code quality is still a problem, though. IT is still very young compared to other engineering disciplines. So, it is very important to keep away from this bad impression of quality, as the “flow” is simply a state of concentration authorized by the fact that one thinks of only one thing : the code (and, as said earlier, not its impacts, secondary functions, etc.)
Do my small open source projects or the rare times I was in this so-called “flow” at work produce some better code than what I wrote step by step? The answer is no. There may have been some important bits of code (used in production by a few thousands customers), but they are not of better quality than the other bits.
Nowadays, if I need more than ten minutes to code a particular functionality, I will not even start coding, because it means I have not decomposed the problem enough to code it efficiently and with the right degree of quality in each of its modules…
While we’re at it
Maybe this is the right moment to try and slash a few stupid things we can read about this subject:
- Instant Messaging “If you really, really need me, you can interrupt, but expect a grumpy return.” (source): man, if it is so important so be in “the flow”, wouldn’t it be simpler to simply turn Messenger off?
- Same for Skype (source).
- The comparison with stopping a surgeon in his job may be the most infatuated of all (same place as previous): in addition to be extremely boastful (after all, less than 1% of us developers work on some code lives depend on), the comparison is wrong anyway: on a multi-hour surgery, a surgeon will stop several times, use the help of assistants, explain an intern the way he proceeds, etc. He definitely is not wearing a helmet to work in isolation, risking to commit mistakes nobody can control.
- And so many other dumb comparisons that I will stop here…
Let’s interrupt developers! That’s right, do it now! If you see one with his helmet of earplugs, and who’s been typing like crazy for the past two hours, stop him… Tell him to take a break, think a bit about what he is doing, explain it to you. Ask him for a diagram, challenge him with producing a different object-oriented structure. Do you really think he won’t have to take back any of the code he has just laid at once? That the two of you won’t have a single idea to improve what he’s done?