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

41–50 of 127 posts

Re: Cognitive Biases in Software Development

#41

Post by izacus »

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.

But those two things are not related - my experience shows is that a giant amount of code WILL run forever. That quick hack you did? In production for 6 years. That quick "demo" you thew together? People will curse you for next 10 years.

If anything, FAANGs have resources and intertia to actually work on technical debt. Smaller companies will just churn and churn and churn until they bog down into unmaintainable mess of a code and can't respond to market changes anymore because their codebase is impossible to change or maintain.

Then they'll usually call us to fix their issue and be angry when the answer is "there's no easy way out of the mess you caused" while their competition is moving ahead of them.

Re: Cognitive Biases in Software Development

#42

Post by giantDinosaur »

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…

Although somewhat amusing, I'm assuming there's more to 'MemoryHolder' than just an inappropriate name. What was wrong about it at the type level that illustrates your point? Or do you mean to say that it's (somehow) illustrative of a lack of conceptual understanding?

Re: Cognitive Biases in Software Development

#43

Post by rendall »

reallydontask wrote: post #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'…

"MD: I don't understand why we can't just copy what they did."

What was your reply?

Re: Cognitive Biases in Software Development

#44

Post by z3t4 »

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…

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 like LLVM. Others think of real world items like containers, ships, streams, etc.

Re: Cognitive Biases in Software Development

#45

Post by fnord123 »

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…

>If the language I'm working in supported FP, then my world would be much better.

Assuming FP means functional programming and not function pointers, what language these days doesn't support functional programming?? Are you coding in AWK? Seriously almost every language but C supports higher order functions, anonymous functions, and recursion (though recursion is an anti-pattern and iteration is superior).

Re: Cognitive Biases in Software Development

#46

Post by ThalesX »

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 functionality needed extraction.

Re: Cognitive Biases in Software Development

#47

Post by onion2k »

raverbashing wrote: post #40
onion2k wrote: post #25

Earlier quoted context omitted.

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.

'a' and 'i' are perfect for indexes

Except they're not as good as 'index', which is obvious and provides some meaning, so why accept single character name?

I have an eslint rule that blocks single character var names on my projects. It makes my team develop good habits, and no one has ever complained about it. Our code is very readable.

Re: Cognitive Biases in Software Development

#48

Post by devurand »

saberdancer wrote: post #30
Gibbon1 wrote: post #10

Earlier quoted context omitted.

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.

Exactly. I did layout for awhile. Some boards you knew weren't going to come back. Customer was just paying for us to turn a schematic and BOM into a board with the least amount of cost possible. Quoted low. You could let the autorouter have at it. But other boards (especially finicky high clock speed chip tester boards) would definitely be coming back. Sure you could let the autorouter do its thing, but when that board came back for a rev, I'd have to fuck with all of that laziness to make space for new components or reduce the layer count.

Re: Cognitive Biases in Software Development

#49

Post by jacobush »

rendall wrote: post #43
reallydontask wrote: post #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'…

"MD: I don't understand why we can't just copy what they did." What was your reply?

We can. They have a product owner, a designer, a developer and a tester full time.

Re: Cognitive Biases in Software Development

#50

Post by z3t4 »

Cthulhu_ wrote: post #34
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'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).

I also write the most dumb and simple code and if it works, then great, I don't touch it until it needs to be optimized or more likely: removed.

Sometimes I don't really know what I'm doing, just getting all tests to pass. Then once it's working, when I know why it works, I will clean it up by removing unnecessary variables, double negations, and name the magic numbers, etc, and try to make it as simple as possible.

Post reply on HN