Live data from Hacker News

Cognitive Biases in Software Development

smyachenkov.com

111–120 of 127 posts

Re: Cognitive Biases in Software Development

#111
post #81

Earlier quoted context omitted.

I don't think this is the right mental model of coding. It seems a bit too similar to the idea that "most people simply cannot read". We all accept that nobody can read without instruction, practice, and feedback. Why is coding somehow different? If anything, I think reading is more foreign/difficult, because coding is explicit thinking, and we all think. Whereas reading is a completely synthetic act that starts with…

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

I look at a coding problem and think, what problem did I or somebody else solve in the past that looks similar to this new problem? What’s different about this new problem? What’s the same? In that sense coding is more like reading, in that it is about pattern recognition and “reading the pattern”, then it is about creating something new entirely.

Re: Cognitive Biases in Software Development

#112

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.

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

Sometimes small and easy, sometimes big and impacting the whole system. Generally small changes are preferred but that’s not always possible.

Re: Cognitive Biases in Software Development

#113

Earlier quoted context omitted.

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

Sometimes small and easy, sometimes big and impacting the whole system. Generally small changes are preferred but that’s not always possible.

We generally review anywhere from 50 to 300 lines per diff. An unfamiliar reader may not be able to anticipate spooky action at a distance in other parts of the codebase, but a good design doesn’t permit much of that anyway. The reader can certainly understand what’s going on in the change, and if they don’t they shouldn’t approve it.

Re: Cognitive Biases in Software Development

#114
post #109

Earlier quoted context omitted.

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

I don't find that to be the case. I'm usually looking for bigger things like: 1. making multiple trips to a relational database when a single statement joining tables can make it one trip; 2. not handling exceptions that can cause data loss or data corruption.

(I'm not trying to be exhaustive. The examples above are common ones I've seen regularly and they make me cringe.)

I don't need to know the variable names used in these cases. The very act of not using a relational database properly or not handling exceptions is easy to spot.

Re: Cognitive Biases in Software Development

#115
post #5

There's something deeply unnerving about ugly code, I don't think we can just say 'well it works'. I think we should maybe aspire to find a frame of reference for evaluating when to change and not. During development, I find iteration can be useful, i.e. when you have code that's 'hot in your mind' and can be re-worked. Another key that the article doesn't seem to reference is encapsulation. It's one of the most gold…

Rewriting an ugly API could be problematic if not rewritten while fresh. Once it starts being refed everywhere good luck.. I bet there are no test cases either and the task becomes daunting and expensive

Yes, that's the thing. Exactly. APIs are by definition leaky. Look at Python v2 v3 debacle. So it has to be really well planned, even then possibly not worth it.

Re: Cognitive Biases in Software Development

#116

Earlier quoted context omitted.

Sometimes small and easy, sometimes big and impacting the whole system. Generally small changes are preferred but that’s not always possible.

We generally review anywhere from 50 to 300 lines per diff. An unfamiliar reader may not be able to anticipate spooky action at a distance in other parts of the codebase, but a good design doesn’t permit much of that anyway. The reader can certainly understand what’s going on in the change, and if they don’t they shouldn’t approve it.

Some of our changes are bigger if they touch several systems. You have to have very good knowledge of each system to make an assessment of the impact of the change. And nobody has time to really look into this. You don’t get much credit for code review on the scrum board.

Re: Cognitive Biases in Software Development

#117
post #44

Earlier quoted context omitted.

People think differently and the higher up in the abstraction level, the more diverse it will get. Like for example some people think in shapes and will get crazy if you do not format the code in the same shapes. Others think in words and writes the code as like they where talking to a human. Others have images in their head and doesn't really care how the code looks. Some people annotate their code so that it looks…

I have a coworker that names variables after Marvel and Disney characters.

I'm not proud of this but I once temporarily named an exception class after a cartoon character and it kept popping up in server logs for years.

Re: Cognitive Biases in Software Development

#118

Earlier quoted context omitted.

I've exactly the same problem with perfectionism. It's not what the industry wants. And I mean anywhere: "If the language I'm working in supported FP, then my world would be much better" :) I've seen the fuckups that are possible in FP, and indeed worked with a guy who used it to make things as complex as possible. You can really produce nasty code because of it's much-touted compositionality in the hands of a dickhe…

Nice quote from Friedrich Schiller. When I searched it from curiosity, I found another statement by him that seemed appropriate for the topic at hand: "He who considers too much will perform little."

This is why procrastination is more widespread in high IQ individuals.

Re: Cognitive Biases in Software Development

#119

Naming stuff is not trivial and not a bikeshedding.

There are two difficult problems in software engineering: cache invalidation, naming things, and off-by-one errors.

I can vouch for problems #0 and #1 but I've never experienced #2.

Re: Cognitive Biases in Software Development

#120
post #15

If the author reads this: Dark theme completely FUBARs the code snippets. Sample: https://i.imgur.com/QUO48fn.png

How did you change theme to Dark?

You set your OS' system theme to Dark, and the browser should pass this information on to websites.
Post reply on HN