Best practices for working with multiple programmers

Question

I think most programmers prefer to work solo on projects, even when it's not feasible. I prefer to work alone, even outside of programming projects. When working with other developers, I typically find that

• I don't like their formatting or conventions (such as variable or method names)
• I don't have a good understanding of how the code they wrote works, which I would have if I wrote it myself
• I think there is a better or more efficient way to implement something they wrote

What are the best ways to overcome these issues and any other similar team issues for a project with 4-5 programmers?

Answer 1

There is only one way of overcoming those issues. It is namely "Communication". The problems you describe are due to you programmers not speaking to each other. If you had discussed what would be the best or most efficient way of solving a task it would be implemented in a way that you want. Further you could agree on formatting and conventions.

For the understanding their code part you need to have weekly code reviews where you discuss everyones code. Then you can ask questions while they present their work and this helps tremendously with increasing everyones quality of code as well.

Answer 2

I love working with a team. The difficulty is that to work effectively with a team, the team members all have to actually work together, not just all work separately on the same project.

You need to discuss things like why you prefer one coding convention over another, and then all agree on one set of conventions, whether they're your personal favorites or not. Whatever they are, you'll get used to them, and appreciate the consistency.

You should be reviewing and critiquing each other's code. Actually, you should probably be programming in pairs most of the time, but I doubt you'll believe me on that, so just review each others' code. No piece of code should be considered "done" until another programmer has reviewed it and made sure that it will be understandable to the next person who needs to maintain it.

Look for excuses talk to each other and ask questions as you are coding. If you find yourself trying to choose between 2 or more ways to attack a problem, even if you think you know the likely best answer, get a sanity check from one of the other developers. You'll both learn something from the conversation, and you'll gain more of a shared concept of how the code is being put together.

Have a brief meeting every day, so everyone can say what they've been doing and how that's going. That way, everyone will have a better sense of the status of all the bits of work that are going on and how it's being approached.

Answer 3

You don't own the code--as a group you can choose coding conventions or not. You won't always get your way, just learn to adapt.

You'll never feel as comfortable with other peoples code. In XP this is the reason the push pair programming. But normally the best way (as with everything else) is to dig in and learn it.

If you have a more efficient or better code (Readable is WAY more important than efficient--see the previous point) then you should discuss it with them.

This is a career and you don't own what you do. You will have to work with many people, get used to it or be so good that you can do it all your self and fund your own projects.

It's a career, not fun--if your job was fixing roofs in the middle of the summer and they tell you to do it in a way you don't like because it's easier to do it that way as a crew, you just do it. Period.

Answer 4

Ask them "why", but politely. Programmers are usually more than happy to expound their reasoning, and unless the answer is "It's the way I've always done it," you're likely to learn something useful. For example the difference between "good" and "bad" Hungarian notation, the virtues of different naming conventions, and why the chosen algorithm is good enough for the task at hand.

Answer 5

I just have some thoughts. Most of the other answers seem to have covered the communication aspect of this problem fairly well, but I would like to address each bullet point you made with a thought or 2 of my own:

I don't like their formatting or conventions (such as variable or method names)

This is a conceit that you can't really afford. There are probably 20 people out there who don't like your formatting or conventions. If you were not part of the process in deciding these things, then you need to get over it and learn how to adapt. If you are part of the process (or can be in the future), then bring your concerns up to the other developers. Don't just complain, though. Have solutions/alternatives already mapped out and ready to go.

I don't have a good understanding of how the code they wrote works, which I would have if I wrote it myself

No you wouldn't. If you are making this claim then you haven't worked in a high-paced changing environment very much. I've got code that I wrote 6 months ago that I can't understand just by glancing at it. If it wasn't for the fact that it was written with a couple of my personal quirks I wouldn't even really know it was mine. It may require more effort to re-engineer someone else's work, but make no mistake, you will be re-engineering it to understand it later on no matter who wrote it.

I think there is a better or more efficient way to implement something they wrote

Awesome. Every team loves improvements and efficiency. Bring it up to your fellow developers. If there is a senior developer or architect appointed above you, let him know. Share your ideas with the team openly and freely. Be prepared to accept others' ideas as well though. I find a lot of people say the same things you're saying here, but their real meaning is "My way is better and you can all just suck it. Do it my way or you're all pudding heads." Don't be that guy. Be as willing to change as you're expecting other people to be.

Answer 6

I have thought about these questions myself for awhile now. I am a team lead and am working with 2 other programmers. One of the programmers has a very similar style to myself - not the same, but close enough. I don't feel it warrants any changes on his part. What is the point of starting something for the sake of different tabbing conventions or variable names.

The other developer is a c programmer (we are vb.net programmers working on a .net project). He writes vb code as if it were c code (I suppose if the roles were reversed, we would write c code as if it were vb). I had some issues with this. But after I thought about it for awhile. The issues I had were really just an uncomfortable feeling that strange looking code gave me. There was really nothing wrong with his code. His code is clean and works very well. Besides, the code will be abstracted behind the class interface that he exposes to the rest of the program. So in the end the coding style doesn't really matter for us. As long as the program is correct and the comments are reasonable. We are all smart enough (at least I hope), that debugging shouldn't be that difficult.

Now it would be a different story if he was coding in c# and we were coding in vb.net. We could still manage, but it would be more difficult.

