Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cognitive Biases in Programming

medium.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Cognitive Biases in Programming

#31

Post by mikeash »

dualogy wrote: post #30
mikeash wrote: post #26

I'd like to add one which I might call "Excessive machine sympathy." This is where the programmer shies away from using a certain technique because it's too difficult, not quite grasping that it's difficult for the computer but not for the programmer. I often see newer programmers acting like: f1() for element in array { f2() } Is easier to code than: for element in array { f1() f2() }

What kind of example is this, the 1st is an entirely different 'program' than the 2nd? Unless f1 is a no-op.

Yes, they're not the same program, but they're equally easy to write. I see people shying away from doing work in each iteration of the loop because of a feeling that it's more difficult to write the code.

Re: Cognitive Biases in Programming

#32

Post by mikeash »

onion2k wrote: post #27
mikeash wrote: post #26

I'd like to add one which I might call "Excessive machine sympathy." This is where the programmer shies away from using a certain technique because it's too difficult, not quite grasping that it's difficult for the computer but not for the programmer. I often see newer programmers acting like: f1() for element in array { f2() } Is easier to code than: for element in array { f1() f2() }

Did you mean to say 'easier'? I don't think I understand the point unless that should be 'harder'. Maybe I'm guilty of the bias you're talking about.

Yes, I see people thinking the first one is easier because they're thinking that you only do f1() once, instead of doing it thousands of times. In reality, both are equally easy to write, but it's hard for some people to shift their thinking from the work the computer does to the work the programmer does.

Re: Cognitive Biases in Programming

#33

Post by pgeorgi »

tomxor wrote: post #24

IKEA Effect: This is a good one, however I think it's also a bit oversimplified... >If you’ve ever worked for a company that used a dumb internal tool rather than a better out-of-the-box solution, you know what I’m talking about. This is probably not what the author is talking about, but there is a valid case for "inferior" in-house tools or libraries this overlooks. In some cases a suitable off the shelf component e…

> As i'm sure many people have experienced the opposite of "dumb internal tools" in the form of frustratingly buggy and unpredictable off the shelf components

For example pretty much everybody who has to use SAP, Navision or other such tools. Especially when it comes to upgrading all the local little modifications to the next service release, gah!

Re: Cognitive Biases in Programming

#34

Post by onion2k »

mikeash wrote: post #32
onion2k wrote: post #27

Earlier quoted context omitted.

Did you mean to say 'easier'? I don't think I understand the point unless that should be 'harder'. Maybe I'm guilty of the bias you're talking about.

Yes, I see people thinking the first one is easier because they're thinking that you only do f1() once, instead of doing it thousands of times. In reality, both are equally easy to write, but it's hard for some people to shift their thinking from the work the computer does to the work the programmer does.

That's really interesting. So the point is that they're effectively the same in the sense of the amount of work necessary to write the code, and putting in the effort to code the first one might be premature optimisation if running f1() thousands of times isn't actually an issue, or that you might need to debounce f1(), or guard against side effects, which is 'harder'.

I think I'd find it really hard to let go of the idea that my code might be doing something wasteful like calling a function it doesn't really need to call. Maybe it's because I've been coding since the early 90s when clock cycles and memory actually mattered a bit more. It's certainly given me something to think about. Thanks.

Re: Cognitive Biases in Programming

#35

Post by the_af »

mediocrejoker wrote: post #7
wakamoleguy wrote: post #5

This is a list of five cognitive biases that one could go research a lot deeper. On its own, the post doesn't offer much actionable advice on how to use or avoid these day to day. They even conflict in nonobvious ways. For example, I use the arrow keys in VIM rather than learning more efficient, more efficient navigation. You could call that hyperbolic discounting, but I consider it avoiding premature optimization (I…

Just to play devil's advocate: maybe you would use vim more frequently if you were more efficient and thus more productive with it?

