Cognitive Biases in Programming

https://medium.com/@evidanary/cognitive-biases-in-programming-5e937707c27b

by yranadive • 9 years ago

109 47 9 years 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).

throwanem2• 9 years 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.

seanmcdirmid2• 9 years 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.

sidcool• 9 years ago

It's more about efficiency in doing repeatable tasks.

akvadrako• 9 years 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• 9 years 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.

mikeash7• 9 years 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• 9 years 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• 9 years ago

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

partycoder• 9 years 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• 9 years 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• 9 years 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_af3• 9 years 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.

mathattack• 9 years ago

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

TwoBit• 9 years ago

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

whipoodle2• 9 years ago

Weird. They almost sound like.... humans, or something.

joe_the_user• 9 years 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• 9 years 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.

speedplane2• 9 years ago

Sadly, those days are few and far between.

gm-conspiracy• 9 years ago

Good architect.

whipoodle2• 9 years ago

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

tomxor• 9 years 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• 9 years 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!

mikeash7• 9 years 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()
  }

onion2k2• 9 years 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.

mikeash7• 9 years 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.

dualogy• 9 years ago

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

mikeash7• 9 years ago

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.

metaobject• 9 years ago

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

mikeash7• 9 years ago

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

jankotek• 9 years 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.

dahart• 9 years 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• 9 years 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.

Cognitive Biases in Programming

Related Stories