Cognitive Biases in Programming
medium.comThis 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.
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.
Learning vim commands won't increase how fast you type, it will increase how fast you edit.
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.
But it does matter how efficiently he navigates.
And this where vim can shine.
Although I prefer structuring the program, not using structured editor.
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).
> 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.
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.
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.
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.
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.
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.
So you might as well use sed as Eclipse for doing your programming?
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."
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.
It's more about efficiency in doing repeatable tasks.
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.
Good architect.
A bunch of non-falsifiable claims with a colorful unrelated brain graphic. Not very useful.
There needs to be one about scar tissue. Programmers tend to fear doing anything that they feel burned them in the past.
Weird. They almost sound like.... humans, or something.
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.
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.
> 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!
> 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.
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.
"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.
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()
}
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.
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.
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.
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.
It's a bad gut reaction to have for a newer programmer who is struggling to find any solution to the problem at hand.
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?
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.
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.
Seems like an aggregate explanation for why technical debt exists. :-)
People who don’t use their text editor in the manner I do have a brain disease- oops, I mean cognitive bias.