George Dinwiddie’s blog

I was asked about how I would mentor people in the context of being the team leader. Tricky situation, that.

On the one hand mentoring people without their request is an instance of what Jerry Weinberg calls “inflicting help.” At best, it’s ineffective. Usually it’s worse.

On the other hand, an organization has a reasonable expectation that the people working there will improve over time. Who better to help a team do that than the team leader? (Continued)

Don Gray got me started, with his posting of 3×5 notecards for studying the patterns in the book, Fearless Change: Patterns for Introducing New Ideas, by Mary Lynn Manns and Linda Rising. I agree with him that it’s a wonderfully helpful book, and I thought the idea of creating cards to carry and study at odd moments was a good one. I’m just too cheap to buy the Avery cardstock–not when I’ve found that I can print ordinary 3×5 cards in my wife’s inkjet printer (an Epson C60).

So, at Don’s suggestion, I re-formatted his format and created both OpenOffice and PDF versions of the cards. I hope you find them useful, but be sure to read the book! Not only is that fair to the authors, but the cards will make a lot more sense to you.

I saw this question in a blog post by Mark Schenk:

About two-thirds of the way through the workshop one of the students asked “when do we get to the stage where we can tell the client what the answer is?” This literally stopped us in our tracks – we were so accustomed to working on the basis that complex problems have no single correct answer that we hadn’t explicitly explained this and we had bumped headlong into a prevailing management mindset.

That question struck a chord. I thought back to the days when I first learned XP. Most of the ideas and practices resonated strongly with me. The one that seemed most foreign, Test Driven Development, became a personal fixture after trying it for three days. Yep, this was the way software development should be done! It was so obvious and right, and I told everyone I knew.

They all immediately agreed and thanked me for the information. Well, not exactly. (Continued)

I attended a session with Naomi Karten at the AYE Conference last Fall, so I knew she had a lot of good things to teach me. In spite of those high expectations, I was blown away by this book. In fact, the only negative thing I can say is that there’s material for two or three books in here. Having read through it once, I know I’m going to have to re-read it in sections. (Continued)

Matt Heusser just posted a blog entry on conferences, where he makes excellent recommendations. During much of my career, I relied primarily on magazines and online communications (remember CompuServe?) to broaden my horizons. These were worthwhile, but are no match for face-to-face communications. (Continued)

Writing my introductory post led me to think of some of the many people who have taught me important lessons. One of those people was Duc Tran, an engineer I knew when I was a technician at Rixon. He taught me a technique for using an index register to keep track of current state, instead of relying on a flock of boolean values and “if” statements. That revelation changed the path of my life, and led me to seeking simpler, yet more powerful, constructs. I was caught in a lay-off (my first of many) not many months later, and I’ve lost track of Duc Tran. I doubt that he’s aware of the influence he had.

It’s perhaps a characteristic of the human condition that we are often unaware of the good we do in the world. We must keep trying in spite of the lack of feedback.