Live data from Hacker News

Cognitive Dissonance in Programming

hangaroundtheweb.com

31–40 of 51 posts

Re: Cognitive Dissonance in Programming

#31
post #24

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.

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.

Re: Cognitive Dissonance in Programming

#32
post #27

Earlier 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…

> 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)?

Re: Cognitive Dissonance in Programming

#33
post #27

Earlier 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…

> But that is expensive so is not done.

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

#34
post #11

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 compile…

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.

Re: Cognitive Dissonance in Programming

#35
post #26

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.

Re: Cognitive Dissonance in Programming

#36
post #24

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.

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.

Re: Cognitive Dissonance in Programming

#37
post #11

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 compile…

Word up bro. Pushing 40 over here feeling the same way. Take it back to first principles. Remember Alan Turing and Vint Cerf.

Re: Cognitive Dissonance in Programming

#38
post #11

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 compile…

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.

Re: Cognitive Dissonance in Programming

#39
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.

Re: Cognitive Dissonance in Programming

#40
post #6

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 ex…

I think by definition if it's heavily plagiarized another source it's not a great article.
Post reply on HN