I thought this was an interesting article, but in real life I'm not quite sure how big the problem of programmers being unwilling to admit their own mistakes is.
A checkin goes through many checks and eyes in which mistakes are bound to surface, and not admitting to those mistakes is not really an option most of the time. What's more, they are different kinds of checks, so if you can find an excuse for one thing telling you something is broken it's likely you won't have an excuse for the next. By the time a CL goes from code review to autotests + CI, you've potentially had to admit to a few mistakes or things you could've done better. This happens daily in my workplace - and it's not that these checks are foolproof and we all check in perfect code, but there are certainly a lot of silly and not silly mistakes in both approach and syntax which we regularly have to admit to making.
Cognitive dissonance appears to be a very big problem with security - people not aggressively auditing their systems, rationalizing away concerns, etc.
I think this has a lot to do with certain developers not knowing much about security and not wanting to go down the rabbit hole of potential threats and concerns. In my experience a lot of people from project managers to developers would just rather ignore things they don't really understand (especially if it's not causing an immediate problem).
Especially true because customers rarely want to pay for it and when there are issues you just sweep them under the rug and move on. Developers are the last people we should look to blame / change if we want better security.
I did not mean to suggest that it is exclusively or even primarily a developer problem, though developers do also have a role, for example in following best practices.
Right. The author seems to talk about typos and simple bugs in the code, but every programmer makes those on a regular basis and no way anyone could deny such a bug when it's pointed out to them.
This cognitive dissonance seems like it may be more applicable at a higher level, when talking about design flaws in the system. There the programmer can actually come up with excuses for their "issues". For example, if someone complains "but your design won't scale to 1 million customers" the programmer might reply "come one, we need to be fast" or "we won't need that kind of scale until years from now"
> A programmer who truly sees his program as an extension of his own ego is not going to be trying to find all the errors in that program. On the contrary, he is going to be trying to prove that the program is correct – even if this means the oversight of errors which are monstrous to another eye.
From the original 1989 "Version 1.0" of The Hacker Test[1]:
0477 Ever spend ten minutes trying to find a single-character error?
0478 ... More than an hour?
0479 ... More than a day?
0480 ... More than a week?
0481 ... Did the first person you show it to find it immediately?
I don't know if this is caused by cognitive dissonance of the ego, "highway hypnosis"-style blindness from staring at your own code for too long, or something else. Regardless, programmers have always had this problem.
A pattern in Conway's Life that generates an infinite pattern of live cells. (it's a pattern that drives forward across the cellular automata universe, continuously puffing out permanently-live "smoke")
I freely admit I'm defective. Software development is a constant cycle of solving problems and then solving the problems created by solving the previous problems. Fortunately, I love solving problems.
I am the same. In fact, there are whole classes of bugs that you overlook when you don’t consider it could be a stupid mistake that you, the programmer made.
For example, if you’ve ever written a “perfectly good, you know it has to work piece of code” and spent hours trying to prove that the compiler is wrong, or some other crazy reason. If you are humble about it, you can more quickly accept that you might have made a mistake and possibly find it more quickly.
This class of bug is, to me, the “it’s impossible for this code to break” type, where it really is impossible and you made an obvious mistake. In the rare cases where it is a serious problem and not your fault (also possible, but quite rare), it’s important to know how to do the hard work to debug deeply.
A skilled programmer knows both how to trust their tools, question themselves, but also how to question, build or fix their tools if necessary. I think patience/persistence and confidence/humility gained through experience, combined with being creative, thoughtful, open-minded and somewhat of a perfectionist (but not completely one!) is what it takes to code.
This is a great article and more people should read it. I was wondering why the sentences sound so familiar and it turns out it's heavily plagiarised (as in, a substantial number of sentences and paragraphs are
lifted verbatim from) Gerald Weinberg's book The Psychology of Computer Programming (listed at the end as one of the "references").
Read this book; much of it is still very applicable decades later (and the exercise of translating it into modern terms makes you think and is valuable too).
I was about to say the same; the phrase "The programmer comes down the hall with his output listing and it is very thin..." certainly shows its age. The message, however, is just as relevant now as it was then.
Depends on your definitions. If someone makes a copy of the Mona Lisa and claims it as their own, does it stop being a great painting? (Or if you don't think the Mona Lisa is a great painting, replace with whatever you think is.)
In fact given what I can tell of the author(s) in this case, we should be grateful it's so heavily plagiarized; the less they plagiarized (and the more they inserted their own content), it seems the worse it would be. :-)
----------------------------------
BTW I took a look at the article again, and it contains solely of two paragraphs picked up verbatim from Wikipedia, followed by the remaining paragraphs each verbatim from book. The only changes I could detect were:
1. where the book mentions "Starting with the work of the social psychologist Festinger", the article has "Starting with the work of the social psychologist Leon Festinger" with a link to the Wikipedia article for him
2. the article introduces random bolding of various words
3. where the book says
> There are thousands of variations to these plaints, but the one thing we never seem to hear is a simple...
the article says (turning the correct "hear" into "here")
> There are thousands of variations to these objections, if you are interested in finding more, check out devexcuses or programmingexcuses. But the one thing we never seem to here is a simple...
Apart from that, there doesn't seem to be a single original sentence in the article.
It is an interesting perspective, but I find it flawed. First of all, the author doesn't seem to understand artists, so those analogies fail. Secondly the comment of: "But the one thing we never seem to hear* is a simple 'I goofed again.'" tells me they haven't worked with many senior devs. I find once devs have enough experience to not have self-esteem issues over their own skills, there is little hesitation to admit mistakes. If we limit the scope of the article to being about newer devs, though, the content holds more value.
Maybe, but I would caution against assuming that either age or experience are antidotes to the phenomena described in the article. I've met some very experienced people (as in multiple decades of experience) who were still pretty insecure, and it definitely affected their work in exactly the ways described in the article. So to me it seems like genuine self confidence (or lack thereof) is a bigger factor.
The thing is "a simple I made an error" is not a good enough reason: everybody makes mistakes but why weren't they caught in UT, ET, code review?
Explaining the cause of errors and improving the process (IF necessary) is much more interesting than "sorry, I made a mistake".
It's implied, isn't it? "I goofed up" is admitting that "I didn't test it thoroughly".
A more interesting question, imo, is: how does the user/customer community receive an honest admission of goofing up? Do users/customers think less of the programmer? Or do they value the honesty?
Yes, sure, because the programmer is the oracle of testing.
There are redundancies that should be set up in the development process for this reason.
Admitting the mistake gives you nothing but low opinion of everyone involved. (which is in itself sad)
The only thing to do is to set up whole systems to prevent them from arising again. But that is expensive so is not done. Instead, everyone is moderately discontented with the junk they use.
> Yes, sure, because the programmer is
> the oracle of testing.
I'm assuming the above is sarcasm?
> There are redundancies that should be
> set up in the development process for
> this reason.
Of course there should be tests, redundancies, fault-tolerant mechanisms and recovery systems _when_ errors/disasters occur. But these constructs are only functions of investments in time and money - and there is no absolute endpoint for tests which can signal that a program is completely error-free, only sufficiently error-free. And that word "sufficiently" is function of money and time. Developers and sponsors make explicit decisions about how much and what kind of testing is sufficient.
> Admitting the mistake gives you nothing
> but low opinion of everyone involved.
> (which is in itself sad)
If that has been your experience, would you mind sharing the anecdote(s)?
The goal is to produce, as efficiently as possible, programs that work adequately for their intended purpose. "Work adequately" does not mean perfection. The optimal solution has failures in almost all directions - not-quite-rigorous processes, not catching all bugs, not testing all scenarios, just-barely-adequate code review, just-barely-adequate tests, and so on. To "improve" any of those would be to make the whole process more inefficient.
That's at best, when management knows what they're doing. At worst, those things are totally missing, and technical debt kills you later.
Indeed, I find the value of programming, emotionally, comes in part as a test of oneself against the inanimate world. There's no negotiating with a program, no sales, no bullying. If it doesn't work, it is abundantly clear whose fault that is. In its own way, this is a very comforting perspective. Read Shop Class as Soulcraft, by Matthew Crawford (one of my favorite books), for more on this.
One outcome of Crawford's analysis is that really skilled craftsmen (he would consider programming a craft) are excellent at admitting failure - it's the only path to success.
I do agree the author of the article doesn't seem to understand artists, and appears quite prejudiced against the artistic creative process. Creating art seriously is every bit as challenging as programming, mostly in the same ways.
I wanted to be a programmer from the age of 8. I noodled around a bit in BASIC, and then taught myself C at around 15 or 16. I was easily into my 20s before I could even reasonably claim that I understood C.
I've turned 40 this year and even though I've written a lot of code in the last 30 years, I still don't really feel like I'm a good programmer, so I tend to always blame myself before the libraries or the compiler or the daemons or the hardware.
Yeah, if you still call yourself bad at something you've practiced daily for thirty years, most likely what needs to be corrected is not your skill set but your definition of competence.
Plus, programming is extremely broad. You could spend 10 years mastering embedded linux programming yet know little to nothing about data science programming, game programming, GPU/VFX/shader programming, HDL programming, etc. There's simply too much to learn.
If you don't feel like you know less and less every year that you are doing something then you are not gaining any wisdom and will likely never be truly great at it.
Yes! This is a healthy attitude. Others say don't beat yourself up about it, I would say it's not about that, just not making assumptions that are useless.
Sometimes it is a network error, or a hardware error, but at the end of the day, you can't just point at that and blame it, you've got to try to work around it, or at least fail in a way that looks like you tried and point out what the source of the issue is. It feels like playing whackamole sometimes though.
You can get a pretty good assessment of someone's C++ knowledge by asking them to rate themselves out of 10, and then subtracting their answer from 10.
If they say 9/10 and they are not Bjarne Stroustrup, it's a good bet their actual ability is close to 1/10.
I've not been programming as long, but a fair chunk of years now. I feel the same way. I think being self taught makes it worse for me as I'm in a workplace where the majority of people are hugely intelligent and have university degrees, I just felt like I didn't belong. I'm just now starting to come to terms with the idea that I'm actually as good at what I do as anybody, so I no longer feel like as much of an impostor, but this has done nothing to change the fact that I still think I just don't know enough. There is so much more to learn that I haven't even touched on, it is both intimidating and inspiring. Reading similar sentiments from people who have been programming for much longer than I have is giving me the sense that this feeling might not go away, ever.
I disagree with article on so many levels. Positions where you truly code alone are rare. The issue of ownership is oftentimes issue of autonomy which is completely normal thing to seek. I heard programmers admit mistakes routinelly - except two rather toxic environments.
I don't see this is a real problem in professional development. The program owner or customer decides whether the behavior of the program is correct or not - not the programmer and not "the computer".
It's not as straightforward. I mean, I wish it would be...
POs or customers don't decide wether code is correct or behavior is correct. The more adequate word would be that they design wether it's useful or not, wether it's good enough or nor or wether it's on spec. Behaviour and program correctness are Comp. Sci. disciplines and coder/engineer responsibilities.
This reads like someone who works only with junior devs or not very good devs. I work on a team of senior devs who are very good and if there is ever an issue where it could be attributable to one or more people, those people will argue about who created the bug: "It is probably related to the code I added yesterday, I will fix it." ... "No, I'm pretty sure it is my code. I'll take a look".
The best way to improve is to admit to yourself that you can always be better. Someone who thinks they are the best has no reason to improve. Anecdotally, I've found the people who can admit their mistakes easily are some of the best programmers I've met.
>But the one thing we never seem to here is a simple: I goofed again
We don't? Who is this guy working with? And keep them far away from me.
There are some good points in here about separating ego from work, and accepting that flaws are an inevitability born from the complexity of software development.
But it's roundabout, uses an unnecessary (and at points erroneous) line of reasoning to get there.
It also conflates the need for "fresh eyes" in problem solving with some ego issue. - How many times have you struggled with something, stepped away for a moment, and come back to find the solution immediately? Or sent code out for a code review, taken it off your mental load, then immediately spotted bugs when you re-visit the code a day or two later?
I was almost derailed by the grossly oversimplified programmer personality dorito chart at the beginning. Personality types are merely stereotypes for shortcutting the immensely complex network of factors underlying every decision in every individual and should not be wielded without a deeper understanding.
Soldier past that part and the article espouses a lamentation common in all social situations: that people often seem to deny truth to protect the integrity of the reality they currently grasp. The essay experiment where groups are interviewed about the deltas in their perceptions after one group is paid $20 to write an essay supporting a viewpoint they oppose and another is paid $1 demonstrates this nicely. The fact that those paid $20 hold on to their original views with more conviction seems to suggest that it is the value people place on their past ideas (more so the efficacy of the abilities they used to arrive to them I suspect) that precludes them from considering the current ideas being proposed.
There is likely nothing special about the environment of programming that gives rise to this phenomenon, and it is probably something more fundamental to the way that humans have grown to interpret the world around them that causes this situation. Anyone who's ever tried to have reasonable discourse with a scouting attitude rather than soldiering one on any subject will have noticed that at some point, some people seem to double down when presented with clear evidence against their views.
50 comments
[ 4.1 ms ] story [ 105 ms ] threadA checkin goes through many checks and eyes in which mistakes are bound to surface, and not admitting to those mistakes is not really an option most of the time. What's more, they are different kinds of checks, so if you can find an excuse for one thing telling you something is broken it's likely you won't have an excuse for the next. By the time a CL goes from code review to autotests + CI, you've potentially had to admit to a few mistakes or things you could've done better. This happens daily in my workplace - and it's not that these checks are foolproof and we all check in perfect code, but there are certainly a lot of silly and not silly mistakes in both approach and syntax which we regularly have to admit to making.
This cognitive dissonance seems like it may be more applicable at a higher level, when talking about design flaws in the system. There the programmer can actually come up with excuses for their "issues". For example, if someone complains "but your design won't scale to 1 million customers" the programmer might reply "come one, we need to be fast" or "we won't need that kind of scale until years from now"
From the original 1989 "Version 1.0" of The Hacker Test[1]:
I don't know if this is caused by cognitive dissonance of the ego, "highway hypnosis"-style blindness from staring at your own code for too long, or something else. Regardless, programmers have always had this problem.[1] http://www.hungry.com/~jamie/hacktest.text
You stare at it and stare at it and get so used to it that you don't notice that you needed a > where you have a <.
A pattern in Conway's Life that generates an infinite pattern of live cells. (it's a pattern that drives forward across the cellular automata universe, continuously puffing out permanently-live "smoke")
For example, if you’ve ever written a “perfectly good, you know it has to work piece of code” and spent hours trying to prove that the compiler is wrong, or some other crazy reason. If you are humble about it, you can more quickly accept that you might have made a mistake and possibly find it more quickly.
This class of bug is, to me, the “it’s impossible for this code to break” type, where it really is impossible and you made an obvious mistake. In the rare cases where it is a serious problem and not your fault (also possible, but quite rare), it’s important to know how to do the hard work to debug deeply.
A skilled programmer knows both how to trust their tools, question themselves, but also how to question, build or fix their tools if necessary. I think patience/persistence and confidence/humility gained through experience, combined with being creative, thoughtful, open-minded and somewhat of a perfectionist (but not completely one!) is what it takes to code.
Read this book; much of it is still very applicable decades later (and the exercise of translating it into modern terms makes you think and is valuable too).
In fact given what I can tell of the author(s) in this case, we should be grateful it's so heavily plagiarized; the less they plagiarized (and the more they inserted their own content), it seems the worse it would be. :-)
----------------------------------
BTW I took a look at the article again, and it contains solely of two paragraphs picked up verbatim from Wikipedia, followed by the remaining paragraphs each verbatim from book. The only changes I could detect were:
1. where the book mentions "Starting with the work of the social psychologist Festinger", the article has "Starting with the work of the social psychologist Leon Festinger" with a link to the Wikipedia article for him
2. the article introduces random bolding of various words
3. where the book says
> There are thousands of variations to these plaints, but the one thing we never seem to hear is a simple...
the article says (turning the correct "hear" into "here")
> There are thousands of variations to these objections, if you are interested in finding more, check out devexcuses or programmingexcuses. But the one thing we never seem to here is a simple...
Apart from that, there doesn't seem to be a single original sentence in the article.
A more interesting question, imo, is: how does the user/customer community receive an honest admission of goofing up? Do users/customers think less of the programmer? Or do they value the honesty?
There are redundancies that should be set up in the development process for this reason.
Admitting the mistake gives you nothing but low opinion of everyone involved. (which is in itself sad) The only thing to do is to set up whole systems to prevent them from arising again. But that is expensive so is not done. Instead, everyone is moderately discontented with the junk they use.
I'm assuming the above is sarcasm?
> There are redundancies that should be > set up in the development process for > this reason.
Of course there should be tests, redundancies, fault-tolerant mechanisms and recovery systems _when_ errors/disasters occur. But these constructs are only functions of investments in time and money - and there is no absolute endpoint for tests which can signal that a program is completely error-free, only sufficiently error-free. And that word "sufficiently" is function of money and time. Developers and sponsors make explicit decisions about how much and what kind of testing is sufficient.
> Admitting the mistake gives you nothing > but low opinion of everyone involved. > (which is in itself sad)
If that has been your experience, would you mind sharing the anecdote(s)?
The goal is to produce, as efficiently as possible, programs that work adequately for their intended purpose. "Work adequately" does not mean perfection. The optimal solution has failures in almost all directions - not-quite-rigorous processes, not catching all bugs, not testing all scenarios, just-barely-adequate code review, just-barely-adequate tests, and so on. To "improve" any of those would be to make the whole process more inefficient.
That's at best, when management knows what they're doing. At worst, those things are totally missing, and technical debt kills you later.
One outcome of Crawford's analysis is that really skilled craftsmen (he would consider programming a craft) are excellent at admitting failure - it's the only path to success.
I do agree the author of the article doesn't seem to understand artists, and appears quite prejudiced against the artistic creative process. Creating art seriously is every bit as challenging as programming, mostly in the same ways.
I've learned not to beat myself up about it.
If they say 9/10 and they are not Bjarne Stroustrup, it's a good bet their actual ability is close to 1/10.
https://en.wikipedia.org/wiki/Dunning–Kruger_effect
And so on.
POs or customers don't decide wether code is correct or behavior is correct. The more adequate word would be that they design wether it's useful or not, wether it's good enough or nor or wether it's on spec. Behaviour and program correctness are Comp. Sci. disciplines and coder/engineer responsibilities.
The best way to improve is to admit to yourself that you can always be better. Someone who thinks they are the best has no reason to improve. Anecdotally, I've found the people who can admit their mistakes easily are some of the best programmers I've met.
We don't? Who is this guy working with? And keep them far away from me.
There are some good points in here about separating ego from work, and accepting that flaws are an inevitability born from the complexity of software development.
But it's roundabout, uses an unnecessary (and at points erroneous) line of reasoning to get there.
It also conflates the need for "fresh eyes" in problem solving with some ego issue. - How many times have you struggled with something, stepped away for a moment, and come back to find the solution immediately? Or sent code out for a code review, taken it off your mental load, then immediately spotted bugs when you re-visit the code a day or two later?
Soldier past that part and the article espouses a lamentation common in all social situations: that people often seem to deny truth to protect the integrity of the reality they currently grasp. The essay experiment where groups are interviewed about the deltas in their perceptions after one group is paid $20 to write an essay supporting a viewpoint they oppose and another is paid $1 demonstrates this nicely. The fact that those paid $20 hold on to their original views with more conviction seems to suggest that it is the value people place on their past ideas (more so the efficacy of the abilities they used to arrive to them I suspect) that precludes them from considering the current ideas being proposed.
There is likely nothing special about the environment of programming that gives rise to this phenomenon, and it is probably something more fundamental to the way that humans have grown to interpret the world around them that causes this situation. Anyone who's ever tried to have reasonable discourse with a scouting attitude rather than soldiering one on any subject will have noticed that at some point, some people seem to double down when presented with clear evidence against their views.