

Avoiding “Smart Guy” Syndrome on Team Projects - gansai
http://programmers.stackexchange.com/questions/125838/avoiding-smart-guy-syndrome-on-team-projects?rq=1

======
trustfundbaby
From one know-it-all to another, let me start with this quote

"Those people who think they know everything are a great annoyance to those of
us who do." \--- Isaac Asimov

1\. The key is to pick your battles.

There is no possible way that a person can be right 100% of the time. So pick
a number out of ten times that you think you could be wrong. Start with 1 out
of ten if you're really convinced you're smart, you'll find that number
declines over time if you're keeping score (you are keeping score, right?)

Now every time you encounter an issue where you have an opposing viewpoint, do
the math and think "could this be the x times out of 10 that I'm wrong" ...
basically you're forced to second guess yourself and listen a little closely
to other points of view.

If its close enough that its not that big a deal if the other guy wins out,
then let it go ... reserve your capital for the really really big fights, the
things that will keep you up at night if you lose.

Keep score, and be honest with yourself. Whenever it actually turns out you
were wrong or that the other viewpoint actually turned out okay, recalibrate
your number.

You might find if you let things go from time-to-time, people will lighten up
around you.

2\. Build alliances.

Whenever you're making an argument, don't go it alone. Try to feel out support
for your POV, ask the more quiet people what they think, you might be
surprised that the actually agree with you but just don't want to weigh in
because they don't really feel that strongly about the debate, don't care much
for you, or they actually want to see you fail because you're always getting
your way (trust me, this happens, its human nature and another reason to pick
your battles). Help other people win their arguments from time to time, and
they might help you win yours

3\. "Lower your voice and strengthen your argument." \--- Lebanese proverb

If you find that you have to be strident to get your point across, then maybe
you don't have the necessary weight to make the same point with overwhelming
force of experience or logic, which means that you're probably making an
argument of opinion that isn't strongly grounded in either.

It doesn't mean if you've been doing something forever and are the smartest in
the world, that you'll be listened to (I've seen people ignored who went on to
found companies that were bought out for millions of dollars while the people
who ignored them were still at their old jobs), people tend to pick sides
first then rationalize them later. remember that ....

"If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will refuse
to believe it. If, on the other hand, he is offered something which affords a
reason for acting in accordance to his instincts, he will accept it even on
the slightest evidence" --Bertrand Russell

best of luck

~~~
lifeisstillgood
"Lower your voice and strengthen your argument." --- Lebanese proverb

Tattooed on my eyelids so I don't forget. Great one

~~~
Achshar
So the thing is that your eyelids are probably the only thing on your body
that you cant look at, even with a mirror. I know that's supposed to be the
point of your comment, but I cant relate how.

~~~
eevilspock
Not if it's tattooed in reverse and you close your eyes in the light. Just
sayin ;)

~~~
Achshar
But if I understand correctly, human eye can't focus on things that close to
them.

~~~
rtpg
if you are near-sighted you can.... I think.

------
bjourne
When I was a kid and went to a new school, I was the best in class at math.
Mathematical ability is pretty clear cut, so there is no room for "yeah you
_thought_ you were awesome, but in reality you were just a know-it-all." I
really was that good. :) In that class, there was a girl who _used_ to be best
at math before I came. She didn't like that I blew her out of the water when
it came to calculating. Though she wasn't very good at math, she was very good
at being a kid, forming alliances with the other children and backstabbing.
Basically got me frozen out and bullied.

My point is that I think the exact same thing happens on workplaces too,
although in veiled form. If you have a gang of C class programmers "lead" by
one B class programmer and one A class comes along, tension will likely occur.
It has happened to me and I'd be surprised if it hasn't happened to more
hackers here on hacker news.

~~~
olivier1664
Maybe the B leader avoid to recruit A class programmer.

------
johngalt
Make the best case you can for adopting course of action X to solve potential
problem Y. Then step back and let the person in charge make the decision.

My rule of thumb is two 'No' answers. It goes like this:

Present affirmative reasons why direction X is the right choice. Try to focus
on the benefits of X rather than pointing out the flaws in the current plan.
If the response is no, I'll try to address any concerns regarding X. If the
response is still no I leave it alone.

I've found that if you continue past this point it becomes an argument. Now
you're challenging the groups ability to proceed after making a decision. Once
that occurs your opinions are an impediment to the groups progress.

Note: Perspective is worth 80 IQ points. The team could be basing the decision
on factors you aren't aware of. The world is seldom simple enough to present
one 'best' answer to a given situation.

EDIT: No they aren't "all against you because you're so much smarter than
them". Seeing this sentiment in some of the comments. Trust me this doesn't
happen. For every one real instance of this, there are 100 instances of
condescending engineer who is just parroting the technology fad of the day. Or
is an architecture astronaut.

To anyone who feels this way regularly ask yourself "How many times have I
felt like this? In school? In college? At job 1? At job 2?" Either the world
is wall to wall jerks, or _you're the jerk_.

------
opminion
It's hard to distinguish between feeling clever and being clever.

As with health issues ("feeling better" vs "being better"), science comes to
the rescue.

~~~
pi18n
I don't actually have any argument against what you said, in fact I agree
wholeheartedly that the answer is the OP should empirically prove what they
claim. Nevertheless, I hope you won't take offense if I use that as the
starting pistol of a short rant.

I find that kind of commentary irritating because I have a co-worker that
thinks he is the more talented programmer. What's worse is that he is rude
about it.

