Project Explanation, A True Tragedy

Question

Guys, I need your help.

In our company, we are to discuss every detail of a finished project with our project manager, phase by phase, code by code, output by output. He is brilliant, arrogant, and a complete asshole.

Every time I am done with my module/task it has been approved by QA pain-makers, it's the "time" to meet the manager. I know what I did is worth praise, but I find it so hard to calm myself down while explaining my part.

Every time he indicates a possible bug of a possible situation, my brain cells die and I can barely come up with a good answer to that. When I get out of his room, all the solutions float before my eyes.

What do you suggest?

N.B. I am very confident in my programming skill.

EDIT:

If the project manager always thinks he's better than you, how can you defend considering he's your boss? And he believes he is right, and obviously you have to be wrong! You don't mess with the "boss". Now, do you?

Answer 1

Change your organization, or change your organization.

Answer 2

1. Take a notebook.
2. Record his comments.
3. Thank him for his comments.
4. Any time you can answer the point, do so.
5. Any time you can't, tell him you'll get back to him.
6. Write them up as review feedback.

Chances are, some of the things he's asked about you won't need to change anything because your design already copes with them. Chances are some of them you will need to address. Review feedback is great. He should be commenting on the design not on you as a person. You need to leave your ego out of it and take it as a chance to improve your design.

Answer 3

Interesting question - not sure of the relevance to Stackoverflow.

However, one thing you said there I found interesting. You referred to QA as 'pain makers'. Don't think of them as pain makers, think of them as helping you save face before other people, such as the project manager or your customers get to see the results of your code.

It may be that the project manager is trying to help. It sounds like he also needs to learn to listen as well, but that's a totally different skill.

Answer 4

It sounds a little like a code review to me, although a little backwards maybe?

Approaching it from the code review point, it took me a while to realize that code reviews aren't personal attacks. They're a good chance to learn from people that have been there before, and a good opportunity for people to find the bugs that may exist, or style rules that have been broken etc.

Without knowing the extent of the discussions, your time-spent in the company etc, it's really hard for me to say for sure that the guy is just being a jerk, if the code review bit doesn't fit the situation, then it may be time to change positions.

Answer 5

Well frankly, you are not confident at all. But that's OK.
What you can do is to write down all the points that he says, so everything wont float when you leave the room.
Second, if you were confident, you could also defend your own code better. Yes maybe he's right, but you can also be right, there are more ways to Rome. Sometimes, the better programming solution leads to decrease of performance to name 1 reason.
Also, create Unit tests. Unit tests help to make you write better code, and you know better why you made certain choices.

Good luck.

Answer 6

Four things:

1. Prepare yourself for the questions he'll likely ask. Even memorize the answers. That'll serve you to do a last review of the design/code by yourself.
2. When in front of the guy picture yourself as an actor: it's not you who's talking to the guy, it's this character that is self confident and is not intimidated by assholes. Take acting lessons, if possible.
3. If a solution to a problem that made noise in the meeting and is relevant occurs to you afterwards, tell him about it. Better late than never.
4. If there really is a mistake or a problem, admit it readily, but don't let it get personal.

Although you saying that people are assholes and pain makers might indicate you feel like a cowboy coder that hates process, that by itself is a thing to review. Of course I have too little data to know for sure, just an impression.

Answer 7

Breathe.

It sounds like you're experiencing anxiety from meeting with your boss that is causing you to become discombobulated. This is an anxiety-based problem, and like many anxiety-based problems, the solution is similar; breathe.

