Whats it like writing software with a team?

[merlin bar]

Just wondering what its like to work with a team of software developers.
What kind of pressure are you as an individual under to produce code. Are you expected to know everything ( NIO, SQL, JWhateverItIsYourNotFamiliarWith )off the top of your head?
Also, how do opportunities to move up in a company arise, given that you are writing as a group.

[Tara Bhattacharjee]

Opportunities to move up simply do not exist after about 5 years in the software unless you want to switch to some kind of management. In my group only one guy is 45ish. EVery one else is in early-late 30's.
SW programmer job is too much above the starting level ( salary wise) for other kinds of jobs and too low below the executive/manager type of jobs. May be someone else can help to state this better.

[Mark Herschberg]

Originally posted by merlin bar:
Just wondering what its like to work with a team of software developers.
What kind of pressure are you as an individual under to produce code. Are you expected to know everything ( NIO, SQL, JWhateverItIsYourNotFamiliarWith )off the top of your head?
Also, how do opportunities to move up in a company arise, given that you are writing as a group.

Less than 10% of my career has been spent on solo projects. Everything else has been done as a team. Most software is written by teams, not individuals. (It's unfortunate that most colleges aren't group based.)
You're as much "pressue" as an individual. It really varied by how the team works. In many teams, the work is divided up, and each developer is responsibile for his own work. At times you work with others, getting input, talking about how to do things, doing code reviews. Some methodologies (such as XP), have you do pair programming.
Think of it this way, when you do a project solo, you come up with a schedule and follow it. The same is true of a team project, it's just that some task requires talking to others, especially during integration (and you better remember to schedule time for it!).
You're not expected to know everything. In fact, that's a benefit of working in a team. In areas where you're weak, you can ask a team member for help.
One caveat, the team incentives need to be set up correctly. I just finished a great book called "Finding Time" by Leslie Perlow. She described how individuals were rewarded for their own tasks, even at the expense of the team. It resulted in some people being both very demanding of other's time, and not be helpful when they had the key information. The "team players" did poorly, because they helped others at the expense of their own work. But that is a problem with the corporate culture and project management, not team based work in general.
Promotional opportunities are as normal. You managers should be watching your accomplishments and promote you as necessary.
(Truth be told, I think far too many people get promoted far too quickly and are overly concered with titles.)

--Mark

[shay Aluko]

Originally posted by merlin bar:
Just wondering what its like to work with a team of software developers.
What kind of pressure are you as an individual under to produce code. Are you expected to know everything ( NIO, SQL, JWhateverItIsYourNotFamiliarWith )off the top of your head?
Also, how do opportunities to move up in a company arise, given that you are writing as a group.

I don't know about your particular situation but i would expect that as your experience and skill level grows you can progress from being a developer who write code modules to someone who writes small subsystems to leading a small team--some companies have different titles for each stage e.g team-lead, architect, distinguished engineer etc...

[Al Newman]

One caveat, the team incentives need to be set up correctly. I just finished a great book called "Finding Time" by Leslie Perlow. She described how individuals were rewarded for their own tasks, even at the expense of the team. It resulted in some people being both very demanding of other's time, and not be helpful when they had the key information. The "team players" did poorly, because they helped others at the expense of their own work. But that is a problem with the corporate culture and project management, not team based work in general.

When interviewing for a job always ask about review policy. I've been at two companies which had highly 'scientific' state-of-the-art systems which put each employee in precise rank order 1-500.
Complete disaster. The 'team-players' helped out as normal but found information hard to come by from the 'smart-guys' who had figured out that information closely held translates directly into promotion and reward. The most successful people at these places were absolutely shameless credit-grabbers.
One chap managed to pole-vault his way into two major promotions in the space of 6 months by taking credit for other's work. He put a young 'senior' developer into hospital for a month with a nervous breakdown by landing him with an unimplementable 'architecture' and then disappearing when the project started going sour.
I worked with an 'architect' who was too busy to help. Busy circulating emails explaining why all the things which were going wrong weren't his fault but rather that of the legion of defective underlings which the company had (unaccountably) managed to hire. Well I didn't really expect help from this clown by then but the shiv in the back was a bit much I thought.
The direct result is that most team-players go elsewhere very quickly. In both cases the company went down the tubes soon after.
What we should be looking for are team-based or percentage-based reward schemes. Rewards distributed to successful teams or to tranches of successful people (such as the top 20 or 30%). Both approaches have their drawbacks, particularly the team-based reward one. But they don't turn the organization into a collection of individual predators in a Hobbesian tooth n' claw world. Either approach rewards win-win collaboration which is what you want to see.
When I go to an interview I'm looking for a few warts to show. I find obvious imperfection reassuring. If a manager or a company looks too good to be true during the interview be very careful. The chances are they're only good at looking perfect and will be a hellhole to work in.
[ December 08, 2003: Message edited by: Alfred Neumann ]

[Rufus BugleWeed]

My sister-in-law has a magnet on her refrigerator - A team effort is a whole buch of people doing something my way. I've never seen a team only hierachies. Generally forward moving people worry more about making the boss happy than solving the cutomer's problems.
The project often fails, but still they move ahead. Even if it means going on to another company to repeat.

[Al Newman]

Originally posted by Rufus BugleWeed:
My sister-in-law has a magnet on her refrigerator - A team effort is a whole buch of people doing something my way. I've never seen a team only hierachies. Generally forward moving people worry more about making the boss happy than solving the cutomer's problems.
The project often fails, but still they move ahead. Even if it means going on to another company to repeat.

This is true but also an uncharitable way of putting it. An effective team requires leadership, which involves 'doing things my way' to some extent. A team isn't a democracy, of course it's a heirarchy. Possibly even an enlightened despotism. A good team is an effectively-run heirarchy led by a person who is effective at communicating goals and getting buy-in from the other members of the team as well as adopting and using the ideas of others.
A dysfunctional team is marked by bad leadership or no leadership.