Teamwork
-
I was at my six year old's hockey game this weekend and for the first time that I've seen it this year, there were two passes and a score. Smoothly executed, well timed, using their teammates as they should. Unfortunately my son was on the bench when that happened, but at 6 1/2, he's a little young, playing on a 7-8 team.
But it was neat to see someone take the puck in their zone, a couple skates and then a pass up the boards to a teammate. Usually they continue to skate until a defender is right on them, but this was an early pass. Then only another 20 feet covered before the forward made a pass to the center, hitting the other forward in stride. More often than not, a forward will just keep skating, attempting to score themselves, or maybe pass at the last second if there is a defender there.
I bring it up, not because any of you care about hockey, especially 6 year old hockey, but because of the teamwork it made me think about. Another Dad and I were talking about it since most kids don't use their teammates. We talked about when you learn it and how you go about teaching it. To me, you learn it in sports when things get competitive and the coach sits you for not learning it. but in life it's different.
Most people that write software seem to have an aversion to using their teammates. Especially in the Windows world, though Linux isn't immune. Look at all the "like" projects on SoundForge. It seems that everyone wants to invent or develop things themselves instead of using someone else's work. Even the components and plug ins that I see used are really just "plugged" in for a specific feature, not built into the work being built.
And I think that is partly a problem from learning programming. We too often go it alone, or work as individuals instead of as a team. There is so much synergy to be gained by spending some time working in a team and learning to use what others write as well as give of yourselves, meshing things together to make something better than either of you could do together.
Development has often been an individual effort, trying to make a bunch of "units" into a system. We could all do better by taking a few minutes to work more in a team environment, let go of some ego, and make things better for the entire group.
Steve Jones
-
Steve,
You are right, there is so much lost energy from programmers writing the same code that someone else just wrote but there are very good reasons for it. The biggest reason is probably, I say probably because I can only speak for myself with certainty, because most really good programmers cant find teammates who can write code that is as good as their own or that integrates with the "art" side of their development. I have spent 30 years as a consultant and you would not believe the trash that I have had to fix and/or work with that was passed off as being good enough to put into production. In my lifetime, I have met maybe 5 programmers that I thought were really good enough to write code that I could trust or that I thought looked like it belonged in my project. I have a friend (one of the few "trustees") who recently went to work for a major package delivery service (which I should not name of course but they are probably the biggest). One of their lead, lead mind you, dba's and developers creates his sql statements using the wizard in SQL Querry Analyzer, then copies the generated code to his application. Can you imagine that ... hundreds of millions of packages being delivered, billed for, tracked, routed, archived ... and the code driving all this is so inefficient because one of the main guys just doesn't get it .... would you want to trust something from this guy in your project ??? I think not.
THe second big reason is that most of us dont want to risk our reputations on someone elses code or plugin that leads us down a path to destruction. Product "A" touts that it will do "X" and you need "X" so rather than write, you buy ... uh-oh .... the next version will do it right ...
and you just structured you design around them doing it right the first time ...
Gosh, it seems this subject must have pushed my favorite button .. sorry .. think I'll stroll down to Pensacola bay and watch the pelicans land, it so much more entertaining than trying to figure out how to make someone elses code act right ...
-
Del - what you say reads funny but rings SO TRUE...
Going by the old adage - "If you want to see something well done, DO IT YOURSELF!" - it's tough to work with developers who write shoddy code (100 lines instead of 15; no standardised variable names; no indentation; no comments; no concept of modularity et al.....) - the one that drove me particulary crazy was this guy who was supremely case insensitive..eg: "Dim InTnOfRoWS as integer".... this, after being told a ZILLION TIMES to PAY ATTENTION - a senior developer who had been coding for over 20 years...his applications worked beautifully till you looked at all the stuff swept under the carpet....
I'm with Del on this one....
**ASCII stupid question, get a stupid ANSI !!!** -
That really hits home for me too. I agree with Del (above). I have a short list of developers that I actually consider savvy enough to build solid code and an immense list of developers that I [know] from experience code horribly. The "good" coders are the ones that take pride in their work. It's a challenge, it's an art and it's a source of pride when it's done.
From direct experience, I can say that working with a team of solid developers is a welcome treat for me and I firmly believe the level of my teammates motivates, inspires, challenges and elevates my performance also. Face it: when you work with turkeys it's frustrating. Most project timelines don't include "training the developers to do it right" as a task.
-
Good points, and I agree that's the case in many places. But are you sure you're code is better than someone elses?
I think this is valid in some cases, there are definitely some superstars on the short list in many companies. But often I think that we just don't want to "team" together with someone else and get things more synergized. Maybe it's the other person that won't team with you, or maybe it's you.
Still, I'd hope if people complained about your code or you found it wasn't being used, that you might look to improve what you do and work more closely with others.
-
Re: maybe it's you.
ouch.
-
Got to look in the mirror. I know it's been me in the past a few times
-
There are always reasons to code something up yourself. Perhaps whatever is available doesn't have quite the right features. Or perhaps you want to learn how to do it yourself. It's not always about a lack of teamwork. Teamwork is great, but at least in my case, the only way I can REALLY understand something is by working through it on my own. Therefore, in many cases I won't ask for help as quickly as someone else might; I'd rather hit my head against the wall a few times and challenge myself. In the end, I think it makes me a more valuable, well-rounded member of the team.
--
Adam Machanic
whoisactive -
A few random thoughts:
1) When teamwork works successfully, I have found that "the whole is greater than the sum of the parts". That is, the team will produce more than each of the individuals working alone can produce.
2) I have been an n-tier Windows and Web applications developer, working as a consultant for many different kinds of companies for the past 11 years. I have seen very few situations in the past 11 years where successful teamwork was in place. From my experience, here is how I percenived successful teamwork was facilitated: (a) regular team meetings, so that everyone knew what everyone else was doing, and team members would have a chance to provide helpful feedback to other team members on issues and problems individuals were having on their code; (b) an environment that was cooperative, not competitive; and (c) to facilitate the developement process (normally after a developer creates and then unit tests a component), peer review of a developer's component by another team member.
--Jeff
-
I make no claims of being a developer let alone a good one but here's something I ran across a while ago on another site (TechRepublic) that helps keep me in check and think in terms of team. I keep a copy posted in my cube just to remind me every so often.
"The Ten Commandments of egoless programming"
1. Understand and accept that you will make mistakes.
2. Your are not your code.
3. No matter how much karate you know, someone else will always know more.
4. Don't rewrite other programmers' code without consultation.
5. Treat people who know less than you with respect, deference and patience.
6. The only constant in the world is change.
7. The only true authority stems from knowledge, not from position.
8. Fight for what you believe but gracefully accept defeat.
9. Don't be "the guy in the room"
10. Critique code instead of people -- be kind to the coder, not to the code.
I work as a team with our office webmaster developing apps for our intranet. He does the HTML, some VBS, and the artistry of the site. I handle the servers, database, T-SQL, and some minor programming. We don't fully understand each other's world but we have done some good work together IMHO, and do manage to teach each other a thing or two occasionally, as long as I stay teachable.
Steven
-
I think the problem is that as you gain seniority you get promoted and assigned to lead teams without anyone giving any advice or training on how to go about it. Leading a team is a very different skill to coding.
Having a single developer work on something is very different from having multiple developers work on something. A project manager needs to define exactly who does what and where the boundaries are for each person.
A good tech spec is a must for larger developments although the time necessary to produce documentation is often regarded as "contigency" within the project plan.
I have worked on 2 may be 3 projects that had a good tech spec and loads where the spec started off OK then degraded as deadlines became ever more apparent. In the end shortcutting the tech spec phase resulted in lost time later on so it really was a false economy.
-
"In the end shortcutting the tech spec phase resulted in lost time later on so it really was a false economy".......
EVERYBODY (at least most people with common sense) knows this but so few ever implement it! Ultimately everything's driven by the people who hold the pursestrings and quality is always compromised!
C'est la vie, I guess!
**ASCII stupid question, get a stupid ANSI !!!**
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply