How does flimsy code affect your mental health?

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...

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!

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.

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).

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.

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)

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.

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.

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.

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.

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.

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!

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.

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 🤪

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, fherehab.com/cocaine/about-cocaine/ may be helpful. Personally, when I feel like things are making me angry at work, I take a week off right away.