What a Developer’s Day is Really Like

Ahh, the developer. Wakes up, rolls into the office, sits in a cubical all day writing code. Takes a break while eating lunch at his desk. Writes more code. Goes home. Writes a chunk of code for a personal project. The stereotype is clear: Developers code. Period.

Too bad that’s not at all true.

Working in an OfficeCoding is an important but ultimately small part of the developer’s job. On top of coding, they do all the general “office worker” tasks just like accountants or marketing folks: emails, meetings, bathroom breaks and running out for coffee are all part of the day. They also do non-coding tasks specific to their particular skills, like peer training, architecture sessions and planning exercises. So what are their days actually like?

Let’s look at a developer’s day and see if we can figure out where the time goes.

John the Staff Developer

Meet John. John is a staff developer at a large healthcare firm. He’s part of a 10-person team that works on the secure messaging module of an EMR system. John’s team is about halfway through a big project to add secure chat to their module. It’s Tuesday.

8:05 a.m.: John’s usually the first one in, and today is no exception. He drops his daughter off at track practice before school and then heads into the office. First up: coffee and email. He’s got 36 emails from a Healthcare IT list, two from the build system, three from the bug-tracking system and five from co-workers. John deletes the build notifications, makes a note to handle the new bug that was assigned to him and responds to the four meeting requests from his colleagues. He also fires off a congratulatory email to a co-worker, who was writing to tell him about a promotion.

8:40 a.m.: That bug is bothering John, but first he’s got to make some progress on the real-time messaging protocol architecture. He’s supposed to present it to the team on Thursday.

9:00 a.m.: John’s coworker Jeff pops his head in to say good morning. He’s closely followed by his colleagues Maria and then Nick.

9:10 a.m.: Back to the real-time messaging protocol. Now, where was he?

10:00 a.m.: Daily team standup. John heads over to the conference room, grabbing another coffee on the way. He mentions that he’d like some focus time on the real-time messaging protocol and briefly describes the bug he was assigned. Nick says he’ll drop by later — he’s working on a similar bug.

10:40 a.m.: Another email check. Oh, look — the mailing list has started offering naming suggestions for the next IEEE standard. The best one so far is Pigeonomics. John rattles off a couple of suggestions.

11:00 a.m.: OK, real-time messaging protocol or bust. John’s been working out a polling model that he thinks will do the trick. He’s got the model outlined and has identified some of the probable objections. Now he just has to think them through.

12:05 a.m.: Oops. John’s late for his bi-weekly process review meeting, but at least he got some good work done. Nothing seems to get accomplished at these meetings, but it’s a prestige committee and John is hopeful they can start seeing their ideas take root within the larger team. They’ve been talking about adopting an Agile methodology and the SCRUM consultant gives an interesting presentation.

1:00 p.m.: Lunch at the nearby sub shop. Double turkey on wheat with Swiss. It’s practically a Tuesday tradition. Maria’s also taking a late lunch, so they go together and get a bit distracted talking through a problem she’s having with the message addressing logic. They end up working it out, though.

2:15 p.m.: More email. The mailing list naming joke continues. There’s also an update from the culture team scheduling an all department meeting for next week, and a reminder that the fridges will be cleaned out at the end of the day. Human Resources has apparently been busy, too: The new annual review site is up and HR’s asking for initial self-reviews to be done by tomorrow. The build system has been spamming again, so John resets the log mailer level.

3:00 p.m.: Intern candidate interviews. John’s team wants to work with some interns this summer and John’s agreed to do some technical interviews. He spends an hour with two candidates, one of whom is a really sharp coder. With some seasoning he could be a good fit and potentially someone to snap up after college.

4:00 p.m.: Time to look at that bug. John really should keep working through the real-time messaging protocol, but the bug’s still bothering him. He pops over to Nick’s office to discuss it. It looks like there might be some strangeness with the routing. John and Nick talk through some ideas that point to the routing service API between two versions — maybe there’s a bug there causing the problem. John digs in and writes some tests to try to trigger the issue.

