Subj : Re: Typical work day To : comp.programming From : Anon Date : Thu Sep 29 2005 12:04 am Replies inline. "Phlip" wrote in message news:fco_e.425$056.136@newssvr19.news.prodigy.com... > 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? Just checked back to see and they were related to additional "minor" tasks and modifications to existing programs. None to do with the current main project, but all work related. There weren't too many of these emails actually, most of the others were automatic error reports from programs, messages directed to the wrong person or messages sent to all staff (new procedures for reporting mistakes made by other departments, that sort of thing). > A related question: When you helped Bob, what are the odds he will need to > send an e-mail asking for more help? Well he didn't actually send an email until after 4pm, it was all oral before that but at many different points throughout the day. I guess I should mention that he sits directly adjacant to me. It's therefore easy to start asking questions and breaking the other persons train of thought without even standing up. I thought he probably would need more help, but underestimated how much. I gave him all the information saying to write it down but I guess it was too much to take in all at once. Maybe what I should have done was get it down into a document or email myself from the beginning and send it to him so he has something to refer back to after I've discussed it with him verbally? >> 10:05 to 11:10 - Looking into new problems in ExistingProgramA and >> ExistingProgramB (70 mins) > > Do you write unit tests for the problems? Rarely I'm afraid. I've written unit tests occasionally (with help from NUnit) but not nearly enough. The main place I've used them has been in shared components that form part of a data access layer if you like (it's actually a wrapper for a very buggy third-party COM component that is used to connect to the company's also-very-buggy accounting software). >> 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? There's about 80 staff in total in the company. In the IT department there is me and 2 other windows developers, a web developer, assistant web developer (who started last week) and a network administrator. Here's the rough history of of staff within the department... (sorry if this is a bit lengthy) I started December 2003 and besides me there was a another windows programmer, web developer and network administrator. Outside the department there was also a technician for dealing with installing software etc plus a designer who helped with the web site and also did design work (business cards, posters, advertisements etc). There was no IT manager. Over the next few months, the web developer also became the IT manager the other programmer left and the technican was needed elsewhere in the company so couldn't do his previous job anymore. We hired an assistant for the network administrator. A few weeks later the network admin left so the assistant became the main network admin. My workload increased dramatically after the other programmer left as I inherited all his code. During the time we were both there, he was fixing bugs and fulfilling minor change requests for his existing programs all of the time without any time left for new projects. He refused to let anyone see his code (even the IT manager couldn't get access as he had no control other this other programmer who was a relative of the managing director). I inherited over a hundred bug-ridden VB programs with Z1 to Z56 or whatever as the variable names (all globals) and functions that dealt with getting the difference between 2 dates by storing the dates as strings and extracting the month, day, etc instead of just using DateDiff() and the Date datatype. For quite a long time after that most of my time was used up on maintenance of these programs (combination of changes in the company causing these programs to break easily plus new feature requests). Fortunately we're now at a level where many of these programs have been replaced and the rest are fairly stable (though still difficult to extend). Then the web / design guy became the main web guy and moved into the IT office so the IT manager could concentrate on his management duties. We got a new programmer but she left to go back to her own country after about a month. Someone from elsewhere in the company became the network administrators assistant (though neither was really in a senior role and they did the same kinds of things). Very late 2004 we got the other 2 developers. During 2005 the IT manager left and was replaced by the network administrator assistant. Last week we got the new web assistant. > Whether it is or not, do you have a "helpdesk ticket" system to triage > these requests? No, but we could do with such a system. I'll pass the suggestion on, but to be honest I think if one was developed nobody would bother using it. I got my manager to start sending me Outlook task requests, which he did for a while, but seems to have stopped. It was either an in-person interruption or a phone call from him on his mobile that I got this permission request from. Now to change the permissions there's a user editor that I made outside of working hours, so at least changing the permissions doesn't take long to do. Normally the network administrator sorts these out but I think he busy setting up peoples PCs at the time (as well as these things, and dealing with the phone system he also gets the job of building computers for new staff members, by the way). >> 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. Yeah, feels like all the *thought* work that I do over that time will just get forgotten by the end of lunch before there's time to get it down. I usually work on the more minor requests in this sort of time period but in this case my tasklists and inboxes were in desperate need of a bit of organziation so I did that. >> 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? The project plan update was for ProjectA. MinorA was a very short program (a few hours work maximum) that needed to be done before a few other things could go live (one of which was ProjectA). ProjectA has a duration of approx 2 weeks. ProjectA is a big chunk of a slightly larger project the other developer (not Bob) is working on. The managing director originally wanted the whole project completed the same day, which we told him was impossible. He came in the next day shouting stuff like "I wanted this done by the end of yesterday - I feel like I'm talking to a brick wall!" etc. >> 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? Well my project just about advanced as far as my project plan for it stated. It left me with a headache though. I'm not sure about Bobs as the things I were helping him with on this day were more generalized questions rather than specific to any one project. I think he spent most of the day making changes to a piece of software that he had already completed because the new customer services manager who started last week doesn't like the way it works. >> 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? He doesn't. Most people grab him as he walks around the building. The permissions I were changing were permissions used by in-house programs (I prefer not to do this as it isn't really my job, but the IT manager requested it). I don't get involved with active directory. >> 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? Nah, just another sudden issue that came up. No orders could go out because there were no screens on the machines used to track the parcels as they go out so they couldn't see messages informing them of problems with the orders etc. Exactly what happened to the monitors which were there in the morning, and had been used without problems for over a year, or why no monitors from elsewhere could be used, I have no idea. Just following orders in a quick phone call from the IT manager on his mobile (not sure on the original source). >> 13:52 to 14:48 - Work on ProjectA (56 mins) > > Yay! Did you do one small thing, and completely finish it? Hmm unfortunately I don't have the information handy on exactly which aspect I was working on here. But generally in this sort of session I get at least half of a subtask from my project plan completed. > (Did it have automated unit tests, written at the same time?) If it was inner code that actually did the work and accessed the database etc and it's what I'm thinking of (work on a re-usable product class - we don't actually have a proper business layer and I'm trying to build one up by putting code required for various projects into a re-usable library) then I think it had a small amount of testing code done at the same time (very brief so I wouldn't even really call it a unit test). If it was user interface work then no. >> 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? Yes, though in many cases someone who is stuck can consult someone else who uses the same software to find out, there is nobody specifically to deal with tech support and it usually ends up being whichever developer produced the software. In the past, a long long time ago (before the developer who was there when I started left) and I actually had a bit more time, I'd produce help files using HTML Help Workshop (produces .CHM files) and integrate this help into the software. Even when I used to do this however I don't think anyone really ever bothered checking the help files. I've been called out to problems where a user has been sat staring at a screen looking confused asking "I've forgot how to do X. Can you remind me?" when there's been a message on the dialog box that they've had open, that's said "To do X, click button Y.". This is actually on the screen, not hidden behind a tooltip or help button. Generally nowadays though we're instructed not to waste time on documentation. The good news is I think our company may be employing someone specifically for the purpose of writing documentation soon. The bad news is I don't know how long it'll last - we got our first system analyst about a month ago and from day 1 he ended up doing human resources leaving no time for his real job (he's since left the company for this very reason). >> 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. Certainly, I think you have helped highlight this issue. I read somewhere recently that for small development teams it's an idea for programmer 1 to do development in the morning, tech support in the afternoon. Programmer 2 does the opposite. Unfortunately this wouldn't really work for us since we mostly have our own programs that we know, and don't see that much of each others code. This is slowly changing and there are a small number of programs that 2 developers have worked on now. We don't have code reviews but I'd like that to happen at least once in a while (when I've suggested it there's been an outcry of "we don't have time!"). As well as improving everyone's understanding of each others code a little, it'd help me know how I can make my code easier to follow for them. I comment my code a lot and think I use good variable, class and method names, but aren't sure how well the others would cope with things like asynchronous operations which I've been using for speed reasons (downloading data from one server at the same time as downloading data from a different server). > 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. Yes, to be honest I've maybe criticized Bob a little too much here. He's not demanding help this much *every* day. It's not so much the teaching that I dislike, it's more to do with the fact that it interrupts me too often. If I get a request for help via email for example I'd be happy to offer assistance after I've finished what I'm doing, or about 2 hours after the request maximum. But usually they come verbally when I'm trying to concentrate about something. Currently, I'm thinking what I should have done, was got down everything he needed to know in an email and sent it on, with a polite request to email if anything needs clarification. On the one hand it seems silly to email someone sitting adjacant but don't see how else the random disruptions can be cut out. Each time he seemed perfectly happy at the end of the discussion as if no further clarification would be needed. > 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. A lot of the problem with recording things is the time it actually takes to record and the fact that there's a "drop everything and do this right now" to every request from the managing director. When he makes a demand and stands behind you saying "tick tock tick tock tick tock" until the request has been done (which has happened before, but is fortunately not a daily occurrance) I'm not sure how well he'd take to you making a note of what it is you're doing. I always try to get my own tasks into Outlook and prioritize them when possible however. Thanks for the tip though and I'll be sure to check out BugZilla. Since that sounds like it's actually intended for software development it may be more suitable. > 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. That's correct and none of our department uses one. The closest we've got is outlook task requests but they generally don't get stuck to. The new IT manager has at least put a sign on the door to stop non-managers coming in (people ignore it but it's helped a little anyway) and likes all requests to go for him (and the majority do). Usually though it still ends up being all verbal. We've also had paper based "IT request forms" in the past which I don't think anyone ever filled in. Personally I think an electronic solution is better, though I think a lot of our problem is not being insistent enough on people using them. I appreciate your feedback anyway, thank you. I'll look more closely at a few of your suggestions. .