Personally I think it is much more important that the individual team members use a coding convention that they are happy and comfortable with. This will mean that they are productively coding instead of referring to some style guide that tells them how many tabs they need to indent a function.

That doesn't mean that they are free to do as they wish with the application use cases or requirements - they are set by the customers.

Answer 7

Oh Please! Coding standards are like abortion arguments: everyone has one (except me, I have no real opinion on abortion other than if you don't want one, don't have it), everyone thinks theirs is the absolute correct one, and everyone thinks everyone else's stinks.

I use different methods because I've found they're easier to read. For example, a test block in PHP I'll write like this:

if (condition) {
  statements;
} [optional else or elseif]

But if I write a block in Pascal I'll do this:

if (condition)
  begin

  end;

It depends on the language, for me it's easier to read this way for both. But if someone wants to put the { on the line after the if in PHP I don't really have a problem.

Answer 8

While I can understand the frustration associated with having "foreign" code, there are two opportunity's for you to mature with this "obstacle"

1. Every developer has to learn to go through the "curly brace war", and by that I mean finding a way to get a common coding standard. Learning to clearly articulate why you prefer certain techniques, but more importantly learning to listen to why someone else has a different view. Then learn to lay some of yours down for the good of the team / project.

2. What however will be of much greater value for you in the long run will be the learning to read other peoples code. For this one you just have to push through it and don't avoid it. You might even find that you learn a lot.

Answer 9

I believe that the bigger a team gets, the more important unit testing becomes.

• Make sure the code you write yourself is covered by unit tests.
• Try to convince the other team members to write tests.

Living with (your own and other's) code is easier when you have tests that cover the code. This is true even for code that you don't like.

Answer 10

The best answer is to find a team whose thought process matches your own, so you don't have to compromise.

A realistic answer is to deal with it as best you can. If it's just a matter of different code style (e.g. same line braces vs. next line) it's not a big deal, although I understand how it's frustrating if people aren't following the guidelines for the language they're using. If it's something like utterly nonsensical coding standards that make zero sense (e.g. Hungarian notation where it's not needed, SoMeWeIrDnAmInGsTyLe, all variables must be no more than 8 characters long, etc.) then try to change it, because it's obvious that the person writing the code has no clue or just cargo-culting with what was there before instead of being intelligent enough to want to improve it.

Answer 11

First off, adapt my coding style re: white space. Long ago, some clown wrote a joke article on best practices giving code examples with like 12 full tabs of white space everywhere he could; making code impossible to read without a 12 foot wide screen or in .0001 font size. A lot of programmers assumed it was credible and started doing it - even though it was really obviously not good practice. It drives me crazy. Come on guys, I say, you're smarter than that. 50% or more white space on the 240 column page doesn't make any sense. Put the first curly brace on the same line as the function or class signature (with a space or two, not a tab or two in between). Use 3 spaces to indent for code levels (5 if you have a partially blind team member). Then use a blank line here and there in the code to put things in smaller logical blocks.

Here's another example of something that's bone-headed. I'll first tell you this doesn't come from an inexperienced half-wit. It's in some very good code by a guy who was able to get a very advanced technique working while most of the rest of the world is still scratching their heads about it. This is what's frustrating to me. Why are good programmers so bone-headed about formatting their code?

    for (Iterator<Byte> iterator = collection.iterator(); iterator
            .hasNext();) {
        byteArray[i++] = iterator.next();
    }

Now just look at the format of the for condition. If you actually think about it, isn't that an entirely illogical place to put a line break? For one, I had plenty of space to see the entire for ... { on one line. (Luckily, this guy doesn't use multiple tabs to indent.) But if he absolutely couldn't live without breaking it up, why there in the middle of a function spec? There's a perfectly good delimiter just before that - the semi-colon - that would have made more sense as a break point. My vote is to put the whole condition and the opening { (that goes with the for) on the same line. He also ends well - easy to match the closing brace with the "for" that opened. (Some people - and tools (Is that redundant?) - like to put that in strange places too.)

Second - make note of the focus of each programmers expertise and if there's a significant difference, be sure that's reflected in which part of the code each programmer works on. An expert in industrial control in robotics, an engineer who primarily works on the complex mathematical bits, and the guy with the CS degree who impresses himself with totally obscure code construction (the less understandable, the more sophisticated it seems, right?) are all going to write code differently. Where there are these significant differences, break the work up so that each individual strength matches the job.

When there aren't such differences, agree on coding style and in any case - code review, code review, code review. Quite frankly, I've been through a lot of sloppy spaghetti code in my life (12 times down the line in debugging and changes by the maintenance group, or the result of cock-eyed integration) and was well on my way to being an expert on the code after 2 minutes of talking to the last guy who worked on it. (Side note: There is in fact, a point at which it's better to rewrite the code than to continue adapting.)

Personally, I prefer to work at home on my own as well. I've never met a programmer who prefers or works better in a cubical surrounded by lots of other programmers, discussions, and interruptions. But you have to get used to working in a team, and that means taking the time to get together and discuss (not fight) what you're doing. That's actually part of the job - it really is. Much better to accept it and do it systematically, efficiently, and effectively. And while we're at it - it's also part of the job to spend time transferring knowledge and information to the people who write the documentation (some of which you may need to write yourself). And when you're experienced enough to up your level of responsibility, you may even find yourself chatting more often with managers and people in marketing, etc.

Coding alone is a hobby. Professional software engineering is a multi-faceted occupation.