I've been a programmer for many years. I've seen projects succeed and projects fail.
Someone has said that managing programmers is akin to herding cats. Programmers put blood, sweat, tears, and ego into their code (or at least they should!). For many programmers, their code is their art. When this is the case, they - quite naturally - become protective of their code. With this philosophy/scenario, there can rarely be smooth roads. One of the philosophies that I had the unfortunate experience of working under was 'egoless code'. Yeah, sure. Sounded good to the managers. It rarely worked in reality. <walkthrough> One strategy that kinda/sorta worked was "code walkthroughs". It was understood beforehand that these were code walkthroughs, *not* "code walkons". The programmer invited other programmers to a conference where they could comment on (not criticize!) the programmer's code. The invitees did not need to be familiar with the project. It brought the programmer out of the solitary environment that we get into. It was, for the most part, a learning opportunity for all involved. It also increased respect for other's coding ability. </walkthrough> Another suggestion is that the teams pursue a common, *well-defined*cooperative (read: non-competitive!) objective. On Sun, Jul 3, 2011 at 2:50 AM, Ross Gardler <[email protected]>wrote: > Hi Ted, > > I think the warning in your mail should be heeded. Whilst there are > opportunities and established practices for collaboration on shared > code, ensuring the collaboration happens can be difficult. It requires > a certain level of humility, patience and effort on the part of all > involved. > > Since you are obviously concerned about this do you have any ideas > that can help us develop the right relationship for collaboration > between the different parties involved? > > Ross >
