On 30/10/11 1:19 PM, Chuck Guzis wrote:
Toby Thain [toby at telegraphics.com.au]:
Are there common things that a programmer waits for?
Reminds me of a discussion that I had with Greg Mansfield, then of
Cray sometime around 1983. We were discussing mods to Unix (I, BSD
for the VAX; he, UniCOS) and I happened to mention that maintiang the
makefiles and integrity of partial builds was a bit of a burden. He
responded that he didn't bother with partial builds--he just
recompiled the whole thing every time.
After all, he was running on some very fast hardware. Indeed, even
today, I'll find myself wondering what the heck I'm doing working out
a makefile for a project whose compilation time is a minute at worst.
One increasingly important reason: parallel builds. A correct makefile
gives you that for free.
Even to correctly rebuild "the world" in parallel (and if you're doing
that, you WANT it happening on multiple cores) will require a correct
makefile. It's a worthwhile investment. Plus you never know when you (or
some random end user, in the open source universe) will want to build on
a verrrrry slow machine. They'll curse you if you only ever built on an
8 core Xeon and never gave a damn about incremental builds or
efficiency. (Another justification of the original proposal to keep dev
boxes slow: or you might never end up with sensible makefiles.)
And I agree--time spent away from the damned box is probably more
important than time spent in front of it in the development process.
Thanks for concurring; I was wondering if I was the only person on the
list who felt thinking, design, and reasoning were important parts of
programming.
For me, time spent sleeping seems to be my most
productive time I
find that designing software when fatigued results in many mistakes
and foggy thought.
Oh yes, can't count the times when I've burned out on an issue at 6pm
and solved it by 10am with a fresh mind the next morning.
My most valuable development tool remains a quadrule pad and a
pencil.
Mine too!
My most valuable lesson learned is *never* give in to management
pressure to cut development time on a project. We all could take
lessons from Michaelangelo there.
The funny thing is, management never learns. They get burned by cutting
a time budget, fail to join the dots, and do it over and over again.
Lessons from Michaelangelo and the late great Fred Brooks, indeed.
--Toby
--Chuck