Earlier quoted context omitted.
There will always be things you dont know. I've learned not to beat myself up about it.
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.
Cognitive Dissonance in Programming
31–40 of 51 posts
Re: Cognitive Dissonance in Programming
#32Earlier quoted context omitted.
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 w…
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)?
Re: Cognitive Dissonance in Programming
#33Earlier quoted context omitted.
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 w…
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.
Re: Cognitive Dissonance in Programming
#34I 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 compile…
Re: Cognitive Dissonance in Programming
#35I 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".
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.
Re: Cognitive Dissonance in Programming
#36Earlier quoted context omitted.
There will always be things you dont know. I've learned not to beat myself up about it.
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.
Re: Cognitive Dissonance in Programming
#37I 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 compile…
Re: Cognitive Dissonance in Programming
#38I 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 compile…
If they say 9/10 and they are not Bjarne Stroustrup, it's a good bet their actual ability is close to 1/10.
Re: Cognitive Dissonance in Programming
#39The 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.
Re: Cognitive Dissonance in Programming
#40This 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 ex…