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).
Cognitive Biases in Programming
11–20 of 49 posts
Re: Cognitive Biases in Programming
#12Earlier quoted context omitted.
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.
Re: Cognitive Biases in Programming
#13Hyperbolic 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).
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.
Re: Cognitive Biases in Programming
#14I 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.
Re: Cognitive Biases in Programming
#15Earlier quoted context omitted.
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.
Re: Cognitive Biases in Programming
#16Earlier quoted context omitted.
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…
Re: Cognitive Biases in Programming
#17Re: Cognitive Biases in Programming
#18There 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
#19Hmm, 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.
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.
Re: Cognitive Biases in Programming
#20Hyperbolic 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.