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.
Coding 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.
