 |
| Image from Pexels.com |
Definition of Overtime
From Wikipedia, "overtime is the amount of time someone works beyond normal working hours". In most first-world countries, laws regulate either how much someone can work outside of typical expectations or the compensation someone receives for working these excess hours.The United States has laws regarding overtime. However, tens-of-millions of working persons are excluded from these laws. (Note: I am one of them, as I'm a computer software engineer, otherwise known as a "professional".)
For me, when I enter overtime, I "burn hot" (my term for extreme focus and cognitive processing, where great work gets done very quickly at the cost of health). Burning hot leaves me drained. I burn hot when in overtime to get out of overtime as fast as possible.
My History of Overtime
My professional career has consisted of only being a person making, editing, testing, and otherwise working with computer software code. Wherever I find myself, overtime creeps in.University
Anyone applying themselves honestly to college and university will have faced mountains of homework. Multiple times. These projects certainly will have altered social and personal habits, including sleeping and eating. When work fills time normally allocated to work and time set aside for acts of living, this is easily defined as overtime.Keep in mind that students do not qualify for overtime. Students pay for this work, the work being highly variable, and a service gets rendered by the school in the form of "teaching", with the student's hope for the delivery of a degree. Think of it as paying a third party to audit your work - that money's gone. It's up to the standards of the third party to determine if the audit passes!
Regardless, my time at university established a harsh work ethic. Life was schooling, schooling was life - there was only one goal, and that was to graduate with the highest marks in the shortest time with the most credential. In a drastic understatement, the years grinding 20 pounds of homework into a 5 pound backpack destroyed what was me. What came afterward was the ability to focus and work and accomplish when others expected it from me.
Then I graduated. Work and leisure were now separate - I now had a 'life'. How to balance these two things university didn't teach me. (Probably doesn't teach anyone, not actively.) This lack of knowledge would have consequences...
 |
| Image from Pexels.com |
Security
Cyber security programming and project development found me after school. There was plenty to do: the company was growing with new products but still relying on legacy code that was the business's bread-and-butter.After 4 years of self-destruction being a model student, my naivety still thought the American Dream lived on. If I did everything correctly (stay clean, get good grades, be charismatic, etc.), reward would come. Once the diploma checkbox was ticked, a person could get a job at 40 hours a week and be paid well. There were supposed to be laws for that.
Reality existed a bit apart from the Dream. There was so much to learn, things university never hinted at. Schedules were being kept tight without a producer (ie product / project manager). Me working remotely added further obstacles.
Not enough time existed in the day. More than the 9-to-5 was required of me. But I'd done 12 to 16 hour days for the last 4 years. But I was getting work done in the 9-to-5. But the American Dream said that if I had done well, I would be awarded. I had done well. And I was ready for my 40 hour week.
Such a mentality didn't last long when the hard times crunched the company. I felt betrayed but was now aware I'd let down implicit expectations. (Note: not explicit expectations, where things like overtime responsibilities would be stated in writing or asked for directly.) Armed with knowledge on how to better navigate the workplace, I took up another role.
 |
