Mentoring
I've instituted a process in my group at work wherein each developer spends a few hours each week actively studying a specific problem domain in software development. Thus far both of my reports have chosen to study formal software architecture.
Our process is simple. A book is selected and a specific amount is read each week outside the office. We then allocate between an hour and ninety minutes for discussion of the text. This is one-on-one time between the developer and myself - we close the door to the office, put on a little music, ignore the phone, and discuss the finer points of the reading.
Every six months we stop and see if we want to change to a different topic. This is about to happen for my team, so we'll see where they want to go. I'm also about to pick up a third developer, and I don't know what he's going to want to study. I'm hoping he chooses something different, to spread the knowledge around some.
Initially, I've asked them to read Gamma's excellent work on design patterns, but now we're moving into books that I've never read before. One of them is working his way through a text on enterprise-scale SOA, which is interesting; we're getting some new ideas into the discussion (and our last conversation went completely off the rails for half an hour into the concepts of what users want vs what users need...perhaps the most useful conversation we could possibly have!).
The great thing about it is that I've never read this book! So he's reading it and then spending the hour explaining the ideas to me, and I spend the hour asking questions about everything he says. Sort of an anonymous socratic method. I learn some things and he learns a lot.
A simple formula for formal software mentorship:
1) Consistency
2) A single goal for a fixed period of time
3) Time spent both in and out of the office
4) Learning effort expended without assistance from the mentor
We always bring the conversation back around to the work we're doing during the week, and look for real-world applications. Sometimes we're forced to admit that it would at best be a stretch. More often than not, however, we can see some immediate use for the week's study, which lets us decide to take a little extra time and incorporate it into the upcoming work.
So far, I've seen significant progress in both developers' grasp of system design and architecture. They're also taking the initiative more and stepping up to drive their own education. Which is the real victory, after all. As always, the best lessons are the ones you don't know you're studying.
Our process is simple. A book is selected and a specific amount is read each week outside the office. We then allocate between an hour and ninety minutes for discussion of the text. This is one-on-one time between the developer and myself - we close the door to the office, put on a little music, ignore the phone, and discuss the finer points of the reading.
Every six months we stop and see if we want to change to a different topic. This is about to happen for my team, so we'll see where they want to go. I'm also about to pick up a third developer, and I don't know what he's going to want to study. I'm hoping he chooses something different, to spread the knowledge around some.
Initially, I've asked them to read Gamma's excellent work on design patterns, but now we're moving into books that I've never read before. One of them is working his way through a text on enterprise-scale SOA, which is interesting; we're getting some new ideas into the discussion (and our last conversation went completely off the rails for half an hour into the concepts of what users want vs what users need...perhaps the most useful conversation we could possibly have!).
The great thing about it is that I've never read this book! So he's reading it and then spending the hour explaining the ideas to me, and I spend the hour asking questions about everything he says. Sort of an anonymous socratic method. I learn some things and he learns a lot.
A simple formula for formal software mentorship:
1) Consistency
2) A single goal for a fixed period of time
3) Time spent both in and out of the office
4) Learning effort expended without assistance from the mentor
We always bring the conversation back around to the work we're doing during the week, and look for real-world applications. Sometimes we're forced to admit that it would at best be a stretch. More often than not, however, we can see some immediate use for the week's study, which lets us decide to take a little extra time and incorporate it into the upcoming work.
So far, I've seen significant progress in both developers' grasp of system design and architecture. They're also taking the initiative more and stepping up to drive their own education. Which is the real victory, after all. As always, the best lessons are the ones you don't know you're studying.