working in a team

keith73

I just needed to vent, hope y'all don't mind.

I've been working for my current employer for a little over a year now and things are decent. I've been involved in several large-scale php projects, one of which I was responsible for designing and managing from the ground up. I've had to work with about 6 different programmers, a graphics desinger and some marketing and project management people. It's been a pleasure working with almost all of them, except 1 particular programmer. Even the marketing dept doesn't drive me as nuts as this one programmer.

it could be a long story, but I dont' want to bore you with details. short story is that me and this co-worker worked on a major revision of our company's main cash cow, a web application that interacts with monitoring devices that work over a network or the web. For my part I manage the mysql database, some perl scripts that run in cron jobs and much of the back-end admin interface. my colleague works with these devices and the web interfaces to them as he is more familiar with how the devices work. on the last revision we wanted to simplify our predecessors code so that making changes would be easier. we were supposed to code with the future in mind. I did, but apparently my colleague did not. it's now 6 months later and more features are being added to the app. my colleague has a penchant for over-complicating issues, to the point that he won't listen to anyone elses suggestions and just decides that his way is best and everyone else is wrong.

Ever worked with one of these people? Someone who claims to do things "the right way" but thinks that the right way is just whatever way makes less work for them. We had some heated arguments over various aspects of the project 6 months ago. Those arguments are cropping up again as we re-visit the project once more.

I don't claim to be perfect in my coding and realize that my way may not always be the best way, but if someone has an opinion on my methdologies or coding practices, I'm willing to listen.

One thing I can't stand is when others dont respect my point of view. case in point, 8 months ago, when approaching the project, I outlined all the things I thought we should do and not do. coding practices, naming conventions, using functions as much as possible, using include files where static values are defined in constants, etc.
when my colleague didn't offer any opinions on this outline, I figured it was cool with him. we both went about our assigned parts of the project, and lo and behold, he did not follow a single thing I outlined. He could have at least told me what he didn't agree with and how he thought it should be done.

now we're re-visitng the app and the old arguments are resurfacing. this is going to be a fun 2 months.

I'd like to hear others' stories of dealing with coworkers in a project team and how you dealt with conflicts of opinions.

keith

Elizabeth

Keith,
I've done a lot of teamwork in my time and I've come to realize that there are a few people out there who aren't happy unless they are making someone else miserable 😃

There are those who feel the need to control everything because it makes them feel important and covers up their own insecurities. They will do the opposite of what "should" be done just for spite. I have a few clients like that at the moment, but as they are clients as opposed to co-workers, I have to suck it up and just make fun of them behind their back, ha ha. 😃.

Many years ago I bought a book entitled "How to Deal with Difficult People" and it really helped me out at the time. At least it might help you from banging your head against the wall for the next 2 months. And if it makes you feel any better, at least you're not married to the guy... have sympathy for his wife/girlfriend, she has to live with him 24/7.

hth a little-
-Elizabeth

ahundiak

The classical development approach:
1. Get together and decides who does what
2. Split apart and go do your part
3. Hook everything together.

A key feature of the above approach is that it usually fails.

You might want to look at some articles on eXtreme Programing (note: these folks use the term extreme before it became cool).

Some key XP points:
1. All code is looked at by at least two people.
2. Set short term (week or two) goals and ensure the software actually meets the goals.

Finally, keep an open mind. Sometimes these 'difficult' people really do have some good ideas.

vaska

hire are third party consultant to help manage the way things are done...the money you spend will likely be worth it...save time, energy and headaches...v

keith73

Elizabeth:
I spent 4 years dealing with clients as well, I know what that's like. I deal with idiots on our helpdesk for one of the sites all the time now. people who should not be allowed near a computer. ugghh.

ahundiak:

1. Get together and decides who does what
2. Split apart and go do your part
3. Hook everything together.

A key feature of the above approach is that it usually fails.

we did that on the first revision. problem is everything works fine after hooking them together. But now, with changes needed to be made, my co-workers lack of foresight in his coding will lead to longer hours and if something doesn't work, it makes us both look bad because management doesn't care who didn't do what, they just want us both to have the thing working.

