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, no registration required.

(Repost, I posted this in the wrong section before, sorry)

So I'm sure everyone has run into this person at one point or another, someone catches wind of your project or idea and initially shows some interest. You get to talking about some of your methods and usually around this time they interject stating how you should use method X instead, or just use library Y. But not as a friendly suggestion, but bordering on a commandment. Often repeating the same advice over and over like a overzealous parrot.

Personally, I like to reinvent the wheel when I'm learning, or even just for fun, even if it turns out worse than what's been done before. But this person apparently cannot fathom recreating ANY utility for such purposes, or possibly try something that doesn't strictly follow traditional OOP practices, and will settle for nothing except their sense of perfection, and thus naturally heave their criticism sludge down my ears full force. To top it off, they eventually start justifying their advice (retardation) by listing all the incredibly complex things they've coded single-handedly (usually along the lines of "trust me, I've made/used program X for a long time, blah blah blah").

Now, I'm far from being a programming master, I'm probably not even that good, and as such I value advice and critique, but I think advice/critique has a time and place. There is also a big difference between being helpful and being narcissistic. In the past I probably would have used a somewhat stronger George Carlin style dismissal, but I don't think burning bridges is the best approach anymore.

Maybe I'm just an asshole, but do you have any advice on how to deal with this kind of verbal flogging?

share|improve this question

closed as off topic by Mark Trapp Nov 23 '11 at 4:57

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

10  
I like to 're-invent the wheel' as well. Thats a great way to really understand a new technology. Which, in turn, helps you with others. Plus, quite frankly, often its just as fast to re-invent a wheel than it is to learn, maintain, and alter someone's crappily coded, poorly documented wheel. –  GrandmasterB Sep 9 '10 at 20:39
29  
Re-inventing wheels is great for learning, and highly recommended. However, for 'real' code that's going to be doing something important, pick the existing tried and tested solution! –  Peter Boughton Sep 9 '10 at 22:47
6  
Sometimes when 're-inventing the wheel' you end up 'building a better mouse trap'. –  Rusty Sep 10 '10 at 0:18
2  
You make a crappy wheel, understand that it IS crappy, and go and find a fantastic one made by somebody who knows how to do it. –  user1249 Dec 2 '10 at 18:12
1  
@Rusty, with the issue being it's a mouse trap and not a wheel ;) –  Matthew Whited Feb 4 '11 at 11:26

9 Answers 9

up vote 37 down vote accepted

Don't just let them talk. Get them in front of a keyboard. The phrase "ok, show me" should do it. My experience is most blow hards aren't that great, and when they actually try to do what they say it doesn't work and things get real quiet.

share|improve this answer
1  
I can hope. Honestly they probably are better programmers than me, but I have really hard time learning from, or being in the same room as, a social dullard flaunting his abilities like it's a license to be a complete d***. –  Peter G. Sep 9 '10 at 20:42
1  
Just because they're better than you doesn't mean what they always know what they're talking about. –  Conrad Frix Sep 9 '10 at 21:01
    
I'll give your method a try then, next time it happens. Thanks. –  Peter G. Sep 9 '10 at 21:17
2  
Pragmatic is the keyword. –  rwong Nov 30 '10 at 6:59
1  
@PeterG. how did this go? –  user1249 Oct 3 '11 at 14:08

I've been programming for thirty years. I know lots of people who consider me a "programming master." Want to know my dirty little secret? I'm just barely competent in a few areas, but that's it. Mostly I suck.

I've worked with some incredible geniuses in those years, not the actress-on-a-podium-bubbling-about-her-co-star kind of genius, but the blazing IQ, Genius with a capital-G kind of genius. Heck, I've read Knuth.

If you work hard and long enough at it sooner or later you're going to realize that the very best you can do is really quite insignificant compared to the breadth and depth of talent out there. I fail to see how anyone can reach that point and come away with anything but the deepest humility.

Anyone that lords their views over another person and believes that their way is the correct way above all else is simply not a very good programmer. Take my word for it.

My advice, you're on the right track not burning bridges. Listen politely, take whatever good from it you can, then go your own way.

share|improve this answer
    
