Subj : Re: Typical work day To : comp.programming From : Phlip Date : Wed Sep 28 2005 04:35 am Anon wrote: > 09:00 to 10:05 - Reading and responding to emails and helping Bob with > SQL > searching on Booleans (65 mins) Are all of these e-mails project related? It's an icky question, but how many might have been avoided, somehow? How many involve fire-fighting? A related question: When you helped Bob, what are the odds he will need to send an e-mail asking for more help? The pattern here is programmers need higher bandwidth communication than e-mail. > 10:05 to 11:10 - Looking into new problems in ExistingProgramA and > ExistingProgramB (70 mins) Do you write unit tests for the problems? > 11:10 to 11:15 - Setting up user permissions for 3 members of staff who > have changed departments (5 mins) Why are you doing IT work? Is your shop too small for a full-time IT guy? Whether it is or not, do you have a "helpdesk ticket" system to triage these requests? > 11:15 to 11:30 - Not enough time to be worth starting project work > before > lunch so went through flagged emails, archiving completed items (15 mins) I get that pattern too. I feel like I can't risk getting warmed up if I'l be interrupted before actually making progress. > 11:30 to 11:50 - Project plan update (20 mins) > 11:50 to 12:07 - Meeting with IT Manager on MinorA (17 mins) > 12:07 to 12:51 - Lunch (44 mins) > 12:51 to 13:11 - Checking e-mails and helping network admin with Outlook > issue (10 mins) Okay, more planning and more IT. Is the planning for near-term stuff? or long-term stuff? > 13:12 to 13:17 - Helping Bob with SQL subqueries (5 mins) So if Bob wrote this post, would his day have been fulfilled? Put another way, how much did the projects advance, regardless how much you feel _you_ advanced them? > 13:17 to 13:30 - Helping network admin with registry issue (13 mins) Okay, you have an IT guy. Does she or he have the helpdesk system? And why were you dicking with user accounts before? > 13:33 to 13:48 - New feature request for ExistingProgramC (there's no > spare monitors so now the program needs to speak to the user!) (15 mins) Was this feature triaged, so someone evaluated it was more important than your subsequent work on ProjectA? > 13:52 to 14:48 - Work on ProjectA (56 mins) Yay! Did you do one small thing, and completely finish it? (Did it have automated unit tests, written at the same time?) > 14:53 to 15:10 - Providing user assistance (user forgot how to use one > of > the lesser used features in ExistingProgramB) (17 mins) Okay, this is tech support work. Is your shop too small for tech supporters? > 15:11 to 15:15 - Checking latest error reports (4 mins) > 15:15 to 15:21 - Seeing a user about a rare bug with in ExistingProgramB > (6 mins) > 15:22 to 15:42 - Looking into problem a user reported - problem caused > by > mistake by someone in another department (20 mins) And more tech support. In conclusion, there's a reason why shops don't mix these activities up. They hire different people for IT, helpdesk, and tech support. You need to be programming more, or your shop needs to know you are working multiple roles, and this affects your velocity trying to _prevent_ these bugs and glitchies. > > ---- > > Another one... (times are start times) > 08:45 Explaining to Bob where data is stored and how the tables link > together that relate to his project. Told Bob to write the information > down, > he made a few notes but I mean "few". Also answering questions from IT > Manager about ExistingProgramD. Again, this part is good, because you and Bob together, in theory, make more progress than either alone. That's just a theory, but done right the effects average out over time. You now know many incidental things, beyond the SQL details, about Bob's project. And don't blame Bob for not being a stenographer. Being a teacher is hard, but the odds _will_ go down that Bob needs to ask these things again. > 9:48 Work on ProjectA > 10:01 Answering questions from IT Manager about ExistingProgramE. > Giving > Andy more help on the databases (recap of what I told him earlier). > 10:26 Work on ProjectA > 11:26 Helping network admin with VBScript. > 11:41 Modification to ExistingProgramE > > 12:50 Got back from lunch to Bob wanting a reminder on the information > I > gave this morning. > 13:03 Work on ProjectA > 13:42 Showing Bob the databases / tables he now needs to use as a > result > of new features for his project requested from IT manager. > 14:17 Updating IT manager on progress of ProjectA and Bob's project. > 14:47 Producing daily work report (had to do this anyway as managing > director requested it, it isn't just for this post). > 15:01 Slight change to ExistingProgramF (just making an OK button the > default instead of cancel), the rest of this block of time was spent > refreshing Bob's memory of the database. > 15:17 Work on ProjectA > 15:44 Re-explaining the database to Bob > 15:53 Adding extra feature to a component in a class library required > for > ProjectA > 16:04 Re-explaining the database to Bob > 16:12 Continued work (and completion) of library modifications for > ProjectA > 16:40 Reading and responding to emails, also sent email to Bob > explaining > the database. > 17:02 Update of daily work report. Right. You are splitting your day between work on your "own" project, and helping others. The good news is work is shared, and everyone knows more about what each other is doing. The bad news is the firefighting. Anyone with a burning ticket in their hand has a free excuse to interrupt anyone (especially you;) to ask for help. And yet for some reason the burning tickets keep showing up. This tends to happen when a shop does not have a system for the non-burning tickets. Look at a bug tracker like BugZilla or similar. Enter _everything_ into it; the line items of feature requests, the bugs, the IT glitches, the build script glitches, the potential interruptions, etc. Then the team should set the priority of each item _fairly_, so some are middle priority and some are low priority. Reaffirm you _will_ get to them. Not everyone is high-priority. Now everyone does the features in order. You may find, for a while, that firefighting is more important than development. So be it. You will, however, be able to fight those fires with a clear conscience, without the nagging feeling you should be "working". Over time, as the team pushes down the count of open issues in your bug tracker, you will find yourself working on the infrastructural "nice-to-have" details that _prevent_ fires. (Things like unit tests.) I have seen shops where the programmers worked in crazy mode, adding bugs and not sleeping, while at the same time the IT department used a simple ticket system, insisted every request enter their rooms as a ticket, and worked miracles. These IT departments instantly satisfied even the most trivial requests, while the developers worked for months to implement simple features. The ticket system works for both IT and programmers, and I suspect you guys don't have one. -- Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!! .