Subj : Re: Constant interruptions and left brain - right brain thing
To   : comp.programming
From : Anon
Date : Thu Sep 29 2005 12:04 am

"Chris Sonnack" <Chris@Sonnack.com> wrote in message
news:tkhlj150q2pua2vb6i5sarj9tqljuf12uo@4ax.com...
> I can't speak to the work modes of others, but it's not uncommon for
> me to be--figuratively speaking--several "sub-routine calls" into a
> process that requires successfully "popping each frame off the stack"
> on the way back to the main process.
>
> Interruptions are deadly when that's happening--usually results in
> "stack corruption" of some sort.

Yes I agree with that. Sometimes a change might require a minor change to be
made in 5 different parts of a program. The effects of some of the changes
going live but not others could be deadly and if you've spent some time
figuring out what needs changing, and you've made 3 of the changes, then get
interrupted, you may forget about the other 2.

Also while working in a function you might notice something wrong with
another function, and then something wrong in another, and that can lead to
a stack of problems. I try to make a quick note to fix it later and finish
what I'm doing in the current one to work around that though.

In an ideal world the changes would be planned out and documented before
being made but in reality we're always being rushed, usually by the managing
director such as when he requests a new feature and wants it ready within 5
minutes to show in a presentation to another company. Another time he asked
our web developer for a pretty major reworking of our website (which is the
source of most of our orders) and demanded it was live within 30 minutes.
The web guy protested and was basically told "Forget about all this
documentation bullshit, just do a quick job, we'll take the bugs out later"
(we're told that quite often, by the way). At one point he stood behind the
developer counting down the remaining time he had left.

When developing new software I might have thought of a way to solve the
problem but an interruption before I've finished getting it all down (into
either code or a quick english explanation) may cause me to forget the
solution and have to work on it again.

Out of interest how much detail do you go into in your design work? For new
software that is likely to take more than a couple of days I try to at least
get down a UML diagram planning out what classes will be used and how they
will link together along with the more important public methods. I don't
include private methods at this stage however, but I include XML comments
for nearly every method in code. When maintaining older software there is
never any documentation or comments in the programs so I try to map out
which functions call which other functions, and what they do, plus decipher
the various variable names. These older programs are all written in classic
VB (so no OO), the functions are named things like cewrtwrt_Click(),
dojob(), dojob7(), etc and the variables for most of these are global and go
from Z1 to Z30.

.