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.
Latest comments (29)
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.
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.
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.
If you are a person who cares about many factors then work can take a very bad impact on your mental health.
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
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.
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.
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).
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!