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

21–30 of 49 posts

Re: Cognitive Biases in Programming

#21

Post by speedplane »

SeanDav wrote: post #16
yaantc wrote: post #12

Earlier quoted context omitted.

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…

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.

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.

Re: Cognitive Biases in Programming

#22

Post by speedplane »

ak39 wrote: post #19
joe_the_user wrote: post #14

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.

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.

Sadly, those days are few and far between.

Re: Cognitive Biases in Programming

#23

Post by gm-conspiracy »

ak39 wrote: post #19
joe_the_user wrote: post #14

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.

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.

Good architect.

Re: Cognitive Biases in Programming

#24

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

Re: Cognitive Biases in Programming

#25

Post by mikeash »

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

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

Re: Cognitive Biases in Programming

#26

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

Re: Cognitive Biases in Programming

#27

Post by onion2k »

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.

Re: Cognitive Biases in Programming

#28

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

Re: Cognitive Biases in Programming

#30

Post by dualogy »

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.
Post reply on HN