Leave Developers Alone

  • True not just for developers, but really anyone who creates. I'd suspect that interrupting a writer would have the same effect. Same for an artist, architect, etc. I'd say the real problem is that many of the people who are being put into management roles should not be in such a position.

    But that leads to another discussion about bad managers. Hummm, seems we have an Excel circular reference here!

    The more you are prepared, the less you need it.

  • Andrew..Peterson (10/30/2015)


    True not just for developers, but really anyone who creates. I'd suspect that interrupting a writer would have the same effect. Same for an artist, architect, etc. I'd say the real problem is that many of the people who are being put into management roles should not be in such a position.

    But that leads to another discussion about bad managers. Hummm, seems we have an Excel circular reference here!

    Yes, I'd put IT developers in the same category as writers, architects, artists, and chefs in terms of how important it is not to have interruptions or micro-management. Actually, were it not for IT, had I started my career 50 years ago, I'd have chosen one of the aforementioned professions and couldn't picture myself doing anything other.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • I like the analogy to chefs, artists and others who create. We all tend to really get into our work and interruptions destroy the "mojo" have have going on at the moment.

    Some companies are starting to realize that developer's brains are a scarce resource, and interrupting them can dramatically impact productivity.

    I think that quote from the editorial does an exceptional job of summing up the impact of interruptions. A phone call that interrupts my flow of thought is devastating when I'm in the middle of something complicated.

    Great editorial. It's as true and applicable today as it was when it was originally published.

  • I agree completely with the editorial. Unfortunately I'm in a job where I wear so many hats that interruptions always seem to be about 3 (or more) deep (depending whether you count the things from which I was interrupted weeks, months, or years ago, and never got back to).

    Here is a great, funny, graphic demonstration of why not to interrupt a programmer:

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

    or a PDF version:

    https://dl.dropboxusercontent.com/u/25009451/ProgrammerInterrupted.pdf

    P.S. It's not "loathe to pay" but "loath to pay."

  • ArmenStein (10/29/2015)


    I wrote an article called The Cone of Silence. We use it at our company, and it really helps to get stuff done.

    Excellent article and idea, Armen! Very simple and elegant solution, it should be required reading for all managers though it would be the bane of micromanagers anywhere.

    -----
    [font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]

  • Wayne West (11/2/2015)


    ArmenStein (10/29/2015)


    I wrote an article called The Cone of Silence. We use it at our company, and it really helps to get stuff done.

    Excellent article and idea, Armen! Very simple and elegant solution, it should be required reading for all managers though it would be the bane of micromanagers anywhere.

    I rather enjoy being interrupted all the time so that I don't actually ever complete something. The good lord put me on this Earth to accomplish certain things and, right now, I'm so far behind that I'm going to live forever! 😛

    P.S. Only us old geezers can say things like that and get away with it in real life. :hehe:

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • It is a cultural thing. Sometimes you can't change the culture. Amazingly so at some places after you have explained the cost.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Wayne West (10/29/2015)


    At my previous job, the IT director was well known for scheduling meetings at the moment you came in or 15 minutes before you left, so I set Outlook with a private meeting from 8-9am and 4-5pm. Since it was private, he couldn't auto-schedule me for a meeting, and he never questioned it. It was wonderful. It's a method that I highly recommend.

    I think a cubicle farm and open office plan probably encourages interruption, and people don't realize how much it hurts our productivity when our train of thought is derailed. If you have a private office and can close the door, then you can create privacy. It might not help you against C-level incursions, but that's the way it is. Fortunately, in my current job, not only do I have a private office but IT (all four of us) are in our own cottage in the corner of the campus, so people have to really go out of their way to bother us.

    Excellent idea for meetings. I have started to mark out times when I'm busy or want some uninterrupted work to occur.

    I'm torn on open plans. I think they vary depending on teams. I worked in a few teams (10-12) where we were in a one room, and people used headphones to work. If they weren't worried about interruptions, or were open to discussions, they'd take them off.

    On the flip side, I see people get buried in offices and become less productive because they're too isolated.

  • I worked in one office where you were only allowed to schedule meetings during core hours (10-12 and 2-4). This worked as you were almost guaranteed everyone could make the meeting and it could only fill up at most half of your day. People ended up being very efficient at meetings and a lot of work was done. People also never double booked meetings and although I am not sure why I suspect that the value of a good meeting was considered greater than the delay i.e. everyone attended and the target was met. Also meetings never took the hour or an impromptu meeting used up the rest of the time if all were present then the original meeting was left in the calendar and never attended (more productive work!!!). I miss that place.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • It helps if all the team members on a project attend a 15 minute stand-up meeting each morning, and then if someone needs additional information from someone, then they break out together after the meeting.

    Also, it helps if the organization has an IM service like Microsoft Link, so everyoneyou can chat asynchronously throughout the day with other team members or folks from outside IT without constantly dropping by each other's desk or filling up your email inbox.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • GilaMonster (7/25/2011)


    There's no need to bug developers every hour or so checking on what they are doing or how far they are.

    I agree 100%. But does that apply to senior people (like, I think, yourself) - whan you are "THE expert who can fix things", aren't people going to bug you when there's a big problem, regardless of whether you want to be bugged?

    Tom

  • Jeff Moden (11/2/2015)


    I rather enjoy being interrupted all the time so that I don't actually ever complete something. The good lord put me on this Earth to accomplish certain things and, right now, I'm so far behind that I'm going to live forever! 😛

    P.S. Only us old geezers can say things like that and get away with it in real life. :hehe:

    I can get away with it, because I'm 99% retired. 😀

    You've got a few years to go before you can, Jeff! :w00t:

    Tom

  • TomThomson (11/26/2015)


    GilaMonster (7/25/2011)


    There's no need to bug developers every hour or so checking on what they are doing or how far they are.

    I agree 100%. But does that apply to senior people (like, I think, yourself) - whan you are "THE expert who can fix things", aren't people going to bug you when there's a big problem, regardless of whether you want to be bugged?

    There have been plenty of occasions where I've wanted to know what SQL Server is doing and how far along it is.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • This was removed by the editor as SPAM

Viewing 14 posts - 31 through 43 (of 43 total)

You must be logged in to reply to this topic. Login to reply