Communication Within Programming Teams?

aldheorte asks: "If you are a developer you have probably, over your time on various development projects, seen lots of projects with really awful code and some projects with really good code. You may also have observed that sometimes the projects with really awful code have a few excellent developers involved, while projects with only intermediate or mediocre developers are able to maintain a pretty good quality of code overall. The lucky few may have even seen that legendary situation of great developers and great code. I have always been mystified by this apparent discrepancy and I think a recent article on CSS development in a team environment may hit the nail on the head: 'The quality of code generated by a team rarely owes as much to the skill of the individual members as it does to the level of communication between them.' I am interested in the experience of others here on Slashdot. Have you observed this discrepancy between individual talent and a project's quality of code as well? How much of the success or failure of communication is based on the members of the team themselves as opposed to the management of the team, especially with respect to allowed time and deadlines?"

Comments

Tech Leads as information conduits

[dmorin]

One thing I've noticed on successful teams is that the best senior technical people are not those that put their head down and code like maniacs, nor are they the ones who stand in front of the whiteboard with the circles and the arrows. They're the ones that display an almost mystical ability to simply know everything that is going on in the team, and be able to redirect at will in order to optimize what's going on.

Part of this is being the listening board for other members of the team, which comes naturally as a result of being a senior member. But it also comes from always having one's ears open, without having to force your way into every conversation and say "What's this? What are we talking about?"

You'll know if you're doing it right because the world around you ends up feeling like you're in the middle of a giant coincidence. You hear two people talking about something and you say "Hey, I just saw a tutorial on that in so-n-so's blog" or the guy in the cube next to you says to anybody that's listening about a problem he's having with JSP and you shout back "Check with Ashish, he told me he was looking into something similar a couple weeks ago..."

Let stuff arrange itself in the background of your brain so that you can call it back when you need it. And then bring it up as needed, don't shove it down anybody's throats. You see an article that says Struts is out and Tapestry is in, you don't walk to everybody's cube and say "Hey, did you hear that Tapestry is the new thing?" Forward a link to the article to the team. The ones that want to read it, will. But then a month or two later when the boss asks whether you should go to Struts, then is the time to say "I hear Tapestry might be the better choice..."

Once upon a time I used to argue that hacking is understanding of the resources available to you, and creative application of those resources toward problem solving. Everything that you take in, be it what you did, read or heard, counts as "resources available to you."

Yes

[aristus]

I had the pleasure of working under a truly stellar programmer. Through braindead bosses and vauge requirements he built a system that worked *and* scaled 100:1. Comments were rare but almost unecessary, because all of it was astonishingly consistent. Many a time I was working on the code, wishing for a lib that would... oh, wait! It's already written. 500%? absolutely. He had to be replaced by 5, count 'em FIVE people.

Re:Define good code

[titzandkunt]

Good code, in no particular order:

Fulfills the specs, no crashes, leaks, etc etc etc, obviously.

Reuses, and is reusable, where sensible (making a religion out of reuse is as bad as no reuse IMHO)

Is comprehensible to the rest of the team (but maybe not on first inspection)

Is documented (Javadoc stylee, for preference!)

Sparse, to the point where nothing can be taken out (without deteriorating into an obfuscated C entry. The rest of the team still have to understand it)

Just one man's opinion.

T&K.