Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Why Pivots don't do their best work at night

There is an interesting article by Swizec Teller over at Business Insider talking about why programmers do their best work late at night.

This is not the case at Pivotal.  Generally when we have clients committing code late at night, the team ends up having to refactor it and get tests around it the next day.  Often leading to a net loss of productivity even if the amount of time invested was greater.  So why then do so many developers seem to agree with the article?

The article has two general theories, and unfortunately I think they are correct for most developers.  However, rather than having developers commit all their code at night, Pivotal has better solutions to problems the article talks about.

The first theory is that developers need to hold the whole code base in their head, and any interruptions will force them to start over.  So late at night is the only time developers are able to get work done without interruptions.

At Pivotal, we have large open spaces that would generally provide enough distraction to keep any work from being done if this theory were always true.  So how do we get anything done then?  We avoid the problem altogether.  We don’t keep the whole code base in our heads, we simply don’t have to.  Since all of our code is test driven, you are focused only on making a single test pass at a time.  You don’t have to worry about the whole system.  Once your test passes, you can run all of the tests, and they will tell you if you’ve broken any other part of the system.  Test driving code also tends to make code that is more loosely coupled, meaning it is easier to change one part of the system without changing the others.  So we don’t have to worry about the other parts all at once, we can do them one piece at a time.

The second theory, is really just the first one but from the developers perspective.  He says that once it is late enough, you are so tired that nothing can distract you from writing code.  Essentially, once nobody else is distracting a developer, they have a tendency to distract themselves by checking email, web, IM, etc.  And once it is late enough, these distractions either go away, or you are too tired to devote attention to them any longer.

I certainly agree with the problem stated here.  If left to my own devices, I will often find a dozen other things to occupy my time, rather than writing code, even if I find the code interesting.  This is, in my opinion, one of the biggest advantages of pair programming.  Your pair is simply not interested in your email.  Because of this, a pair of developers is able to stay on task all day long.  The productivity boost from this is tremendous.  I simply had no idea how productive I could be until I started pair programming.  There are many other benefits to pairing: training of the weaker developer, knowledge transfer, shared ownership of code, better code design.  If I could only pick one benefit though, keeping everybody on task would probably be it.

Unfortunately, it is also one of the hardest selling points of pairing programming.  The decision of pairing or not, is usually not made by the developers.  Most managers are going to see the situation of two people working on the same problem as a waste of time.  Splitting them up should double the productivity right?  Unfortunately it’s really hard to say, “We don’t actually work as hard when we are working by ourselves.”  It’s not a proud fact, and you don’t really feel that it should by the foundation of your “why we should pair” argument.  So try to sell them on the other benefits first…

Since Pivotal developers are so productive during the work day, couldn’t we be extra productive by going home and working late into the night?  Maybe, but probably not.  Working late tends to throw schedules off.  It’s hard to get to work at 9 if you go to bed at 4.  Everybody starting at the same time means everybody pairs.  It’s one of the few drawbacks of working at Pivotal, your work schedule is not flexible if you are pairing.

Working at Pivotal can also be very tiring.  We only work 40 hours a week, but because we are pairing full time, you can get exhausted by the end of the day.  You especially see this in new Pivots.  Their first couple of weeks are pretty intense.  After that people seem to fall into the rhythm of things.

The original article wasn’t trying to solve a problem, it was only explaining why developers tend to do their best work at night.  So if you are developer, I’d recommend using the solutions Pivotal uses rather than working until 4am.  If you manage developers who do this, your job is more difficult.  Developers are not easy to change.  The reason it works at Pivotal is we only hire people who are capable of working this way.  Some people are simply not good socially, and will not be a good pair.  So it will be a struggle, and may require new people, but in the end, your development will be better off.

  • Pingback: Weekly Roundup: Jonathan Kohl at Agile Vancouver()

  • Joseph Beckenbach

    “Developers are not easy to change.” Heh, there’s a bit of misdirection. In my experience, developers change easily when their environments change to be actively supportive instead of actively disruptive. Sure, there’s some adjustment (which you note for “new Pivots”) when you no longer need a habit which you set up to protect yourself from a bad environment.

    Part of my job as Scrum Master (or manager) is to make the environment good — or, barring that, progressively less bad. The better we do at that, the more our team members can work on deliverables instead of obstacles.

Share This