Let’s interrupt developers !

Cet article est également disponible en français.

The context

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 :

http://www.infoworld.com/d/data-center/no-interruptions-technologist-work-247487

http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

http://programmers.stackexchange.com/questions/46252/how-to-explain-a-layperson-why-a-developer-should-not-be-interrupted-while-neck

http://blog.ninlabs.com/2013/01/programmer-interrupted/

http://casa-laguna.net/all-the-news/show/do.-not.-ever.-interrupt.-a-programmer

http://www.drdobbs.com/tools/just-let-me-code/240168735 

Reality

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…

Conclusion

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?

About JP Gouigoux

Jean-Philippe Gouigoux is a French software architect & MVP Connected Systems Developer. He regularly talks at University of South Brittany and Agile Tour.
This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Let’s interrupt developers !

  1. Simon says:

    I do feel the need to respond to you quoting me about the grumpy response 😉

    You do not know me and I do not know you, but when I’m trying to figure out a complex issue and convert it to code, I often put on my headphones as some sort of thinking-hat and try to work out the complex issue.

    That’s what I call “the flow”.

    But, that aside, I am a grumpy person, this is a personality trait of mine, which is the origin of the remark, not explicitly the moment, but in my article, it did help 😉

    • JP Gouigoux says:

      Your kind tone in answering seems to indicate that you are not as grumpy a person as you think you are 🙂

      I can definitely relate to this act of blocking the external stimulus in order to think in depth at some point. My article was aimed at people who would do this for a complete day while still reading/responding to their IM and complain they can’t concentrate.

      Thanks for your input !

      JP

      • JM says:

        Thanks for clarifying “My article was aimed at people who would do this for a complete day while still reading/responding to their IM and complain they can’t concentrate.” as that was not clear to me.

        At first glance it seemed like you were dismissing the importance of a quiet environment for developers to work in. When you talk of “Reality” it should probably be made clear that this is your subjective perception of reality not backed up by any empirical evidence. When a study of roughly a hundred developers and thousands of coding sessions demonstrates the impact of interruptions in the real world I think a balanced view is required. Those who say, based on this evidence, that developers need to work in total isolation are probably going down the wrong path, but the same can be said of those who just ignore this evidence.

        In my world, it is rarely the case that every coding session is decomposed into small 15 minute tasks that don’t require any kind of prolonged complex thought process. It is more often the case that I end up coding for a solid hour (or two) with multitudes of client specific business rules, workflow rules, data store diagrams, caching constraints and so on… all balanced acutely in my head. Now one could say that this is just an ignorant way of working but the “reality” is that in most companies I’ve seen that is how things work. The full stack developer has a lot on his plate and things are not made simple for him.

        I currently work in an space reserved for developers, we are 11 in one room adjacent to an open space (5 developers work on one single product and the 6 others work on various projects). There is a constant flow of project managers coming in and out of our space constantly interrupting individual developers or calling for little on the spot meetings. The impact of this constant flow of people and discussion is huge, whether one believes in “flow” states or not, one cannot possibly think such an environment in coherent or conducive to being productive.

        Divas are not the questions, I think some of it is a knee jerk reaction from developers who are just sick of being treated without any regard.

        I get your points by the way. I’m just saying I don’t think it is that black or white…

        Thanks for your article!
        JM

        • JP Gouigoux says:

          Thanks for your comment, JM. The article indeed had a polemic tone (perhaps too much of it), but I am glad the comment cleared my position. I feel sorry for you if you have to work in such an inadaptated environment as you describe… I sure hope you will get it to change, one way or another.
          Cheers,
          JP

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha Captcha Reload