Are Cocky Developers Worth It?(itmanagement.earthweb.com)
itmanagement.earthweb.com
Are Cocky Developers Worth It?
http://itmanagement.earthweb.com/features/article.php/3771746/Are+Cocky+Developers+Worth+It?.htm
33 comments
I can't stand articles like this. Not because they don't impart any wisdom, but because they sound so phony and contrived. If you are going to write fiction, at least get your archetypes right. Guys writing memory management code on windows are 50 year olds with giant beards, not cocky youngsters who use the phrase "mad skillz." The mad skillz guys are the ruby programmers who believe the apex of programming is building a "domain specific language."
Yes, this article is contrived and the archetypes are a bit skewed, but it closes on an interesting point.
I, myself, am a cocky developer. Additionally, my technical brain is better connected to my mouth and works far faster than my social brain. Often, my comments are misconstrued as attacks and it has significantly weakened my ability to impact decision makers.
I am however, well aware that I have problems. I aggressively seek out feedback and encourage those who provide it to "give it to my straight". Via this process, I have significantly improved my communication skills and developed some political tact.
This brings my to my next point: cocky people like to be right, but are well aware when they are wrong. If they are making statements which appear to be ad hominem attacks, they probably aren't doing it intentionally, or they don't mean any harm. So just mirror their behavior, be honest, be direct, tell them that their personality is hurting team moral, and suggest they try to improve themselves. Then, agree upon personal commitments of GROWTH AND IMPROVEMENT not instantaneous performance, which dictate their performance rewards.
Hell, I had one manager who requested to review all emails I sent to customers. My communication skills are many fold better for it.
Follow that plan, and I guarantee you can turn most any cocky coder into a productive team member. If you're lucky, that team member will even significantly educate the rest of the team and encourage them to do the same.
This is what people managers are supposed to do...
I, myself, am a cocky developer. Additionally, my technical brain is better connected to my mouth and works far faster than my social brain. Often, my comments are misconstrued as attacks and it has significantly weakened my ability to impact decision makers.
I am however, well aware that I have problems. I aggressively seek out feedback and encourage those who provide it to "give it to my straight". Via this process, I have significantly improved my communication skills and developed some political tact.
This brings my to my next point: cocky people like to be right, but are well aware when they are wrong. If they are making statements which appear to be ad hominem attacks, they probably aren't doing it intentionally, or they don't mean any harm. So just mirror their behavior, be honest, be direct, tell them that their personality is hurting team moral, and suggest they try to improve themselves. Then, agree upon personal commitments of GROWTH AND IMPROVEMENT not instantaneous performance, which dictate their performance rewards.
Hell, I had one manager who requested to review all emails I sent to customers. My communication skills are many fold better for it.
Follow that plan, and I guarantee you can turn most any cocky coder into a productive team member. If you're lucky, that team member will even significantly educate the rest of the team and encourage them to do the same.
This is what people managers are supposed to do...
I've also found the following strategies helpful:
Be less vocal. You might be right in your opinion on some matter, but, you don't always need to express it. Some things are okay to be ... less than ideal. Let people make their own mistakes (just try to contain them to less important system areas). Teach rather than debate.
When you do have a strong opinion, try to phrase your comments as less oppressive suggestions. If over time people ignore your suggestions and it's a critical system component, only then become more assertive and vocal. People hate being told what to do. But if you plant a seed, they are much more open to modifying their view in the long run, after they have digested your reasoning.
Everyone likes to do things their own way. As long a business goals are being efficiently achieved, don't mess with things. It seems better to guide people than direct them.
Be less vocal. You might be right in your opinion on some matter, but, you don't always need to express it. Some things are okay to be ... less than ideal. Let people make their own mistakes (just try to contain them to less important system areas). Teach rather than debate.
When you do have a strong opinion, try to phrase your comments as less oppressive suggestions. If over time people ignore your suggestions and it's a critical system component, only then become more assertive and vocal. People hate being told what to do. But if you plant a seed, they are much more open to modifying their view in the long run, after they have digested your reasoning.
Everyone likes to do things their own way. As long a business goals are being efficiently achieved, don't mess with things. It seems better to guide people than direct them.
Me:
Cocky Youngster
Wrote a memory manager in C++ for Windows
No beard
Don't think I've ever used the phrase "mad skillz" to describe myself
Never played with Ruby
---
Well, you got one point right anyway. :-)
Cocky Youngster
Wrote a memory manager in C++ for Windows
No beard
Don't think I've ever used the phrase "mad skillz" to describe myself
Never played with Ruby
---
Well, you got one point right anyway. :-)
You: need to work on reading comprehension.
He said he was describing an archetype, and made no claim as to whether you fit it or not.
He said he was describing an archetype, and made no claim as to whether you fit it or not.
I didn't see anything in the article that suggested it was (or wasn't) fiction, so where'd all this archetype nonsense come from?
Maybe menloparkbum was just writing an ironical-kinda-funny comment, but I've known people very similar to the character in the article, I've occasionally been the character in the article, and I'd be surprised if at least a few of the regulars around here weren't similar to the character in the article.
Maybe menloparkbum was just writing an ironical-kinda-funny comment, but I've known people very similar to the character in the article, I've occasionally been the character in the article, and I'd be surprised if at least a few of the regulars around here weren't similar to the character in the article.
Well, from the point of view that generally people really want to work with people they like and respect... no.
It's bad enough in small teams, but in large teams people like this can be really destructive.
It's bad enough in small teams, but in large teams people like this can be really destructive.
I worked at a place where the lead developer had this problem. All of the other programmers were new, and he'd been there over a year, so I think we were all willing to learn and listen ... but he did not accept any feedback at all and was determined to dictate, not cooperate. There's a difference between engineers and monkeys, and the lead clearly wanted monkeys; little coding robots who didn't question his strategies or methods, didn't make suggestions, and just obediently churned out what they were told without providing any input into design or architecture. To boot, he was absolutely unforgiving if your style didn't match his (for instance, I usually put the first property of a CSS rule on the same line as the opening bracket, and he doesn't ... and he told the owner that I was incompetent for this and similar infractions), but there were no formal style guidelines; you had to look at his code and try your best to format it exactly, or suffer embarassment and wrath.
The whole thing was rather demoralizing and I left in the first month, after quickly learning not to contribute if I was intent on keeping my job for even that long. The other skilled developers left shortly thereafter. He now works mostly with designers-turned-developers and purposely hires less-competent developers so that he doesn't have to field criticism.
It's a little disappointing still, because there's a whole group of people who believe that myself and a group of talented ex-colleagues are incompetent because of this person's [intentional and petty] mischaracterizations and immaturity, but I'm trying to be over it.
I guess that's only tangentially apropos, but cocky developers are no fun, especially when they're in powerful positions.
The whole thing was rather demoralizing and I left in the first month, after quickly learning not to contribute if I was intent on keeping my job for even that long. The other skilled developers left shortly thereafter. He now works mostly with designers-turned-developers and purposely hires less-competent developers so that he doesn't have to field criticism.
It's a little disappointing still, because there's a whole group of people who believe that myself and a group of talented ex-colleagues are incompetent because of this person's [intentional and petty] mischaracterizations and immaturity, but I'm trying to be over it.
I guess that's only tangentially apropos, but cocky developers are no fun, especially when they're in powerful positions.
Whereas I come at this from the opposite perspective.
If you're absolutely certain you're correct, it's natural to want to limit the amount of discussion, feedback, and argument you have to deal with. You've already made up your mind, and that's that, and it's unlikely that a convincing enough argument exists that would cause you to change your mind.
The catch is, you have to be really, really good at what you do in order to adopt this stance, otherwise it's just sheer overbearing arrogance.
That's where the conflict comes in. Most people, frankly, aren't that stellar at what they do. A lot of folks kinda muddle along, and often change their opinions about accepted practices whenever they read something that takes precedence over their experience. If you doubt this, I think you need only to read some of the security-related threads here on News.YC, or just about any thread on OpenBSD-misc that incurs the wrath of one of the developers.
Furthermore, if he was the team lead, and he established a particular syntactic convention -- for whatever reason -- and you didn't follow it, then -- and I say this as gently as I can -- you weren't doing your job. That doesn't mean you were incompetent, and I'm not looking to insult you. But, basically, you weren't following his rules, and he was within his authority to establish those rules. It sucks that his rules weren't written out, but on the other hand, it's really not all that hard to look at some code and then format yours similarly. (Especially with CSS.)
Then apparently the lead developer started hiring what you call monkeys. I call them trainable.
See, my grandfather had a similar problem. He was one of the best RF and cable TV distributions systems guys in the Bay Area up until he died a few years back. He was an idiotic businessman, but when he was dealing with the technology, he simply was one of the best. (I could bore you to tears with stories.)
He absolutely refused ever to hire anybody else with cable TV experience. He hated dealing with them, because they'd been taught all of these bad habits that he would first have to un-teach before he could even begin to get them to do things his way -- the right way. Instead, he hired people with no experience at all, and they naturally just followed his lead, along with a little coaching.
It isn't quite possible to do just that in software development, because I think software development requires an entirely different kind of thought process from just about anything else. But, I can see the appeal to hiring inexperienced developers, and making them do it your way right from the beginning.
If you're absolutely certain you're correct, it's natural to want to limit the amount of discussion, feedback, and argument you have to deal with. You've already made up your mind, and that's that, and it's unlikely that a convincing enough argument exists that would cause you to change your mind.
The catch is, you have to be really, really good at what you do in order to adopt this stance, otherwise it's just sheer overbearing arrogance.
That's where the conflict comes in. Most people, frankly, aren't that stellar at what they do. A lot of folks kinda muddle along, and often change their opinions about accepted practices whenever they read something that takes precedence over their experience. If you doubt this, I think you need only to read some of the security-related threads here on News.YC, or just about any thread on OpenBSD-misc that incurs the wrath of one of the developers.
Furthermore, if he was the team lead, and he established a particular syntactic convention -- for whatever reason -- and you didn't follow it, then -- and I say this as gently as I can -- you weren't doing your job. That doesn't mean you were incompetent, and I'm not looking to insult you. But, basically, you weren't following his rules, and he was within his authority to establish those rules. It sucks that his rules weren't written out, but on the other hand, it's really not all that hard to look at some code and then format yours similarly. (Especially with CSS.)
Then apparently the lead developer started hiring what you call monkeys. I call them trainable.
See, my grandfather had a similar problem. He was one of the best RF and cable TV distributions systems guys in the Bay Area up until he died a few years back. He was an idiotic businessman, but when he was dealing with the technology, he simply was one of the best. (I could bore you to tears with stories.)
He absolutely refused ever to hire anybody else with cable TV experience. He hated dealing with them, because they'd been taught all of these bad habits that he would first have to un-teach before he could even begin to get them to do things his way -- the right way. Instead, he hired people with no experience at all, and they naturally just followed his lead, along with a little coaching.
It isn't quite possible to do just that in software development, because I think software development requires an entirely different kind of thought process from just about anything else. But, I can see the appeal to hiring inexperienced developers, and making them do it your way right from the beginning.
The catch is, you have to be really, really good at what you do in order to adopt this stance, otherwise it's just sheer overbearing arrogance.
It is sheer overbearing arrogance no matter how good you are at what you do.
Arrogance is not a characteristic reserved only for the less competent, and it is never a positive trait in even the most competent.
The only difference between a competent jerk and an incompetent jerk is that it may be worth your while to make an effort to look past the less-than-desirable qualities of the competent jerk in order to take advantage of the good advice he or she may have. This does not mean that competence excuses a jerk from the responsibility to learn how to not be a jerk.
I think what you may be trying to say is that it's reasonable to tolerate an arrogant jerk if their skills truly tip the scales in their favor. That's fine, but I'm saying that everyone, including the most skilled jerk, has something to gain from purging arrogance from their personality.
It is sheer overbearing arrogance no matter how good you are at what you do.
Arrogance is not a characteristic reserved only for the less competent, and it is never a positive trait in even the most competent.
The only difference between a competent jerk and an incompetent jerk is that it may be worth your while to make an effort to look past the less-than-desirable qualities of the competent jerk in order to take advantage of the good advice he or she may have. This does not mean that competence excuses a jerk from the responsibility to learn how to not be a jerk.
I think what you may be trying to say is that it's reasonable to tolerate an arrogant jerk if their skills truly tip the scales in their favor. That's fine, but I'm saying that everyone, including the most skilled jerk, has something to gain from purging arrogance from their personality.
I do agree with you actually; several years back, I was on one of the larger INTJ mailing lists, and I got into a, uh, er, heated discussion in which I was nearly alone in arguing that it was worthwhile for INTJ-types to tone down their abrasiveness and perceived arrogance.
Interpersonal skills are always a great thing to have.
It's just that, among those that are really, really good at what they do, they tend to adopt this attitude of arrogance, and like you say, the only time it should maybe be tolerated is if they're really that good.
Interpersonal skills are always a great thing to have.
It's just that, among those that are really, really good at what they do, they tend to adopt this attitude of arrogance, and like you say, the only time it should maybe be tolerated is if they're really that good.
Right, but that's the thing -- I've had a lot of jobs, been a contractor/freelancer for the last couple years and had three or four desk jobs before that, and I've worked with a lot of different people and a lot of different sets of style guidelines. The problem here was that there _weren't_ any style guidelines; it was all in his head. It wasn't just copying his obvious conventions, which we all did after the initial code review and realizing how unreasonable he was about it, it was also doing anything in a way that was different than what he would do, which is decidedly harder than just copying syntactical formatting. He didn't like my solution to a problem and made me redo the whole thing, and said, "When you get there next time, ask me what to do". I did this, and he came over and told me to do exactly what I did before, but because it wasn't formatted "correctly" (read: according to unwritten and shifting style guidelines existing exclusively in this man's head), he hadn't recognized it.
In one instance, my colleague noticed a potential security hole in a PHP application and notified the lead ... who ignored it because "the application is running fine and I don't change production code lightly". Which is laughable because this dude actually edited code directly, live on the servers; there were no test servers, and we weren't allowed to set them up, so we just had to test what we could locally and cross our fingers when it was sent up to the real environment.
And so on. I mean, I could go on with things like this for a long time. But, the point is, it wasn't that he disagreed, it was that he was entirely unreasonable and wouldn't ever even listen. If you have a group of people that do things fundamentally different than you and aren't interested in adjusting, then it makes sense to jettison them for those who are somewhat more compatible. The thing is that we were interested in adjusting and adhering to style guidelines, corporate conventions, and similar, and I personally haven't had any substantive problems following varied style guidelines in the past, but they had no conventions or guidelines here, and developers were just left to catch on as best as they could and hope that it wouldn't set off the existing members of the "company family" ... which wasn't easy here.
And it's more than just the style guidelines. The act of physically typing code is not that exciting for most developers. This guy was not open to any input at all, and would shoot us down swiftly whenever we brought something that wasn't praise. It wasn't a matter of just disagreeing and then not being able to accept the boss's decision. The problem was what I typed, that he expected robots that would deliver without questioning or working to find the best solution. The whole point of an IT team is to work together and contribute and everyone listens to everyone and comes up with the best combinations of concepts, methods, etc. That's how a team of engineers works, and that's what makes IT enjoyable. That's not how it worked there. There, it's "Defy guy and be ridiculed and fired".
This is enough for now. You get the drift, I hope. They've been through three different sets of qualified people now (all the while oblivious that this man is the reason why all his subordinates left, despite being notified of such), so I think that's the main reason they've settled on on-the-job development training for designers instead of real programmers.
In one instance, my colleague noticed a potential security hole in a PHP application and notified the lead ... who ignored it because "the application is running fine and I don't change production code lightly". Which is laughable because this dude actually edited code directly, live on the servers; there were no test servers, and we weren't allowed to set them up, so we just had to test what we could locally and cross our fingers when it was sent up to the real environment.
And so on. I mean, I could go on with things like this for a long time. But, the point is, it wasn't that he disagreed, it was that he was entirely unreasonable and wouldn't ever even listen. If you have a group of people that do things fundamentally different than you and aren't interested in adjusting, then it makes sense to jettison them for those who are somewhat more compatible. The thing is that we were interested in adjusting and adhering to style guidelines, corporate conventions, and similar, and I personally haven't had any substantive problems following varied style guidelines in the past, but they had no conventions or guidelines here, and developers were just left to catch on as best as they could and hope that it wouldn't set off the existing members of the "company family" ... which wasn't easy here.
And it's more than just the style guidelines. The act of physically typing code is not that exciting for most developers. This guy was not open to any input at all, and would shoot us down swiftly whenever we brought something that wasn't praise. It wasn't a matter of just disagreeing and then not being able to accept the boss's decision. The problem was what I typed, that he expected robots that would deliver without questioning or working to find the best solution. The whole point of an IT team is to work together and contribute and everyone listens to everyone and comes up with the best combinations of concepts, methods, etc. That's how a team of engineers works, and that's what makes IT enjoyable. That's not how it worked there. There, it's "Defy guy and be ridiculed and fired".
This is enough for now. You get the drift, I hope. They've been through three different sets of qualified people now (all the while oblivious that this man is the reason why all his subordinates left, despite being notified of such), so I think that's the main reason they've settled on on-the-job development training for designers instead of real programmers.
OK, that's fair. Given all that, the guy isn't qualified to lead a mule, let alone a development team.
Your old boss is not really cocky, just a fascist control freak.
Nobody is so good as to make up for the destruction of team cohesiveness and morale. Seriously. Nobody. No, not even you.
Everyone is allowed a gaffe or two. Everyone needs to get slightly thicker skins. Life is a contact sport.
That said, if you're a jerk on my team and you are unwilling or unable to change your jerkish ways after my best attempts at coaching, I will eject you from the team.
Simple.
Everyone is allowed a gaffe or two. Everyone needs to get slightly thicker skins. Life is a contact sport.
That said, if you're a jerk on my team and you are unwilling or unable to change your jerkish ways after my best attempts at coaching, I will eject you from the team.
Simple.
IMO they are not worth it. The cost of tolerating the cocky developer is the productivity of the surrounding team.
In reality very few developers exhibit these borderline autistic traits that seem to result in complete lack of social skills and they are NEVER worth working with.
When the team suffers the product suffers.
In reality very few developers exhibit these borderline autistic traits that seem to result in complete lack of social skills and they are NEVER worth working with.
When the team suffers the product suffers.
Im petty sure House MD was a show about a cocky programmer, but nobody could get the jokes, so they changed it to a medical drama.
No they are most definitely not worth the hassle. Most of the cocky types I have worked with had a lot of attitude but very little ability or talent. They were very good at office politics, though.
Interesting to read.
...but it seemed to me that all the manager really did was actually tell the cocky coder to not be a d-bag and he listened...aren't people supposed to listen to their boss? / Why didn't he just do this in the first place when he first noticed the attitude?
...but it seemed to me that all the manager really did was actually tell the cocky coder to not be a d-bag and he listened...aren't people supposed to listen to their boss? / Why didn't he just do this in the first place when he first noticed the attitude?
...aren't people supposed to listen to their boss?
You're kidding, right? Being a manager of really smart people that can easily move jobs is not easy.
You're kidding, right? Being a manager of really smart people that can easily move jobs is not easy.
I agree, this is a really difficult balance. In the real world I think Tyler would have said "Ok, I'll try and be nicer to those other folks" during the one-on-one meeting then returned to his original behavior w/in a matter of days or weeks.
So, do you compromise the technical strength of the team by firing Tyler or do you compromise team unity by keeping him?
My thought is that this is not a simple one way or the other answer. The post took the middle ground of talking with Tyler, which I don't think would really work out the way he wrote most of the time. Is there something else he could have said?
If you've had several conversations and this behavior is just the way it's going to be then what are the boundary conditions around when it's best to keep Tyler around vs firing him?
So, do you compromise the technical strength of the team by firing Tyler or do you compromise team unity by keeping him?
My thought is that this is not a simple one way or the other answer. The post took the middle ground of talking with Tyler, which I don't think would really work out the way he wrote most of the time. Is there something else he could have said?
If you've had several conversations and this behavior is just the way it's going to be then what are the boundary conditions around when it's best to keep Tyler around vs firing him?
I was a manager for many year and ran into this situation. I tried many techniques and found that:
1) My company really likes people to get along. It was very difficult to promote and pay my star developer more. 2) It did have a huge impact on the team. More than one person actually quit in a direct response to the less-than-subtle criticisms. 3) Having a group of mediocre to good programmers means that you simply cannot do certain things. The memory management issue was a good example in the article. It is a slippery slope and one I'm simply not interested in following to the bottom.
I kept (and am now trying to recruit for my startup!) this star simply because truly great programmers are hard to find and once I found one, I would do almost anything to keep them.
To answer the actual question, though, yes I talked with this person often, sent them to classes, read books and sought advice on how to teach them better people skills.
1) My company really likes people to get along. It was very difficult to promote and pay my star developer more. 2) It did have a huge impact on the team. More than one person actually quit in a direct response to the less-than-subtle criticisms. 3) Having a group of mediocre to good programmers means that you simply cannot do certain things. The memory management issue was a good example in the article. It is a slippery slope and one I'm simply not interested in following to the bottom.
I kept (and am now trying to recruit for my startup!) this star simply because truly great programmers are hard to find and once I found one, I would do almost anything to keep them.
To answer the actual question, though, yes I talked with this person often, sent them to classes, read books and sought advice on how to teach them better people skills.
Quick summary: technical skills != people skills.
(But: people skills are learnable, sometimes).
(But: people skills are learnable, sometimes).
Also, someone with really bad people skills can undermine the entire team's technical skills.
The cocky guy in the story sounds like one of those extreme "we should code it all in assembly" types. I'm not usually very impressed with the pragmatism (and therefore the technical decisions) of people like that. Of course I don't know the context here.
Are cocky developers worth it? Depends how cocky and how good they are.
[deleted]