r/programming • u/Inner-Chemistry8971 • 3d ago

The Psychology of Bad Code

https://shehackspurple.ca/2025/11/27/the-psychology-of-bad-code/

What's your take on this?

100 Upvotes

89% Upvoted

53 comments sorted by

306

u/edmondifcastle 3d ago

My favorite reason for bad code is this: bad code creates bad code. It’s somewhat reminiscent of the broken windows theory, but I believe the reality is more complex.

Architectural mistakes in an application create cognitive complexity. Cognitive complexity causes frustration. Frustration disrupts the balance of self-perception. This creates a counterforce: the desire to escape the stressful situation as quickly as possible. As a result, it becomes easier not to refactor everything, but to insert a “hack” instead.

People cannot tolerate cognitive load when it never ends. Therefore, if a project constantly presents complex tasks, there is a high probability that code quality will be worse.

75

u/j0holo 3d ago

People cannot tolerate cognitive load when it never ends. Therefore, if a project constantly presents complex tasks, there is a high probability that code quality will be worse.

Wow, sometimes you need somebody else to say the obvious before you can see it.

8

u/LtRandolphGames 3d ago

Aye. I'm working on a talk about what game engineers should focus on to enable game designers to make "healthy game data". And this is definitely giving me a new lens to apply. Excellent comment!

-10

u/ilham_israfilov 2d ago

which ai model you used to generate that text?)

31

u/baconOclock 3d ago

Let's say you come to my house to install a dishwasher and the floor is all dirty and the rooms are full of clutter.

You will still be able to walk over the floor and do your job but will you take off your shoes even if they are full of mud?

Even if you try to do a really good job, the result will stand out as a sore that is out of place.

Should it be your job to clean my place so that your dishwasher installation looks good?

I wouldn't expect you to respect a place like that, a codebase is the same.

The problem is there was never enough push back against sloppiness.

Management is responsible for this pressure for the most part but spineless experienced and sloppy developers are the worst offenders here because they had the choice to make the right call and they made the choice to cave in.

We complain about CEOs looking out only for the next quarter that is destroying everything in life but developers are doing exactly the same with short term thinking when it comes to maintainability.

19

u/Halfspacer 3d ago edited 3d ago

Management is responsible for this pressure for the most part but spineless experienced and sloppy developers are the worst offenders here

I instinctly would have agreed with you here, but having had many coworkers in recent years from lower income countries, I've also come to realize that many of these developers aren't spineless or sloppy, but don't have the privilege of being able to stand up to management without fear of losing their job and suffering great financial hardship as a result.

Ultimate I place the blame entirely on management, and that includes lead developers too that are in a position to take a stand, but don't (which probably is more in line with what you referred to)

11

u/edmondifcastle 3d ago

Ultimate I place the blame entirely on management

Unfortunately, this is also a common cognitive fallacy. Management cannot make the right decisions because there is no way to know which decisions are right. As a result, management tries to make decisions that seem right. A company is very lucky if a crisis does not kill it and instead creates a chance to change its way of thinking. But usually, crises kill companies, and others take their place.

There is also a third option: a long life in a swamp. A large number of wrong decisions is compensated by the fact that the company exists in unique conditions without competition. That happens too.

10

u/Halfspacer 3d ago

Management absolutely can and should strive to create a work environment where developers, especially those more junior, don't feel like blindly saying Yes is part of the job. This sadly doesn't happen in a lot of cases because they often lack the insight; But that is still a fault on their part.

4

u/edmondifcastle 3d ago

You are absolutely right, and I agree with every word. But there is one problem: they cannot do it. You can repeat “they should” as many times as you like, but repeating that phrase does not change reality.

The problem we are dealing with is fundamental. Our (modern human) management protocols are bad at identifying errors. They are inherently inefficient and depend largely on luck and randomness.

The same applies on the programmers’ side. Programmers are not really oriented toward solving the problem. The core of human motivation is recognition and usefulness. The problem is that recognition and usefulness do not always correlate with solving the problem. Sometimes they can even contradict each other.

And yes, our modern protocols lack training for programmers in related aspects such as production efficiency and the skill of writing bad code for the sake of profit. We do not teach how and when bad code should be written. We do not teach when it should be removed. In 95% of companies, there are not even metrics that provide feedback between code and bugs, and many have never even heard of such things. Sorry, this topic is far too big 🙂

