A few years ago, I started up a weekly tech seminar in my organization. We do everything from demos of new technologies, to sharing technical issues and solutions we found to them, to watching videos from the web of our favorite speakers on technical topics.
There's another thing we like to use this time slot for: group coding sessions. We take a simple problem from Project Euler, and we code it up as a group on a projected screen. The sessions allow the developers to share tips on tools, talk about the right seams in code, and
Someone asked me why we would code in a group, and I sent them the following
Benefits
Here’s the benefits as I see them:
· It’s great for everyone to get to know each other.
· It’s great to work with other people and learn how to develop in a more collaborative environment.
· It’s great to create a more collaborative environment.
· It’s great for everyone to know everyone else on all dev teams. Especially as some groups are more segregated than others.
· It’s great to see how people use tools differently, as we all use things differently and become more productive as we work together on things.
So from an organizational standpoint, it’s all good.
That's what I said. The details are a bit more complicated. Let me talk a little bit about some overvations I've made and lessons learned.
Results
We've seen great results from working together in these sessions.
It's no secret that I am a big fan of NCrunch (I tweet about them from time to time), and that and ReSharper are two of our key dev tools. We got enough licenses for every developer to use both, but people weren't really using them. After seeing the tools in use as we do a test-driven style example, people come up and ask for their license. Spending a little time coding together has meant that we get a better return on the tools we bought, in terms of usage (hopefully they learn to use it wisely).
We usually send out the solution after the exercise, so everyone can work on any finer points after the fact. We've seen people dive deep into an optimization, or work on finding analytic solutions to brute force problems. It gets people thinking about something other than the features their day job offers them, and they seem to be really excited about these other opportunities (I'm using the proactive follow up as evidence here).
Further, you get some peer recognition. Everyone contributes some code, and those people who can code get the kudos of their peers. Better still, we've found hidden talent and enthusiasm in all our colleagues. It's great to know who can do what, and it's great to give them props for doing so in a group.
I don't care who you are. When you start out, coding in front of people is hard. You have to let go of that ego. You have to silence that little voice of doubt. You have to get past freezing up. And it's better to do it here than, say, during a job interview or a more important coding session at a conference, meetup, or Hackathon. And everyone does it. It's harder for some than others, but you see them grow in confidence, both in themselves and in their code.
One Big Observation
One thing that kills, absolute kills a group coding session, and that's negation. Someone else writes a test and implements a method, and the first thing the next guy does is delete the body of the method and put in a pet implementation. Maybe it's better; maybe it's not. I've seen both, actually, and what is most important here is a concept straight out of the improv comedy world. I know it's a weird place to apply the concept, but one of the core concepts of improv is that you never negate anything anyone else does. You build on it. You manipulate it. But you never simply say no.
Imagine a comedy sketch at The Second City that goes like this:
Milli: "And now I'm a T-Rex trying to make a peanut butter and jelly sandwich in a military cafeteria."
Vanilli: "No, you're not. You're eating a pizza on the set of The Sound of Music."
And where does Milli go from there? Vanilli has just taken the momentum out of the skit and turned things over on their head. The same thing happens in a coding session.
The trick of great Improv is "Yes, and..." In the Milli-Vanilli sketch above, Vanilli can do this by saying, instead:
Vanilli: "Yeah, and I'm a four-star general who walks in and does a double take as you cut the crusts off your sandwich."
Momentum saved, and the skit moves forward.
Yes, And
So do this while coding. Sure, someone may have just taken a misstep. Maybe you see a more optimal way to do something. Maybe you think your way is cleaner. Keep that to yourself and don't negate what someone else has done. Add to the example as is. One of a couple things may happen. The example might evolve until it's obvious why your way might have been better. Or you might learn something new. Either way, I've observed that sessions that are allowed to evolve dynamically are more enjoyable.
Conclusion
I happened to be talking to Clark Sell on Friday during our That Conference call. He's currently reading a book on Improv Wisdom, and said something very similar. I haven't gotten to read the book yet myself, but I recognize the rule on the cover... "Just show up." Which has a familiar vibe to what draws me to the tech community. A big part of getting better is speaking up, doing, and making things happen with the people around you who also show up.
So get your code on. Do it now. Do it with your co-workers. Just because you're dark matter, doesn't mean you don't matter. You can do it.
There's another thing we like to use this time slot for: group coding sessions. We take a simple problem from Project Euler, and we code it up as a group on a projected screen. The sessions allow the developers to share tips on tools, talk about the right seams in code, and
Someone asked me why we would code in a group, and I sent them the following
Benefits
Here’s the benefits as I see them:
· It’s great for everyone to get to know each other.
· It’s great to work with other people and learn how to develop in a more collaborative environment.
· It’s great to create a more collaborative environment.
· It’s great for everyone to know everyone else on all dev teams. Especially as some groups are more segregated than others.
· It’s great to see how people use tools differently, as we all use things differently and become more productive as we work together on things.
So from an organizational standpoint, it’s all good.
That's what I said. The details are a bit more complicated. Let me talk a little bit about some overvations I've made and lessons learned.
Results
We've seen great results from working together in these sessions.
It's no secret that I am a big fan of NCrunch (I tweet about them from time to time), and that and ReSharper are two of our key dev tools. We got enough licenses for every developer to use both, but people weren't really using them. After seeing the tools in use as we do a test-driven style example, people come up and ask for their license. Spending a little time coding together has meant that we get a better return on the tools we bought, in terms of usage (hopefully they learn to use it wisely).
We usually send out the solution after the exercise, so everyone can work on any finer points after the fact. We've seen people dive deep into an optimization, or work on finding analytic solutions to brute force problems. It gets people thinking about something other than the features their day job offers them, and they seem to be really excited about these other opportunities (I'm using the proactive follow up as evidence here).
Further, you get some peer recognition. Everyone contributes some code, and those people who can code get the kudos of their peers. Better still, we've found hidden talent and enthusiasm in all our colleagues. It's great to know who can do what, and it's great to give them props for doing so in a group.
I don't care who you are. When you start out, coding in front of people is hard. You have to let go of that ego. You have to silence that little voice of doubt. You have to get past freezing up. And it's better to do it here than, say, during a job interview or a more important coding session at a conference, meetup, or Hackathon. And everyone does it. It's harder for some than others, but you see them grow in confidence, both in themselves and in their code.
One Big Observation
One thing that kills, absolute kills a group coding session, and that's negation. Someone else writes a test and implements a method, and the first thing the next guy does is delete the body of the method and put in a pet implementation. Maybe it's better; maybe it's not. I've seen both, actually, and what is most important here is a concept straight out of the improv comedy world. I know it's a weird place to apply the concept, but one of the core concepts of improv is that you never negate anything anyone else does. You build on it. You manipulate it. But you never simply say no.
Imagine a comedy sketch at The Second City that goes like this:
Milli: "And now I'm a T-Rex trying to make a peanut butter and jelly sandwich in a military cafeteria."
Vanilli: "No, you're not. You're eating a pizza on the set of The Sound of Music."
And where does Milli go from there? Vanilli has just taken the momentum out of the skit and turned things over on their head. The same thing happens in a coding session.
The trick of great Improv is "Yes, and..." In the Milli-Vanilli sketch above, Vanilli can do this by saying, instead:
Vanilli: "Yeah, and I'm a four-star general who walks in and does a double take as you cut the crusts off your sandwich."
Momentum saved, and the skit moves forward.
Yes, And
So do this while coding. Sure, someone may have just taken a misstep. Maybe you see a more optimal way to do something. Maybe you think your way is cleaner. Keep that to yourself and don't negate what someone else has done. Add to the example as is. One of a couple things may happen. The example might evolve until it's obvious why your way might have been better. Or you might learn something new. Either way, I've observed that sessions that are allowed to evolve dynamically are more enjoyable.
Conclusion
I happened to be talking to Clark Sell on Friday during our That Conference call. He's currently reading a book on Improv Wisdom, and said something very similar. I haven't gotten to read the book yet myself, but I recognize the rule on the cover... "Just show up." Which has a familiar vibe to what draws me to the tech community. A big part of getting better is speaking up, doing, and making things happen with the people around you who also show up.
So get your code on. Do it now. Do it with your co-workers. Just because you're dark matter, doesn't mean you don't matter. You can do it.
No comments:
Post a Comment