It is understandable that one might view any post advocating working less as an attempted justification for laziness. Within 'software' however I personally feel that it is imperative that one takes a step back and looks at their time investments more pragmatically.
This is a viewpoint shared by Itamar Turner-Trauring, who shares his viewpoint extremely succinctly over at Code Without Rules.
Uniregistry
Rolling back the clock, I was thinking back to my time at Uniregistry and trying to put a finger on exactly what made me leave. The answer was obvious. I was overworked, and it was my own fault.
When I was initially offered the job, it was on a trial basis. Given that I wanted the job, I worked extremely hard to show off my skill set and prove that I was up to the task. It turns out that I was. I got the job, and during my time with the company I was rewarded appropriately.
The problem was that by working 12 hour days, and by working weekends I was joining an inappropriate culture of excessively hard work. Not because hard work is bad, but rather because long hours are mentally and physically exhausting whilst not necessarily being particularly productive.
Yes, the euphoria of resolving an issue that you have been struggling with for hours is fantastic. On the flip side, the stress associated with being unable to resolve such an issue is unbearable. Independent of euphoria, or stress this approach is still inefficient. It is almost always the case that these incredibly tough problems are extremely simple and would be resolved in a matter of minutes after a good nights rest.
Frank Schilling (the CEO of Uniregistry) is an extremely intelligent, and targeted man. He has fantastic ideas, has built a fantastic team, and has created amazing products. I remember heated discussions pertaining to timelines and execution whereby he would be unhappy with how long we had proposed a particular piece of functionality would take to produce. To try and be as appeasing as possible we would provide realistic timelines premised on working long hours. In hindsight this is why I ended up burnt out, generally fatigued, and in the end left my position.
This case was particularly interesting because it was more psychological than anything. For me personally, I never wanted to be the first to leave the office. I didn't want to be perceived by my co-workers as being lazy when in fact leaving 'early' may have simply been realistic. I suspect that my coworkers may have felt similarly.
This certainly isn't a unique situation. I am aware of a number of people working for companies where similar working cultures develop. It is ridiculous - it is tantamount to self harm.
Double Negative
Fast forward to today. I am my own boss, so I can dictate my own working hours. This (unsurprisingly) means that I am able to justify taking time off as needed, and develop working habits that are appropriate to optimal performance.
Having built three significant multi platform products, and numerous other smaller projects it is certainly fair to say that I have been productive. I am however still prone to being generally over optimistic, and to overworking.
Software and programming requires mental capacity. It requires intelligence, and concentration. As such whilst there are some jobs whereby one can work on autopilot for ridiculous amounts of time, I do not believe that software is one of them. Itamar states that in his current position he has negotiated a 35 hour working week. I can absolutely see an argument for working even less than this.
When programming there are two things that have become patently apparent to me. Firstly my efficiency and productivity are obviously improved before lunch. Secondly, at the end of the day I have significantly more occurrences of the infamous 'why on earth won't this insert simple thing work !'.
As stated by Dan Abramov:
"If you’re debugging a problem late in the evening, drop it and sleep on it. Sleep deprivation makes it far too easy to miss typos and other simple mistakes."
I would extend this. As well as sleep deprivation causing you to miss typos, having been staring at a screen for the 10 previous hours has the same effect. As it happens, Itamar has dedicated a whole post to this: Go Home Already.
Going forward, it is clear to me that I need to get my programming done in the mornings, and be prepared to take breaks/leave it until the morning. It is a simple case of learning from experience.
Were I to still work for Uniregistry (or any other software company for that matter), I would be intrigued as to how the conversation would go down were I to propose only working mornings. On the face of things it looks like pure laziness, but taking a step back it is simply honest, and pragmatic.
As a company owner myself (now), I would certainly prefer for my employees to be realistic and up front with me. I am 100% certain that as long as you have good employees who you can trust to manage themselves appropriately then productivity will increase.
At the end of the day it comes down to two words: Realistic expectations.
What others say..
Having written this post, I wanted to investigate further what others have to say on this topic/'idea'. It turns out.. quite a lot.
This post from back in 2012 outlines the history of the 40 hour work week.
One quotation which resonated with me was the following:
"That output does not rise or fall in direct proportion to the number of hours worked is a lesson that seemingly has to be relearned each generation."
To me, it is not so much that each generation needs to 'relearn' this. As in my case, I am well aware of my reduced performance but for idealogical reasons choose to overwork. We need to listen to our bodies.
The previously mentioned post as well as this article from the Guardian pertain to working in general, not just the software industry. The latter refers to doctors who I agree should absolutely not be overworking - they are potentially responsible for peoples lives !
Whilst not (normally) effecting human life, the software that we build is oftentimes widely used and wide reaching. There are software tools used by millions of users daily/hourly which are responsible for extremely important systems, and account for millions of dollars of economic output.
It turns out that the 'literature' on the topic matches up with my own thought processes, whilst also referencing research which proves my sentiments.
The wise boss would let his workers manage themselves (within reason) to optimise output and efficiency.
I hope my boss does.