6 ms·

Cognitive Biases in Programming

109 points by yranadive 9y ago

seanmcdirmid 9y ago
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).
- throwanem 9y ago
  Navigating by search is so much faster - at least in Emacs, where you can get back where you started with a single chord. One of the many reasons I use anything else only under severest duress. No counting, no slow tap-tap-tap and watching the cursor move, no nothing. No struggle to get there, no struggle to get back where you were before you went. No effort. See a thing and jump to it. Do whatever, then jump back. Nothing else I've ever used is like it.
  - seanmcdirmid 9y ago
    But this is like typing speed. If I could type twice as fast, my productivity isn't going to improve much because my programming bottlenecks are mental. What this does allow you to do is develop a nice rhythm, it can be annoying to go back to the old way, but in the big scheme, it probably doesn't effect your productivity that much.
    - yaantc 9y ago
      I think there's an important difference. A great part of a developer time is reading code (even one's own), and navigation is part of it. While typing speed is only relevant to writing code. That makes efficient navigation more important than efficient typing speed. Personally, I never cared much about my typing speed (just enough to move from "pathetic French guy typing with two fingers" to "hey I use a majority of my fingers and don't need to look at the keyboard most of the time"), but I do use emacs navigation heavily.
      - SeanDav 9y ago
        I agree with what you say, but using an editor with bookmarks and simple find ability - and almost every editor has these - is more than enough for efficient navigation of code. One does not have to spend months using vim/emacs until its use becomes muscle memory, to efficiently browse code.
        speedplane 9y ago
        A simple feature of almost all programming editors, having two files open side by side, vastly reduces the amount of short term mental juggling you need to do.
        throwanem 9y ago
        What's really nice is being able to split the window in which you're viewing a file, and keep part of it visible in one pane while using the other to browse or to read another part. (Or, similarly, being able to have two windows side by side on the same file.) When you have strongly interdependent sections of code which are far enough apart that they can't both fit in the same viewport, this is invaluable for quickly gaining a grasp of what's going on.
    - KSteffensen 9y ago
      So you might as well use sed as Eclipse for doing your programming?
- sidcool 9y ago
  It's more about efficiency in doing repeatable tasks.
- akvadrako 9y ago
  > 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.
  - emsy 9y ago
    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.
    - the_af 9y ago
      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.
- mikeash 9y ago
  I find it extremely ironic that one of the biases is "premature optimization," and then it goes on to say that you should immediately stop using the arrow keys to navigate because "You end up saving a lot of time."
- tchaffee 9y ago
  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.
raspasov 9y ago
A bunch of non-falsifiable claims with a colorful unrelated brain graphic. Not very useful.
partycoder 9y ago
The brain can make real-time decisions because it does not evaluates reality from scratch at every moment, but rather runs everything through a learned model of the world. That model is based off incomplete information, and will always be biased.
wakamoleguy 9y ago
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 don't use VIM often). Getting caught up in cognitive biases is itself an example of a problem that interferes with our productivity. It doesn't strike me as a useful view of the big picture, other than the realization that perhaps software engineering is all about balancing these sorts of conflicting factors. E.g., know when to experiment, quick and dirty, and now when to go deep in refactoring.
- mediocrejoker 9y ago
  Just to play devil's advocate: maybe you would use vim more frequently if you were more efficient and thus more productive with it?
  - the_af 9y ago
    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.
    - c22 9y ago
      Learning vim commands won't increase how fast you type, it will increase how fast you edit.
      - the_af 9y ago
        Again, does it matter how fast you edit when compared to spotting what to edit, which change to make, and how to explain it to your teammates? I think it matters very little. Obviously, if you're so slow you it drives your teammates crazy then it becomes a problem, but really, I don't think the difference lies in learning VIM's shortcuts.
mathattack 9y ago
Seems like an aggregate explanation for why technical debt exists. :-)
TwoBit 9y ago
There needs to be one about scar tissue. Programmers tend to fear doing anything that they feel burned them in the past.
- whipoodle 9y ago
  Weird. They almost sound like.... humans, or something.