I think there are different ways to look at "being good", sometimes I liken the type of programming I do to more of a craftsmn / tradesman, I doubt I'll ever make a breakthrough in computer science or invent some crazy algorithm that will be a major breakthrough, however the people who do that sort of thing often get bored building "regular" apps as they always want something more and more challenging, anyways I'm rambling but I think theres something to be said for just being a solid programmer in a few areas as you can still be very valuable to an employer –  programmx10 Jun 2 '11 at 6:10

Like most social situations, it depends on the context.

If this person is in a lead role (the context likely being a workplace), then you're kind of hosed unless you can convince them to use different techniques than the ones they choose. Hopefully they are open to critique from their team. In many cases I've found that presenting good, fact-based, solid arguments for why your particular approach is better for the project will often win them over. If they continue to be stubborn just because "that's how it's supposed to be done" (or some other silly reason), then they end up looking bad anyways and you look like you at least tried to be rational. In this case, I'd also recommend checking out careers.so ...

If this person is your peer, you can pretty much just ignore it and move on. Better would be to ask them to explain why they value a particular library or approach. Through discussion, they may realize that your constraints are different than they anticipated (for example, you don't need "awesome super-fast library X" because you don't need raw pedal-to-the-metal speed, or you don't want to use "prebuilt component Y" because you are aiming to minimize dependencies). You might also gain valuable insight into some of what they're suggesting. Usually in situations like these I end up going mostly my own way, but I'll usually also glean some helpful information from at least looking into whatever approach/technology/library they are advocating.

If this person is underneath you, then tell them to bug off :) Ok... maybe be a little more constructive than that (don't be the very type of person you are trying to deal with!), and again try to understand what's going on and communicate effectively.

In the end, if the person is really being a hardcore blowhard who doesn't want to compromise, isn't open-minded, and doesn't care to learn; then all you can really do is ignore it and try to make the best of the situation.

share|improve this answer
    
I'm probably not good enough yet to land a job, so it's all fellow students/online people/etc. I don't have a problem learning other methods (I actually value it), but when I tell someone I want to try this, and then they retort stating how horrible of an idea it is, I feel like losing it. Maybe avoidance is the best approach. –  Peter G. Sep 9 '10 at 21:03
2  
To Nick - I wouldn't ignore a blowhard peer. They have the ability to sneak under neat you and blow your initiatives. Blowhards tend to be political as well, so it is best never to underestimate their ability to do damage, however dumbf* they might be. –  luis.espinal Oct 12 '10 at 22:56
1  
@luis "Blowhards tend to be political as well, so it is best never to underestimate their ability to do damage," ... I would give you +100 on this if I could. Been there, dealt with that. –  Bill Nov 29 '10 at 19:38
1  
@Peter G - if you are a student. Ignore them, stop conversing. They will move on in time and so will you. If employed... you have a whole different bunch of troubles. –  quickly_now Feb 4 '11 at 3:20

Try to figure out why he feels the need to intrude in this way.

  • Is he afraid of you doing the wrong thing and wasting company money/time?
  • Is he insecure and afraid of being irrelevant?
  • Is he trying to be helpful by suggestion a better solution, but failing?
  • Is he misunderstanding your goal in exploring the solution space?
  • Is this his way of being friendly?
  • Did someone tell him that you should always use X, so he always suggests X? Why did they tell him that?
  • Is he a salesman for X technology?

These all have different responses.

With a better understanding of your 'blowhard'--start by losing that label for him--you will be much more able to find a way to work together.

You might also investigate why this bothers you so much. Why aren't you able to ignore his input, or harmlessly deflect it?

share|improve this answer
    
+1 for considering that he might not realize the effect he's having. Most people who annoy us have no idea what they're doing, and often, we end up interpreting what someone says based on our experiences, which are different than theirs, and so we've attached meaning to a behavior and setup "rules" that no one knows about but us. –  Tim Claason Feb 15 '11 at 16:30

Switch into a functional programming mode. Most blow hards know Java and nothing else. So the moment you hit them with something weird like say Haskell or Lisp or even Ruby they are going to stop dead.

share|improve this answer

I would tell them to f**k off (You could use more diplomatic verbiage if you wish.) or simply ignore them. There aren't many options beyond what I've said. (Murder could work but legality varies by locale.)

share|improve this answer
4  
I don't think thats the best way to deal with the situation... –  TheLQ Sep 9 '10 at 20:48
1  
I've tried the less-than-diplomatic approach, but I don't like doing it. Yelling just makes me feel worse. Many times I've felt like punching them through a wall, but they're usually a lot bigger than me (shamu comes to mind). And at my cornstalk 6' 130lbs physique, it would be like trying assault a bowling ball with a pipe cleaner. –  Peter G. Sep 9 '10 at 20:53
    
@Peter - I am considering deleting this as it isn't exactly a serious answer on my part. –  ChaosPandion Sep 9 '10 at 20:58
1  
It's fine. Life needs more comedy/sarcasm anyways. –  Peter G. Sep 9 '10 at 21:08
    
I don't think I've ever been pushed this far in the workplace, but this is probably your only choice with an extreme blowhard. –  JeffO Sep 14 '10 at 14:22

Why do you care what this person says? Are they your boss? Who cares? Every job has a guy, hopefully not you, that they avoid, or they hear him coming down the hall and they duck. They just don't like him. They may not even know why. But that's just the way the world is. Be cordial and who cares. Sounds like you want your pound of flesh and to smack him around a little bit.

share|improve this answer
    
Difficult if you work for someone like this. –  quickly_now Feb 4 '11 at 3:22

There was a guy like this in my last workplace. Not only did he have an opinion on every single discrete task everyone else was working on, but he'd also roll up and ask "what are you doing - I'm just interested!" right when you were getting into a task, rather than getting on with his own work to which he had been assigned. It's one thing having an opinion about something now and again – we each have views, and productive teams should always be open to valid input from their peers – but it's quite another prospect when an individual repeatedly puts other developers off their work by asking them to stop what they're doing and explain it to them, in the hope that they might develop an opinion during the course of the conversation that they propose having instead of letting their colleagues get on with their work.

When this particular guy tried the above on me, his opening line was "What are you doing?", to which I gave a brief polite overview summary of the task I was just getting started on, in case he was actually just asking casually rather than seeking a long and not very enlightening debate on the subject as I suspected from painful prior experience was his intention. When in reply to my overview explanation he went on to say "I don't understand?...", in a tone that suggested nothing would make me happier than stopping what I was doing to explain my intentions to him in more detail, I just said "Why would you need to understand?", which stopped him dead in his tracks.

Every other developer in the office chuckled loudly as he made his way sulkily back to his seat, unable to reply to my question. The lesson here, if I can presume to give one, is that these people are always best dealt with civilly and calmly, but firmly. If you fail to entertain their interference with your work, and nip any conversations that are threatening to take the tenor of an argument before they even begin, these people generally have nowhere to go in their attempt to derail your thought process.

share|improve this answer
    
I am not sure I like that approach, everyone on the team should know what everyone else is up to - approach and all, otherwise if they are off for some reason, no one can pick up from them. Also, where possible, the whole team should contribute with regard to technique to ensure the best approach. –  Orbling Feb 4 '11 at 10:53
    
I disagree – we’re development teams, not The Borg. Design by committee doesn't work, and neither does chopping and changing assignments as if developers were merely interchangeable parts. I'm certainly open to other people respectfully contributing views and opinions to my work, but as noted above I make a distinction between having an existing opinion and merely putting other people off their work by asking them to stop what they're doing and burn time explaining their ideas to you. Some people just like to hear the sound of their own voice, and this particular dev was in that category. –  user15534 Feb 7 '11 at 0:48
    
@orbling, sounds like a reason for a scheduled meeting to me! –  user1249 Oct 3 '11 at 14:09
    
@Thorbjørn Ravn Andersen: In the modern world, you quite often have distributed teams over continents. A scheduled meeting can be a very hard thing to achieve, something to be avoided where possible at anyrate. –  Orbling Oct 5 '11 at 13:45
    
@Orbling, the answer clearly talked about developers being located in the same physical location. However, even for distributed teams you need coordination to avoid people being disrupted all the time. –  user1249 Oct 5 '11 at 14:28

Hit them with the "You should never use something you don't understand" line.

share|improve this answer

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