Why Some People Think They're Great Even When Their Work Is Terrible (2017) | Hacker News Reader

Why Some People Think They're Great Even When Their Work Is Terrible (2017)

forbes.com

33 pointsalexellisuk46 comments

I obviously don't know "Pat" in this example, but the half-assed coding combined with missed deadlines and inability to recall code he wrote later sounds a lot more like a motivation problem than a competence problem.

It's really hard for some people (myself included) to give good, timely work when they simply do not care about the stuff they're working on. It's entirely possible that Pat is actually a very good programmer on projects that he cares about (following code standards, meeting deadlines, "going above and beyond" etc), but may have been put on a project that he doesn't feel is interesting or mentally stimulating.

From experience, I can say that a not-insignificant amount of projects in corporate America (and probably other countries too, I just have not worked outside of the US) really are "busy work", that create little or no actual value to the company or the world, are not intellectually interesting, and are largely worked on to justify the existence of some middle-manager. When I am working on a project like this, especially when it's the only thing I'm assigned, it's incredibly hard for me to care about the results of it.

Granted, I might be a crappy programmer, but I think the dichotomy between "good programmer" and "bad programmer" is needlessly reductive.

The point of that anecdote wasn't the actual work of that programmer, but that he ranks himself much more competent than others who know his work do. That last part is the point of Dunning-Kruger.

>sounds a lot more like a motivation problem than a competence problem.

This has been my experience for the vast majority of cases when I worked in software quality. I think the Dunning-Kruger effect may be real, but possibly a special case describing a much smaller subset.

I've worked for orgs where software was an enabling product and not the product given to their customers. The leaders took the perspective that they "do not need world-class ingredients to make a world-class product". Meaning, the software didn't have to great for them to create a great end-product. So it's little wonder why there was little motivation to improve software quality. I think if properly motivated the competence would follow.

>I can say that a not-insignificant amount of projects in corporate America (and probably other countries too, I just have not worked outside of the US) really are "busy work", that create little or no actual value

You may be interested in the book Bullshit Jobs by the late David Graeber

"Bullshit Jobs" has been on my reading list for a couple years now. Maybe I'll bump it up and try reading it soon.

It's funny and very paradoxical, because all this is based on the Dunning-Kruger Effect, they even ask professor Dunning about how it's possible that someone think their (low) abilities are overestimated and probably he is suffering of the very definition of Dunning-Kruger Effect:

The Dunning-Kruger effect is nice, but it's not reproducible at best, and probably it's not real [1] [2]

1: https://www.mcgill.ca/oss/article/critical-thinking/dunning-...

2: https://scholarcommons.usf.edu/numeracy/vol10/iss1/art4/

Yeah, Dunning-Kruger feels like a way for people to rationalize away people who they don't like that project confidence. Oh, it's just Dunning-Kruger, I saw them make a mistake once, so they're not really smart.

The Dunning-Kruger experiment really only seems to indicate that we shouldn't trust self assessments. Not that there are hoards of confident people out there who will never know how terrible they are.

If anything, Dunning-Kruger tells use that we know less about the world than certain study methodologies would suggest. However, people instead grab it and insist that it lets us know more about the world.

This was my first thought as well. The Dunning-Kruger effect is poorly supported, but people pass it around like it's a divine revelation.

I worked with a guy who told me, you don't need to be that good, you just need the initiative. It was wildly cynical, but when I applied it to successful people I know, who failed quickly and often to iterate, their success didn't come from being meticulous or aligned to some exogenous universal criteria, they acted first then responded and followed up until it was sufficient.

There are boobs who think they are better than they are, and I've certainly been one, but you work with the tools you have. Worthwhile people will generally forgive you for failing, they don't forgive not trying because of uncertainty.

Becoming somewhat immune and suspicious of discouragement means you will take opportunities others won't, which even if it's just survivor bias, it's the factor most highly correlated to success.

I like this insight. When we think about 'grit' and the ability to fail and fail but keep trying, and have the confidence to persevere, isn't this a negative thing when the point of view is from one who is already competent? I tell my students that it all comes down to staying humble concerning your abilities, but to take initiative and be perhaps presumptuous or arrogant in your goals. Dunning-Kruger can be viewed as someone who will never make it; but just as easily as someone who has not yet made it and is on the path to success.

> Last month was Pat’s performance review, and after receiving a low score from his manager, Pat incredulously argued: > > “I’m one of the best programmers in this department!

If Pat made it to the "performance review" thinking he was a great developer while his manager was thinking otherwise, then the issue is Pat's manager not providing actionable feedback in a timely manner.

From there it's easy to hypothesize that the "deadlines" are given to him rather than discussed, and that maybe he's cutting corners to try and meet them.

Someone should invent a nice name for being tired of hearing about Gell Mann and Dunning Kruger. There’s never any new, clever, or interesting insight, they are only ever used to shit on someone the person invoking them doesn’t like.

It’s accidentally self referential. People who think it’s clever posting articles about dunning-Kruger are totally unaware it makes them look like a midwit, at the very least immature.

> and he doesn’t even remember his own code months later.

Horrible. Everybody knows you should both remember and cringe at your own code months later.

