Sorry Napster fans, I’m talking about a different kind of P2P here … career development in a peer-driven context.
In nearly every group I’ve joined, some bright developers eventually banded together and decided they were frustrated at feeling out of touch with the industry. The answer has always been some sort of peer-driven career development effort. For example, back in the late 90s, I remember we set up a regular meeting which the entire Navisphere development organization was invited to. Each week (or was it month?) a speaker would present on something new they had learned. Occasionally, a guest speaker from another organization would present on something they were doing. The speaking responsibility rotated among volunteers until we realized it was basically the same 3 people over and over again, and it fizzled out.
More recently, I’ve been involved in two small-scale groups where advanced topics in programming languages, tools, and methodologies were presented by volunteer “experts” to whoever wanted to attend. These, too, started strong and fizzled out. Managers got all excited about this idea and started pushing their people to attend, which made it worse. Nobody wants to spend their spare time researching a new technology only to present it to a silent group of resentful colleagues.
This past month, two colleagues of mine decided to take this idea in a different direction. Presentations and slides and research are for, well, students and researchers. What if they stopped talking and started doing?
The call went out to a few dozen developers and their managers. Who wants in? The only rule? Everybody codes. Leave your title and your comfort zone at the door and come ready to get your hands dirty.
Only five people signed up, including the two organizers. They scrounged for computing resources, deployed open source software, and got a project started up in their spare time (lunchtimes, evenings, and weekends). The goal? Write a proof-of-concept application using some new technology or methodology. Align it vaguely with the group’s (or at least the company’s) objectives. Upon achieving success, either improve the application or abandon it and start a new one. Every so often, show off the results to the rest of the group.
Maybe it’ll fizzle out in 3 weeks. Or maybe they’ll stumble onto something awesome which will turn into the Next Big Thing.
I’m hoping it lands somewhere in the middle, and a group of passionate engineers remind themselves why they got into this field in the first place, have a little fun, and sharpen their saws on their own. The rest is gravy.