vaska:
a 3rd party isn't an option. the company wouldn't spend the money and would question why we couldn't get things to work ourselves.

Thanks for the input folks.

keith

AstroTeg

Peer to peer code reviews could be handy (say maybe once a week or at each milestone or slightly before a milestone). In the one shop I was in, I was hoping this would move forward with this because we had 6 developers using 6 different coding styles and rules. I think with reviewing your peer's code could help you help them or spark new/better ideas and approaches. But your mileage may vary...

It depends on if you feel this is a fight worth spending energy on. If it is, its a lot easier to persuade someone if you present the facts as to why a process, method, or approach must be followed. Will it sink in? Maybe. Maybe not. A manager might be able to help if you present the problem and some possible solutions (managers don't like to hear problems, but if you give them some solutions, they'll tend to be more motivated).

Otherwise, if its truely a problem, then it may be time to brush up the resume and start sending it out... Just depends on how you want to deal with the situations.

keith73

Originally posted by AstroTeg
Peer to peer code reviews could be handy (say maybe once a week or at each milestone or slightly before a milestone). In the one shop I was in, I was hoping this would move forward with this because we had 6 developers using 6 different coding styles and rules. I think with reviewing your peer's code could help you help them or spark new/better ideas and approaches. But your mileage may vary...

I wouldn't have a problem with peer-to-peer, unfortunately, I've tried that before. when someone gives me constructive criticism of my code, I listen and I go over their comments point by point. when I do the same with this person, his philosophy is, "no, that's the wrong way. that's stupid." If I dare ask why, I'm told, "because it just is".

Otherwise, if its truely a problem, then it may be time to brush up the resume and start sending it out... Just depends on how you want to deal with the situations.

that's not an option. with a (soon-to-be) 2-year old and another kid on the way, and the fact that php jobs are hard to come by with all the M$-technology based jobs I keep seeing listed. It isn't worth leaving over the differences of opinion with 1 person.

keith

LordShryku

Leave? Why? Push him out the door 😃

I think I've been reading too much BOFH

rpanning

I agree with AstroTeg. You should either confront him, to a manager or to him, or get out. If he doesn't change his ways of thinking things will go sour. And he may bring you down with him. So, fix it or leave it. My 5 cents... 🙂

Weedpacket

I learnt some time ago the value of a Pearl Harbour file. Basically keep an ongoing record of what decisions were made when, and what your opinions at the time were. Keeping copies of relevant mail helps for validation, as does the usual source-control and backup and logging facilities that the "paperless office" is so good at.

If and when things turn sour, and there's a risk of you being pulled down, it's part of your defence.

In an ideal world such things are unnecessary, of course. But in this case, your colleague sounds like anything but.

Of course, if things really do go seriously pear-shaped (like, company-threateningly pear-shaped), and your file doesn't show that you tried hard enough to warn company bosses (or is missing crucial events), you could find yourself being asked some uncomfortable questions about what you were doing about the problem at the time (apart from documenting the Decline & Fall of the project). So keeping such a file behooves you to exercise due diligence on your own activities as well.

vaska

vaska:
a 3rd party isn't an option. the company wouldn't spend the money and would question why we couldn't get things to work ourselves.

interesting. whenever i tell my clients that i'm going to hire this person or that person to help with this or that...they ask me why...ask for a fee breakdown on things...and thank me for taking care of them...

and with some clients...i don't even ask...i just take care of it (after years of hard earned trust)...

if the project is really as substantial as you say it is, your client will understand just why you are pulling in a consultant to work with you for maybe 4 hours a week or so...maybe even less after the initial visit...

speaking from experience...Weedies (the champion of breakfasts?) idea is a must...a very good habit...i keep a log of all my hours (billed and unbilled) and then write plenty of comments along side everything...

i seem to have a problem with writing too many bland comments...i'll stop now...v

Merve

Reminds of group projects in school....argh! Code the most important parts together, go over everything together twice a week, say...and don't let this get in the way of your ability to code.