If the author reads this: Dark theme completely FUBARs the code snippets. Sample: https://i.imgur.com/QUO48fn.png
How did you change theme to Dark?
Cognitive Biases in Software Development
31–40 of 127 posts
Re: Cognitive Biases in Software Development
#32> When you look at complicated systems and clever solutions - most likely it took a lot of time and resources to implement it, but all you can see is the smooth result. It is easy to fall into this fallacy because complex solutions always require a lot of work, testing, and iterations.
I used to have this problem all the time with the managing director:
MD: Company X has a really nice and simple help system. Why can't we do the same?
Me: We can, but we need a product owner, a designer, a developer and a tester full time on this for at least a couple of months.
MD: I don't understand why we can't just copy what they did.
Re: Cognitive Biases in Software Development
#33Over 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.
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.
Re: Cognitive Biases in Software Development
#34I 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).
Re: Cognitive Biases in Software Development
#35If the author reads this: Dark theme completely FUBARs the code snippets. Sample: https://i.imgur.com/QUO48fn.png
How did you change theme to Dark?
Happened automatically on my device, probably because I have macOS running in dark mode. It's a feature. Switch your OS to the color scheme and language you prefer and websites / apps should adjust accordingly. Should. We're not quite there yet.
Re: Cognitive Biases in Software Development
#36Earlier quoted context omitted.
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?
Exactly this. I'm working on a codebase right now that looks like it was written by someone who had barely finished school, figured out how to use a function in JS to produce the HTML for an input element inside of an XHR response callback, then just kept reusing that over the next eight years leading to multiple >10K LOC files. I'm not sure the original author ever intended the application to be around that long.
Re: Cognitive Biases in Software Development
#37The 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 reason about software in smaller and smaller granularity, e.g. classes. And then we want to load down every single class with armor as if it needs to be protected against the wild hordes of unwashed masses who will rampantly mutate it. But most classes naturally fit into a larger unit, a cohort of classes, and they are coupled with each other, and they mutually share state. You can't understand the whole thing by staring at a single class, anyway. But it feels like we are doing the right thing because we are told every class needs armor. Nevermind that now every class is 3x bigger, and so the whole thing is 3x bigger, which makes it 9x harder to fit in your head! Uggh!
Re: Cognitive Biases in Software Development
#38I 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?
I think the GP's
> I call this, Developer Inertia:
should read
> I call this "Developer Inertia":
Re: Cognitive Biases in Software Development
#39My 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 connected with ones ability to think clearly about any given problem and the ability to logically deconstruct it in smaller, more digestible thoughts. If there's confusion in the mind, there probably will be confusion in the code as well.
Also, it just seems as if many are unable to step back and look at the broader side of things when coding. Asking questions like: Are we using the right concepts here? Did we develop sufficient abstractions? Case in point: I was just refactoring a code base for a client where the code was paved with a `MemoryHolder` type, where simply `Buffer` would have been the better name for the same concept.
Re: Cognitive Biases in Software Development
#40Earlier 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…
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 w…
'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.