Collaboration and Programming: Important or Not? [modified]
-
I have been lucky to work with good and smart people during most of my career, and it has been a pleasure collaborating with them. To me programming is a team sport, and I always liked basketabll players like Magic and Bird who could bring the quality of the whole team up.
Old Ed wrote:
which tends to translate in my mind to just lots of talking.
What's wrong with talking :) ?
In principle nothing is wrong with talking. But I've found that much of the talking hasn't been productive or rich with ideas. And don't get me started on the "team" metaphor. Overall I haven't found teams to be managed well, with the most vocal member many times being the most valued, whether or not their actions were best for the application. Note that I changed my post to read "which tends to translate in my mind to just lots of unproductive talking.".
-
I have a feeling your sig explains your view even better than your post :-D.
Software Zen:
delete this; -
Ed, I've been programming almost as long as you. Collaboration works best when responsibilities are well-defined and the participants have a good eye on 'the big picture'. Keeping a broad view requires communication, that 'lots of talking' you noticed in your current environment. You and the rest of the team have to talk to each other so you keep that situational awareness going. If you're creating interface X so that Fred can do function Y, but Fred decides he needs function Z instead, the only way you know about it is if you talk to Fred on a regular basis. I've seen too many projects that started with a big up-front design and then everyone went off and coded. Sometime later, usually close to the delivery date, someone noticed that they needed to integrate the bits and pieces. That's when the recriminations and the all-nighters start. People start making shim logic to glue pieces together, features get dropped, you get the idea. It's a mess that rarely ends with a completely successful product. This doesn't have to be a formal process. I think it's better if it isn't. It's a matter of having the attitude that you've got to remember the global implications of how you're implementing your responsibilities. When you're doing something that could affect other people, check it out.
Software Zen:
delete this;Your points are well taken. I did work on one great product team where the members were well matched experience and temperament wise. And the manager was a great architect and manager, a rare find. In that environment communication/collaboration was quite natural.
-
In principle nothing is wrong with talking. But I've found that much of the talking hasn't been productive or rich with ideas. And don't get me started on the "team" metaphor. Overall I haven't found teams to be managed well, with the most vocal member many times being the most valued, whether or not their actions were best for the application. Note that I changed my post to read "which tends to translate in my mind to just lots of unproductive talking.".
Old Ed wrote:
Overall I haven't found teams to be managed well, with the most vocal member many times being the most valued, whether or not their actions were best for the application.
Again, I have probably been lucky but my experience is very different. Maybe because I have worked mostly for software companies where most managers come from development. In my experience activities such as code reviews, engineering presentations and mentoring of junior developers benefit the overall performance of a group (avoiding the word "team" here).
-
In principle nothing is wrong with talking. But I've found that much of the talking hasn't been productive or rich with ideas. And don't get me started on the "team" metaphor. Overall I haven't found teams to be managed well, with the most vocal member many times being the most valued, whether or not their actions were best for the application. Note that I changed my post to read "which tends to translate in my mind to just lots of unproductive talking.".
My first computer had 64K of Magnetic Core Memory, which was about the size of a modern desktop computer. Collaboration is what allows my piece of code to work with someone else's piece of code. Even with comprehensive documentation (often a waste of time), it comes down to reading the code I interface with and talking to the other developer about how his software works in the overall project's scheme. I gotta make my stuff work with everyone else's so I gotta talk to them about it. When I do a complete standalone software product, including the installation, I don't have to collaborate with anyone, and that is kind of nice sometimes. Other than getting stuff to work together, leave me alone and let me get my work done.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill
-
In principle nothing is wrong with talking. But I've found that much of the talking hasn't been productive or rich with ideas. And don't get me started on the "team" metaphor. Overall I haven't found teams to be managed well, with the most vocal member many times being the most valued, whether or not their actions were best for the application. Note that I changed my post to read "which tends to translate in my mind to just lots of unproductive talking.".
Old Ed wrote:
And don't get me started on the "team" metaphor. Overall I haven't found teams to be managed well, with the most vocal member many times being the most valued, whether or not their actions were best for the application.
Reminds me of a previous job where the manager told me that I was going to be the "Team Leader." To his horror I informed him that we didn't have real teams. When he calmed down he asked me why I thought that. To which I replied that real teams have cheerleaders that wear skimpy uniforms. If I could choose the cheerleaders and their uniforms, then I'd be team leader, otherwise no thanks. Never did get the cheerleader babes, but at least I didn't have to write the reports on the team meetings I slept through.
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
-
I have a feeling your sig explains your view even better than your post :-D.
Software Zen:
delete this;The same feeling here. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I'm an old timer and personally I think collaboration of any kind is an excellent way to bring the level of productivity and inventiveness down to the level of the worst member of the collaborators.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
Welcome in the CP's Memorable Quotes page [^]. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Welcome in the CP's Memorable Quotes page [^]. :-D
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
I'm an old timer and personally I think collaboration of any kind is an excellent way to bring the level of productivity and inventiveness down to the level of the worst member of the collaborators.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
Could be worse. The intelligence of a committee is equal to the IQ of the dumbest member of the committee divided by the square of the number of members. Suddenly govt antics begin to make sense. :-D
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
Hello all, I've been a programmer for over 30 years, enjoy it, and am constantly assessing industry trends. One trend that has gone over my head is that of collaboration. Even when working in teams, I've always had an area of specialization and collaborated very little outside of initial design meetings, pre-launch debugging, and problem resolution. The environment I currently work in stresses collaboration, which tends to translate in my mind to just lots of unproductive talking. I'd like to hear from programmers across the spectrum, from recent college grads to old timers, on how collaboration works (or not) for you, its pros and cons, etc. Thank you...
modified on Wednesday, January 14, 2009 1:21 PM
I've been in the industry as long as you have, and I agree. Back in the day, we had to think for ourselves and learn to think outside the box. It became almost as natural as breathing. Enter today's youngsters that didn't start programming for a living until long after our 20th year in the business. Someone somewhere thought "extreme programming" was more productive, but I disagree. It might be for less experienced developers, but for us old guys, it certainly isn't.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
In principle nothing is wrong with talking. But I've found that much of the talking hasn't been productive or rich with ideas. And don't get me started on the "team" metaphor. Overall I haven't found teams to be managed well, with the most vocal member many times being the most valued, whether or not their actions were best for the application. Note that I changed my post to read "which tends to translate in my mind to just lots of unproductive talking.".
My experience is that a collaborationist should be shot ;P Really, collaboration works best when the team is small enough to fit in one room (even if that is a 12 man room) so that everyone can pretty much hear what is going on with everyone else. Also, it requires that peoples egos are wrapped up in quality production, not in personal production.
Silver member by constant and unflinching longevity.
-
Hello all, I've been a programmer for over 30 years, enjoy it, and am constantly assessing industry trends. One trend that has gone over my head is that of collaboration. Even when working in teams, I've always had an area of specialization and collaborated very little outside of initial design meetings, pre-launch debugging, and problem resolution. The environment I currently work in stresses collaboration, which tends to translate in my mind to just lots of unproductive talking. I'd like to hear from programmers across the spectrum, from recent college grads to old timers, on how collaboration works (or not) for you, its pros and cons, etc. Thank you...
modified on Wednesday, January 14, 2009 1:21 PM
Constant collaboration for business applications which are usually ill defined up-front. Collaboration for up-front design phases on non-business / well defined applications.
Todd Smith
-
Hello all, I've been a programmer for over 30 years, enjoy it, and am constantly assessing industry trends. One trend that has gone over my head is that of collaboration. Even when working in teams, I've always had an area of specialization and collaborated very little outside of initial design meetings, pre-launch debugging, and problem resolution. The environment I currently work in stresses collaboration, which tends to translate in my mind to just lots of unproductive talking. I'd like to hear from programmers across the spectrum, from recent college grads to old timers, on how collaboration works (or not) for you, its pros and cons, etc. Thank you...
modified on Wednesday, January 14, 2009 1:21 PM
I'm an old boy too - and I 'invented' collaborative programming back in '84. Two programmers working together on one source - it was important that both programmers were of high caliber and reasonably evenly matched (otherwise it's either tutoring or the blind leading the bland). The software produced was the most bug-free and stable that the company had ever produced - and it was on time and under budget. Pros: No 'silly' errors - the typist has a second pair of eyes, so questions like 'shouldn't that be less than or equal rather than just less than' get asked - and therefore thought about - early on. Well thought out logic at every stage. 'wouldn't it be more efficient to do it like this' or 'Hey - and if we did it like this, then we could re-use this here' Opportunity to keep 'in the zone' - for example one programmer can go off to enter some test data, write some support routines, look up some help etc. while the other continues to program in the main flow. When done in short stints this speeds things up as it doesn't break the flow. Learning opportunities - even v. experienced folk (like myself) can learn from others - even when it is just down to keyboard shortcuts, clever ways of doing simple things etc. Big Bus Safety - if one gets hit by a big bus, the other is fully competent to continue the task. Cons: Selling it to management - the assumption that it will take twice as long / cost twice as much. Matching programmers well - Both I think need to be experienced and reasonably evenly matched. Temperaments are important - programmers need to be more than willing to share their knowledge One note - I think it is important to note that this is in collaboration and PROGRAMMING - analysis, design etc. is another kettle of fish altogther
If I knew then what I know today, then I'd know the same now as I did then - then what would be the point? .\\axxx (That's an 'M')
-
I've been in the industry as long as you have, and I agree. Back in the day, we had to think for ourselves and learn to think outside the box. It became almost as natural as breathing. Enter today's youngsters that didn't start programming for a living until long after our 20th year in the business. Someone somewhere thought "extreme programming" was more productive, but I disagree. It might be for less experienced developers, but for us old guys, it certainly isn't.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001John Simmons / outlaw programmer wrote:
but for us old guys, it certainly isn't.
Isn't that just because we're grumpy old b*stards that don't want to talk to anyone face to face if we can avoid it?
If I knew then what I know today, then I'd know the same now as I did then - then what would be the point? .\\axxx (That's an 'M')
-
I'm an old timer and personally I think collaboration of any kind is an excellent way to bring the level of productivity and inventiveness down to the level of the worst member of the collaborators.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
John C wrote:
I'm an old timer and personally I think collaboration of any kind is an excellent way to bring the level of productivity and inventiveness down to the level of the worst member of the collaborators.
2 years ago, i would have said you were off your rocker.... collaboration could work. Then we hired again.... :doh: so here is a 5....
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb) John Andrew Holmes "It is well to remember that the entire universe, with one trifling exception, is composed of others."
-
Hello all, I've been a programmer for over 30 years, enjoy it, and am constantly assessing industry trends. One trend that has gone over my head is that of collaboration. Even when working in teams, I've always had an area of specialization and collaborated very little outside of initial design meetings, pre-launch debugging, and problem resolution. The environment I currently work in stresses collaboration, which tends to translate in my mind to just lots of unproductive talking. I'd like to hear from programmers across the spectrum, from recent college grads to old timers, on how collaboration works (or not) for you, its pros and cons, etc. Thank you...
modified on Wednesday, January 14, 2009 1:21 PM
I have 25 years of programming experiance and I've tried collaborating with other people on various projects. I've found (apparently) I don't think like most other people and I take different directions than a lot of people. While I'm collaborating with others, typically I have to do a lot of explaining, a lot of convincing, a lot of talking. It takes a lot of time. But when I just code it up, with comments of course, and let other's peer review it later, they typically say, "Hey, that's cool way of doing it!" and it takes about 1/3 the time as when I'm "Collaborating".
-
Hello all, I've been a programmer for over 30 years, enjoy it, and am constantly assessing industry trends. One trend that has gone over my head is that of collaboration. Even when working in teams, I've always had an area of specialization and collaborated very little outside of initial design meetings, pre-launch debugging, and problem resolution. The environment I currently work in stresses collaboration, which tends to translate in my mind to just lots of unproductive talking. I'd like to hear from programmers across the spectrum, from recent college grads to old timers, on how collaboration works (or not) for you, its pros and cons, etc. Thank you...
modified on Wednesday, January 14, 2009 1:21 PM
It's not collaboration that is the problem, I find - it's enforcement of collaboration at all points of the process. I'm a better analyst and algorthmist than most of the programmers I know, thus enforced collaboration means to me that I spend far too much time explaining, more than once, exactly what I'm doing and where I'm going with it. On the other hand, if I'm not certain of what I'm doing and where I'm going with it, I seek collaboration. Thus, I truly enjoy anything that makes collaboration-when-I-need-it easy and effective. One scenario where I've always advocated collaboration is in deadline coding, where I've found pair programming to be much more effective than solo programming - i's get dotted and t's get crossed more reliably. Another is when your design is complete and you're about to get to coding. Here is where one NEEDS to justify your design to someone else, because if you can't, it is probably a bad design. At all points, though, you need to collaborate with someone whose skills range from just slightly less than yours to much better than yours. This, unfortunately, is where enforced collaboration often throws crowbars into the gears of project progress. To put perspective on this, I'm a 20-year developer who has worked in DOS, Unix, Windows, and Web, for development groups ranging from two to two thousand, in just about every role in the SDLC.
-
I'm an old timer and personally I think collaboration of any kind is an excellent way to bring the level of productivity and inventiveness down to the level of the worst member of the collaborators.
"It's so simple to be wise. Just think of something stupid to say and then don't say it." -Sam Levenson
LOL .. How brilliantly put. I'm kind of the same mind. I do collaborate with a couple of independant developers (like myself) on a few projects with mostly rewarding results. But there are times when I have to say (or would like to say) .. can you all just sod off and let me do this so that it gets done and someone gets paid. A balancing act!
The only thing unpredictable about me is just how predictable I'm going to be.
-
I have been lucky to work with good and smart people during most of my career, and it has been a pleasure collaborating with them. To me programming is a team sport, and I always liked basketabll players like Magic and Bird who could bring the quality of the whole team up.
Old Ed wrote:
which tends to translate in my mind to just lots of talking.
What's wrong with talking :) ?
Nemanja Trifunovic wrote:
What's wrong with talking Smile ?
From my experience its because poeple have opinions. Ewwww ;P
The only thing unpredictable about me is just how predictable I'm going to be.