Collaborating to improve solutions AND people is tough. Programming is the easy part.

In Hiring and Interviewing Engineers, a recent Hanselminutes podcast, Scott ran through a sample interview process where he presented an obscure scenario to Carl Franklin. This was not as a test of whether Carl could get the answer (it was obscure and intended that he wouldn’t have previously seen such an issue before), but intended to observe how he went about trying to resolve the issue. This lead to Matt Davis suggesting what I can only assume to be (remember, obscure, I have never seen this type of scenario either) a viable solution in the comments on Scott’s blog. I thought this was great. No pretentious, "Your solution was crap" argument. No, "My solution is the penultimate solution to the problem" response. Pure, level-table, colaboration to improve a solution. There’s a lesson to be learned here I think.
First, from a "Microsoft versus the world" perspective:
There has been a LOT of bashing of Microsoft (read the Rory Blyth‘s two posts [one, and two] defending Microsoft and its developers from bashing by Robert Scoble or David Starr‘s Open Letter to Scott Guthrie). Instead of having open collaboration to improve, both sides (Microsoft and it’s detractors) distance themselves from one another and, often, the mudslinging begins. It has been rumored that Microsoft has a "EEE" pattern of integration ("Encourage", "Enhance", "Extinguish") that extends to open source and even to some of its partners. Open sourcers (okay, not a word, but you get my point) have fear because of this history and some resort to bashing Microsoft rather than working with them to improve the products. It looks like both sides need to re-examine how they collaborate. To improve, that cold war has to be ended through unilateral disarmament from one side or the other.
Second, from a "My code versus yours/legacy" perspective:
I don’t think that those who wrote the application before me intended to make code that was un-maintainable. I don’t think anyone goes to work thinking, "I want to make something worse than it was yesterday" now or in the past. One day I will no longer with the application I am working on now. I certainly had the best intentions in the code I wrote. I am certain that those before me had the same best intentions as well. To resolve this, a distinction between the solution (with the problem) versus the people implementing the solution needs to be made. With collective code ownership (an admittedly difficult concept to embody), both the solution and the people can improve as the system is improved.
Stated like this, it all just seems so easy…. heh.

2 thoughts on “Collaborating to improve solutions AND people is tough. Programming is the easy part.

  1. HOLY CRAP!!  First time in and I can leave a comment?  Forget what I was going to say, I am posting right now before I lose my chance!

  2. Glory of glories, twice in a *ROW*!!  We are on a roll here!I have to be honest with you, I don’t think the whole contest between Blyth and Scoble is a great representation of either side.  Strikes me as two people with a somewhat self-centered viewpoint competing with each other to see whose manhood is longer.  No time for that sort of stuff.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s