How to deal with idiots in your office

[Npl]

Hmmm.. I really hate my work nowadays... Im not really the type to do well with conflicts and if I have to explain the some thing 3 times I typically lose my patience.

Currently I work on a project and some conflicts with the guy at charge are looming, really he is not at charge but just successfully taught everyone that its pointless to argue since his answer are just of the sort of "Im genius, got certificates, you ask too many questions (or to others than myself: you are not competent in OO)".

Well, he clearly doesnt have much competence in what the project requires, just he has somehow managed to get basically free reign by throwing some elaborate words of success at the right people or something similar. I had some conflicts early but since then we have some clear separation of our work. So there are now the people he could accuse of not understanding object orientation and those he could push into other areas of the project (1 at the count).

The separation will soon break, and I will either have to adopt to his garbage or start a conflict again. I will try to remain calm and "review" the lack of common sense of his work, but I`m sure this will turn ugly fast...
The leaders have little technical knowledge, and the rest basically has given up arguing and watches the project run into a wall while doing work in a way they know it cant fit the requirements.

 

[Grall]

Talk to this guy's boss, or is he (also) cone-haired?

 

[Npl]

he made a solid illusion that any criticism on him is unfounded, because he is an OO Guru. Somehow this resonated well with the chiefs

 

[Grall]

So you need to collect some evidence and dispel the illusion. Or don't his bosses know what he is doing, and thus can't tell that his methods are (alledgedly ) flawed?

 

[UniversalTruth]

I really hate my work nowadays

If you really hate it, then leave it. I think you will feel much better free from problems. I like when people are problems free. I don't like when people like to have ones and do attract them by various weird ways

 

[Npl]

Grall: yeah thats basically it, but this will turn ugly really fast. Its hard to explain technical stuff to guys who arent familiar with it, and AFAIK there already was such a collision some time ago and the guy still reigns. I am in a better position for such complaints than the previous employee though.. just dont know how to keep a cool head in discussions.

UniversalTruth: I dont hate all of it, just some aspects. There is no job without its downsides, and without job there still is that money problem I havent solved for the rest of my life. I wouldnt be a happy bum.

 

[Alexko]

Kill them. Kill them all.

 

[NRP]

Just make sure the stuff you're responsible for gets done. If the overall project still fails, eventually the powers that be will see through this guy's BS. The important thing is to control your emotions and not let this guy's actions control them for you. Much easier said than done, I know.

Good luck. If it weren't for assholes, work would be splendid. I guess that's why they have to pay you though.

 

[Npl]

its the project leader heads that will be the ones rolling, that guy will just walk away unscathed - even more so if I dont place criticism now.
I just could sit there and watch the train-wreck happening, but I don`t feel comfortable doing that.

 

[Grall]

Maybe it is the project leader's head that needs to roll - if the leader allows a team member to essentially poison/sabotage the work effort with bad ideas and implementations, then that project leader isn't a very good leader. The next project leader might be more observant; although you should still relay your concerns about this guy to your bosses of course.

 

[Florin]

Don't worry about it, accept that you can't change it and it's not your responsibility.

Stay calm, avoid setting up another conflict, be nice to everyone, even the idiot.

The only one who is hurt when you're walking around angry or upset is yourself.

 

[Albuquerque]

I agree with Grall.

Your first step is to voice your concerns with the project leader. Build a case with very specific examples, support it with documentation, and present it to the best of your abilities. At that point, you're done -- follow the leader as prescribed, and carry out the project to the best of your own abilities. Ensure that anything that you personally own or can be held accountable for is complete and accurate.

The best you can do is ensure that all the parts you're driving are the parts that do not leave the rails. If the whole thing crashes, there should be no doubt of your full support and engagement with the project.

This person may get out unscathed this time, but people with that sort of ego eventually pay their dues. Some people bounce between jobs for their entire lives, leaving a path of destruction. There's truly nothing you can do about it; when he leaves (or is fired) from this job, he will likely do the same at their next job. His own internal rationalization will be something akin to "They all hated how smart I was and blamed stuff on me that totally wasn't my doing."

 

[vjPiedPiper]

Do you have coding standards? Do you do code reviews - as a group?

I would suggest you implement a set of coding standards at least for your code, and then try and implement code reviews, at first with more than 1 person reviewing. Perhaps start with the more junior and less troublesome employee's, once they start to see the benefit and improved code, then try and foist them onto the troublemaker.

Plus code reviews will improve the quality of code and communication amongst the entire team, it is well recognized practice and would be very hard for the troublemaker to argue against,

 

[KimB]

Do you have coding standards? Do you do code reviews - as a group?

I would suggest you implement a set of coding standards at least for your code, and then try and implement code reviews, at first with more than 1 person reviewing. Perhaps start with the more junior and less troublesome employee's, once they start to see the benefit and improved code, then try and foist them onto the troublemaker.

Plus code reviews will improve the quality of code and communication amongst the entire team, it is well recognized practice and would be very hard for the troublemaker to argue against,

I do have to say, code reviews are a fantastic process. I'm not sure how feasible it would be to implement them if they aren't being done, but they're a really good way to improve the overall quality of the codebase, as well as catch bugs early (dramatically reducing debugging time).

Unit tests are also a tremendous help.

 

[Npl]

we have tons of standards and formal requirements, the first are rather individually interpreted (some of them are written by people with little knowledge aswell) and the latter rarely executed due to time-pressure.
The thing thats totally lacking however is a runtime-concept for the whole project.

I talked to the boss Monday and wrote down a few key points, sure the project leader will talk to me the next days.

 

[imaxx]

Unit tests are also a tremendous help.

...what exactly can you develop without test and ensure commercial quality?

Anyway, if they have tests and they pass, his mess should at least work (mostly).

 

[Npl]

well sure, but if theres eg. no concept how to communicate between threads and everything is just supposed to figure out miraculously how to work together, integration and system test are going to be really funny with random deadlocks and state corruption.
So its working and tested code, but not a fitting solution.

Gonna see how this pans out, right now there likely wont be any action until the next milestone

 

[KimB]

...what exactly can you develop without test and ensure commercial quality?

Well, this is part of the point: the code has to be tested during development anyway, just for the purpose of getting the software to function correctly, so why not formalize and regularize the concept, and make it so that the tests are re-run every time a code change is performed?

Anyway, if they have tests and they pass, his mess should at least work (mostly).

Well, that's only one issue. There are also issues of direction. For instance, as Npl notes, there is no runtime concept for the whole project. That's a bad situation. You need to have a good overall direction for the project, or else it'll just be a mishmash of each programmer's individual concept that doesn't do anything well.