Live data from Hacker News

Cognitive Biases in Programming

medium.com

11–20 of 49 posts

Re: Cognitive Biases in Programming

#11

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

It's more about efficiency in doing repeatable tasks.

Re: Cognitive Biases in Programming

#12

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

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.

Re: Cognitive Biases in Programming

#13

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.

Re: Cognitive Biases in Programming

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

Re: Cognitive Biases in Programming

#15

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

So you might as well use sed as Eclipse for doing your programming?

Re: Cognitive Biases in Programming

#16
post #12

Earlier 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…

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.

Re: Cognitive Biases in Programming

#19

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.

Re: Cognitive Biases in Programming

#20

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