Programmers are talented, smart, skilled professionals. We put in lots of our own effort to educate ourselves and stay up on current technologies. We work hard and we feel great satisfaction in our achievements. We donate our time to charities when the opportunity arises. We give back to our local communities. All things considered, there are a lot of really great programmers in the world.
I lead a team of software developers. Does that mean I am the “best” programmer on the team? Certainly not. It just means that I lead the team. As the leader of the team, it is my job to: inspire, encourage, trail blaze, and motivate my team to be the best they can be. So who is the best programmer on my team? I don’t know, and I don’t care. There shouldn’t really be a “best” programmer on the team. Everyone on the team is great and working hard.
A team that really meshes and works well together doesn’t let egos get in the way. It doesn’t matter if you’re a rock star developer. When you’re on the team, you’re part of the team. You might be the JavaScript expert, the master of SQL queries, or the guy who can refactor anything. When you’re part of the team, you should try to use your strength, but don’t let that interfere with the team’s flow.
Sometimes it makes sense for a more experience developer to work with a less experienced developer. A common first instinct is that the senior person is mentoring the junior person, but it’s actually going both ways.
Each of the two developers is bringing a lot to the table. Their different experiences and views allow them to each approach the problems differently, ask different questions, and apply different, existing knowledge.
If either person’s ego gets in the way, it would prevent the 2-way knowledge transfer in addition to creating friction between them.
<p><a href="/images/files/WP_000541%5B5%5D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 4px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top: 0px; border-right: 0px; padding-top: 0px" title="WP_000541" border="0" alt="WP_000541" align="left" src="/images/files/WP_000541%5B5%5D_thumb.jpg" width="300" height="225" /></a>One Developer and one Junior Developer can pair on a task and share knowledge. Does one act like the other one is just along for the ride? No. </p> <p>Your pair partner, is watching your back, guiding the team, and keeping the pair honest. Which one does that job? Both. If you had one person drive the whole time, you’re not going to see the benefits of pair programming. </p> <p>If you let your ego get in the way, you might not let the junior developer write any of the code. They may not know every library, every design pattern, or even the intricacies of the language they’re using, but those guys can write some great code.</p> <p>I don’t know how the Junior Developers are on your team, but ours write great code and show a high level of professionalism in their work. </p> <p><a href="/images/files/RichAndEric.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="RichAndEric" border="0" alt="RichAndEric" align="right" src="/images/files/RichAndEric_thumb.jpg" width="300" height="225" /></a>And sometimes you get a Junior Developer pairing with the Developer Intern. How the pairs split up doesn’t really matter. Who is working with whom doesn’t really matter. Each and every member of the team is bringing something to the table, and it is this interaction that is making the team as effective as it is. These two are as productive a team as any other pairing that we’ve got. </p> <p>Someone is probably reading this and thinking I am crazy for letting a Junior Developer and a Developer Intern pair together. They’re good though, and they really get great stuff done.</p> <p>We can accomplish a lot of stuff when our team works individually, however, we can accomplish a lot more as a group. You might be the “best developer” on your team, but if you keep thinking and acting that way, you’ll be missing out on a lot. I learn a lot when I pair with <em>any</em> member of my team. It doesn’t matter how much experience the person has. Everyone knows <em>something</em> I don’t, and no one approaches the problems exactly the same way I would.</p> <p>There is no “Ego” in “Agile Team”, so don’t bring yours to an agile team and expect good results.</p>
Comments