How to deal with the “programming blowhard”? [closed]

Question

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.

Do you have any advice on how to deal with this kind of verbal flogging?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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?

Answer 5

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.

Answer 6

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.)

Answer 7

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.

Answer 8

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.

Answer 9

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