I had a bit of a relapse of the Avian-SARS-Monkey-Flu (or whatever it was) and I’m just now getting out from under it.  I tried to keep working this past week, though, although I wasn’t too productive. 

So now I’m a bit behind from all the sick time and I’m trying to scramble to catch up.  Unfortunately, while I’m most productive in the mornings, I’ve got meetings all morning (until noon).  Worse, my presence on most of these calls is really only needed for about five minutes on each, except for monitoring (which is what breaks my concentration).

Of course, the monitoring is important, too.  The problem is that it’s hard to predict when you’re needed.  The reason I bring up monitoring is that it’s imperative to get ahead of any misconceptions or wrong information that people try to disseminate about your projects.  I’ve seen projects burn up many hours trying to fight misconceptions after the fact, so you have to stay in meetings and pay at least passing attention so as to immediately nip it in the bud (just nip it, nip it in the bud    ).

A couple of examples of the types of things that you have to be alert for:
The deflector:  This person, seeking to justify their own project’s shortcomings, will attempt to use your project as the reason.  They’ll say something like, “Project X (their project) is behind schedule because Project Y (your project) has not yet provided Item Z.”  This requires a quick response (provided, of course, that you haven’t been derelict in providing “Z”) along the lines of, “Project Y is working to the agreed-to schedule and Item Z was provided on Date A to Person B on your team.”  I especially love giving this sort of answer because it quickly deflates the deflector.

The upset techie:  This person (often on your own team!) either has a disagreement with a design decision or is an adherent of some pet technology or methodology that isn’t being followed.  This person is so convinced that he or she is right that they’ll announce to the world that your project is doomed to failure, inefficient, inflexible, and riddled with bugs.  Fortunately, I haven’t had to deal with that too often.  But I do recall one case where I got dragged into it as an outside auditor.  One disgruntled programmer had told a director-level executive that the project’s code was sloppy, unorganized, and riddled with bugs.  I had to examine the code and report on its correctness.  Ultimately, I didn’t find very much wrong with it, but I had to spend a lot of time getting to that point (the project was composed of thousands of source files, as anyone who has ever had to review a large Java project will understand).

Interestingly, unless I’m doing a lot of research and writing something complicated, this blog stuff doesn’t require nearly the amount of concentration as real work.  Those of you who have done programming work may understand when I reference the trance.  I’ve found that design work requires the same kind of concentration levels (or at least it does for me).  Constant interruptions or being in meetings isn’t conducive to reaching the trance.  I’ve tried writing design docs while on conference calls in the past and found that I had to significantly rework those sections afterwards.  When I was still working in the office, and doing programming work, I used to reserve mornings for coding and I’d put a stuffed penguin on my cubicle wall as an indicator to people that I wasn’t to be bothered.  Usually around noon the penguin would come down and I’d spend the afternoon dealing with email and support issues.

The only problem with this is that there are people out there who just don’t get it when it comes to the trance and think that it’s just a silly anti-social geek/programmer thing.  Usually, these are not people who have done coding work (of, if they have, they weren’t any good at it).  But even if they don’t truly understand, I’ve always wondered why someone would hire a person to do a particular job and then not give the person time to do it.  That’s effectively what they’re doing if they’re constantly interrupting their programmers.