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

41–49 of 49 posts

Re: Cognitive Biases in Programming

#41

Post by throwanem »

speedplane wrote: post #21
SeanDav wrote: post #16

Earlier quoted context omitted.

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.

Re: Cognitive Biases in Programming

#42

Post by c22 »

the_af wrote: post #35
mediocrejoker wrote: post #7

Earlier quoted context omitted.

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

Learning vim commands won't increase how fast you type, it will increase how fast you edit.

Re: Cognitive Biases in Programming

#43

Post by mikeash »

onion2k wrote: post #34
mikeash wrote: post #32

Earlier quoted context omitted.

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…

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.

Re: Cognitive Biases in Programming

#44

Post by the_af »

c22 wrote: post #42
the_af wrote: post #35

Earlier quoted context omitted.

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

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.

Re: Cognitive Biases in Programming

#46

Post by thesz »

the_af wrote: post #35
mediocrejoker wrote: post #7

Earlier quoted context omitted.

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

But it does matter how efficiently he navigates.

And this where vim can shine.

Although I prefer structuring the program, not using structured editor.

Re: Cognitive Biases in Programming

#47

Post by kruczek »

mikeash wrote: post #43
onion2k wrote: post #34

Earlier quoted context omitted.

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…

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.

Re: Cognitive Biases in Programming

#48

Post by mikeash »

kruczek wrote: post #47
mikeash wrote: post #43

Earlier quoted context omitted.

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.

Re: Cognitive Biases in Programming

#49

Post by kruczek »

mikeash wrote: post #48
kruczek wrote: post #47

Earlier quoted context omitted.

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?

Post reply on HN