Just a general question. If you had a coworker of equal rank (lead) who refused to use standard C++ facilities (STL, Boost, etc...) how would you approach it? His feeling is: A) He owns his portion of the code and can do whatever he wants, regardless of any risk and B) He prefers low-level C and Win32 code in C++ because he wants the people working under him to be extremely aware of underlying pinnings. He's also banned any higher level libraries (COM, MFC, ATL) for his group. I see this as being a large negative for his team and is terrible for teamwork and team building. How would you proceed? I can elevate the issue, but I'd rather resolve things peacefully. Thanks.

Tough situation. Are you each in charge of separate teams? If so I'd just focus on using these higher level tools to build better, more stable software faster. Hopefully someone will notice your productivity and you can attribute the difference to your embracing a more modern C++ style.

Quote:Original post by Rydinare
I see this as being a large negative for his team and is terrible for teamwork and team building.

How so? I could see saying it has a negative impact on their ability to deliver software but their ability to work as a team seems to be a stretch. Second are you graded on lines of code produced if so he may be ahead in "productivity". What are your design standards? Do they dictate this kind of thing? If he is the team lead for his team then what he says goes for his team more or less.

Personally I would give him anybody on my team who prefers that kind of thing and take anybody from his who doesn't and thank god I don't work for him.

Quote:Original post by Rydinare
Just a general question. If you had a coworker of equal rank (lead) who refused to use standard C++ facilities (STL, Boost, etc...) how would you approach it? His feeling is: A) He owns his portion of the code and can do whatever he wants, regardless of any risk and B) He prefers low-level C and Win32 code in C++ because he wants the people working under him to be extremely aware of underlying pinnings.

Don't you have some kind of common coding standards you follow? I mean, either you decide on a team level that you avoid these libraries, in which case he's doing the right thing, or you decide that you use them. And then I'd expect everyone on the team to follow that convention.

If the team, or your project manager, or your bosses or the company or whatever decides on a standard, he'd better follow it. If he refuses to, you don't have many options other than to elevate the issue.

But of course, if you don't have a convention that says "Use proper, modern C++, including Boost", you can't really blame him for not doing it.
You can try to educate him, of course. If I had to guess, I'd say he probably doesn't know C++ well enough to be comfortable with STL/Boost. And if that's the case, helping him learn the language better might be all it takes.

However, regardless of that, I'd say it's a serious problems if he "feels that he owns the code and can do whatever he wants".
Not much of a team player, is he?

Some background behind it is that I'm new to the team. We're working on the same project, however, he has a small group on the project that he's been leading and will continue to lead. Neither one of us can overrule the other, was how it has been phrased to me. There's definitely been some feeling that his teamwork is poor. Upon joining the team, I was told that I need to be very involved in reviewing the processes and standards being used -- there are a few small documents, which are pretty minimal. If I elevate it, I'm sure I will have management support behind me, but I'm worried about creating a negative situation.

Finally, I don't blame him for not using it in the past; he probably wasn't aware of the true benefits. Blaming him for not using it going forward once he's made aware of the benefits is going to happen. He's already shown a lot of resistance to even discussing it.

Set up a private meeting with him - just the two of you, nobody else. You want a chance to openly and thoroughly, albeit respectfully, discuss his reservations concerning standard and widely accepted libraries without it becoming an "issue." The key is that you don't want to "convince" him to agree with you; you want to hear his reasoning, and then see if there isn't a compromise that can be reached, or if you can't allay his fears.

Most importantly, don't expect him to capitulate fully, no matter how right you may be. It's probably more realistic to aim for a series of gradual changes, where he accepts the uses of, say, <algorithm> first and then, seeing the benefits of that, begins to embrace more standard library elements.

Good luck!

I would say that if the file extension is .cpp then you should be using the standard libraries or maybe some of your own.
If the file extension is .c then you don't have a choice.

The ego and bad leadership skills aside. When coming into a project that is already established the worst thing you can do is to start "criticizing" the code, decisions, etc... that have already been done and made. It's the past! No sense in dwelling on it. If he's the lead and that is the process he's established then when in Rome do as the Romans do.

Now you can slowly start to turn it around by becoming a advocate for a new process and involving in the whole team. If you can show value in your new process by being a "teacher" rather than a "criticizer" you'll strengthen your position and weaken his. Make sure to try not to devalue any of the work he's done or currently doing, it's default process. Use good neutral words as I feel, I think, We could try, etc... If you don't it'll just breed contempt, put him/her on the defensive, and propagate the negativity. Think "come to the light. Just go to the light man...it's safe, warm, and not bad".

A good leader is a leader who will listen to all their teammates/subordinates and defer to the idea that best fits the given situation. There typically isn't just one smart person on the team. More than often leading is just managing personalities, ideas, schedules, and expectations rather than being the sole individual contributor (ie. best coder, best this, best that) on a project. My current management really suffer from this problem. They = Smart whereas, You = Stupid. It happens...but if you can get them to think they came up with the idea you'll eventually get what you want. Just don't forget to make sure to take some credit while giving your leadership credit.

Anyway...my 2 cents from 4 years of working in a negative, destructive, and generally not very fun environment. I'd leave but the money is too damn good. Though...I have some new job prospects that are equal or greater in pay. Woohoo...