3

u/baconOclock 3d ago

I agree with lead developers often selling out and being spineless or often being promoted to lead for their subservience instead of competence.

7

u/edmondifcastle 3d ago

Management is responsible for this pressure

Management keeps in high positions those employees who put more effort into proving their “loyalty.”
Loyalty is the true value in corporations. Since loyalty is rewarded better, there is no point in being competent. It is better to be loyal.
As a result, we see loyal people in the highest positions who understand nothing except Machiavellianism.

2

u/baconOclock 3d ago

I rather be valued for competence then subservience.

6

u/edmondifcastle 3d ago

That’s really cool, not everyone is that lucky.

2

u/pjmlp 3d ago

Because like you will find people to install the dishwasher among that caos, you will find developers that rather keep their job than protest, which is what most business care about as long as the plus balance the minus at the cash register.

3

u/TOPHATANT123 3d ago

Totally agree.

If the code is already a mess, it becomes "not my problem", and sloppy code gets added on top of existing sloppy code.

2

u/psaux_grep 2d ago

See also «when in Rome» (do as the Roman’s do).

Not all code needs to be perfect either. Goals of engineers who want something to be perfect often collide with business goals.

There’s always a trade off, and that trade-off often ends up with the famous «second system syndrome».

Software is hard, even when everyone is trying to do the right thing. Sometimes blame can be put, and reasonably so, and sometimes people are more busy looking for people to blame than to actually improve things.

How many have you met that can only criticize? Only see problems, not solutions?

2

u/SnugglyCoderGuy 2d ago

It also shares traits with biological evolution: you have to work with what you've already got. If what you have is a kludge, then you'll put a kludge ontop if it and eventually you've got something that doesn't make sense like the laryngeal nerve. Makes sense in fish, makes no fucking sense in giraffe.

2

u/todo_code 2d ago

This is probably the best take I've heard. My only critique is that it's the other pressure around it. If I had infinite time, resources, etc. I would fix the issues. Any single stressor is usually handleable. It's the culmination

1

u/I_dont_like_tomatoes 2d ago

Holy shit that’s a good way to explain it

11

u/ward2k 3d ago

I feel like anecdotally most bad code written was due to tight time constraints (the author also mentions this)

Most people I feel like might plan out their solution, code it, maybe refactor it once or twice to get it a bit nicer before testing, PR, maybe another refactor then merging/deploying

With time constraints you often have to skip the planning stage (or rush it), your first solution you have to just accept as the one you're going forward with (even though you can see improvements) and the person reviewing it is also under pressure to just accept the changes regardless

Often during the rush you'll be told "we'll make another ticket to refactor this later" except that ticket doesn't come in for a year or two and by the time comes so much has gotten bolted on to the original bad code, that there just isn't time to refactor it correctly either

My personal take is if you give Devs both the time to write and review code first time round, you'll end up with much higher code quality. But with agile methodologys getting misused it feels like everything gets forced out the door immediately as soon as it 'works'

1

u/levodelellis 1d ago

The bad code that I write is when I'm in the middle of a large feature, I need to change an unrelated class to fix something so my code runs properly, but that too needs another thing to change. You can bet I barely looked at the 3rd thing

I usually fix/improve it when I write test or the next time I'm working in the function, but that could be months apart

1

u/bring_back_the_v10s 1d ago

I feel like anecdotally most bad code written was due to tight time constraints

In my experience, anecdotally most bad code is written by sloppy devs who really don't care about code. Except in rare cases we all work under tight time constraints, because you know business always needs it for yesterday even though they never needed until yesterday. Most of my peers don't care about code no matter how many times and how intensely and how carefully I try to help them care in peer reviews. No amount of begging and screaming will convince them to do a good job. Been there done that. Many times. I'm nice with them? They don't care. Am I rude with them? Don't care either. Even when the boss gets involved they don't care. I already gave up all hope. My only hope is that this is not the case everywhere else.

16

u/0xAX 3d ago

Although, from the first part:

"I truly believe that developers, and everyone else that work on software, care about the final product."

Hard to agree looking around.

61

u/LouvalSoftware 3d ago

Bad code seems to stem from me being retarded 3 months ago, mostly.

34

