Re: Typical work day

Replies inline.

"Phlip" <phlipcpp@xxxxxxxxx> wrote in message
news:fco_e.425$056.136@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 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.



.

Quantcast