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

91–100 of 127 posts

Re: Cognitive Biases in Software Development

#91

Post by lmilcin »

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…

Depends on the definition of "can"

I think, most people have potential to be able to code. By "can" I mean if they applied themselves to learning.

The problem is there's just no easy way to somehow transfer the knowledge and experience of what it means to actually code. The Doening-Kruger effect is in full force because you can't tell if you can code until you can. Moreover, almost every technology today must cater to complete beginners so it is easy to write a Hello World but then there is no way to tell you how to put your solution together. There is nuggets of wisdom but you need to have some prerequisite knowledge and experience to make use of them.

It is easy to see that I can't sight-read music. I mean I am amateur flautist but for some reason I just can't "get it" (but I also did not try hard). I know you can sight read because there are a lot people that can just take a printout and start playing it without previously studying it.

The same is not true with programming. It is not easy to see people do programming -- you only see results that you do not understand until you actually can code. You can appreciate the music but you can't appreciate the code until you actually can code.

It does not help that the whole industry is crazy right now. There is very small proportion of people with actual experience because of exponential growth of number of developers. The salaries are inflated and newcomers are getting paid as if they were experts in other industries. If you are getting paid a lot it means you must be valuable, no?

Re: Cognitive Biases in Software Development

#92

Post by commandlinefan »

lmilcin wrote: post #91
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…

Depends on the definition of "can" I think, most people have potential to be able to code. By "can" I mean if they applied themselves to learning. The problem is there's just no easy way to somehow transfer the knowledge and experience of what it means to actually code. The Doening-Kruger effect is in full force because you can't tell if you can code until you can. Moreover, almost every technology today must cater t…

> If you are getting paid a lot it means you must be valuable, no?

And if you actually are experienced and try to offer a newcomer some guidance in writing code that they won't regret having written a year from now, they'll accuse you of being a "perfectionist" who's wasting time trying to obtain some theoretical optimization.

Re: Cognitive Biases in Software Development

#93

Post by jackcosgrove »

This is a good essay, and I think one of the main lessons is that programming is a small part of software development.

The question of whether to use an inefficient, readable implementation or an efficient, cryptic implementation can mostly be solved with the correct class topology. If classes are SOLID, then it is easier to justify a cryptic implementation of one method as that is hidden from most other developers. A class that will be inspected by others more, such as a business logic service layer, should lean towards inefficient, readable code.

Likewise, the question of whether to reuse or roll your own can also mostly be solved with a good architecture. Logically separating components makes it easier to tailor the implementation to the use case, and replace if necessary.

As always, breaking the problem into smaller problems is most of the battle.

Sadly software development as it is taught and measured by interviews, is mostly about programming and algorithms. The real art and value in software development is interface design and system architecture design.

Re: Cognitive Biases in Software Development

#94

Post by bpyne »

So many good lessons for newer developers and good reminders for more experienced ones. It was due to the Bike Shedding Effect that I came to not appreciate code reviews. Every review seemed to break down into discussions of variable and method names. I tried several times to create "off topic" rules like no discussion of variable names, etc. It didn't work...ever.

Now that I've been away from mandated code reviews for quite a while I can understand why reviewers go to the trivial. Firstly, "code reviews" are really "system reviews". It's difficult reviewing a project whose requirements you don't know with a design that came about through iterative design and possibly in a language you don't use.

My current team is small and split into an integration group (mine) of two people and a UX group of two people. My group partner and I look over each other's projects and stay up on the requirements as the project progresses. But it's completely informal. Yet it seems to work better than having a group of 2, 3, X number of randomly chosen developers from my department.

Re: Cognitive Biases in Software Development

#95

Post by Ididntdothis »

bpyne wrote: post #94

So many good lessons for newer developers and good reminders for more experienced ones. It was due to the Bike Shedding Effect that I came to not appreciate code reviews. Every review seemed to break down into discussions of variable and method names. I tried several times to create "off topic" rules like no discussion of variable names, etc. It didn't work...ever. Now that I've been away from mandated code reviews f…

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.

Re: Cognitive Biases in Software Development

#96

Post by dajohnson89 »

_y5hn wrote: post #55

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

I write similar comments sometimes, although a little more descriptive. It's to acknowledge that this snippet has some issues and could be improved, but for whatever reason not now.

I also go back sometimes and do just that. without the comment I forget 95% of the time.

Re: Cognitive Biases in Software Development

#97

Post by TheOtherHobbes »

commandlinefan wrote: post #84
appleflaxen wrote: post #58

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…

> similar to the idea that "most people simply cannot read". I think you're probably right, but in a strictly semantic way: I think it's feasible that nearly everybody (excluding, say, the severely mentally handicapped) could learn to program to a reasonable level of proficiency, with enough effort. However, most people won't, so it ends up being the same as if most people can't.

HN is a self-selecting population of higher=than-median IQ people with specific interests. Outside of that population, skill levels look like this:

https://www.oecd.org/skills/piaac/Country%20note%20-%20Unite...

Re: Cognitive Biases in Software Development

#98

Post by gibbonsrcool »

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.

Re: Cognitive Biases in Software Development

#99

Post by shervinafshar »

catchmeifyoucan wrote: post #8

I think line anxiety might be another one. Unless it’s just me. If I feel that a function or a file is just irregularly long compared to the others, I find myself asking if I need to break this thing up to be more abstract

Definitely not just you. To quiet such anxiety, I usually ask myself whether the length of the function is affecting the readability and speedy understanding of the logic. Longer functions are not necessarily bad, but if they pack so many logical units and so many scope variables, they could be improved.

Re: Cognitive Biases in Software Development

#100

Post by C4stor »

Ididntdothis wrote: post #95
bpyne wrote: post #94

So many good lessons for newer developers and good reminders for more experienced ones. It was due to the Bike Shedding Effect that I came to not appreciate code reviews. Every review seemed to break down into discussions of variable and method names. I tried several times to create "off topic" rules like no discussion of variable names, etc. It didn't work...ever. Now that I've been away from mandated code reviews f…

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.

But seriously, naming things correctly makes understanding the global system so much easier.

The whole point of naming things is that you don't have to dive in this 60 LoC function, but rather can use its name to know what it does, and make a global mental model.

If you're not naming things correctly, you effectively make it almost impossible to review the design, and that's why people starts with asking about names.

Reviewing names is the exact opposite of picking local stuff. Names have no importance locally, but they have tremendous one globally.

So, please, use good names ^^

Post reply on HN