Subject: Mentoring open source programmers
From: Michael D. Crawford (crawford@goingware.com)
Date: Thu Feb 22 2001 - 03:19:13 CST
There's an article tonight on http://slashdot.org on the subject of "Making
Software Suck Less", it's at:
http://slashdot.org/article.pl?sid=01/02/21/1842208&mode=thread
The article generally promotes the idea that expert programmers should
mentor the neophyte programmers and gives some tips on how to do this.
I've been trying to help others write better code for a long time now. I
can say I've actually mentored one engineer, a woman friend who was very
unhappy with her low-paying job as a biological laboratory technician at
U.C. Berkeley - I talked her into becoming a programmer, and now she owns
her own house in high-priced Berkeley with money she made at her
programming job.
I also participate sporadically in the NeoProgrammer's Collective, which is
BeOS specific but has a lot of good information on C++ programming:
http://www.neo-programmers.com/
I posted a couple comments with tips on writing better software with links
to books, book reviews, tools and articles that the AbiWord folks might
find helpful.
While some of the tools I talk about are quite expensive, if you can afford
them I expect they'd be well worth the money - and some powerful tools are
free, like Bounded pointers for GCC, or using GCC with the -pedantic and
-Weffc++ options.
If you prefer your normal compile-edit-test cycle to not be interrupted
with dire warnings of minor stylistic nits, you can use something like the
"make lint" method I discuss in the comments, adding a target to the
makefile that's meant for testing the style of the code, rather than
actually building a working executable.
Note that cross-platform development combined with rigorous validation
tools like this can make your code extremely robust - you'll catch a bug on
one platform with one tool that would have been hard to find on a different
platform with another tool. You've probably experienced by now that
changing platform makes a latent bug more apparent; now imagine that you're
sweeping through you're bugs with different kinds of sieves on the
different platforms.
The bulk of the tips I posted in tonight's Slashdot discussion are
pertinent to C++ programming, and are about how to learn about things that
make a direct impact on one's productivity and quality as a C++ programmer.
My comments are posted at:
My own efforts to help other programmers
http://slashdot.org/comments.pl?sid=01/02/21/1842208&cid=178
More helpful tips for you
http://slashdot.org/comments.pl?sid=01/02/21/1842208&cid=249
Lately I've been working on a Mac debugging contract. I hadn't done much
direct Mac OS API stuff for a while (I did write a product for the Mac last
year, but it was written to the ZooLib cross-platform framework). It
brings back a lot of good memories, and while I have strayed far from the
fold since the days I bled in six colors, I'm really getting back into it.
What that means to you is Real Soon Now I'll be doing some debugging on the
Mac port of AbiWord. If things work out OK with the work I'm doing now,
I'll be buying a dual G4 533 Mhz Mac, so doing things like Spotlight
debugging on AbiWord will actually be a reasonable thing to do.
Best,
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
crawford@goingware.com
Tilting at Windmills for a Better Tomorrow.
This archive was generated by hypermail 2b25 : Thu Feb 22 2001 - 00:20:15 CST