Avoiding “Smart Guy” Syndrome on Team Projects(programmers.stackexchange.com)
programmers.stackexchange.com
Avoiding “Smart Guy” Syndrome on Team Projects
http://programmers.stackexchange.com/questions/125838/avoiding-smart-guy-syndrome-on-team-projects?rq=1
10 comments
"Lower your voice and strengthen your argument." --- Lebanese proverb
Tattooed on my eyelids so I don't forget. Great one
Tattooed on my eyelids so I don't forget. Great one
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.
Not if it's tattooed in reverse and you close your eyes in the light. Just sayin ;)
But if I understand correctly, human eye can't focus on things that close to them.
if you are near-sighted you can.... I think.
[deleted]
That quote is the Chuck Norris of proverbs - even tattooed in reverse on my eyelids, I can still be inspired by it :-)
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.
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.
Maybe the B leader avoid to recruit A class programmer.
Likewise with management. I worked at a place managed by a confederacy of dunces that promoted people I'd never have promoted, but who I realized were people who did not threaten the leaders' authority by being too smart.
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.
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.
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.
As with health issues ("feeling better" vs "being better"), science comes to the rescue.
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.
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.
Actually I saw the first comment about the boss posting as well, which altered how I judged all latter comments. All the other posters were fairly respectful and mostly wrote the OP should consider that he might be wrong. Can't disagree with that, really.
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.
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.
This is exactly what I thought would be irksome, and it was :)
I am aware that it is hard to avoid a subjective analysis when it involves oneself, yes. So I'll just say, as far as your points on long functions, interdependency, and reuse, I agree, to a point. I'm not exactly writing, say, single line functions, though.
As far as crashing goes, I throw exceptions over corrupting data, please give me some credit. I mean crashing as in some internal state goes awry (e.g., failing to lock properly in multithreaded code) so he doesn't know why it is crashing.
I will take your comments under consideration. I'm afraid there's nothing I can do here that will prove I know what I am talking about, so I guess you will have to draw your conclusion on our dialog alone.
I am aware that it is hard to avoid a subjective analysis when it involves oneself, yes. So I'll just say, as far as your points on long functions, interdependency, and reuse, I agree, to a point. I'm not exactly writing, say, single line functions, though.
As far as crashing goes, I throw exceptions over corrupting data, please give me some credit. I mean crashing as in some internal state goes awry (e.g., failing to lock properly in multithreaded code) so he doesn't know why it is crashing.
I will take your comments under consideration. I'm afraid there's nothing I can do here that will prove I know what I am talking about, so I guess you will have to draw your conclusion on our dialog alone.
> 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.
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.
There's a plugin available for Visual Studio that does something like that: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...
I think it is the same with Linus. He feels he is clever and he is being clever too. Just saw his tech talk on git the other day on youtube, which he gave in Google. He does not care. He is damn opinionated. My point is being smart does not ignore other people's views.
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.
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.
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.
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.
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.
- 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.
It's awesome when you have both types of people together.
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.
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.
"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.
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.
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.
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.
"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