5:45 a.m.: I wake up, grab a quick shower and a bite to eat, and then I take the subway to work. I use this time to read up on industry news in Computerworld, Wired, and other tech publications.
6:30 a.m.: I usually get in right about 6:30 a.m. and start my day by seeing what I missed between 5 and midnight the previous day. This usually involves going through about a dozen or two e-mails about the products I work on and listening to one or two voicemails. These are rarely urgent since folks have my cell phone number and would call me in an emergency. I am on the early shift by choice. Most folks are on the late shift, though, so that gives me some quiet time to plan my day.
7:00 a.m.: By 7 a.m., I have a pretty good idea about what’s in store for the day, but I double check my calendar to make sure I haven’t forgotten a meeting or something. If one of the e-mails or voice messages was about a customer issue I’ll usually get started on that right away. I’ll start by looking at the customer service description of the problem and then check to see if the software testing group already knows about a defect that might cause the issue. If I can match the two I just have to prove that the bug caused the error and let customer service know how to fix it, work around it, or when it will be fixed in the software. If the problem is new, I’ll have to try and reproduce it and then figure out what caused it. This is usually very quick if the customer and customer service described it well but it can turn into real detective work involving copies of the customer database, WebEx [online conferencing] sessions, and phone calls if they didn’t. Usually though, I can spend the next three hours plowing through some development issues like bug fixes or feature development towards the next release or documentation to support those, such as functional requirements and product specifications.
10:00 a.m.: The morning is usually meeting time. There are team status meetings on Mondays and various product meetings on most of the rest of the days of the week. These take about an hour each and are usually very effective at advancing the various projects I’m involved in. After each of these meetings is usually an informal breakout with any number of other developers during which we hammer out details of what was discussed in the meeting or what wasn’t because it was too much detail.
12:00 p.m.: Lunchtime. I often just eat at my desk, but lately I’ve been trying to get out more and clear my head from the challenging world of debugging and software development. I hit a local deli, grab a quick bite, and then take the long way back to the office. I feel refreshed and ready for the afternoon.
1:00 p.m.: After lunch, we usually continue on development efforts (coding or documentation).
2:00 p.m.: Since all of the late-risers are in by now, the afternoons are usually more collaborative with more informal discussions and meetings about the projects and assignments.
4:00 p.m.: Afternoons are also usually build times, so a couple of days a week there is usually a scramble to check in the latest code and database changes before the build is kicked off. The software testing group will get the results of the build and test it so I can expect fresh bugs in the morning. While the build runs I’ll have to e-mail the testers about what was changed and what is new for this build.
5:00 p.m.: The day typically ends here when the night shift enters—unless there’s a crisis and the programmer must stay on until it’s resolved. I head home.
7:00 p.m.: After dinner, I start studying for a professional programming software certification I’m pursuing. Technology is always changing, so it’s important to keep your skills up to date. Plus, I’ve read that programmers with this certification can earn 10 percent higher salaries than those who aren’t certified.
10:00 p.m.: I’m beat. After a quick check of work e-mail (no problems), I head to bed.