Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cognitive Biases in Software Development

smyachenkov.com

Post reply on HN
Print view View original

101–110 of 127 posts

Re: Cognitive Biases in Software Development

#101

Post by Trasmatta »

bpyne wrote: post #94

So many good lessons for newer developers and good reminders for more experienced ones. It was due to the Bike Shedding Effect that I came to not appreciate code reviews. Every review seemed to break down into discussions of variable and method names. I tried several times to create "off topic" rules like no discussion of variable names, etc. It didn't work...ever. Now that I've been away from mandated code reviews f…

I think code review is still valuable, but I agree that the majority of actual reviews are surface level and unhelpful. On my team right now there are like three different people who all have different opinions on how code should be written, and all bikeshed it differently. It's really interrupted my flow lately, because I'm thinking less about what to write and more how I can do it in a way that will appease the reviewers. And then I get differing feedback anyway and have to spend my time mediating between the reviewers who don't even agree themselves.

Re: Cognitive Biases in Software Development

#102

Post by Ididntdothis »

C4stor wrote: post #100
Ididntdothis wrote: post #95

Earlier quoted context omitted.

That’s why pair programming works better than code reviews. Unless you have crazy amounts of time there is almost no chance a code reviewer can really understand the design of the change. So you end up with people picking on very local stuff like variable names. With pair programming you have two people who understand the history of the code and why decisions have been made.

But seriously, naming things correctly makes understanding the global system so much easier. The whole point of naming things is that you don't have to dive in this 60 LoC function, but rather can use its name to know what it does, and make a global mental model. If you're not naming things correctly, you effectively make it almost impossible to review the design, and that's why people starts with asking about names.…

Totally agree about the importance of naming. But the big problems that are hard to fix later come usually from design flaws, not from naming and often are overlooked in reviews.

Re: Cognitive Biases in Software Development

#103

Post by ng12 »

lmilcin wrote: post #91
W0lf wrote: post #39

My personal observation (and view of course) is that most people simply cannot code. And I am not talking about that reverse-a-binary-tree or traverse-a-linked-list type of coding, but more profoundly they just cannot wrap their head around a problem and are able to create a sufficient solution with respect to the context of the code and its environment at the same time. Good software development is strongly connecte…

Depends on the definition of "can" I think, most people have potential to be able to code. By "can" I mean if they applied themselves to learning. The problem is there's just no easy way to somehow transfer the knowledge and experience of what it means to actually code. The Doening-Kruger effect is in full force because you can't tell if you can code until you can. Moreover, almost every technology today must cater t…

> I think, most people have potential to be able to code. By "can" I mean if they applied themselves to learning.

My time spent teaching makes me think otherwise. I saw so many smart, motivated young people who simply could not get their homework done. This was especially discouraging since my alma matter has a very strong focus on pedagogical programming.

There's something about programming that "clicks" for some people. They can look a the little pieces and immediately understand how to put them together. If you don't have that spark it's going to be an extremely challenging journey.

Re: Cognitive Biases in Software Development

#104

Post by draw_down »

l0b0 wrote: post #54

There's also cognitive bias bias - prematurely jumping to the conclusion that some opinion is simply based on cognitive bias, and should therefore be dismissed or contradicted. Basically, it's good to use awareness of cognitive bias to moderate your own thinking, but if you signal to others that you think they are labouring under some bias don't be surprised if they shut down the discussion ASAP.

Great post, thanks.

Re: Cognitive Biases in Software Development

#105

Post by pythonaut_16 »

commandlinefan wrote: post #92
lmilcin wrote: post #91

Earlier quoted context omitted.

Depends on the definition of "can" I think, most people have potential to be able to code. By "can" I mean if they applied themselves to learning. The problem is there's just no easy way to somehow transfer the knowledge and experience of what it means to actually code. The Doening-Kruger effect is in full force because you can't tell if you can code until you can. Moreover, almost every technology today must cater t…

> If you are getting paid a lot it means you must be valuable, no? And if you actually are experienced and try to offer a newcomer some guidance in writing code that they won't regret having written a year from now, they'll accuse you of being a "perfectionist" who's wasting time trying to obtain some theoretical optimization.

Unfortunately that mentality isn't limited only to newcomers. There are plenty of developers with many years of experience who still practice that same short sightedness.

Re: Cognitive Biases in Software Development

#106

Post by iffybookmark »

kspacewalk2 wrote: post #90
jasode wrote: post #81

Earlier quoted context omitted.

>None of us start out life being literate, but few people lack the ability to become literate. Why is coding different? To elaborate on the sibling comments, coding is generative work instead of passive consumption like reading. This split becomes easier to see when looking at a bunch of domains. Most of people can learn to read a book but very few can write a good book. Similarly, it's easier to re-tell someone else…

Generative work is not all created equal. Most of programming we all do is like applying physics equations in practice. A tiny portion is truly on the cutting edge, more akin to physics research. Likewise, a lot more emails and discussion comments and school reports are written, per volume, than masterpiece books.

I'd be willing to bet that

{people who can look at a real world problem, choose an appropriate physics model, and apply the right equations, correctly}

and

{people who can look at a real world problem, choose an appropriate logical model, and apply the right language/frameworks/code, correctly}

are probably really quite similar sets.

Re: Cognitive Biases in Software Development

#108

Post by closeparen »

Ididntdothis wrote: post #95
bpyne wrote: post #94

So many good lessons for newer developers and good reminders for more experienced ones. It was due to the Bike Shedding Effect that I came to not appreciate code reviews. Every review seemed to break down into discussions of variable and method names. I tried several times to create "off topic" rules like no discussion of variable names, etc. It didn't work...ever. Now that I've been away from mandated code reviews f…

That’s why pair programming works better than code reviews. Unless you have crazy amounts of time there is almost no chance a code reviewer can really understand the design of the change. So you end up with people picking on very local stuff like variable names. With pair programming you have two people who understand the history of the code and why decisions have been made.

That doesn’t sound right. How big are the changes you’re reviewing?

Re: Cognitive Biases in Software Development

#109

Post by C4stor »

Ididntdothis wrote: post #102
C4stor wrote: post #100

Earlier quoted context omitted.

But seriously, naming things correctly makes understanding the global system so much easier. The whole point of naming things is that you don't have to dive in this 60 LoC function, but rather can use its name to know what it does, and make a global mental model. If you're not naming things correctly, you effectively make it almost impossible to review the design, and that's why people starts with asking about names.…

Totally agree about the importance of naming. But the big problems that are hard to fix later come usually from design flaws, not from naming and often are overlooked in reviews.

I agree with you. My point, if it wans't clrear, is that I think correct naming is a prerequisite to finding design flaws in review ! Hence we have the same ultimate goal :-)

Re: Cognitive Biases in Software Development

#110

Post by closeparen »

bigpeet wrote: post #17
de_watcher wrote: post #13

Naming stuff is not trivial and not a bikeshedding.

There should be naming guidelines just like how a team should have style guidelines. The discussions should happen when creating (or updating) these guidelines. Then these guidelines should be followed, no need for long discussions during code reviews. Variable name does not follow guidelines => Mark it as an issue, defer to the guidelines move on.

No. The purpose of a name is to convey meaning to the reader. There is exactly one valid complaint about a name: “I’ve read this carefully and I still don’t know what it means.”

A standards-compliant name that interferes with understanding is not okay. A name everyone gets, which happens to not follow a rule in some rulebook, is probably fine.

Post reply on HN