Work Life Balance = Fn (Code Quality, Best Practices, Technical Debt)

This is based on a set of realizations I have when I look back through my career as a developer on code quality, best practices, etc. However, this blog post is not to teach you about the importance of any of it (or software engineering) in a traditional sense. There are tons of articles/books/sites dedicated to doing just that, a couple of mouse clicks away.

What I wanted to write about is the impact of not following any of it in our personal lives.

To begin with let’s consider [T=0], A New Project:

Occasionally, we are lucky enough to work on a fresh code base (zero code written yet, just created the repo). Everybody seems happy at the first couple of weeks; code being written, reviews/tests done, features delivered. Client(s) is happy, team is happy.

But as the time goes by (e.g. around 5th to 7th sprint) we realize there are issues popping up, it’s difficult to add features, make modifications or worst fix a certain bug without breaking another. I’m not going to make a detailed list here, but readers (assuming you are working in the software industry) know type of issues they encounter too well on daily life. This is technical debt. And technical debt gets amassed by each release, bug fix we do over the time span of the project (- lifetime of any sizable project/code base spans over more than a decade).

One important observation, we must make here is, most of us will eventually end up spending lot of hours trying to solve the mess. Either the mess is our own doing or created by someone else. Most often that ‘someone’ is not even a member of the current team!

Keep doing this for couple years, it will result,

1. Lot of time spent in the office/project(s), sleepless nights
2. Lots of mental stress
3. Screwed up health (- yeah — those junk foods we eat late night at the office will eventually screw us big time by the time we hit late thirties (forties if you are lucky!)
4. Eventually (after a couple of years of repeatedly doing #1, #2), explore deep stuff such as (A) purpose of life, (B) who am I… © why am I doing it!. Or worst end up being medicated for depression, anxiety! LOL!

Now I’m not going to say we can keep the technical debt to zero. In fact, given enough time and complexity any project/code-base will have some debt. In my opinion, it’s just a side effect of life/world not being perfect. How? There will always be,

• Areas of code we will change where we don’t know much about!
• Release deadlines and production issues.
• All sorts of problems in life cutting into our decisions relating to work.
• And the list can go on!

Like I mentioned again, there are plenty of books/material out there just to teach how to write quality code. And most of us programmers did complete coursework on these topics during our undergrad years. With all that problem persists and we all suffer from it!

My observation is nobody really understands or noticed the effect of bad code in our lives as programmers.

It’s almost similar to environment pollution. We know it’s bad. Therefore, we talk about it, and we try to what we can to keep it to a minimum like any sane person would do! But there is always some other guy who will do something bad for the environment!

Same goes for code bases, while everyone thrives to write clean code and follow whatever the practices that are agreed as the best for the project, there will be a someone who will commit some ‘not so nice’ code (due to a variety of reasons mentioned above!). Which not only ruins his/her peace of mind in the long term, but also a lot of other people as well!

Over the years, this observation made me to treat such bad programmers, as people who lacks empathy towards others or bad team players. My rationale here is: say there exists a team member who write stuff that not up to the expected standard (- contributes towards growing technical debt), that’s added work/cycles. Those cycles must come from him or some other team member. Basically, there got to be someone who will clean the mess up (be it in the next day or next year where a guy might not even be in the team thus making it worse for current team members).

Two questions arise:

1. Do you want to be that guy? Who fails the team by screwing their work life balance at minimum.
2. Do you want the guy next to you in the project to be that guy? Where you might end up fixing the fallout, he/she creates?

To me answer to first question revolves around, whether he/she is a right fit for the job/role he is hired for. The answer to the second question is obviously ‘No’. Which again makes you think about the first question; but the answer is slightly different. If you don’t want the next guy to be like that, why not thrive, not to be that guy yourself?

Another observation I made in the past was any process, tool, material will fail unless the mindset of us (As programmers) don’t change positively towards it. Unless we keep demanding excellence from ourselves and team mates next to us, no tool/process can save us!