How much overtime are you willing to work? How much compensation should there be? Does this depend on the type of work? These are all good questions. Before doing a code review it is a good idea to have a set of agreed on coding standards. Similarly, it is important to think about the answers to these questions ahead of time, before you are pressured (either by yourself or externally) to work overtime. Make sure you have an established set of values so that you can confidently make future decisions that are consistent with your goals and limits.
Before getting to the various situations regarding my personal overtime policy, I will state just some of the pros and cons of working overtime.
There are some definite pros to working overtime. A hard day’s work builds a sense of accomplishment. If after an 8-hour day of nothing but meetings, phone calls, and other interruptions you fell as if you got nothing accomplished, a couple hours of uninterrupted coding after everyone has gone home can make it feel like you salvaged your day. If you had a productive day and were “in the zone”, you may want to ride that wave a little longer. That sense of accomplishment can give you a boost of energy, like how joggers claim to feel invigorated from jogging.
That is just some of the pros from working overtime for yourself. There is a good chance that others will notice your hard work too. It can be a definite ego boost to have others appreciate you for your hard work. This can lead to salary jumps as well. It is true that the harder you work at your career the more benefits you will probably get from it.
There are some definite cons to working overtime. For starters, it leads to exhaustion and fatigue. There is a maximum number of hours that can be worked by a software developer and maintain a high level of focus. An 80-hour workweek will not yield double the productivity as a 40-hour workweek. The fatigue will result in distractions, which drop productivity.
Working overtime is done because you are putting pressure on yourself to get something done. That pressure causes stress. A little bit of stress can be a good thing, like a little adrenaline boost. Too much stress is a bad thing. It can lead to stress eating, increased alcohol consumption, and larger mental health issues.
Increasing overtime affects family life, aka “work/life balance”. The more time working the less time there is for the spouse, children, and friends. When I am working a lot of overtime there is certainly less time sitting around the table eating a home cooked meal and more fast food so that I can quickly get back to work.
Some of the work I do out of office is keeping up to date on the latest technologies. That is an important job of any software professional. If I am working a lot of overtime just to get customer projects done, then there is less available time for me to stay current.
There is potential when working a lot of overtime to create developer silos. A developer can work for months on a project outside normal work hours without interaction with the rest of the team. Is there the normal guidance from a design committee, are there code reviews, and are system integration and customer acceptance tests being included? If I am working a lot of overtime on a customer project that is required to meet the same “definition of done” as all my other projects then this will create pressure on other teammates to work extra overtime as well in order to support me.
It should be the policy of any sustainable company that working overtime should not be plan “A”. There are some exceptions for seasonal companies. For example, game developers often have an annual deadline to release for Christmas/Black Friday sales, accountants work long hours during tax season, and farmers work hard during harvest. Owners can communicate that they will not approve vacations and overtime is not optional during that busy month. After that month of overtime surge there will be a recovery break. Overtime is not being required every single month of the year.
In sustainable companies, there should not be a plan to demand overtime at the start of a project or sprint. If you get 75% through a sprint or project it and realize that the team will not meet the deadline then it is decision time. Either the project manager will extend the deadline or work items be deferred to the next sprint, or overtime will be approved to get the project or sprint done on time. However, that is a red flag that the team is not good at estimating, project planning, or some other shortcoming. The team must work to fix whatever the shortcomings are. If not addressed, the likely outcome is that all projects or sprints will demand overtime.
If a company has difficultly in getting out of the habit of demanding employees routinely work overtime then a policy of paying time-and-a-half can give the company the nudge it needs to break this habit.
There must be an allowance to expect the unexpected. Getting 75% through a project and realizing that there is more work than expected is common. Because plan “A” did not include overtime, adding overtime is still an open option. If plan “A” was to work overtime then when unexpected things happen the only recourse is to add even more overtime or let the deadline lapse. Good planning is to leave as many options open as possible. To have plan “A” being to work overtime reduces the number of options available in the future.
Employees should always have the option to refuse overtime. Companies are not always (nor should be) privy to personal details of employee’s lives that may restrict their ability to work overtime. Refusal must be a real option. An employer may ask employees to work overtime, but employees need a safe place to refuse. An employer cannot claim that they give the option to refuse overtime, but if any employee does refuse overtime then there will be consequences. For refusing overtime, employers should not blacklist employees as “not a team player” which will influence bonuses or salary.
So with the preamble out of the way, let me finally get to my person overtime policy.
These are my own personal values guiding my own overtime policy. I think it is important that I write them down so that I can refer to them later. These policies apply only to me. I recognize that every software professional will have his or her own policies. I will respect everyone’s opinion and will not demand others work more or less that me, even if they choose to work no overtime at all.
There are numerous situations that I will work overtime free. I consider this part of my salary and just coming with the territory of being a professional software developer.
Whatever overtime I choose to work, I will ensure that I am well rested. I try not to work so much overtime on personal projects that it interferes with the productivity in my day job. I will cycle on the amount of overtime I work. I may work a month where I put in a lot of overtime, but them I follow that where I try to limit myself to just 9 to 5.
I do spend an enormous amount of “think time”. I brainstorm ideas. I think up different ways to approach coding problems or present arguments to other people. I have no idea how much time I spend on this (which is why I could not charge for this even if I wanted to), but it is a lot.
Sometimes I will work overtime just for my own personal integrity of hitting a deadline that I have committed to. For example, someone asking me a brief question about his or her project can distract me. After they leave, my mind may still be racing with the details of their project. It is my fault alone that I cannot focus on my assigned task. I may end up working extra overtime to make sure I complete my task on time.
I do think that all professional software developers do need to some of their own time to learn new technologies. It can be a full time job just staying current. I am not expecting to be an expert on every latest trend. However, I do expect all developers to read up on new technologies and go through a few throwaway example programs. I would not expect a company to cover 100% of the cost of training its employees on new technology; it is just easier to hire new college kids that already have this training.
Learning new technologies is the only point where I do expect that all developers will spend at least some time on their own. I think it fair to companies to expect this as well. However, this does not have to be a daily demand. It is fine to take a few months off (or more) in order to maintain a good work/life balance and pick this up at a time when it is more appropriate. If companies do demand this then they cannot be assigning too much other (e.g. customer project) overtime work. Companies must give employees enough free time to meet their learning obligations.
Learning technologies is one thing, but the eventual goal of that is to on-ramp that new technology into your day-to-day work. I know that new technology will make me more productive. However, the switchover time and training of my colleagues can make the new tech seem somewhat dubious. If I can work a little extra to get documentation done or create little helper functions or snippets to make the on ramping seamless, I think this is time well spent. I find it hard to ask my company to invest in this time on unproven technologies.
In the same vein, “talk is cheap, show me the code”. Sometimes I have difficulty getting people to believe in a new technology or strategy. A good way to counter this is write a quick, throwaway proof-of-concept application.
Those are some of the conditions that I am willing to work free overtime. Of course, I am not above taking money for that. If someone wants to pay me to go to conference to learn new technologies or split the costs of on ramping, then I am cool with that. Offering a small bonus to learn new skills is welcome, even if that bonus works out to well below the legal minimum hourly wage.
I do not think it is fair to work on customer projects at reduced pay. Learning new technologies benefits my employer and me, whereas meeting a customer’s project deadline mostly only helps my employer.