
Cognitive Biases in Programming - yranadive
https://medium.com/@evidanary/cognitive-biases-in-programming-5e937707c27b
======
wakamoleguy
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
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
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
Learning vim commands won't increase how fast you type, it will increase how
fast you edit.

~~~
the_af
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.

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

~~~
akvadrako
_> 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
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
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.

------
joe_the_user
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
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
Sadly, those days are few and far between.

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

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

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

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

------
tomxor
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
> 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!

------
jankotek
> _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.

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

------
luord
"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.

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

~~~
kruczek
Well, it's a good gut reaction to have. As you wrote yourself "In reality,
both are equally easy to write" \- therefore the first one is a good default
to assume, because in some cases it may actually matter.

If you choose good default, then you won't spend any more time thinking about
it; if you have bad defaults, then you will have to figure out where the
slowdown comes from and eliminate it.

~~~
mikeash
It's a bad gut reaction to have for a newer programmer who is struggling to
find any solution to the problem at hand.

~~~
kruczek
So, if I understand your point correctly, you mean that newer programmers, who
are struggling to find any solution at all, would go for the (subjectively)
easier one, i.e. the one with f1() outside of the loop?

I agree they would go for the easier one, but I don't understand why they
would perceive the first version to be easier. And even if they would, why is
it bad?

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

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

