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

21–30 of 127 posts

Re: Cognitive Biases in Software Development

#21

Post by raverbashing »

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.

Some people will just find it as an excuse to go all over it the naming issue. Worse than the "80 columns is the limit" people, because after all 80 columns is 80 columns. But there's no "ideal name" for some people.

Re: Cognitive Biases in Software Development

#22

Post by alanfranz »

raverbashing wrote: post #20
de_watcher wrote: post #13

Naming stuff is not trivial and not a bikeshedding.

No, sorry. Wasting too much time is BS. Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus. Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line. More important than picking the perfect name: - Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life…

What is a good name?

Sometimes the failure at finding a good name (and taking 30 minutes to name your variable) means your abstraction is not good and/or your variable encloses multiple concepts.

Of course, a short-spanned internal-only variable used just once or twice doesn't deserve a 30-minutes debate; OTOH a public variable which could be externally exposed by a class could require a bit of thinking.

Re: Cognitive Biases in Software Development

#23

Post by mesaframe »

ravenstine wrote: post #19
wwn_se wrote: post #14

Not all code is critical and intended to maintained forever. Everyone is not working at Google, Amazon etc. most code I write is not run daily by 1000s of users.

Maybe there are just lots of FAANG engineers on HN, but it's amusing how many people overestimate the size and scope of the projects most software developers work on. There's so much discouragement and pessimism if a software wasn't written to handle millions of requests, or intended to live on for 15+ years. On the contrary, there's software written all the time that has a realistic lifetime of a few years before it…

But, how would the developer know about the lifetime of the code. How would the developer know if code will never be extended or will remain stale for the rest of the life?

Re: Cognitive Biases in Software Development

#24

Post by hyfgfh »

_7fvc wrote: post #16

I call this, Developer Inertia: It's hard to learn others' code, but it's easy to fix to bugs in others' code. It's easy to write your code, but it's hard to fix bugs in your code. It's good to have someone else looking at your work in established projects. Pair programming provides some value to overcome this problem. Overcome your weakness, you'll become a better developer.

You call what? Can you be more specific?

Re: Cognitive Biases in Software Development

#25

Post by onion2k »

raverbashing wrote: post #20
de_watcher wrote: post #13

Naming stuff is not trivial and not a bikeshedding.

No, sorry. Wasting too much time is BS. Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus. Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line. More important than picking the perfect name: - Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life…

You're naming a variable, not the title of your Magnum Opus.

You're naming a variable, and that name is probably the most important documentation about that specific point in the code. A lot of the time a useful name will be quite obvious, so you should use one. If you see code that has variable names like a, i, myVar, value, etc then it's usually a sign the developer didn't think very hard about the code that they were writing. Using a name that gives some context to the data the variable should hold is massively useful to the next developer to work on the code (which is usually you, so you'll be thankful you did).

Re: Cognitive Biases in Software Development

#26

Post by diggan »

alanfranz wrote: post #22
raverbashing wrote: post #20

Earlier quoted context omitted.

No, sorry. Wasting too much time is BS. Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus. Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line. More important than picking the perfect name: - Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life…

What is a good name? Sometimes the failure at finding a good name (and taking 30 minutes to name your variable) means your abstraction is not good and/or your variable encloses multiple concepts. Of course, a short-spanned internal-only variable used just once or twice doesn't deserve a 30-minutes debate; OTOH a public variable which could be externally exposed by a class could require a bit of thinking.

Elements of Clojure is an excellent book that goes through what a good name is and what it should represent. Don't be put off by the "Clojure" in the title, the book is really not about Clojure but about programming, using Clojure for its samples.

You can read a sample chapter online, which is the chapter about naming. Highly recommended! https://leanpub.com/elementsofclojure/read_sample

Re: Cognitive Biases in Software Development

#27

Post by diggan »

raverbashing wrote: post #20
de_watcher wrote: post #13

Naming stuff is not trivial and not a bikeshedding.

No, sorry. Wasting too much time is BS. Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus. Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line. More important than picking the perfect name: - Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life…

> No, sorry. It's BS.

Way to open up a constructive discussion ;)

Any extreme of naming is bad. Spent zero time thinking about naming and you end up with a codebase where the same thing is called differently depending on how the person felt that day. Or core data structures are called "node", "element" or "link", words that are already overloaded and should be avoided.

On the other extreme, thinking too far about naming leads into bikeshedding and no work getting done.

So as with many other things, balance is the thing that gets you the furthest.

Re: Cognitive Biases in Software Development

#28

Post by jamil7 »

ravenstine wrote: post #19
wwn_se wrote: post #14

Not all code is critical and intended to maintained forever. Everyone is not working at Google, Amazon etc. most code I write is not run daily by 1000s of users.

Maybe there are just lots of FAANG engineers on HN, but it's amusing how many people overestimate the size and scope of the projects most software developers work on. There's so much discouragement and pessimism if a software wasn't written to handle millions of requests, or intended to live on for 15+ years. On the contrary, there's software written all the time that has a realistic lifetime of a few years before it…

Yes and no, I'm guessing most of us here at some point have inherited a codebase that wasn't intended to live longer than a few years or serve 1000s users but nonetheless has. I'm not saying everything needs to be overengineered to be FAANG scale but don't go too far the otherway either, think of the person who might inherit the codebase.

Re: Cognitive Biases in Software Development

#30

Post by saberdancer »

Gibbon1 wrote: post #10
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.

Before I worked on firmware I worked on PCB layout. Thing you learn from that is you can keep fucking with the layout forever and it is simply pointless from a business perspective. Spend an extra day 'cleaning up' the layout. Well sweet now your delivery slipped a day. Also experience with redactoring away a wart only to find there is now a wart somewhere else.

Difference with PCB is that it is normally one off job. If you are building a one off application or a script, clean code is not very important.

If you are building a system that will be used for years and needs to be extensible than it makes much more sense. Just like it would make sense if you got your PCB back and needed to change features or add new ones.

Post reply on HN