Overconfidence is a huge benefit in playing the political game - getting people to take you seriously, managing up, interfacing with the outside world. Like it or not, humans are primed to respond to confidence; for most people, listing the dozen ways a system may fail signals that you shouldn't use the system, while for engineers, it signals that these are a dozen things to be fixed.

The trick - when getting to higher levels of technical management - is learning how to context-switch between being overconfident for the benefit of non-technical stakeholders and being paranoid with the technology so that the things that could go wrong don't actually go wrong.

Right, this is really a tricky game. I help run a nonprofit wiki farm, so a lot of our business is out in the open. We lost one of our clients because they were hanging out in the IRC while we were discussing the cost of an upgrade and the technical issues facing it, as the exit question revealed that they thought we were running out of money.

Now of course donations in the past few months have been roughly double our expenses -- information which is also public. But it's very hard to project confidence during a problem solving session, because it gets in the way of actual problem solving.

I wish I knew where the balance point for secretiveness and openness was for public organizations. But given that all of the candidates for U.S. President seem to be at a bad place, I'm starting to wonder if a perfect balance point even exists.

This is why I don't really want to get back into management, even though sometimes I think at some point it will be the only thing I'll have the patience and mental capacity to do. I saw the best and worst of myself when I was a manager- the worst is what scared me. But moreover, I learned after I stopped being a manager that I didn't deserve the accolades I got. If you were to take the best manager in the world, give him/her a shitty team, a hell of shitty code, shitily designed application and infrastructure, a shitty relationship with the customers/users, shitty support team, and shitty project/product/upper management, and you don't let that manager work to fix these things, they'll quit or fail, guaranteed. If you give them the best of all of these things, they will succeed, guaranteed. Being a good manager- knowing how to manage well and doing it, can be critical. However, it is nothing on its own.

One big difference is that a good manager can take an average team and build a good team over time. If you can't do that, you aren't a good manager.

A manager that can't tell who on their team is good will (in the long run) take an average team and turn it into a bad team.

>Like it or not, humans are primed to respond to confidence

Exactly. My feeling is that while perhaps many of us learned this the hard way, well at least I did--from experience--in hindsight it seems obvious that our emotional impulses and intuitions, while albeit valuable, are not fine-tuned to success in technical careers.

I think intuition and emotional impulses is immensely important for communicating with non-technical stakeholders. They haven't learned the art of emulating a computer so we've got to be a human being. IMHO.

Yea, I agree with that actually.

Fun fact: Dunning & Kruger measured perceived vs actual performance on very simple, and somewhat subjective tasks. Ability to recognize humor was one of them.

It's strangely difficult to find this important piece of the methodology. Wikipedia's article doesn't even mention it, and this context is fairly critical to understanding the effect.

I think you're right that some amount of inexperience and youth makes the kids overconfident, but what has been demonstrated is that the task difficulty is a large determinant in how good people are at estimating their own abilities, and Dunning Kruger only applies to easy tasks [1]. For very difficult tasks, the Dunning-Kruger effect actually reverses and becomes Imposter Syndrome [1][2]. Software engineering may fall into the latter category -- something that is difficult enough that, statistically, on average, beginners are actually pretty good at knowing they can't do it.

[1] http://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-k... [2] https://en.m.wikipedia.org/wiki/Impostor_syndrome

What do you mean "reversed"? DK says that both low and high skilled people estimate themselves as close to average, due to the obvious bias in one's available data

I mean that for difficult tasks, people who are unskilled rate themselves as unskilled, and people that are skilled rate themselves as skilled.

"Our studies replicate, eliminate, or reverse the association between task performance and judgment accuracy reported by Kruger and Dunning (1999) as a function of task difficulty. On easy tasks, where there is a positive bias, the best performers are also the most accurate in estimating their standing, but on difficult tasks, where there is a negative bias, the worst performers are the most accurate. This pattern is consistent with a combination of noisy estimates and overall bias, with no need to invoke differences in metacognitive abilities. In this regard, our findings support Krueger and Mueller’s (2002) reinterpretation of Kruger and Dunning’s (1999) findings. An association between task-related skills and metacognitive insight may indeed exist, and later we offer some suggestions for ways to test for it. However, our analyses indicate that the primary drivers of errors in judging relative standing are general inaccuracy and overall biases tied to task difficulty. Thus, it is important to know more about those sources of error in order to better understand and ameliorate them."

Burson KA, Larrick RP, & Klayman J (2006). Skilled or unskilled, but still unaware of it: how perceptions of difficulty drive miscalibration in relative comparisons. Journal of personality and social psychology, 90 (1), 60-77 PMID: 16448310

