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.
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...
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
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.
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!
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 (rubenscheedler.hashnode.dev/the-mo...) 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.
My angry typing got me a tendinitis. Would not recommend it.
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).
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.
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.
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 ;).
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!
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 🤪
Flimsy is a very polite adjective to be using for the mess of code I had to recently clean. The impact on my health was severe. The main frustration for me lay in the fact the last person to leave the project as it was should have known better. He had all the experience and skills. Instead of organising and leading, he was lazy - he dithered, he wrote obscure (and obnoxious) bits of code, and for good measure littered hacks around the place (the pernicious impact of which was real but difficult to track).
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.
One of my main reasons for creating my own company is to be able to work with tools that I chose and avoid imposed nonsense I've seen in other companies.
Although it's all personal so I guess some people find that my stack doesn't make sense, however well it's not directly affecting me :D
Thanks for bringing this up.
I believe that flimsy code, bad quality code, over-engineered code, unnecessarily complex logic, high cyclomatic complexity have a very bad impact on mental health ( and of course on productivity)
the domain knowledge, the cognitive load, the burden you have to carry with you every time you have to read that code and have to change something is huge.
It is timeconsuming, hard to follow, tiring, confusing, and scary.
hard to read code which is fragile, and likely has no test could drain the most experience dev.
I know that debugging, fixing things, bringing clarity , refactoring, and improving legacy code can be challenging and fun - sometimes, but if you only have to work with such code bases you can easily become frustrated, demotivated, scared by the unknown countereffect of every simple change, and overall, simply fatigued.
this is why we as devs and leads should be really focused on keeping code bases simple and clean.
I think that most things affects our mental health nowadays. My problem was related to the fact that I couldn't control my aggression and anger. I really regret that I didn't listen to my relatives when they talked about my anger issues symptoms, then I could start therapy earlier. Now I am consulting with specialists and I have become much better at feeling myself and restraining myself.
Not really flimsy code but a legacy code base that is severely outdated and needs to be modernized. The original code base dates back to the early nineties and most of the original code is still there. Adding new functionality gets harder due to limitations everywhere. The code base needs to be modernized to make it easier to maintain and extend, and also get it on par with current develop methodologies.
Some of the challenges are
It often gets a bit frustrating, but I don't let it affect my mental health. I just have a clear separation between work and life.
I'd love to share some stuff regarding this but I'm very insecure and sensitive about my mental conditions so please excuse me.
Arigato
If you are a person who cares about many factors then work can take a very bad impact on your mental health.
💀