Calm, deep breathing is a great way to clear out the anxiety and let yourself relax, and let the stress (and it's associated confusion) slip away from you. Practice just breathing deeply (and quietly) by yourself; and next time in your meeting, focus on listening to your boss, of course, but also focus on keeping your breathing steady, and deep. Don't let your anxieties break your rhythm; don't let them get you out of sorts.

Of course, other problem-solving solutions like taking notes and asking to get back to your boss later with more comprehensive solutions are also good, but the true value of those things is similar to the breathing; they give you confidence that you will be able to deal with his questions in a rational manner, and that you will be able to present your ideas in a way that makes your boss recognize your skills.

You see, it's all about confidence; and since you're in a situation that you feel out of control in, you lose your confidence, and therefore have a hard time articulating your skills and solutions. Breathing can help you regain your composure, and your confidence, as can promising to get back to your boss (thereby taking the immediate pressure off), etc. Just try to remember that you have every right to be confident and proud of the work that you've done; don't let the power imbalance shake you.

Answer 8

I had a similar experience, I had a code review with my manager and panel of other developers. They threw criticism from all sides and I was very out numbered, and it was a very stressful situation.

I emailed them afterwards, and said I wasn't going through that again, and that in future could they please do submit reviews via email so that I would have time to respond accurately.

So, tell your manager straight. You'd be happy to explain your solution if he would be prepared to concentrate on understanding it without criticism, and that you'd be prepared to address any potential problems he can identify via email.

Maybe if you could get other collegues to agree, you could do it petition style. Explain how his style of review is not as productive as it could be if he did it your way. Write a letter, put all your names on it and deliver it so its anonymous as to who it came from (unlike an email that'd have your name on it).

Good luck!

Answer 9

Perhaps if as you are doing the project you make notes about what part you did and how long it took, this may be helpful in going through the review. It may be helpful to have various historic tidbits ready.

Why do you believe what you did is worth praise? Is this true every time? Do you really want a, "Good job!" for every little thing you do? I'm not saying what you did was or wasn't praise worthy, just to think a little about the context along with how many others would get similar remarks if he gave our praise too easily, e.g. if you fix a 1 line code bug is that really a big deal?

Answer 10

Others have some helpful answers. I'll just add what I think is sort of simple and obvious: You say that after you leave the meeting, solutions and answers float into your mind. Have you tried just collecting those thoughts (i.e. writing them down, organizing them), and then communicating them to your boss at a later time? That could be by e-mail, or phone, or face to face with notes in front of you.

If both of you can be expected to act professionally, then having open lines of communication and feedback (in both directions) should be commonplace and expected. If there was some great idea, or some important point about your design or implementation that wasn't brought up during a meeting, it's to the company's benefit that you bring it to his attention, so the project as a whole avails of a chance for improvement.

If you feel like you are not comfortable approaching him with followup discussion, then that's an issue unto itself. You could consider broaching this topic with him personally. If he honestly cares about managing his employees right, he should be open to hearing about things that impede good communication and a positive atmosphere in the development team.

Answer 11

http://www.google.com/search?q=bully+boss

Answer 12

I've had problems with bosses who cut me off and talk over me. As though they're so important and busy that they don't have time to let me finish a sentence. It's very irritating. I speak very well and I don't ramble, but somehow they feel the need to cut me off. Maybe this applies to your situation, or maybe your boss has other habits that fluster you.

I've had some success talking openly with them, and naming the action. Something like this: "I'm ready to answer your questions, but I'm finding it difficult when you interrupt me. I'm concerned that you're not getting my full explanation when you do that. Can we change the style of our dialogue?"

I put emphasis in that example to illustrate naming the action, but don't raise your voice or emphasize it in speech too much. Make sure you're calm, confident, sincere, and friendly when you make these sorts of comments.

Constructive feedback should be useful to the recipient. Your boss is trying to give you feedback to make your software better, and you should accept it in that spirit. Likewise, you can give him constructive feedback and he should accept it.

One more suggestion: read the book "Coping With Difficult People" by Robert Bramson.

Answer 13

Leave a copy of this on his desk:

http://www.amazon.com/Handbook-Walkthroughs-Inspections-Technical-Reviews/dp/0932633196

You need to relax.

Additionally, it sounds like you work in a horrible place. Either your view of it is skewed or indeed it is not a place where I would ever want to work. Have you overblown the situation out of proportion? If not then you either need to learn how to deal with it and be ok with it, go to a different company or make changes there.

Answer 14

For two rational people having a case of character incompatibility, @Hamish Smith's solution is an excellent one.

For a power-tripping boss, the only solution is to resign.

And, lastly, in normal situations Project Manager is not your boss. He schedules your time, usually based on your own estimates and priorities supplied to him by the real boss. But the only thing he/she can grade is how well your estimates of difficulty track the actual time spent. He/she is certainly not qualified to grade your code. That's what QA and Technical Lead is for.