Awesome! I'm halfway there!

That part stood out to me as well. If I haven't seen or worked on a section of code for several months, it will take me a while to get back into it. At most, I might remember a high-level description or a particularly weird bug, but certainly not a detailed understanding of the code.

I surprise myself from time to time by picking up multi-year old aborted personal projects and finding them to be much more implemented than I recalled.

I hate to be that guy and I know this is not the point of the article but...

> Pat is a programmer at a large software company. At best, he’s a middling performer; his code is a mess (initializing variables that are never used, using variable names no one else understands, etc.), he takes longer than he should, and he doesn’t even remember his own code months later.

Sounds like this large software company doesn't:

1. Know about/use linters that catch unused variables.

2. Have a code review process that would catch bad variable names that "no one else understands".

3. How many people actually remember their own code months later? That's the whole point of consistent design and good readability?

Sounds like this large software company has some systemic problems (which may be caused by promoting people like Pat... which actually ties back to the point of the article I guess).

> How many people actually remember their own code months later?

Certainly not me. Not only do I often not remember the code, but sometimes I don't even remember working on that particular problem/feature at all.

Yeah, I thought it was a kind of strange point to prove that "Pat" is a bad programmer. I think most programmers, if they're being honest, would admit that they would have trouble recalling any kind of specifics about code that they wrote months before.

Write enough code and you're probably not going to have the headspace to remember it all...

Same. As tempting as it is to try and make code/documentation clear for others (which I do), I do it as much for 6-months-from-now me. This practice has saved me hours if not days over the last couple of years, and hopefully inspires other devs in my company to do the same.

> How many people actually remember their own code months later?

Certainly, I don't. After a month, I mostly think was this terrible/brilliant code really written by me. And then comments confirm it was me.

> he takes longer than he should

Ugh. I get that there are estimations for how long something will take but... Something takes as long as it takes. If consistently he takes longer to finish a task than estimated shouldnt the estimates be adjusted?

