How can a solo programmer become better at working in a group?

Question

Solo programmers can practice good programming habits that will help them with group work (good commenting, coding styles, basic communication skills, version control system use) but there are some skills you rarely develop or bother dealing with until you're working on a single project with several people.

What are some of the habits you learned once you started working with other people for the first time, that aided you in group work, but would have been a hindrance when working alone?

Or, for a counterpoint, do you think such habits even exist? Has everything you've learned from team programming helped you, even when you're programming alone?

Answer 1

Being tolerant of others' coding style is always a big first step. Developers are always very fond of their own approach.

As for getting better... Obviously open-source projects offer a chance to learn to play nicely in a group.

Answer 2

The most valuable lesson I've learned with respect to this is..

"He who seeks knowledge begins with humbleness."

Answer 3

• Be willing to accept criticism
• When you see something that's not done the way you'd prefer, try to think of a good reason why it might be there instead of gratifying the immediate impulse to denigrate it in favor of your way
• Get out of the habit of writing code (and comments - you are commenting, right?) as if you're making notes to yourself. You want to go for clarity over cleverness
• When you need utility/library type routines, use what's already there instead of creating a new one of your own. When you see projects with 4 different StringUtility classes you know all the developers are going off in their own directions and not cooperating well.

Answer 4

The skills you need for working with other programmers are primarily the same ones you need for working with managers, end users, and business analysts--good communication, listening, and recognition of the people around you as fellow professionals with a valid perspective.

Answer 5

It's better to err on the side of being positive when it comes to talking about another team member's code. This is especially so if they're within earshot.

Acknowledge the good. We all like to have our work complemented from time to time.

Don't let the perfect be the enemy of the good.

Egoless programming is tough so try to ignore as much as you possibly can. Nobody loves having their work trashed so when it comes to suggestions or pointing out mistakes less is more. If it's algorithmically sound then more often than note I'll let almost everything else slide (that's the goal anyway).

Even developers that don't much care about improvement have something to contribute to the team.

Keep in mind that developers come in all stripes. Some with formal training to spare, some totally self-taught, most somewhere in between. Just because someone didn't study CS that doesn't mean they're not bright.

There's a great feeling of working on a team and seeing its members, including yourself, improve over time.

Holy smokes this got long. If I manage to stick to 3 or 4 of these on any given day it's a good day :)

Answer 6

Having a daily stand up meeting really improved the communication skills of my team members. It made them more open to the work of other, understand why and how they are doing it that way. Explaining what you are doing and being challenge on a regular basis is a good way to accept criticism.

Answer 7

I always liked the proverbs:

The reason you have two ears and one mouth: You need to listen twice as much as you talk.

or

Even a fool is thought wise if he keeps silent, and discerning if he holds his tongue.

I'm amazed at how many people interrupt and are impatient when working with others, effectively telling their coworkers they are unimportant.

Answer 8

My biggest problem going from single development to a group was to not work on the same files at the same time. I use subversion, but when you check in and there is a conflict because someone else also modified the file you checked out, that was a learning experience.

Coming up with rules of who can modified which files, and when to fix bugs right away, or discuss them and other changes. You don't want to have a junior programmer modifying the core libraries.

Working alone you could change the API, knowing it would break a few things, but you could fix them. Working in a group, you don't know if your change will break someone else's code.