Passing along some information from Mike Kelly regarding the 2009 schedule for the Indianapolis Workshops on Software Testing (IWST.) It's pretty short and dense, so I'll just copy from his blog (link no longer available):
We've posted the 2009 schedule for the Indianapolis Workshops on Software Testing. We're looking for people willing to share experience reports and people who just have a general interest in the various topics and would like to attend and ask questions.
Software development analogies are sometimes fun and potentially revealing. With that being said, I wanted to throw out a small nugget I thought of.
Growing up, I watched a fair amount of sitcoms until I realized the basic plot device. Essentially, something happens where a character on the show makes a choice, is worried about the ramifications of that choice, and is then somehow deceptive. They keep having larger and larger miscommunications and problems as the show goes on, and more problems (and hence hilarity), ensue due to keeping the problems under wraps. Eventually the characters realize the mistake, and the show ends with everyone having learned a valuable lesson.
At some point, I got pissed because I just thought "Why doesn't Stephanie just tell Danny Tanner that she wrecked the car instead of trying to hide it for like two more days? I'm pretty sure Danny's going to flip out and kick Comet and ground you, but at least you get it out in the open. There's definitely nothing to be gained from hiding it. Why would any rational person do this?"
A majority of open source projects have a paucity of documentation. However, they still have value as a working system. I argue that improving the documentation of a codebase intended for general use is one of the highest value activities that a developer can do. Although documentation may not be directly contributing to the codebase, the writer provides a valuable service by understanding the code and imparting that knowledge to others.
I would go so far as to say that there should be open source technical writers. They look for interesting projects to write basic documentation for. While there are a smattering of tutorials for certain frameworks, they are not condensed, are not authoritative, and are often misleading because of changes to the framework or convoluted examples. When the core developers move at the speed of the forum or even IRC, it's tough for a new person to have anywhere near that amount of knowledge. A centralized wiki with pertinent and up-to-date examples is quite useful.
I think I just formalized why I like reading.
A six month project expects approximately
6 months * 4 weeks / month * 40 hours / week = 960 hours.
Title: How to Win Friends and Influence People Authors: Dale Carnegie Published: 1990 Length: 304 pages
Of the books that I have read recently, this one seemed to be a contentious one. I discussed this book with a friend who is in sales, and we came to completely different conclusions on the book's premise. His idea was that the book contained a bunch of ways to manipulate people to get what you want, whereas I felt like the book provided methods to better understand, empathize, and work with people.
Throughout, Carnegie displays quite a bit of humor and wit, and gives memorable anecdotes to drive the points he makes home. Some things are trite on the outside, but they are quite useful once internalized. Here are some of the major points.