How to be successful in a development team

I just read an article located here: http://blog.james-carr.org/2008/08/18/how-to-not-fit-in-on-a-development-team/

And he has some valid points but most of them I take exception.  I’m going to rebut some of his points.

FTA, a few ways to “not fit in on the team”:

1. Make an assumption that you are smarter than your teammates

   This is good advice. Mainly because you can tell who’s an idiot after working with their code for a couple of minutes. Don’t assume outright they’re an idiot. Let them prove otherwise when you work on their code.

2. Do what the customer asks without speaking to them

   I really don’t get how you can do something the customer asks without speaking with them, but I’m going to assume that you mean just blindly do what they tell you to do. I’ll agree with that statement, but you have to understand that when you’re designing an application for a customer they quite often know a lot about what they want, and you shouldn’t dismiss it out of hand. However, having said that, you still need to talk to the customer about their expectations. This is why you try to figure out what they want in the site and not “do what they ask without speaking to them”. Your job is to find that solution they didn’t know they had.

3. Spend time alone rewriting other team members code, and then showing them how much better it is, with an emphasis that “YOUR” way is better

   Totally agree. It’s a waste of your time and theirs. If you think something is wrong, tell them and get them to fix it or convince you otherwise, or sit down and help them refactor. If you’re wrong you’ll learn something, if they’re wrong you’ll look smart and they’ll learn something.

4. Throw a fit if things aren’t going your way. If that line of code that got committed doesn’t meet your satisfaction, let the team know the world will soon end

   You sure as hell better throw a fit if a line of code doesn’t follow guidelines. I don’t expect anyone in my office to commit code that doesn’t follow our coding style guidelines - they’re there for a reason. I follow them, I expect others to follow them.

5. Make sure you go directly to management for questions about anything without involving the team.. management knows everything after all, your team doesn’t

   This should be: don’t go to directly to management without discussing it with the annoying coworker first. Management is there for one thing only, and that’s to manage. Look up the definition of the word. We’re here to code, not pussy foot around about personal baggage.

6. When you’re pairing, your peer is just excess baggage. Give them a few seconds to try something, but remind them that their idea is flawed and quickly take the keyboard from them… that’ll learn em!

   I also agree with this completely. Discussion is the key to extremely solid coding practices and everyone should be working together.

Also FTA, a few ways “to fit in on the team”, some of which I also take exception:

1. You got great ideas, but your peers do too. Remember teamwork is more about collaboration, not about who’s right. Find a middle ground.

   (Emphasis mine) I liked this whole statement up until that last part. “Find a middle ground”???!! No freaking way. There is a best solution to a programming problem, and it’s often for a variety of different reasons. Your job is to find what you think is the best solution and present it to the team. They will tell you why a solution is not optimal if it isn’t, and you’ll be able to refute it or agree with them and find a new solution. Don’t settle for middle ground! If you’re too stubborn to accede and admit that your solution might not be the best, you’re probably in the wrong field.

2. Make customers a part of your team. Customers might submit a story or ask you to do something, but they want[sic] doesn’t always match what they need! So always try to work with them to meet their needs the best way possible.

   Already talked about this above, I agree completely.

3. When you pair program, take turns as navigator and driver. And don’t backseat drive! Remember: it’s pair programming, not “just sit there and watch what I type!”

   I also agree with this one - however, I’m not sold on the pair programming thing. It may be nice for some really quick hack and slash bug fixing, but for general development you should sit down, think about it, and plan it through

4. Be sociable… this is definitely the number one skill one must hone. You really need to be relaxed and take it easy… this isn’t some battlefield and attempts at dominance are always frowned on.

   True! Take dominance in a foosball table!

5. If you see some code that could be improved, invite someone to join you in a session refactoring it … it’s not that they wrote the code wrong or bad, but simply their design can be improved upon

   I also agree. I think I touched upon this above.

6. Let’s face it.. your teammates work hard and do great jobs… make sure you recognize their accomplishments and praise them for their hard work. Praise always makes someone happy.

   Praise is all the more rewarding when it’s deserved. Only praise good work, and only praise code and the coders who deserve it.

Well that’s pretty much it. I think this is an example of someone removing the ego from programming. This is a step to mediocre programming at best. You need to be brilliant and feel brilliant in order to find the brilliant solutions.

Tags: php, programming