joe_the_user 9y ago
Hmm, I would like to add a couple more - I'd be interested if either of these has a name: * Assuming that complexity is additive. * Assuming that complexity of an extension to a piece of software is proportionate to the difficulty of imagining such an extension.
- ak39 9y ago
  These are good. I love it when my initial assumption that an imagined new feature would be a complex and painful refactoring exercise only to find out that a few lines of change was all that was required! Those days I almost feel like the universe has purpose.
  - speedplane 9y ago
    Sadly, those days are few and far between.
  - gm-conspiracy 9y ago
    Good architect.
whipoodle 9y ago
People who don’t use their text editor in the manner I do have a brain disease- oops, I mean cognitive bias.
tomxor 9y ago
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 exists, but is an over-generalised, over-complicated black box with the associated disadvantages. If this component is an important piece of your product or business, and you only need a fraction of the functionality provided by the off the shelf one, then it can be preferable to create an in-house version to gain simplicity, focus, insight and control. 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, when these problems are too broad to reconcile with upstream contributions it's sometimes worth creating a less-capable "inferior" internal version more suited to your use-case.
- pgeorgi 9y ago
  > 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!
mikeash 9y ago
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() }
- onion2k 9y ago
  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.
  - mikeash 9y ago
    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.
    - onion2k 9y ago
      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.
      - mikeash 9y ago
        What I've seen isn't even a matter of worrying about being wasteful with CPU cycles, it's a gut reaction against it because it feels like more work.
jankotek 9y ago
> Have you ever found yourself using the arrow keys in Vim? Real problem is that you are forced to use Vim. For a long time it was the only decent code editor for terminal. Vi is still default editor on many distros.
deleted 9y ago
[deleted]
dahart 9y ago
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.
luord 9y ago
"IKEA effect" seems to be a different name for the "NIH syndrome", which I prefer to call "ownership preference" anyway, mostly because it doesn't use a brand name or an acronym.

109 points by yranadive 9y ago

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

throwanem 9y ago
Navigating by search is so much faster - at least in Emacs, where you can get back where you started with a single chord. One of the many reasons I use anything else only under severest duress. No counting, no slow tap-tap-tap and watching the cursor move, no nothing. No struggle to get there, no struggle to get back where you were before you went. No effort. See a thing and jump to it. Do whatever, then jump back. Nothing else I've ever used is like it.
- seanmcdirmid 9y ago
  But this is like typing speed. If I could type twice as fast, my productivity isn't going to improve much because my programming bottlenecks are mental. What this does allow you to do is develop a nice rhythm, it can be annoying to go back to the old way, but in the big scheme, it probably doesn't effect your productivity that much.
  - yaantc 9y ago
    I think there's an important difference. A great part of a developer time is reading code (even one's own), and navigation is part of it. While typing speed is only relevant to writing code. That makes efficient navigation more important than efficient typing speed. Personally, I never cared much about my typing speed (just enough to move from "pathetic French guy typing with two fingers" to "hey I use a majority of my fingers and don't need to look at the keyboard most of the time"), but I do use emacs navigation heavily.
    - SeanDav 9y ago
      I agree with what you say, but using an editor with bookmarks and simple find ability - and almost every editor has these - is more than enough for efficient navigation of code. One does not have to spend months using vim/emacs until its use becomes muscle memory, to efficiently browse code.
      - speedplane 9y ago
        A simple feature of almost all programming editors, having two files open side by side, vastly reduces the amount of short term mental juggling you need to do.
        throwanem 9y ago
        What's really nice is being able to split the window in which you're viewing a file, and keep part of it visible in one pane while using the other to browse or to read another part. (Or, similarly, being able to have two windows side by side on the same file.) When you have strongly interdependent sections of code which are far enough apart that they can't both fit in the same viewport, this is invaluable for quickly gaining a grasp of what's going on.
  - KSteffensen 9y ago
    So you might as well use sed as Eclipse for doing your programming?