I think I am objectively better for the following reasons; my work has shorter
functions, less inter-dependency between classes, is simpler to reuse, and
most importantly it crashes less. If I asked a question like, "how can I get
this guy to stop being a douchebag and listen to my suggestions (which I swear
would improve the company's codebase)?", I'd be irked by the commentary.

Anyway, I'm sure you all think this is a bunch of sound and fury, signifying
nothing, but it felt good to type it out. Cheers and good wishes to all.

~~~
PommeDeTerre
Have you considered that your "objective" analysis of what is "better" may
still be very subjective, or just plain worse in some cases?

A large number of shorter functions, for example, can often be much harder to
work with than one larger function that performs the equivalent processing. To
properly understand such code (especially when it was written by somebody
else), one must jump around from function to function, rather than just
reading through one function from the top to the bottom.

Likewise, "less interdependency between classes" often translates to more
complexity in other places. To get usable software, the classes will still
need to be connected together somehow. Sometimes this is done via automatic
dependency injection, which usually brings in a whole new set of problems.

Reuse is another "best practice" that often turns out to be bad in practice.
It only works in those cases where the functionality being reused is truly
general. Forced reuse of other, less-general code will often be problematic.
The reused code soon starts needing to take into account slight variations in
order to be used in several different places, and over time this builds up.
This can ruin the code, resulting in a situation worse than had a bit of
duplication been accepted.

Crashing code isn't necessarily a problem, either. Taking a fail-fast approach
is often a good way to detect unforeseen problems while developing code,
before it gets into production use. Even once in production, it's better to
have software crash in an obvious and reproducible way, so it can be more
easily and rapidly fixed. It's often best for it to stop working completely,
than it is to continue on and perhaps cause many more problems (such as data
corruption, or a huge amount of network traffic, and so forth). It can be much
worse to deal with code that "doesn't crash", but only because the original
programmers caught and silently discarded any exceptions that were thrown, or
error conditions that were raised.

What you see as "good code" may, in a given context, actually be quite
problematic. Perhaps your co-worker realizes this, and this is the cause for
some of the friction you're experiencing.

~~~
caw
> A large number of shorter functions, for example, can often be much harder
> to work with than one larger function that performs the equivalent
> processing. To properly understand such code (especially when it was written
> by somebody else), one must jump around from function to function, rather
> than just reading through one function from the top to the bottom.

I wonder if there's an IDE that can do this -- substitute function calls with
the actual function on demand. That might make both camps happy. It's readable
in 1 sitting, but also DRY'd out.

~~~
ZoFreX
There's a plugin available for Visual Studio that does something like that:
[http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...](http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-
bfef-83bd428a0acb)

------
MrQuincle
There is another side to this. At times you really need people to work on a
project without questioning too much, just doing their job. However, most of
the times you will need programmers that know what they are doing. That think
about the bigger pictures themselves and are no mindless robots. An atmosphere
in which things are naturally discussed and questioned is essential to create
great products. If someone is at the same time a great critic and a prolific
programmer, I think there's nothing better. In practice however, those traits
don't always come in the same package. :-)

PS: I think the best you can do is to encourage people to criticize yourself.
Make it natural for them to point at possible faults in your code, your
projects, or management style. The more they can ventilate, the more you can
point out. If it's one-way, it is an attack, not a discussion.

------
coditor
At every job when I started no one knew me yet and I didn't push for change. I
focus on simply doing the best I can do and after you deliver high quality
software (or whatever you are doing) and push out small ideas the actually
improve things you get usually get a reputation as someone who is worth
listening to. Then you can push a little harder. Until then you can't do much.
Evidence of being smart is always better than claiming it.

I once had a 5 week contract at a University where I saw everything the group
was doing was a horrible security nightmare but the manager had no interest in
anything I might say and made it clear; by the end after delivering way more
on my part than anyone thought possible suddenly the manager wanted to know
everything I had to say and then made sure it got fixed.

------
mrchuckmills
I've been on both sides and seen the extremes of both. Sometimes on the same
project. The extreme cases are easier and more fun to poke at, so that's what
I'm going to do:

\- The smart-ass with little to no experience but always knows the right way
to do things. Pounds the drum of change. Would rather burn the project to the
ground and rewrite everything than progressively add business value. Refuses
to consider they might be wrong.

\- The know-it-all leaders who are in fact incompetent. Imposes decisions
which they are not qualified to make. Refuses to consider the opinion of other
intelligent people on the team.

A team is a social endeavor. It might seem great if being "right" was all that
was ever required to change someone's opinion, but humans don't work that way.

~~~
jiggy2011
It's awesome when you have both types of people together.

------
_one
I can very much relate to being the uncomfortable smart guy. And it's not
about "being right". What bothers me is not when there’s a discussion that I
come short out of, but when no one bothers to respond because then it seems
like no one cares about the project as much as I do.

Related to this I think is that I don't really see problems as problematic,
but interesting. I actually enjoy twisting and thinking about every possible
solution, and lately I've started to realize that a lot of people (especially
managers) don't have the same associations to the word problem. So previously
pointing out problems and thinking every body would be exited about them,
turned out to be a very counterproductive approach.

------
adrianhoward
_"Since I didn't pick and choose my battles, my boss now assumes anything out
of my mouth is an over complicated response"_

Assuming that the OP is actually correct in his suggestions (I think everybody
else has covered the other option ;-) - this is a sign of another problem. Not
being able to communicate. Not being able to lead.

Communication and leadership - especially to people outside of your area of
expertise - are skill. It needs practice to get good at it. Being right
doesn't matter if you can't demonstrate to others the value of what you're
saying.

------
nicw
You can be right - but your maturity is determined by your response when the
team "comes around" to your idea. A mature developer nods, and immediately
begins walking through their pre-developed action plan. That person has the
confidence that the team knows there was a mistake, and no need to walk
through the past.

An immature developer throws out the "I told you so" and lauds it over their
team.

We all make mistakes, it's the foundation for the fail-forward-fast mantra. So
acknowledge the mistake, impress others that you have a solution, and move
forward.

