DEV Community

Cover image for How does flimsy code affect your mental health?
Ben Halpern
Ben Halpern

Posted on


How does flimsy code affect your mental health?

Being responsible, whether individually or a team, cannot be good for your mental health, capacity to unwind, etc.

However, I haven't really seen this issue discussed much directly.

Please weigh in, I'd love to hear about your experience with this issue.

Top comments (30)

matthewbdaly profile image
Matthew Daly • Edited

This is something close to my heart. I maintain a large legacy application with many serious issues. After four years of me spending maybe 80% of my working time on this project, it's improved significantly, but there's still plenty of stuff that is downright painful to work with, and it's virtually impossible to write any kind of useful automated tests for this project.

Static analysis is an absolute godsend, and Psalm has caught a huge number of potential issues, but the code base has substantial gaps in the type coverage, so some type issues will still get through until that's remedied. Fortunately this application is an intranet system rather than something web-facing so there's a limited pool of users and we only have to support the web browsers they use, but it can still often be nerve-wracking to push a change live.

Fortunately my colleagues are conscious that this is the case and are very supportive, but the mental load of this code base is higher than just about anything else I've ever worked on. As such it can really be a strain to work on it at times. At this point in my career I know my own limits fairly well and generally know when I hit a wall and need to do something else for a bit, but I have struggled with burnout from time to time on this project. It can be very, very frustrating when implementing a feature takes many, many times longer than it should because it needs to be built on top of existing bad functionality and there's no scope to rebuild it the way it should be built right now. In addition, getting into the highly productive state known as "flow" is much, much harder when working on this project.

We're sincerely hoping the client will agree to our proposed rebuild soon...

kienngo profile image

Wow i thought I had a terrible experience with a legacy codebase which is a mix of AngularJS & jQuery but yours is clearly worse. I spent 2 years on that crap. Learnt a lot but it took a toll on my mental

j143 profile image
Janardhan Pulivarthi

Sometimes I wake up at nights thinking about the future of the legacy code I maintain. 😥

I add a commentary of few points about what to upgrade (which possible version), which components to remove, few supporting life quotes in the developer notes in the repository.

grahamthedevrel profile image
GrahamTheDevRel • Edited

My mental health doesn’t suffer…but I certainly go through keyboards a lot quicker with my “angry typing” when confronted by a horrendous codebase!

Being serious, well organised, structured and COMMENTED code is a lot less stressful to work with and you can get a lot more done. I have been spending a lot more time tidying code as I go rather than “I will fix it later” as it saves me a lot of frustration when I come back to it 6 months later and try to understand what young me was thinking at the time!