5:15 p.m.: The bug isn’t showing up yet, but it’s time to pick up the kids. John sends Nick a quick note and a pointer to his code. Maybe he can turn something up.

What Happened?

If we’d asked John in the morning how his day would go, he would have mentioned the meetings and the real-time messaging protocol. The good news is that he did get to deal with both of those things. The bad news is that he spent about 2.5 hours in meetings and just over two hours on the messaging protocol. The rest of the day was filled with other work. It’s useful work, but unplanned.

John’s situation isn’t unusual, either.

Whether you’re a product manager working on a schedule or a developer trying to estimate what you’ll get done, it’s important to know how much time you’ll spend on planned work. After all, on most days, there’s the work you have planned and there’s the work you didn’t anticipate.  Unplanned work –meetings, emails, helping colleagues, bugs, planning for the next thing — adds up fast. The lesson: Plan for the unplanned.

Comments

  1. BY RobS says:

    Bravo for the details. I’d say that it looks like about 3 days out of every week, with the other 2 really getting down to coding.
    And whenever my boss tried to schedule my workload in 38 hours per week, I reminded her that a typical day gives you about 6 hours of productivity out of 8 (which is why so many work more) if you are lucky, and that she shouldn’t include holidays in that total.

  2. BY dougbert says:

    Oh that picture is a view of “coding hell” – small (single) monitor, noise, and more distractions. Can’t code well in that. Quiet and dark is needed, at least for me.
    Peopleware, by Tom Demarco is a better pattern. After 32 years of coding, that is what works for me

  3. BY Karthic Durai says:

    Great overview of the day. Love the details. I as a developer has the same day but no break for lunch

  4. BY Subha says:

    I differ , I do not think that anything of what is described and examplified above is ” unplanned” . We all work in a team environment and team co-ordination , communication etc is all essential and a daily operational mode. You have to go through meetings , attend reviews , status calls because we all a part of a bigger organisation and just not a one man army or just a single – contributor. I think what could be described as an unplanned things and issues may be a sudden performance issue , a server going down in which an individual is getting pulled into etc.

  5. BY Dilbert says:

    What a stupid article…What’s the point.

  6. BY Kaylen says:

    I come in late at 9:15am every day, sit down at my desk, answer emails, program, get coffee, program, piss, program, eat lunch at my desk, program, piss, more coffee, program, go home at 5.

    I fking hate programming. Too bad I was hired as a Systems Administrator and end up just programming 80% of the time.

  7. BY me says:

    What a developer’s day looks like really depends on where does the developer work. I once had a job where I worked on one project for weeks or months. I was not allowed to be interrupted for bug fixes. Other coders worked on bug fixes. In a different position I was fortunate to have 15 minutes of uninterrupted time and I was expected to fix bugs while also working on projects which might take days or weeks but never months.

  8. BY FOR30YEARS says:

    The developer’s day was exactly the way my day would go while working for a Healthcare organization for 11 years. We did have a work team where each team member was rotated “on call” for a week to handle all of the reported bugs and production issues for the systems and applications supported by that team. Problem is, if the issue was not resolved during that week, you owned it until it was resolved.

  9. BY Devnull says:

    “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” – Conway’s Law

  10. BY MJ says:

    Well captured, and oh, the tech lead stopping by to add more work in to the developer’s bucket with the same delivery deadline, no exceptions. The less and less surprised developer learns that his Tech Lead apparently promised to deliver “everything” on behalf of the developer to impress the big boss.

  11. BY Max says:

    When I was a developer I had so many distractions from 9-5 from users (we were on the same floor), co workers, BAs, bosses, etc. I did most of the real coding after 5pm. Or some days, I’d come in at around 5am and code like hell before the circus began around 9:30. Fortunately, I got out of that by getting into middle management. Now I just delegate all the real work as I man outlook and the telephone for at least 6 hours a day. Even though my boss says its important, it sure doesn’t feel like work.

Post a Comment

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>