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…
>None of us start out life being literate, but few people lack the ability to become literate. Why is coding different? To elaborate on the sibling comments, coding is generative work instead of passive consumption like reading. This split becomes easier to see when looking at a bunch of domains. Most of people can learn to read a book but very few can write a good book. Similarly, it's easier to re-tell someone else…
Cognitive Biases in Software Development
111–120 of 127 posts
Re: Cognitive Biases in Software Development
#112Earlier quoted context omitted.
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.
That doesn’t sound right. How big are the changes you’re reviewing?
Re: Cognitive Biases in Software Development
#113Earlier quoted context omitted.
That doesn’t sound right. How big are the changes you’re reviewing?
Sometimes small and easy, sometimes big and impacting the whole system. Generally small changes are preferred but that’s not always possible.
Re: Cognitive Biases in Software Development
#114Earlier quoted context omitted.
Totally agree about the importance of naming. But the big problems that are hard to fix later come usually from design flaws, not from naming and often are overlooked in reviews.
I agree with you. My point, if it wans't clrear, is that I think correct naming is a prerequisite to finding design flaws in review ! Hence we have the same ultimate goal :-)
(I'm not trying to be exhaustive. The examples above are common ones I've seen regularly and they make me cringe.)
I don't need to know the variable names used in these cases. The very act of not using a relational database properly or not handling exceptions is easy to spot.
Re: Cognitive Biases in Software Development
#115There's something deeply unnerving about ugly code, I don't think we can just say 'well it works'. I think we should maybe aspire to find a frame of reference for evaluating when to change and not. During development, I find iteration can be useful, i.e. when you have code that's 'hot in your mind' and can be re-worked. Another key that the article doesn't seem to reference is encapsulation. It's one of the most gold…
Rewriting an ugly API could be problematic if not rewritten while fresh. Once it starts being refed everywhere good luck.. I bet there are no test cases either and the task becomes daunting and expensive
Re: Cognitive Biases in Software Development
#116Earlier quoted context omitted.
Sometimes small and easy, sometimes big and impacting the whole system. Generally small changes are preferred but that’s not always possible.
We generally review anywhere from 50 to 300 lines per diff. An unfamiliar reader may not be able to anticipate spooky action at a distance in other parts of the codebase, but a good design doesn’t permit much of that anyway. The reader can certainly understand what’s going on in the change, and if they don’t they shouldn’t approve it.
Re: Cognitive Biases in Software Development
#117Earlier quoted context omitted.
People think differently and the higher up in the abstraction level, the more diverse it will get. Like for example some people think in shapes and will get crazy if you do not format the code in the same shapes. Others think in words and writes the code as like they where talking to a human. Others have images in their head and doesn't really care how the code looks. Some people annotate their code so that it looks…
I have a coworker that names variables after Marvel and Disney characters.
Re: Cognitive Biases in Software Development
#118Earlier 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."