Coding and Gardening

Warning: metaphors ahead! May be inappropriate or stretched.

Reading through student proposals for Google Summer of Code yesterday, I took a break from sitting in front of a keyboard to get some gardening done. We've had a few windstorms since I last raked, and with spring beginning, a few weeds have been popping up as well.

One of the issues I've been reminding almost every student about is unit testing. The other is documentation. These are practices which are seen as not fun, not creative.

Raking isn't seen as fun or creative either! Nor is hunting and digging the wily dandelion. But I rake away the dead branches and fir cones, and snag those dandelions because later in the season, my healthy vegetables and beautiful flowers not only flourish without weeds, but look better without litter around them. In addition, we chop up the branches and cones, and use that as mulch, which saves water and keeps down weeds. The dandelions go into the compost pile and rot into richer soil to help transplants be healthy. In other words, the work I do now pays off in the future.

The same is true of writing unit tests, commenting your code, and keeping good notes for user documentation as well! These are habits to build, not onerous tasks to be put off for tomorrow. Your unit tests will serve you well as long as your code runs anywhere. The same is true of your commented code. And finally if you code is user-facing, user documentation is what lets people use it!

So students, please remember to put those necessary bits into your proposal. This along with good communication with your mentor and the entire team are absolutely crucial for a successful project, so bake these into your plans.

Good Notes

Final lovely quote from Creativity, Inc. by Ed Catmull. Please get the book for yourself if you want to know how to foster creativity in a community or company.

In the very early days of Pixar, John, Andrew, Pete, Lee, and Joe made a promise to one another. No matter what happened, they would always tell each other the truth. They did this because they recognized how important and rare candid feedback is and how, without it, our films would suffer. Then and now, the term we use to describe this kind of constructive criticism is "good notes." 

A good note says what is wrong, what is missing, what isn't clear, what makes no sense. A good note is offered in a timely moment, not too late to fix the problem. A good note doesn't make demands; it doesn't even have to include a proposed fix. But if it does, that fix is offered only to illustrate a potential solution, not to prescribe an answer. Most of all, though, a good note is specific. "I'm writhing with boredom," is not a good note.

Catmull quotes Andrew Stanton at length explaining the difference between criticism, and constructive criticism, ending with: It's more of a challenge. "Isn't this what you want? I want that too!" [103]

I think this bit is the key: good criticism focuses on the common goal: a great product. It inspires, rather than creating defensiveness.

I read Reviewboard feedback in a sort of random way, and see a lot of "good note" behavior. But that timely part is sometimes missing. We have some Reviewboard requests languishing, along with patches in bug reports. Fortunately, the Gardening project has sprung up to improve this part of the community. Help out if you have time! https://mail.kde.org/mailman/listinfo/kde-gardening and https://community.kde.org/Gardening.