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

121–127 of 127 posts

Re: Cognitive Biases in Software Development

#121

Post by kroltan »

raziel2p wrote: post #53
kroltan wrote: post #15

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

I get the idea of ios/android apps supporting dark theme, but since when did this concept apply to websites?

Through the prefers-color-scheme CSS media query [1], a draft [2] that is already implemented in mainstream browsers.

Websites can write stylesheets specifically for light or dark preferences. Browsers currently derive this information from the operating system's preferences.

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref... [2]: https://drafts.csswg.org/mediaqueries-5/#prefers-color-schem...

Re: Cognitive Biases in Software Development

#122

Post by Nevermark »

gibbonsrcool wrote: post #98
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 think we should strive to make more ways for people that "can't code" to be able to contribute. It's hard. I've been thinking recently that there might be an additional lesson behind Conway's Law; that the interface and character of a system mirrors its creator(s). This means if you hire super smart people to build something, it's going to require super smart people to interact with, operate, and maintain.

I have noticed that adept software developer's can be more patient with tools that require fiddling, especially if the fiddling feels like challenging but rewarding puzzle solving in a sea of powerful options.

Unproductivity that feels viscerally very productive.

Alternatively, command line tools tend to be created and increase the productivity of the more technically inclined, but are opaque to the less technical.

Which effect is the GibbonsRCool's Law? Or both? GibbonsRCool's Laws of Skill Drag and Acceleration?

Re: Cognitive Biases in Software Development

#123

Post by Nevermark »

onion2k wrote: post #62
raverbashing wrote: post #51

Earlier quoted context omitted.

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

There's also a reason why a lot of people find equations incredibly hard to parse.

This is a nice semi-random deeply nested spot to observe how the topic of naming is so cognitively attractive.

Even in the meta-sense it is being discussed here.

There is something about naming that we like thinking about, and fine tune our thoughts on, more than a simple need for legibility.

There is a sense of ownership in picking a name.

Re: Cognitive Biases in Software Development

#124

Post by Nevermark »

titzer wrote: post #37
crimsonalucard wrote: post #7

The entire human race is a cognitive bias, you can't have christians and muslims be right at the same time. One population of religious people must be wrong and therefore a huge portion of the population must be cognitively biased to an extreme degree of believing in something completely wrong. It is part of human nature to be hugely biased to a completely absurd degree and software engineers and scientists are not i…

> If you can't see how utterly stupid builder pattern is for this case... well... cognitive bias. You cannot win against the prevailing wisdom. Try having a public mutable field on a class, and watch people lose their ever-loving minds. But why do we have more than half of the classes' exposed with getters and setters? Mmmmfh. I think the problem is that it is really hard to reason about software in the large. So we…

Well, obviously the simple solution is not to use getter/setter methods but simply overload the implicit get and set operators of the field when you do need to track or react to field value accesses and changes.

Not a language option? ... Oh, so simple ... and yet, so far away.

Re: Cognitive Biases in Software Development

#125

Post by collyw »

UK-Al05 wrote: post #33
ravenstine wrote: post #18

Earlier quoted context omitted.

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…

Clean code has always meant to simple, easy to understand, not elegant.

I don't think they are mutually exclusive.

In a recent interview question I was asked to find the largest three numbers in python list. My first attempt looped through the starting list, comparing the number to the previous minimum number in the result list - replacing the number if it was larger. I needed a get_minimum(function). It was the obvious solution that came to my head at thr time.

An hour later I realized a far more elegant solution was to sort the list and slice the last three elements. It felt far more elegant to me and was as easy to understand as the initial obvious solution that came into my head.

(Though this is why I dislike these type of interview questions. the first solution in an interview situation is not always the best or final one)

Re: Cognitive Biases in Software Development

#126

Post by crimsonalucard »

Nevermark wrote: post #124
titzer wrote: post #37

Earlier quoted context omitted.

> If you can't see how utterly stupid builder pattern is for this case... well... cognitive bias. You cannot win against the prevailing wisdom. Try having a public mutable field on a class, and watch people lose their ever-loving minds. But why do we have more than half of the classes' exposed with getters and setters? Mmmmfh. I think the problem is that it is really hard to reason about software in the large. So we…

Well, obviously the simple solution is not to use getter/setter methods but simply overload the implicit get and set operators of the field when you do need to track or react to field value accesses and changes. Not a language option? ... Oh, so simple ... and yet, so far away.

No dude. The solution is not to use the builder pattern period. Just have a function/constructor with 50 parameters.

Why? Because the instantiated object requires all 50 parameters to be fully realized. Having to call 50 separate setters means you can create an "invalid" object where only 23 setters are called. Why allow this to happen at all? It's like a null value, why allow that value to exist on a type?

If you need all 50 parameters to be fully realized, then the logical thing to do is to only allow the object to exist with all 50 parameters in place. A constructor with 50 parameters insures that this fact is reality. It's that simple.

Yet even you, with the answer right in front of your nose staring you in the face still thought that you 50 setters is okay with syntactical sugar! That's how powerful cognitive bias is with design patters. "Builder pattern" is a word that lends a sort of artificial aura into what is essentially stupidly dividing up a constructor into 50 setters for no good reason.

Re: Cognitive Biases in Software Development

#127

Post by kccqzy »

ThalesX wrote: post #46
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 recently built a system under very changing directions. I put all my calls into a single controller, so there were some tens of methods in the single controller. It felt nasty, it felt ugly, but when time came to actually keep up the desired functionality, put a break and comb the system, it was great to have a single place from where to extract common functionality from. At this point, it was obvious what function…

This is exactly the attitude we need. Make it work, make it right, make it fast. In that order.

It's sad that too many people are so afraid of technical debt that they demand perfection at first try. At their first try, they don't even know what perfection is.

Post reply on HN