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

71–80 of 127 posts

Re: Cognitive Biases in Software Development

#71

Post by iateanapple »

appleflaxen wrote: post #58
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…

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…

> It seems a bit too similar to the idea that "most people simply cannot read".

Remember that most people require extensive schooling for the better part of a decade in order to learn how to read.

Re: Cognitive Biases in Software Development

#72

Post by W0lf »

appleflaxen wrote: post #58
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…

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…

Elaborating a bit more on this, I have made the observation that again those _most people_ don't care much reading (good) code from other people. There are many outstanding examples of code quality out there. For instance, I've found many good patterns and solutions by simply reading the Chromium source code, many of which I can apply directly to similar problems I'm facing myself for any given software project I'm doing.

The same holds true for literature, I think. Surely, there are many people how can read and write a piece of text. However, there surely is a qualitatively difference between a gossip article from the magazine and Shakespeare's Hamlet.

Re: Cognitive Biases in Software Development

#73

Post by Dowwie »

Cthulhu_ wrote: post #34
cjonas wrote: post #9

I work as a "consultant", building cloud based business software. Above all else, my job is to deliver value. Something I constantly struggle with is "clean code" vs just pumping out a mostly static transaction script and moving on. More and more, I write code I'd almost be embarrassed for colleagues to review. But for the type of work I'm doing (poorly defined, highly volatile, potentially short lifespan), I can't j…

I've been doing Go for a while now, and more and more I find myself just writing out really dumb looking code. Add a new line, write another short-lived variable, treat the guy reading it - me - like he's a complete idiot. I don't work in a team at the moment, but what I do now is the groundwork for something that will likely be used for the next decade (UI work, back / front-end).

Clear and concise isn't dumb. It's more readable and maintainable. The dumb code is the clever code that no one understands and requires weeks of effort to do, and to understand, no more than what the clear and concise code does.

Re: Cognitive Biases in Software Development

#74

Post by celrod »

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.

I agree.

Criticizing someone for being biased is an ad hominem; dismissing their arguments because of it is committing the genetic fallacy.

In the extreme, it reminds me of this blog post, about how knowing about biases can let some folks universally dismiss others they disagree with (and thus manage to never learn or consider alternative ideas): https://www.lesswrong.com/posts/AdYdLP2sRqPMoe8fb/knowing-ab...

Re: Cognitive Biases in Software Development

#75

Post by yamrzou »

cjonas wrote: post #9

I work as a "consultant", building cloud based business software. Above all else, my job is to deliver value. Something I constantly struggle with is "clean code" vs just pumping out a mostly static transaction script and moving on. More and more, I write code I'd almost be embarrassed for colleagues to review. But for the type of work I'm doing (poorly defined, highly volatile, potentially short lifespan), I can't j…

> poorly defined, highly volatile, potentially short lifespan

This. This is the reality of software development, especially in a startup. You have to quickly adapt your code to the client's needs and to the business constraints, because if there is no cash, the company wouldn't exist anyway.

You can't do that with "perfect" code.

Re: Cognitive Biases in Software Development

#76

Post by gherkinnn »

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.

The Fallacy Fallacy!

https://en.m.wikipedia.org/wiki/Argument_from_fallacy

Re: Cognitive Biases in Software Development

#77

Post by lioeters »

throwaway_pdp09 wrote: post #56
cjonas wrote: post #9

I work as a "consultant", building cloud based business software. Above all else, my job is to deliver value. Something I constantly struggle with is "clean code" vs just pumping out a mostly static transaction script and moving on. More and more, I write code I'd almost be embarrassed for colleagues to review. But for the type of work I'm doing (poorly defined, highly volatile, potentially short lifespan), I can't j…

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

Re: Cognitive Biases in Software Development

#78

Post by de_watcher »

onion2k wrote: post #47
raverbashing wrote: post #40

Earlier quoted context omitted.

'a' and 'i' are perfect for indexes or range traversals. Yes, myVar is bad. You can always read the context and see 'for value in list_of_values' or understand what's it that you're working with right now. Yes, be more explicit on the tricky parts, but sometimes i = i+1 is just fine.

'a' and 'i' are perfect for indexes Except they're not as good as 'index', which is obvious and provides some meaning, so why accept single character name? I have an eslint rule that blocks single character var names on my projects. It makes my team develop good habits, and no one has ever complained about it. Our code is very readable.

Are you awful or just trolling? I've said that naming is very important, but I didnt't suggest that people should choose a longer word when two are equivalent. A real way to give 'more meaning' to the index is to indicate to which collection it belongs.

Re: Cognitive Biases in Software Development

#79

Post by collyw »

ravenstine wrote: post #18
sidcool wrote: post #6

Over the past few years I have grown disillusioned by the seemingly hyper focus on clean code concept. It seems perfectly logical to have readable code. But the excess that we programmers do with the concept.

I think what's worse than that obsession, and perhaps is actually what you meant, is the concept of "elegant" code. Elegant code is easily just as bad as spaghetti code. I can't even begin to quantify how many hours of my life were wasted because someone thought it was more important to make something elegant rather than understandable. I get that it's satisfying to make something that "makes sense" if you've built a…

I always thought "elegant" code was clean, concise and understandable.

Edit: Stack Exchange seems to agree that readability is part of what makes code elegant. https://softwareengineering.stackexchange.com/questions/9791...

Re: Cognitive Biases in Software Development

#80

Post by throwaway_pdp09 »

lioeters wrote: post #77
throwaway_pdp09 wrote: post #56

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

> "He who considers too much will perform little."

The perfectionist's curse? I have to say there's a core of truth to that! Analysis paralysis IOW.

Post reply on HN