| Image from Pexels.com |
Healthcare
I moved to one of the biggest electronic healthcare providers in the country. They were generous with the perks, the pay, and the training. The job was software support with partial development, the promise of more development made plain at hiring.Why not go directly into software development? Visas. Despite the highest coding scores out of the entire hire group of 100-200 persons (including hired developers), I do not have a diploma that says "Computer Science". (My two majors are Math and Game Development, though took / audited all but less than a semester's-worth of the Comp Sci curriculum.) Therefore, strictly development jobs were reserved for folks both in and out of country that had the very specific credentials regardless of experience.
OK. "Things will change", I told myself. There was opportunity to do well in my position.
The first months were very gradual and full of good times. Work-life balance existed. But there was danger when a coworker early on told me to make sure I go home at the end of the day; work would pile on and one of the biggest new-hire mistakes was not to go home.
Whatever. Real work did eventually come. And boy, did it come. After letting down the implicit expectations at the cyber security firm, I didn't want to give up on my friends and coworkers at this healthcare company, so my full effort was given.
Then, I hit a block:
I didn't understand what this proprietary system was doing.
This is one of the few lapses in my life where I could not grok a thing. The entire system, as problems became more complex, became more and more incomprehensible in turn. But there was no way I would fail those that counted on me. So, my solution for this problem?
More hours.
Over months, 50+ hour weeks were the norm. It began to tell. Social and personal life suffered. My peers seemed to have smooth sailing while I floundered. More hours were spent. Stress mounted. I butted heads with my manager and did not have a good time.
An emergency hit. 300,000 healthcare patients were in danger due to a faulty code change made by onsite hospital IT staff. Their records were corrupted, meaning doctors could mix medications and procedures for these patients that might kill them.
Working between the hospital administration, their IT folks, and my manager and peers, I scripted a brand-new solution to not only correct the fundamental problem, but also retrieve the patient record histories, setting them to what they were before the corruption. I had saved 300K people from danger in a day and a night on an already long week.
During the debrief of the incident, I was told I should have handled it better. Something that had been told to me for the last year. For this stress that overtime failed to fix, I quit.
 |
| Logo from Microsoft.com |
Microsoft
The healthcare company taught me to not bend lightly to a request or implication of overtime. It also showed me that I still had the physical and mental endurance to take on overtime, something not seen since school. With this means and discretion, I took on software development for Microsoft. |
| Image from THQ Nordic |
Quantum Break was the primary game I worked on for the company. This was when I got introduced to the role of "Tools Developer". The role in software development involves helping other people do their jobs and ensure a given project or company reaches its max potential. It's my favorite kind of software development, no contest. (I digress.)
Microsoft was good to me but for one nagging issue that taints my memory. The problem came in the form of a UK-based, no-longer-works-here developer setup of a proprietary network system for auditing test coverage of games. And it wasn't a problem for the longest time!
Why? Because when the system was handed over to my care and maintenance, we weren't using it. Not knowing fully what I was doing, the system was transferred and I got some responses back on the network, though these were empty. With other projects calling my name and no-one using it anyway, I called it good. The system would send correct responses once people were using it, or I could Google further solutions when the network was needed. I shrugged my shoulders without either fully comprehending the product's operation. We were good.
Except we weren't. Months after the hand-off, the primary office in Seattle sought late-in-development test coverage. I, in the middle of implementing Xbox Achievements, booted up the system. Testers played. Nothing was returned. Seattle called again...
Time was spent off the books to get the network ready, but for naught. It was broken, and I couldn't do anything now that the original engineer had left, taking setup parameters with them. The office had to use my other tools for the QA team to maximize the coverage that they could without analytical proof of it. Seattle luckily took it, and Quantum Break launched to positive reviews.
The moral? I knew of a potential problem and chose to ignore it. Embarrassment for myself and others ensued, with me investing time to only come to failure. Not again would I shove-off problems due to ignorance.
 |
| Image from Pexels.com |
Recent History
Let me preface that I adore my workplace since June 2016. As a Software Tools Engineer at this company, I have gotten to accomplish many things. (Checkout my LinkedIn.) Out of all of my employment here, I've chosen to commit only two instances of overtime. (I'll not count the 2 months spent assisting another organization within the enterprise of the company I work for - that might be another blog post.)The first time I had to clock in later than normal was due to miscommunication. A new piece of hardware needed to be implemented in both our middleware code and in tools. This was also the first time this kind of hardware was under my ownership. After a careful review, I deemed it would take a working week (40 hours of pure effort only spent on this implementation, no distractions, emails, or other responsibilities, not including learning the system). So, assuming 60% of a day can be spent on a single, non-maintenance task, I understood this implementation would be 2 weeks, leaving a few days for learning the section of software that needed updating. That's not how it was interpreted.
Instead, 5 calendar days were allotted, including weekend, for me to deliver a new product with functionality I'd yet to become acquainted with. 4 10+ hour days later, the hardware was supported (and the system improved!). Heck, I even wrote a manual for future engineers (myself included)!
This initial overtime taught me to be very explicit with expectations. It also helped show how I could "put myself away" - ignore the "life" outside of work and make the effort my only concern and goal.
Speed-up to a year later. I am moved to a new team short-notice for a from-scratch product that needs additional help to make deadlines. Three weeks pass of hard work on everyone's part, but due to our effort, we succeed. Hitting the goal was tighter than it should have been. I attribute this close cut to forgetting the Agile development principle of having a testable product as soon as possible. Only in the last three days before deadline did I have code to test, and that won't happen again.
 |
| Image from Pexels.com |
Thoughts on Overtime
I have worked uncompensated overtime due to the failings of others and faults of my own. Realistically, overtime is an almost sure guarantee for me in the future.Must overtime be required of software developers? Absolutely not. Is it sometimes necessary? Yes. Surprises come, but responsible living seeks out these potential circumstances that invite overtime while minimizing the risk and impact extra work would bring. To grow as a person, limits must be pushed - when this is chosen, it's good stress like exercise; when it's forced, it's bad stress (think of being chased by a hungry bear). Whatever happens, overtime cannot be repeated for the same causes as previous overtimes, nor may it occur without consequence.
Should I find myself in overtime, it will be committed to, though only if it there is an observable end to it and such was unplanned. Afterwards, appreciation of the extra effort comes from both rewards and change. At the bare minimum, immediate systematic repair to shore-up what caused the overtime must be taken. I suggest a few repercussions from experience:
- Review the work velocity (amount of time a person typically takes to complete work in a given time-frame) of all persons.
- Make smaller bundles of work for scheduling (larger 'chunks' of work means greater uncertainty).
- Reaffirm that overtime is not the policy of the company or group and that overtime is an embarrassment at the highest level.
- Evaluate the abilities of the schedule maker - they either must detail their objectives to improve, need more training dictated to them, be removed from their position, be fired, or all of the above. (Anything less is valuing incompetence at best, malicious intent at worst.)
- Admit what went wrong and ensure what happened won't happen again. Buy-in from the person in the highest position able to authorize overtime can make this work.
What are your experiences as an employee? An employer? I hope my perspective is a help to you as I know yours is a help to me!
No comments:
Post a Comment