Chances are you are reading this blog because you’re a programmer. If not, that means you are interested in becoming a programmer.

Yes, some people call us programmers, coders, software developers, or software engineers. Some people might start an argument that all the terms previously used to define someone who works in the software industry to develop IT solutions is not correct, although I believe it doesn’t matter much. Sooner or later, in whichever way you are called, you will work overtime, and let me tell you, not necessarily a couple of hours extra. I’m talking about long nights, weekends, non-stop pace.

By the way, if you are a person interested in becoming a programmer, by no means am I discouraging you from becoming one. It’s the total opposite. I highly believe being a programmer gives you superpowers. As stupid as it sounds, it does gives you abilities that a “regular” person doesn’t have. The best of all is that anyone can be a programmer.

However! Just be aware about that…

And back to the main point…

The main point I want to talk about today is why this overtime trend keeps happening especially in the software development industry?

Let me tell you something.


Ha! That was it!

I know, I know, that might be the silliest part of this blog, but it is supposed to be fun at the same time.

As I try to think what my next blog post will be after finishing my Friday load of work and muting all my Slack work notifications as I head into what could be a nice and recharging weekend, I get a sudden call from an unexpected number.

Although I don’t usually like to answer calls from unknow numbers, this time I decide to answer.

John: “Hello? Andres?”

Andres: “Who is this…?”

John: “This is John, your boss. Man, sorry to call you this late on a Friday night, but we’ve got big production issues with the latest release. The client is not happy and we are trying to get this fixed, we need your help. Could you join us on zoom call and help us with this?”

My friends, that’s the description of a recharging weekend converted into a weekend full of coffee with extra shots of coffee.

What can I say… I don’t drink coffee…but, you get the point.

We spent most of our weekend fixing production issues.

Sometimes I wonder whether I should have answered the phone call or not. Whether I should have lied about saying that I was traveling out of town and didn’t take my computer with me or not. Whether I should have completely disconnected myself from all devices or not.

No, I’m not joking. This is mainly due to a constant number of weekends working to get the job done under tight deadlines.

However, to show professionalism and care about the project I decide to help.

Funny Fact: My boss suggested to talk about this on my blog.

When I started my software development career, I enjoyed every learning opportunity. I still do, however, I remember I would go back home after work to keep learning more about the things I hadn’t learned, figured out, or solved during my work time. It is almost like taking a job outside of your regular working hours without officially working and without thinking about working. What can you do if it triggers your brain to keep thinking about learning something that could be the solution to a problem? That means you are enjoying this programming journey, and you are ambitious or excited to learn more and more, at least in my opinion.

If you relate with this character, there is a high chance your work-life balance is on point.

Aren’t you still thinking about work after hours? You might ask.

Let me explain.

You are still thinking about work because what you are interested in is the solution, not the actual work. You are interested in improving your skillset so you can optimize your development time so you can spend more time doing other things that you like besides working.

At a later point in my career, I was at the point that I didn’t want to know anything about software development after work hours. Nothing.

New technologies? I don’t care.

New software patterns? Please stay away from me.

New ways to write tests in your code? Who cares about the tests as long as it works.

New cloud services? I need to disconnect my Internet.

Yes, this can get this bad. Although you might have bad days, like anyone, sometimes you feel this industry is not for you.


Among many other reasons, working too much is one of the leading causes that makes this weird anti-software feeling, at least from my personal perspective.

If you are working overtime there is a chance that something has failed, i.e., there could be bad time estimates, too many meetings, not enough personnel, etc. Look, I understand nothing is perfect.  Just like any app you use. It is not perfect. That’s why you see fixes rolled out every time on any app or software. However, constant overtime work is the result of you having really messed something up.

Let me say it in capital letters if you didn’t notice it.

The result of having REALLY MESSED something up.

For example, among many other reasons of things that could go wrong, I will point out a few:

Poor Planning

If you are programmer as an employee and you don’t deal with negotiating contracts and setting up times to deliver, then you absolutely have no control over this. What happens here is that you, as a programmer, are suffering the poor decisions from someone who thought development could be done in a shorter amount of time and didn’t think of unexpected problems.

However, if you are a freelancer or a programmer who directly negotiates those contracts, then it is completely your fault for not having set aside enough time for unexpected problems in case something goes wrong during development.

Code First, Then Think

This problem happens often with junior programmers. Some jump right away to coding to develop this feature “X” to get it done soon. However, what is really happening here is that the programmer didn’t take enough time to think, evaluate, and consider one or two potential solutions for a specific problem, in this case, feature “X”. Then, whenever you are at the moment of opening pull requests or PRs for code review or to let QA team start testing the new feature “X”, someone else finds that you didn’t include a small but significant functionality as part of the feature “X”, causing you to ditch most of your code as it is a major breaking change, forcing you to start from zero.

Ouch! That hurts. However, it is your fault. Next time make sure to think about the possible solutions and discuss with the client, business analyst, QA member, or team leader about potential unexpected scenarios that could happen if developed in a certain way.

Too Many Meetings

Yes, programmers hate meetings. Every minute, second, millisecond you are on a meeting participating passively, or a nice way to say it is: you aren’t doing anything in a meeting, which is killing your productivity. Yes, here and there I could see the value of a meeting. However, whenever there are too many meetings, it simply does not allow enough room for letting your thoughts flow to solve problems and get stuff done. Therefore, the only time available is outside of regular work hours as this is generally when there are not meetings scheduled, and if there is, then there is a bigger problem.

Be Stupid, Not a Professional

Many people confuse being professional with being loyal. Agreeing with every decision your boss has seems to be the best way to show professionalism, even if you don’t agree with your boss. Fresh out of college or junior programmers are often victims of this without realizing it. The reality is that you are not acting professional. Not sharing your concerns or disagreements in a timely manner can be the difference between getting more “resources” or programmers to working on a team, or ditching little styling changes that are costing you a lot of development time, or not including completely feature “X” for the MVP, or minimum viable product. Hence, you end up spending more time developing a feature that could or could not be as necessary as it seemed, which means the difference between putting unnecessary hours of work during the weekend or simply unplugging yourself from work.

Now, if you think making one of these mistakes is bad enough, costing you one weekend of overtime, think about the mixture of at least two of these or any other mistakes you could think of. It gets bad on a regular basis.

This leads to a constant unhealthy dose of overtime leading to other causes such as:

  • Devaluating your income if you do not get compensated for that overtime work.
  • Time away from your family.
  • Sitting in front of your desk and staring at the screen for longer hours leading to health problems.
  • Eating breakfast, lunch, or dinner while working (this is not good even if you think you do not have a problem with this), also leading to health problems.

After all, is there any way to prevent from working overtime as a programmer?

I believe there is. It is hard.

If you are a programmer as an employee, you depend on how much your employer cares. If your employer cares about you and work-life balance, you won’t work overtime. Although you depend on someone else, there is a solution.

If you work for yourself, the solution is the balance between effective development and good planning.

What do you think about this?

Share this blog post in any social media channel with your thoughts about it.