To clarify, I think what he is saying is that the effect exists on both ends. On the low skill side it's over confidence and on the high skill side it's imposter syndrome. It's the same effect. You are both saying the same thing.

Yes, and that makes "being kind" a lot harder.

Many people reading the article think of a nice person that humbly tries their best but makes a bad mistake. But what if they're a hugely over-confident asshole?

I mean, not everyone likes everyone, so when someone you don't like to begin with is arrogant, you might easily label them as an asshole.

I think the deeper lesson of the article is not to consider other people assholes, and to be kind to them even if you don't like them at all.

I don't agree. I've seen some very junior people change their attitudes rapidly (for the better) when working on a team; if we wrote them off immediately we'd lose out on a lot of promising people.

I was also one of those developers and have since changed my ways :)

Our definitions of "over confident assholes" may differ, perhaps? :)

Absolutely however I do agree with you. If a young developer doesn't integrate into a team role immediately, that's no reason to not hire him.

A lot of great developers are so great because they've spent years alone with their computers just cranking out code. So the best ones won't have the greatest social skills.

But if the kid's still having trouble integrating into their team role after their 6 month probationary period, for example, I personally wouldn't vouch for them any longer.

If there are five equally inexperienced applicants in the wings that will get along with everyone without having an attitude-smackdown first, then that's absolutely a reason not to hire them.

The worst problems I've ever seen on teams spring from people that are arrogant and standoffish, followed closely by people that are too dogmatic about technical minutiae and best practices in the face of situations that require flexibility (my classic example is the prototyping team that spent two weeks setting up an automated testing and deployment infrastructure, even though they only had six weeks to do their game prototype).

I'd take a pleasant junior that's really green but is happy to learn how to code better over a more technically proficient asshole that needs to have manners jammed down their throat any day - tech skills can be taught to a newbie, personality cannot. People have had a couple decades to cement personality habits as junior programmers, so those are mostly fixed, whereas tech skills are super fresh and malleable.

Yes, we might always change someone: a friend, a spouse, an employee.

But that's a risk; depending on that is ill-advised.

Well, part of my point is that assholeness is subjective. Moreover, a certain group of people seem to think there are a lot of assholes, while the majority gets along with most people.

Of course, there are genuinely poisonous people, and I agree on your points with regard to them.

And yet here they are.

With respect, this doesn't tell us what to do if we run into a hugely over-confident asshole.

>With respect, this doesn't tell us what to do if we run into a hugely over-confident asshole.

Fire them, if you can. Before they poison your entire talent pool with negativity.

When I was 19 I started working as a video conference support person for Europe in a multinational. This meant interfacing with the highest people in the company, where a failure could make an insecure CEO or similar complain to the IT manager screaming how this was shit etc. this was using multiple ISDN lines making international calls, so it was prone to failure once in a while. After the first instance, the manager told me to not worry, but to just let him know when something failed so he had answers when the angry user came complaining. This was my first learning experience in this.

A few years later, in the same company, I was managing the middleware servers that handled all communications for the sales people in Europe. Here, when there was a failure, the sales people would have to fax in their copies of the data if there was a failure, so even more pressure. This is where I really learned to both appreciate the criticality of my mistakes as it could make several hundred people redo their work. However, the most important thing I learned with this was to slow down, and pause for a few minutes so that I could explain what was going on to the non technical managers and team leads. This was more important sometimes then actually solve the problem.

Both of these instances and a lot of others that happened over 11 years in that company thought me ot really double, triple and quadrouple check any change. It created a healthy paranoia, but also taught me that mistakes are ok, as long as you learn from them, but also, lean to communicate with higher ups that could not follow the technical jargo. I think the communication part is something that a lot of very confident people have problems with. However, it's very hard to teach this to younger techs, without letting them fail, so as a senior tech, I have seen problems from new juniors, but I have let them actually make the mistake, and feel the stress and pressure that they have messed up. I have found this to be the quickest method to teach responsibility, while standing by them and their mistakes.

Just as a note about detecting mistakes and not correcting them, you choose mistakes that does not hurt the company, and of course you try to show them the mistakes before the cause harm. However, sometimes you catch the mistakes late, and that is what I was referring too.

I think that I have become softer and harder. Harder in the sense that I have no tolerance for bullshit.

Softer in the sense that I want to foster an environment of respect. As a lot of the senior leadership that I've worked with has retired, I've noticed that the 30-40 year old crowd now is more brutal.

The self-confidence of amateurs is the envy of professionals

>It seems paranoia is a great indicator of experience, and over-confidence/arrogance is an excellent indicator of a lack of learning.

This is certainly true, and it isn't limited to the field of engineering.