The Value of Collaboration in Software Development

I've really come to appreciate the Answers section on LinkedIn. It's amazing the kinds of questions that will be asked, and the kinds of thoughtful and thought-provoking answers you'll find posted there. Today, I stumbled upon this intriguing question posted by Steven Burda of Sungard Data Systems, titled "The Reality: What you know? Who you know? Who they know? Or who knows YOU?!":

“it’s not what you know, but who you know”
“it’s not who you know, but who they know”
“it’s not who you know, but who knows YOU”
Lately, the enormous rise of virtual business and social networks is changing the traditional “networking” environment, and it is evident by the exponential growth of sites such as Linkedin and Facebook, just to name a few… Questions: What about the true value-added result of this human “capital” we’re connecting and “collecting” here… and its direct (and indirect) benefit to YOUR future, on both professional and personal level? But most importantly, please tell me: which of the above three statements do you agree or disagree with, and why?

These kinds of questions are frequently asked on LinkedIn, and they make you stop and seriously think before you just whip out a response. (If they don't, they certainly should.) Among the many responses, however, one struck a chord with me, because it resonates profoundly with how I feel about software development and the kind of culture I'm currently seeking in a company. This eloquent, insightful answer was posted by Charles "Charlie" Levenson of Multnomah Athletic Club (italics were added by me):

It's not who you know.
It's not who they know.
It's not even who knows you.
It's who YOU know who knows the things that you DON'T know.
The secret to networking for me has always been using my network to supplement the gaps in my capabilities and knowledge. Almost every project these days requires some level of COLLABORATION and there just are not that many Orson Wells around any more. I know that I will NEVER be as good at some parts of the process as other people I know already are, so why not collaborate with them. For instance, no matter how well I might write, produce, or direct, when it comes to MUSIC, that is simply a giant hole in my skill-set. I have to have a strong network of people I can work with who can provide music capabilities at the level I need to match the rest of the work I do.
For me, the network is about knowing who can do what I can't do so that together we can do great things.

This simple, forthright statement sums up the value of collaboration so eloquently that there's little more that needs to be said. (But you know I'm going to anyway, right?)

For me, having worked as  lone developer for three years, with no access to peers during the totality of that time, I hunger and thirst for collaboration to such a degree that it's nearly overwhelming. I am keenly aware of several facts regarding my current state as a software developer:

• Where I work now, we've been working with a very finite set of technologies. During that time, a whole new suite of powerful technologies has emerged that I know nothing about, and with which I have never had the opportunity to work because there simply wasn't a need or a desire on the behalf of the company to look at them. .NET 2.0 (and now 3.5), LINQ, SilverLight, WPF, WCF, Web Services, AJAX, multi-threaded applications, click-once applications, web farms... The list goes on and on and on. I am keenly and painfully aware of the vast gaps in my knowledge that I desperately want to fill. But filling that knowledge, for me, is a daunting task. How does one begin? For me, I learn best by doing and discussing. Reading is slow and tedious, and requires that you trust the author, that you have the time and space to do it quietly, and that the printed materials are accurate and complete. My schedule tends to be quite busy; the only time I really get to read is right before I go to sleep, and that's not the best time to read technical materials at all.
• I have often made mistakes that could have been prevented through the simple mechanism of peer review. And it didn't even have to be a formal review. Water cooler discussions, informal whiteboarding sessions, lunchtime conversations, inter-cubical discussions about a problem that I just couldn't figure out... any of these things could have helped me to avoid any of the major headaches that I brought on myself. We often look at peer review with suspicion, thinking that it's going to be someone judging or criticizing our code. But the real value of peer review lies in someone being able to point out things that you hadn't considered. "Hey, did you know that there's a class or method in the Framework that already does that?" "This design pattern might actually solve that problem for you." "You might be able to solve that better with an interface instead of a class." "That design might be too tightly coupled; can you explain why you're doing it that way?" (After all, you might have a valid reason for doing it.)
• I find it all too easy to just fall back on the familiar, cozy way of doing things the way that I have always done them. Without a fresh source of ideas, new perspectives, it's very difficult to think outside the box. When you work alone, it's virtually impossible. You have to rely on books, blogs, newsgroups, and Google. It's a hit-or-miss thing at best. But working with people that you know and trust, whom you know to be reputable and knowledgeable about their field, is a great way to gain insight into new ways of doing things that you might never have considered.

What all of this points to is that Charlie Levenson's comment struck home for me. I've been interviewing with companies for three weeks now. And in every interview, I've made it clear that I'm interviewing them every bit as much as they are interviewing me. I'm looking for a culture: a culture of collaboration, mentorship, and growth. I need to know that when I get up in the morning, I'm going to be excited about going into the office because somewhere, somehow, some piece of my knowledge base is going to expand: I'm going to learn something knew.

I once blogged about refactoring as a way of self-improvement, that it's not just a coding activity, but that we should constantly strive to refactor our skill set. I stand firmly by that blog post. What's interesting now, though, is that I'm taking that mentality and applying it to my job search. I want a job where I can engage in constant refactoring of myself every day, where I can sponge knowledge off of my peers every day, and learn something new from them.

So, what Charlie says is absolutely true: I'm building a network of people who know things that I don't, so that they can fill in the gaps in my knowledge, and we can do great things together. With any luck, I can one day return the favor for them or someone else.