So for the sake of your own health, and that of your team, take 5 minutes to clean up your code before committing it and, as I said, comment parts that need it (don’t believe the “good code doesn’t need comments” crap, even the cleanest code is easier to navigate if you explain more complex functions!

renanfranca profile image
Renan Franca

Hello my friend @inhuofficial ,

I am trying hard to not comment on my code because I believe if I named the variables, the methods and the classes right, everyone will understand it.

But this article ( changed my mind about using my comment to give context to the future devs that will maintain the code. I am going to comment when I can't fix a technical debt or when I create technical debt.

mephi profile image

My angry typing got me a tendinitis. Would not recommend it.

wesen profile image
Manuel Odendahl

More so than flimsy code (refactoring can be fun), what crushes my mental health is management pulling in the wrong direction (i.e., creating more flimsy code for no good product reason).

I'm perfectly fine creating flimsy code / making compromises when there is a clearly articulated goal, and metrics in place to keep track of the effectiveness of that compromise.

The more experience I have, the more I recognize that flimsy code can be the best code in specific circumstances. So while it is not fun to have to deal with it in the moment, I know it makes sense.

jankapunkt profile image
Jan Küster

My worst nightmare was an app that was in itself well formatted code and didn't look flimsy at a first glance. The problem was that the more you dive in the more you realize that functions were named by total randomness. In the most crucial methods there were variables like a, b,c and a1, b1, c1 and so on and there was no documentation at all.

The first step you had to do when a customer opened a ticket or bug report: start the debugger. Klick step. Klick step. Klick step in. Klick step. For ages.... I was happy when I gave it to someone else (and felt sorry for him at the same time).

j143 profile image
Janardhan Pulivarthi

Everytime you get a chance to work with the code, add some pointers about how to maintain the code, which issues to fix. Even though they feel like a lot, over few iterations most of these bad naming can be fixed.

It is better to have a one page code style guide and philosophy.

lepinekong profile image
lepinekong • Edited

Problem is the ego. A developer who does not recognize he created a bug is a hassle (I met some on my own projects). But his behavior may be understandable when an organization, even the whole society is playing the blame game instead of taking it as an opportunity to study the bug and make improvement to prevent it that it is on personal or team level. Agile retrospective should be focus on improvement instead of just autocongratulation or flagellation of what team do it right or wrong ;)

More generally people especially juniors think that you can do clean code right away, no it takes at least double time once your code "works" (even triple or quadruple if you work on a framework component to be used by unknow applications) see Uncle Bob the father of clean code. Since many won't take this time, no wonder technical debt accumulating.

chrisgreening profile image
Chris Greening • Edited

The anxiety of knowing flimsy code I wrote before I knew better is out there in the wild in prod has literally kept me up at night

For a while it was derived from open source guilt where I was waking up to panic attacks thinking about all the issues piling up in my repo or passive aggressive emails flooding my inbox but eventually I was able to ease off myself a bit and harden against (some of) the pressure/perceived criticism/etc

After that stint as a lone wolf open source maintainer I picked up one of my first true freelance gigs solo-developing a simple(ish) CRM web app deployed to Google Cloud for a local business. Being that I had never worked on the cloud before and I was one guy working alone, I inevitably had to cut some corners to get it in on time. The open source guilt from the prior months thus morphed into a new anxiety of worrying even a single line of flimsy code would crash prod and it would be on me. Over the following months I did research in my off time and every time the client would request a new feature I would double back and harden some of that old flimsy code/infrastructure (and proportionately reduce some personal anxiety)

And then eventually I stepped into my current role where I'm working with a team to provide marketing analytics to businesses all over the world. I'm the one with the most engineering experience (whereas the others are wizards at data science and stats) so it's my responsibility to harden our codebase and build robust pipelines to keep things moving. Although my threshold for stress and ability to work around flimsy code has risen considerably, there's always those echoes of anxiety surrounding "weak links" in our code whether it's my direct responsibility or not to fix it

And so the cycle continues 😜 the flimsy code is always there, I've just had to learn the optimal ratio of flimsy code to getting deliverables out on time. In an ideal world we'd have perfect test coverage, solid code reviews, and robust documentation but unfortunately that isn't always the case and I've had to adjust accordingly to at least try to roll with the punches to keep my mental health somewhat in check (and iterate over/refactor our codebase as best as realistically possible)

lase profile image
Matt Laser

Honestly, this is a huge problem for me.

I joined on at a subsidiary of a huge, old tech company last year. My group works on a mobile device management product that is essentially "IT as a service" for a huge number of other companies.

I work on the mobile app. The code is not only flimsy, but thanks to a high degree of turnover & poor documentation, it is largely unknown to both me, my team, and the the product & support teams.

While I've done what I can to improve and learn more about the code, it's obvious that we don't have the bandwidth to do the proper learning or refactoring (the headcount to maintain the entirety of the mobile platforms is 2 developers 😖). This leads to near constant anxiety for me, because it's always only a matter of time before some arcane feature breaks entirely, where not even the product team knows what should be happening, but merely only had a vague idea of what was happening before.

I'm doing a ton of interviewing and praying to get out.

drsensor profile image
Fahmi Akbar Wildana

I learn that flimsy code and less automated tests is a good approach for certain cases. I learn this after participating gamejam. Seriously never though of getting hooked in gamedev before so this is really new to me. Along the way I also learn that rather investing on testing, it's best to invest on CI, build system, and asset pipeline as early as possible. Also, aggressive code formatter (i.e prettier, deno fmt, ...) might be bad when you are authoring a library (better to use built-in formatter in typescript-lsp/vscode). Linter still ok but mostly I need to tone it down.

jmau111 profile image

It's a tough question. On the one hand, the lack of good standards and tests can introduce nasty regressions and headaches.

On the other hand, we all start from the bottom ^^, so we need to take it into account when we review other's (potentially less experienced) developers.

However, it's far better to do refactoring and cleaning incrementally. Otherwise, you might reach a deadend.

jonrandy profile image
Jon Randy 🎖️ • Edited

I think it is extremely beneficial. It presents you with a challenge to make it better, re-think it, and improve it. Clean code is boring - it takes little mental effort to deal with and removes anything interesting from doing programming. Dealing with and understanding challenging code, or improving 'flimsy' code is one of the best parts of the job.

For mental health, it couldn't be better... it keeps you on your toes and prevents stagnation and laziness.

xtofl profile image

That is an interesting attitude! Are you serious?

I do feel some satisfaction after reducing some module's complexity, but honestly, I often just don't see what some authors were trying to achieve, and feel like they have thrown away their and my time (and the customer's money). That's what gives me headaches: the waste.

So you're the one we need to come see in time of distress ;).

valeriavg profile image

When I stumble upon gross architectural mistakes it doesn't affect me until the code has a con artist developer attached to it. Being a social animal, I need to be a part of a community, and the realisation that some members of my professional community are proud of wasting time and resources while creating something that will make work of others harder does affect my mental health.

renanfranca profile image
Renan Franca

I do suffer from flimsy code!

The hardest part is that you have to implement new features which required a fancy user experience but you don't have the time to rewrite the old codebase.

So it is creating flimsy code over flimsy code and waiting for the time it breaks and someone paid attention to what you are warning since day one!

jeremyf profile image
Jeremy Friesen

My initial response is invariably "Ugh". But then it turns into "How can I make this just a bit less flimsy?"

Inevitably, it's about refactoring and assuming ownership of the flimsy stuff.

andrewbaisden profile image
Andrew Baisden

Legacy codebases make my head spin right round right round 🙃 Recently experienced this on a project. The documentation was completely out of date it might as well have been abandoned. Your stress levels go through the roof and the whole time your thinking why can't this be using a modern technical stack that i'm used to....

Having to install all kinds of random applications that you have never even heard of before and blindly following the documentation because its your only reference and the only way you can actually get it done.

Just to be met with more frustration and blockers because you don't really know what you are doing and the support you ask for is not very helpful. It is like forcibly installing bloatware on your machine for the purpose of insanity 🤪

kaydengood profile image
KaydenGood • Edited

No job is worth your mental health. Regardless of what others tell you, you need to consider the peculiarities of your psyche, which may not be able to withstand overexertion. So if you want to take a break or change activities, it is better to do it. At the same time, you can adequately assess the situation. Otherwise, you may be mentally overwhelmed to the point where you start abusing something. Stress at work is one of the mechanisms of addiction. If you are interested in this topic, may be helpful. Personally, when I feel like things are making me angry at work, I take a week off right away.