sidcool 9y ago
It's more about efficiency in doing repeatable tasks.
akvadrako 9y ago
> 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.
- emsy 9y ago
  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.
  - the_af 9y ago
    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.
mikeash 9y ago
I find it extremely ironic that one of the biases is "premature optimization," and then it goes on to say that you should immediately stop using the arrow keys to navigate because "You end up saving a lot of time."
tchaffee 9y ago
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.

raspasov 9y ago

A bunch of non-falsifiable claims with a colorful unrelated brain graphic. Not very useful.

partycoder 9y ago

The brain can make real-time decisions because it does not evaluates reality from scratch at every moment, but rather runs everything through a learned model of the world. That model is based off incomplete information, and will always be biased.

wakamoleguy 9y ago

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 don't use VIM often). Getting caught up in cognitive biases is itself an example of a problem that interferes with our productivity. It doesn't strike me as a useful view of the big picture, other than the realization that perhaps software engineering is all about balancing these sorts of conflicting factors. E.g., know when to experiment, quick and dirty, and now when to go deep in refactoring.

mediocrejoker 9y ago
Just to play devil's advocate: maybe you would use vim more frequently if you were more efficient and thus more productive with it?
- the_af 9y ago
  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.
  - c22 9y ago
    Learning vim commands won't increase how fast you type, it will increase how fast you edit.
    - the_af 9y ago
      Again, does it matter how fast you edit when compared to spotting what to edit, which change to make, and how to explain it to your teammates? I think it matters very little. Obviously, if you're so slow you it drives your teammates crazy then it becomes a problem, but really, I don't think the difference lies in learning VIM's shortcuts.

mathattack 9y ago

Seems like an aggregate explanation for why technical debt exists. :-)

TwoBit 9y ago

There needs to be one about scar tissue. Programmers tend to fear doing anything that they feel burned them in the past.

whipoodle 9y ago
Weird. They almost sound like.... humans, or something.

joe_the_user 9y ago

Hmm, I would like to add a couple more - I'd be interested if either of these has a name: * Assuming that complexity is additive. * Assuming that complexity of an extension to a piece of software is proportionate to the difficulty of imagining such an extension.

ak39 9y ago
These are good. I love it when my initial assumption that an imagined new feature would be a complex and painful refactoring exercise only to find out that a few lines of change was all that was required! Those days I almost feel like the universe has purpose.
- speedplane 9y ago
  Sadly, those days are few and far between.
- gm-conspiracy 9y ago
  Good architect.

whipoodle 9y ago

People who don’t use their text editor in the manner I do have a brain disease- oops, I mean cognitive bias.

tomxor 9y ago

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 exists, but is an over-generalised, over-complicated black box with the associated disadvantages. If this component is an important piece of your product or business, and you only need a fraction of the functionality provided by the off the shelf one, then it can be preferable to create an in-house version to gain simplicity, focus, insight and control. 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, when these problems are too broad to reconcile with upstream contributions it's sometimes worth creating a less-capable "inferior" internal version more suited to your use-case.

pgeorgi 9y ago
> 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!

mikeash 9y ago

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() }

onion2k 9y ago
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.
- mikeash 9y ago
  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.
  - onion2k 9y ago
    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.
    - mikeash 9y ago
      What I've seen isn't even a matter of worrying about being wasteful with CPU cycles, it's a gut reaction against it because it feels like more work.

jankotek 9y ago

> Have you ever found yourself using the arrow keys in Vim? Real problem is that you are forced to use Vim. For a long time it was the only decent code editor for terminal. Vi is still default editor on many distros.

deleted 9y ago

[deleted]

dahart 9y ago

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.

luord 9y ago

"IKEA effect" seems to be a different name for the "NIH syndrome", which I prefer to call "ownership preference" anyway, mostly because it doesn't use a brand name or an acronym.