[swalsh]

Kind of reminds me of a story from today. I have about a 70 page design document, laying out exactly how a new system i'm building will work. I've built something very similar in the past at a previous company, so this design is coming from a few years of learning what doesn't work.

As I was trying to explain some of my, well non conventional ideas, another coworker pokes his head over the cube, and calls the design crap. This of course is nothing new, its almost a game for this particular engineer. In the end, I walked away trying to avoid the conversation. It felt emotional though, and frankly hurt my confidence (while probably inflating his own)

It kind of made me think of the phrase "no one ever got fired for choosing IBM" I could have chosen the obvious design, and gone forward. No one would have debated it. However I've done that in the past, and I've seen the terrible problems that come from it. My new design is an attempt to avoid those problems. The attitude really pisses me off though, and I find it extremely counter productive.

[ser0]

I think you can use the co-worker to your advantage. One thing we must all learn is how to defend and justify our decisions. This can either be done before or after implementation, which is what I believe the post is talking about. That is, people criticising others' implementation decisions with limited context. Most of us have read stories of Gates or Jobs dressing down employees that are unprepared. You could consult your co-worker before presenting in the future; assuming you can develop your relationship with him to the point where there is no malice in such an interaction.

On the other hand, I do also recognise that some people just like to mess with others. In such circumstances, if there are no other political concerns, I would simply ask the person the come up with an alternative solution, then argue the alternative on its merits vs. what you have designed. Given your 70 pages of documentation, a simple pros vs cons list that takes into account goals of the project for various timeframes and scales should result in a clear winner. Or should both designs be of similar value, then there is little point in changing your documentation anyway.