To be honest, I found this to be an unfortunate example, especially when mentioned in the same paragraph as writing tests. Knowing all the shortcuts in VIM -- in fact, using VIM at all -- has very little impact in software productivity and quality. Remember, how efficiently a single programmer types matters very little, because that's not where most time in software development is spent, or where most problems arise, for that matter.

Re: Cognitive Biases in Programming

#36

Post by the_af »

emsy wrote: post #20
akvadrako wrote: post #13

Earlier quoted context omitted.

> So what if I use the arrow keys in my editor rather than learn some obscure magic to get where I want a bit quicker? Editor magic is overrated. I learned on vim and was proficient in it, but over time discovered productivity was higher by just using dumb navigation. Every editor feature I need to think about is some feature about the problem I'm working on that I need to forget.

Sounds like you were not proficient at all. I only ever need to think of vim features when it comes to macros/substitute, but those are things that save me tens of minutes of manual input. The rest is muscle memory. The key is to not religiously learn the shortcuts but only stick with the ones you need daily.

Do you think learning you editor's shortcut significantly affected the success of the product you were developing, as opposed to thinking about the problem, choosing the right design and architecture, writing useful tests, having good communication with the rest of the team, prioritizing the right features, etc?

I mean, I'm sure it had some impact, but how did it compare to the other factors I mentioned? My guess: proportionally, its impact must have been insignificant.

Re: Cognitive Biases in Programming

#37

Post by metaobject »

mikeash wrote: post #26

I'd like to add one which I might call "Excessive machine sympathy." This is where the programmer shies away from using a certain technique because it's too difficult, not quite grasping that it's difficult for the computer but not for the programmer. I often see newer programmers acting like: f1() for element in array { f2() } Is easier to code than: for element in array { f1() f2() }

Assuming f1() has side effects, those two blocks of code may be very different.

Re: Cognitive Biases in Programming

#38

Post by tchaffee »

seanmcdirmid wrote: post #2

Hyperbolic Discounting Sounds really weak. So what if I use the arrow keys in my editor rather than learn some obscure magic to get where I want a bit quicker? Likewise, testing is always in that area that is nice to have in code that is going to last more than a few days, but adding them in up front when you are still exploring the design and solution space is just dumb (up there with premature abstraction).

Writing tests is a great way to explore both the design and solution space. For me, that's more than half the value of writing tests. The fact that they can serve as tests after the fact is just an extra bonus.

Re: Cognitive Biases in Programming

#39

Post by dahart »

All of these biases certainly exist. What I want to see is some evidence of how often these actually occur, how much damage each one does, and what ways exist to mitigate them.

I would agree it helps to become aware, but I honestly don't know how to mitigate any of them. It seems like all of them involve predicting the future. I don't know what payoff I'm going to get if I learn vim's wacky and hidden keyboard commands, and the payoff isn't likely to be large if I avoid using vim whenever possible.

Hyperbolic discounting seems like a generally good bias to have - unless I have a very specific bet in mind or the big payoff is an obvious benefit to me or a requirement of some kind, then choosing quick wins is probably the right choice more often than not.

Premature optimization seems like almost the exact opposite of hyperbolic discounting, and avoiding premature optimization feels like the right decision the majority of the time.

But I never know for sure which one was actually the right choice until long after the decision has been made. I've certainly optimized things that didn't need to be, and I've certainly gone for quick wins and regretted not planning for a bigger payoff.

Re: Cognitive Biases in Programming

#40

Post by mikeash »

metaobject wrote: post #37
mikeash wrote: post #26

I'd like to add one which I might call "Excessive machine sympathy." This is where the programmer shies away from using a certain technique because it's too difficult, not quite grasping that it's difficult for the computer but not for the programmer. I often see newer programmers acting like: f1() for element in array { f2() } Is easier to code than: for element in array { f1() f2() }

Assuming f1() has side effects, those two blocks of code may be very different.

Of course. The point is that people seek solutions of the first form thinking that it’s easier to write.
Post reply on HN