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

51–60 of 127 posts

Re: Cognitive Biases in Software Development

#51

Post by raverbashing »

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.

> so why accept single character name?

Because readability suffers with repeated long variable names

There's a reason why math uses i,j,k and x,y,z and it's not to be petty.

Re: Cognitive Biases in Software Development

#52

Post by mtrycz2 »

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

> really dumb looking code

You cannot imagine how I'd value having really dumb looking code in my life.

Yet here I am, swimming in a swap of cleverness that I can't refactor nor will ever be able to wrap my head around.

I envy you.

Re: Cognitive Biases in Software Development

#54

Post by l0b0 »

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.

Re: Cognitive Biases in Software Development

#55

Post by _y5hn » 

  // TODO it works, but it's ugly, rewrite
  function init() {
      // some code
  }
What is ugly, what would rewrite accomplish? Excellent example of bad commenting. Comments are ideally unnecessary, so bad comments just litter code and stink it up even more. No code will live forever anyways, and it says something about someone when they falsely believe in perfection.

Re: Cognitive Biases in Software Development

#56

Post by throwaway_pdp09 »

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 dickhead can generate horrors. Map within a map composed with a reduce composed with... in one statement.

Add in statelessness, which can complicate things in some cases, if said prat pushes statelessness due to the latest blog article he read, it can get worse.

From memory: "against stupidity the gods themselves struggle in vain".

Re: Cognitive Biases in Software Development

#57

Post by kqr »

giantDinosaur wrote: post #42
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…

Although somewhat amusing, I'm assuming there's more to 'MemoryHolder' than just an inappropriate name. What was wrong about it at the type level that illustrates your point? Or do you mean to say that it's (somehow) illustrative of a lack of conceptual understanding?

I'm curious about the same thing. With my Ada background, I see a completely sensible interpretation of MemoryHolder:

A Holder type is a managed (RAII/garbage collected) wrapper that has a reference to some unmanaged/primitive object. If that primitive object is some notion of a contiguous region of memory, then MemoryHolder is a perfectly good name for it.

A name like "Buffer" might not automatically tell the users that the type is managed, or that it wraps some underlying primitive type. That may or may not be relevant to the user, but it's not obviously always irrelevant, at least.

Re: Cognitive Biases in Software Development

#58

Post by appleflaxen »

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 arbitrary symbols that must be memorized by rote before you can even take the next step of using them.

None of us start out life being literate, but few people lack the ability to become literate. Why is coding different?

Re: Cognitive Biases in Software Development

#59

Post by ThePhysicist »

Personally I found that my productivity as a software developer was much higher when I was young and didn’t think so much about the cleanest code or the perfect architecture for a problem and instead just tried different approaches. Now I often feel paralyzed by having to “get it right” from the beginning.

Valid (in my opinion) lessons I cherish today are keeping individual parts of a code base simple and understandable, documenting and testing a lot and preferring simpler solutions over complex ones.

Re: Cognitive Biases in Software Development

#60

Post by dgb23 »

mtrycz2 wrote: post #52
Cthulhu_ wrote: post #34

Earlier quoted context omitted.

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

> really dumb looking code You cannot imagine how I'd value having really dumb looking code in my life. Yet here I am, swimming in a swap of cleverness that I can't refactor nor will ever be able to wrap my head around. I envy you.

Both "dumb" and abstracted code can be hard to read and change. The most important part is consistency.

It is generally easier to write dumb code that is consistent. It requires less mental energy and is often a very good starting point for refactoring into something more declarative and DRY.

The pain comes from inconsistent code, often either based on wrong previous assumptions, premature optimization or time pressure.

Post reply on HN