Feels like this should have 2017 in the title. This is just a light overview of what the Dunning-Kruger effect is (or was claimed to be), Pat sounds extremely fictional and conveniently useful to help describe "the effect" (which - if you search HN you'll find multiple links to a 2010[0] article challenging DKE, even the of-submitted Wikipedia page[1] expresses doubt).

[0]: https://www.talyarkoni.org/blog/2010/07/07/what-the-dunning-... [1]: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

First, this article is from 2017.

Second, it does not accurately describe the Dunning-Kruger effect.

Yes, people who are less skilled in an area over-estimate their level of skill and those who are more skilled tend to under-estimate. But the less skilled don't necessarily think they're better than the more skilled.

Basically, if your skill is a 5, you might think you're actually a 10. And if your skill is a 20, you might think you're an 18.

So just because someone thinks they're highly skilled, it doesn't mean they're experiencing Dunning-Kruger.

This probably varies hugely by industry/field/company, but what about when the metrics are nonsense? The metrics setters can also be incompetent(but think that they are competent!) and it’s probably a much larger issue than we think. For example, I work at a large multi billion dollar auto insurance company you have definitely heard of. One of the metrics is total losses settled with in 7 days as it correlates with higher customer satisfaction. However, they conflate correlation with causation: The customers were happier overall not because of the speed but because they were happier with the offer they received for the value of their vehicle and thus settled the claim quickly. Compared to the people who were unhappy with the offer and refused to settle their claim. This is something that is painfully obvious to those handling claims but goes right over the heads of the process and executive types. Just like the remembering their code from months ago metric in this article. I’m not even a programmer and I know that is not how it works.

The problem here is less “Pat” and more the managers or systems which allow Pat to reach the point in his career where he believes he is a good developer.

Some of Pat’s failings can be identified these days by code linters; and at least periodically if not in your CI on every push, listing should be done.

The usual problem is that the people deciding who to promote are not qualified or equipped to make sound judgements.

I'd go one step further and paraphrase some Deming and say that problem is both that Pat and the company are rating him against everyone else.

There are so many confounding factors in an organisational system that to try and rate people against each other effectively is nigh on impossible.

Also even if in some imaginary world you do manage to rate everyone against each other, guess what, half you people will be below average, that's statistics. And it could likely mean nothing to the effectiveness of your organisation.

In Pat's case and most software engineering we should set up the processes to ensure that quality is maintained. Add automated checking and testing, code style guide, clear service boundaries and all that.

There's been talk in the past of having some levels of certification required to be called a software developer/engineer. I'm not convinced this is a bad thing.

To be a pilot, you have to at least jump through a lot of hurdles and formalities, and some of those will make you better. I think the world of corporate software development could use a few fundamental hurdles.

The actual engineering professions have professional certifications that you have to attain to be allowed to do much of the (especially safety-critical) work of the profession [0] without supervision.

[0] https://www.nspe.org/resources/licensure/what-pe

The problem I feels is that we have no decent foundational standards and methodologies to build the software upon like we would a building or bridge.

Civil and structural engineering have a lot of the basics abstracted away in to easily reusable knowledge that can be applied from one project to the next.

Software engineering sometimes feels like we never managed to pull ourselves much further beyond a Leonardo Da Vinci drawing.

Also, we are again defaulting to assume that Pat is the problem here. He's likely an average software engineer, and if not then we've done a terrible job at education, hiring, or promotion, which again is not necessarily his fault.

The problem is the system, and certification would potentially resolve some aspects, but he still could be ranking himself incorrectly against other engineers and therefore we might be right back to square one.

I used to joke when I left academia that this combined with the imposter effect was why academia in the west is totally stalled. So many professors are positive they understand everything outside of their little silo as deeply as their silo, especially with regards to social policy and politics. It was quite shocking when more than a few suggested after a few drinks ideas that were inches from the sterilization programmes and such from the early 20th century. The people usually making it high up with people with the highest example of this effect because the effect gave them an extreme confidence in their statements even if they were totally wrong. The administration and such wouldn't realize this and they would get promotions etc.

Yet. Some of the smartest folks I met were convinced they were imposters and because of that didn't have the same confidence and usually were hen pecked to death because their analysis commonly differed from the social norm of the academic class.

> inches from the sterilization programmes and such from the early 20th century

How exactly? Given you are criticising your colleagues it's hard to determine how charitable this account is, especially since you give weight to descriptions given while inebriated, assuming that accurately represents their views.

I am being unbelievably charitable. Honestly I chalk it up to culture and the elitist attitude that permeates it. However at the same time there is a reason I specifically state after a few drinks. At least then it gives them an out. I know at least a few who discussed these ideas openly in the lunch room. Bad enough one day I had to get up and leave for my desk.

You might be interested in the book "Intellectuals and Society" by Thomas Sowell, it touches on that among other things.

I'll add it to my kindle.

I'm curious if one can inoculate oneself against this at all?

I follow a pattern of proactively trying to solicit critical feedback from coding peers as well as management. I've found this is a little unique, I think most people like the "no news is good news" model better.

I've found that often I have to dig hard to get people to give me some areas to improve upon. When I ask the "so where do I make changes to make me better", I often get a lot of compliments, I think because people are often uncomfortable sharing critical observations. I listen patiently and thank them, but then try to persist for areas of improvement. Giving people a day or two warning (I thought this might improve the process) just seems to amplify that effect.

But after all that, I wonder if I'm just "getting out ahead" of the DK effect by controlling its uncomfortable truths before they hit hard, in a subliminal effort to preserve my mediocrity.

I think one way is to do some activities where it's easy to see that you are not the best in the room. I lift weights for exercise. I can easily track my progress and improvement, but it's also obvious at a glance that there are others who are lifting more than I can. I then extrapolate that this applies to most everything else I do as well.

> At best, he’s a middling performer; his code is a mess (initializing variables that are never used, using variable names no one else understands, etc.), he takes longer than he should, and he doesn’t even remember his own code months later.

Not everyone is a top performer. If you're a large software company you're going to have lots of 'average' people.

The "his code is a mess" is hard to qualify.

Variables that are never used and no one understands? So this imaginary large software company doesn't use an IDE or linters of any kind? That seems quite unlikely.

He takes longer than he should? Because he's average and you're holding him to an above average standard? Or you've overloaded him with work which is quite likely.

>Dunning-Kruger Effect

An unproven hypothesis that is often misapplied and is absolutely misapplied in this case. This 'large software company' is clearly the major failure in this article and not some random engineer.

> you're going to have lots of 'average' people

Yes, by definition there will always be an average. But "average" for employed s/w devs should differ to national average - you can still expect developers to maintain certain standards, and that higher-ups will perform better (than say, the average s/w grad).

>Yes, by definition there will always be an average. But "average" for employed s/w devs should differ to national average - you can still expect developers to maintain certain standards, and that higher-ups will perform better (than say, the average s/w grad).

I dont disagree. The article to me reads differently. Like the author was digging for 'failures of a developer' but only proposed issues that are for sure failures of the company.

I expect the entire article is horseshit. A scenario that was invented in this dude's mind.

Out of interest I just checked out the authors other articles.

Topics ive noticed is Emotional Intelligence, burnout, racial/sexual discrimination, and performance reviews.

This guy has little to no clue about the tech side. He doesn't understand maintaining standards or how any of the software development process works.

Isn’t identifying Dunning Kruger effect in someone else a paradox? Fancy word for building a narrative. You can set up anyone to fail or succeed. I’d prefer to evaluate the situation as a whole, and usually the truth centers around circumstances.

> and he doesn’t even remember his own code months later

To be fair, this is also true of me. What can can done?

I assume the implication is that code isn't well enough documented/commented, or the code written was poor -but still, if you work on several fairly complicated, yet similar, issues in a few months, what can you do beyond re-read the original tickets/PR to recall the original context?

I have to say I just had this exact situation and conversation come up while visiting family in the south. They all complained about construction workers and not being able to find one that's competent they all think they're the best and they all do very very bad work. That's only in the South they have homes up north and they don't have that problem at all they're constantly trying to get their contractors to travel South to work for them. even people who were born and raised in Florida that were involved in this conversation agreed 100%.

I would read the article but I know it all already

Reply on news.ycombinator.com