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 (29)
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 ;).