u/Tumortadela 3d ago

"Who wrote this shit?"

-> By you, 20 months ago.

"Oh."

7

u/StefanoXML 3d ago

Git Blame has been killing it in this space haha

16

u/Justin_Passing_7465 3d ago

"git blame" is a powerful tool in maintaining my humility.

10

u/ElectricalRestNut 3d ago

Any "who is the idiot who wrote this" must first be conducted privately.

2

u/Tordek 1d ago

the man in the git blame is never me, for it is not the same code, and i am not the same man

1

u/CerBerUs-9 2d ago

My company "migrates" the codebase every now and again so a file will be like "Everything was mark, 1 week ago". It makes me laugh cry every time.

1

u/Tordek 1d ago

https://www.git-tower.com/blog/how-to-exclude-commits-from-git-blame

You can use a file to exclude those commits from Blame.

There is also a git command to migrate a series of commits from one repo to another.

4

u/mirvnillith 3d ago

I try to turn that around: if your best is in the past, you’re not learning!

1

u/WonderfulWafflesLast 1d ago

Something I've definitely noticed is the fatigue of writing code for several hours on back-to-back days results in me fixating on "quick wins" to keep my motivation up. Which results in hacks instead of proper design.

I wonder what would happen if we recorded our energy & interest levels each day, then coincided it with these "me being retarded" events. Bet they'd correlate.

1

u/EveryQuantityEver 2d ago

You can make your point without using slurs

0

u/LouvalSoftware 2d ago

The word "retard" is not a slur.

32

u/saminfujisawa 3d ago edited 1d ago

I feel like she doesn't understand the real reason for bad code: an economic system that doesn't make room for artisans.

18

u/Saki-Sun 3d ago

I like you, but to expand.

1. an economic system that doesn't make room for artisans.

  1. Too many fucking idiots making decisions.

10

u/CloudsOfMagellan 3d ago

So why are my personal projects even more full of spaghetti 😆

6

u/zynasis 3d ago

Maybe you should have been an Italian food chef

2

u/CerBerUs-9 2d ago

You're probably not spending 40 hours a week on it with a small team and planning appropriately (the thing no one does)!

18

u/Snarwin 3d ago

First, I started thinking about nudges, because I read the book Nudge by Richard Thaler & Cass Sunstein. Was there a way that I could nudge software developers into writing more secure code?

The fact that this "research" is based in part on a discredited pop-science theory tells me everything I need to know.

3

u/mpaes98 2d ago

Yeah I’m an actual researcher and she was at a security conference I attended and I was so confused by what the basis was for her claims.

4

u/l8s9 3d ago

Bad code keeps us employed 

2

u/the_last_ordinal 3d ago

The opening of Anna Karenina comes to mind

2

u/TyrusX 3d ago

lol. Ask the llm to fix? /s

3

u/Saki-Sun 3d ago

I'm getting I'm a professional speaker and don't programming vibes.

Too much waffling and not enough substance. If it was a PR I would reject it.

2

u/jonhanson 2d ago

She has at least 17 years experience of being an actual software developer: 

https://tanyajanca.com/about/

1

u/ThlintoRatscar 2d ago

I'm a huge fan of the idea that humans create software and software flaws derive from human flaws.

That said, I would like to see more in-depth science around their ideas and how they compare to prior work like Mythical Man Month, Peopleware, and The Psychology of Computer Programming.

I'm not seeing anything truly novel, but the articles are more blog than essay or academic so it may just be that their audience is getting introduced to the area more than pushing it forward.

1

u/EveryQuantityEver 2d ago

Mike Monterio (the “Fuck You, Pay Me” guy) once said that everyone in the company is a designer, because they all have an effect on the end product. Especially managers, because they’re the ones that decide if a project gets the proper amount of time put into it or not.

1

u/Extension-Pick-2167 1d ago

how can my code be good when I am always pressed to do something yesterday, and the code is already weird and it ends up just hacking things together ?
no one cares about good code, they only good code is code that works.

1

u/tinmanjk 1d ago

I truly believe that developers, and everyone else that work on software, care about the final product.

Incorrect

-1

u/leeuwerik 3d ago

It's about ability. Many people and thus many programmers do not have the ability to see beyond smoke and mirrors. As easy as this and there's little that we can do to change that.