Caring for Your Health is Part of Programming

Caring for you health is part of programming large

If you think this is going to be another blog talking about the common health problems programmers have, then you are right.  Actually no. Well… kind of, but with a twist.

Let me tell you a story. A personal story.

For the past year, I’ve been working on one of those projects… What do I mean by that? Well, if you have several years coding for a living, most likely, you have worked on projects hard to understand, not fun to work on, and hard to complete on time. On top of that, it requires updating legacy code lacking the proper documentation…

‍…I actually said it wrong.

‍A legacy code which the only documentation available is the business owners’ knowledge.

‍As a requirement, unit tests are mandatory to get a 95% code coverage. To put a cherry on the top, the legacy code can’t be debugged.

‍For the sake of making the story more interesting, let’s call this project TCB, aka, Taking Care of Business, something that didn’t happen.

‍None of the developers of the team had a true knowledge of the programming language in which this legacy code was written. We were able to understand the general idea of the code, but let me tell you it was a constant guessing game. Personally, I always hoped I had understood correctly the logic written in that legacy code to translate into an upgraded version of TCB.

‍I didn’t start working on TCB from the beginning. In reality, I was moved from another project to work on TCB to increase the resources to complete the project on time.

‍It’s funny in the tech world you are defined as a “resource”.

‍Anyways… back to the story.

‍The challenge: work on the rest of the features, 3 months-worth of development, to complete and deliver TCB within a month and a half. Like any good programmer team, we got our headphones ready, bought plenty of coffee, and switched our IDE themes into a dark mode, and said: “Challenge Accepted”.‍

The reality is we were a remote team. Therefore, I didn’t know if anyone got extra coffee, put on their headphones, or even used a dark theme for our IDE of choice. I was trying to make the story more interesting.

However, we did take on a challenge in which we couldn’t say no. There was no other choice. Knowing all of this, failure was the only possible outcome.

‍In order to compensate for the amount of work and the amount of time available to complete on time, we had to work late nights and weekends. I worked about 60 to 70 hours a week average. Some days, I worked 10, 11, 12 hours. My record was 14 hours one day. If you are a person who considers 14 hours-worth of work means to be a committed, team player, I can tell you it is one of the dumbest things you can do as a programmer.

I am a person who works out almost every morning. Working out gives me energy, relaxes my brain, helps me stay away from the monitor for a few hours, plus it helps me stay fit. I also run about 3-5 miles two to three days a week. If you guessed it right, working 10 to 14 hours almost every day leaves no room to work out, but only to eat and sleep. Whenever I had the chance, I went to run for 10 to 20 minutes. Then, I took a quick shower and got back to sitting position and coding mode.

Unfortunately, my short runs didn’t last long either as all of the sudden my right ankle was hurting after jogging for a few minutes without any reasonable explanation. A few months later, I realized my pain was due to stress and the antidote for it was a one-week vacation which magically healed my ankle.

Look, I was committed to finishing the project on time at the expense of my wellness. The more hours I put to code, the more bugs the Quality Analysts (QAs) found. Completing user stories was taking longer than I anticipated, and my code quality was on the floor. Oftentimes, I felt the temptation of finding shortcuts that would speed up the development process. However, those shortcuts didn’t include the first part of that word: “short”.  Long hours of work made my brain tired and putting lines of code with a tired brain is a “no bueno”.

Wait, I talk Spanish. The correct way to say it is “no es bueno”, or “not good” in English.

‍Overall, everything was a disaster. My health was a disaster. My code was a disaster. The project was a disaster.

‍Thinking that working more hours was going to be the solution was the worst decision after all. By working longer hours, I sacrificed my allotted workout times. Remember I mentioned working out makes me more energetic? That extra energy was gone.

‍Not getting enough sleep was another problem. My body didn’t get enough rest to be fresh and ready for a job that requires a lot of concentration. Remember I mentioned working out relaxes my brain? That extra hour or two of brain relaxation was gone too.

‍Working on TCB under tight deadlines and constantly not completing user stories on time due to buggy code was getting me sick with an illness that can’t be seen or felt: stress. Remember my ankle started hurting all the sudden which prevented me from running? Not being able to run was not relaxing my brain and not helping me stay fit, which affected the quality of code. Therefore, I wrote more buggy code, which made me more stressed and work more hours. Therefore, I couldn’t go work out… and the infinite loop kept going…

‍Listen, If there is something I learned from that experience it is that staying healthy is a key factor if you want to be programming for a living and you care about writing clean and quality code. Next time you think about compromising your health, think about the repercussions it could have not only in your code, but also in your life. No job is worth risking your health. Plenty of jobs are out there, but you only get to live once.

Share this article or checkout our social media channels!