I agree: explaining a problem to a third party (even just a cat) can do
wonders. One is forced to focus on the problem, as you are forced to
describe it very carefully (especially if you are talking to a cat).
:)
Jon
Dan Shafer wrote:
A relatively new user posted the following comment on the list a
couple of days ago.
> I have the habit to think that I did something wrong before thinking
> it's a bug in the tool I use (perhaps a not so good habit :-)).
I, too, have tended to begin with the assumption that if my program
isn't working, it's my fault and not that of the development tool or
language I'm using. Over the years, I've found more and more that
that is not the case.
I'm managing a tech project right now that's being written in Java
(not my choice). The programmer is a really seasoned pro. The project
was estimated at two weeks, planned for two months and is now in its
14th week without a beta being completed. Lots of reasons for that
(and I've been called in to try to stem the bleeding and get the
thing finished). But in reviewing what's happened over the past six
weeks or so, it's clear that well over half of the delays have been
caused by two things: (a) bugs in code to which the programmer does
not have source access; (b) problems in the development environment.
Java is particularly sensitive, e.g., to where it expects to find
things and how it behaves when it can't.
The moral: assume nothing. There is no such thing as bug-free code
that does anything non-trivial. There's just code whose bugs have not
yet been located.
Years of stress and far too many gray hairs led me to this bit of
advice I shared last weekend at RevCon West during my opening
keynote. I have a hard-and-fast rule NEVER to wrestle with a bug by
myself for longer than one hour. If I can't fix it in an hour, I get
help...from this list, from another programmer, or even by asking my
wife to sit patiently while I go over my code line by line
(incomprehensible jibberish to her), during the course of which it is
amazing how many things suddenly crystallize.
I was gratified and amazed at how many experienced programmers sought
me out to thank me for that insight at the show, so I figured it
would be worth sharing here.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Shafer, Revolution Consultant and Author
http://www.shafermedia.com
Get my book, "Revolution: Software at the Speed of Thought"
From the RunRev store
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
