Cognitive Biases in Programming
medium.com
Cognitive Biases in Programming
1–10 of 49 posts
Re: Cognitive Biases in Programming
#2Hyperbolic 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).
Re: Cognitive Biases in Programming
#3A bunch of non-falsifiable claims with a colorful unrelated brain graphic. Not very useful.
Re: Cognitive Biases in Programming
#4The 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.
Re: Cognitive Biases in Programming
#5This 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.
Re: Cognitive Biases in Programming
#6Seems like an aggregate explanation for why technical debt exists. :-)
Re: Cognitive Biases in Programming
#7This 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…
Just to play devil's advocate: maybe you would use vim more frequently if you were more efficient and thus more productive with it?
Re: Cognitive Biases in Programming
#8Hyperbolic 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).
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.
Re: Cognitive Biases in Programming
#9There needs to be one about scar tissue. Programmers tend to fear doing anything that they feel burned them in the past.
Re: Cognitive Biases in Programming
#10Hyperbolic 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).
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.…
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.