Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

When I'm passionate about something (particularly programming) I find it really easy come off like the guy Peter G. was talking about in Dealing with the “programming blowhard”.

So what techniques do you use to

1) Identify when you are indeed a blowhard?

2) Communicate something "important" without seeming self important?

Specific example help like When giving criticism ask "have you considered what happens when XXX changes" instead of "never take dependencies on implementation details"

When giving advice "showing with code is better than talking" or use a reference.

share|improve this question

closed as primarily opinion-based by MichaelT, Snowman, Bart van Ingen Schenau, gnat, durron597 Aug 21 at 14:45

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

Must... not... make... Arrested Development... joke. –  StuperUser Jan 11 '12 at 17:51

7 Answers 7

  1. Assume it's true. Because recognizing it in hindsight doesn't help.

  2. Don't criticize without concrete examples of why the technique you're criticizing will cause problems. If your advice is ignored, just move on, accepting that you may not hold the only right answer... or a right answer at all.

And above all, stay out of religious wars. If someone wants your advice, they'll ask for it and be glad you could spare the time to share. Otherwise, keep your opinions to yourself. Whatever's bugging you, it's probably not as important as you think it is.

share|improve this answer
Excellent advice. –  Fishtoaster Sep 14 '10 at 4:58
I see that you've focused on the "criticizing blowhard" the "advice blowhard" exists too. –  Conrad Frix Sep 14 '10 at 5:38
+1: The most important lesson I learned in my career as a programmer was "just because it's my idea, doesn't mean it's the best idea". Also, good enough may not be perfect, but it is - by definition - good enough –  Binary Worrier Sep 14 '10 at 9:24

Try to talk less than you listen.

share|improve this answer
+1 wise advice in most situations! –  Walter Sep 14 '10 at 11:39
...but slightly introvert answer also. –  Henrik Feb 12 '11 at 22:57
Listening before talking almost always pays off. Talking too soon = jumping to conclusions. It's taken me 20 years to learn to shut the f@#$ up and I still don't do it very well. Know the value though. –  quickly_now Feb 13 '11 at 1:09
Actually, it's a corollary of one of the Franklin-Covey effective habits: "Seek first to understand, then be understood." –  Peter K. Feb 13 '11 at 1:18

Give people the benefit of doubt by assuming they know what they are doing. Then if you feel like something's wrong with what they're doing you'll be cautious (that is- polite about it) because since they know what they're doing it's probably you who misunderstood something.

If you have no stake in the project then don't give advice unless you feel there's something very wrong or you are asked to. If you have a stake in the project talk facts. Then if the other person is irrational it'll be obvious to everybody.

share|improve this answer

Talk more slowly. Pause now and again. But don't replace silence with Um, Err or Y'Know.

There's a tendency amongst some knowledgeable technical people to talk fast and excitedly. This comes across as assuming that everyone around you can keep up, it also does not give much of a chance of having a conversation (things have moved on so fast).

Stopping and pausing before talking allows others to have their say (and by listening more you might learn something). And talking a little slower gives the impression that you are thinking and have thought about what you are saying. It's also easier for the conversation to ebb and flow back and forward. You don't come across as such a forceful jerk.

Oh, and try to avoid swearing. It often seems fine when you say something - you use swearing for emphasis or to show some emotional point. It usually just sounds terrible though.

share|improve this answer

Try giving your advice/criticism only once and if it is not accepted move on. It is fine if you are asked to provide arguments for your point of view, but know that it is time to stop when you realize that the other side will not be convinced (perhaps because they do not understand certain thing that you do or vice versa) by any of them.

Also, don't turn a argument about programming into a flame war. Keep it strictly on about the bit of code or logic that you are discussing, and avoid making personal attacks.

Always be open to the possibility that you may be wrong, and evaluate every argument posed by the other side seriously and objectively - no matter how low an estimation of that person's abilities you have.

And lastly, a lot of the seriously annoying people I talked with tend to be some sort of fanboy or zealot and any argument with them often end up as being a pointless and irrelevant "your OS vs my OS", "your editor/IDE vs. my editor/IDE" or "your language/framework vs. my language/framework" p*ssing match.

share|improve this answer
+1 for the fanboy thing. That wears very thin. –  quickly_now Feb 13 '11 at 1:15

It's tough in a technical field because, we're expected to have all the answers. If your app crashes, you don't respond with, "What do you think caused the connection to fail? I value you as a child-of-the-world, and want to encourage you to voice your opinion in a non-judgmental space."

In technical circles, if I think I'm right, I say so. If you prove me wrong, great, I like to learn and a little debate is one way to do it.

share|improve this answer

Regular human compassion and empathy would be enough. Feel the atmosphere before speaking.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.