Topics

Featured in Development

Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner. A system is understandable if it meets the following criteria: complete, concise, clear, and organized.

Featured in Architecture & Design

Sonali Sharma and Shriya Arora describe how Netflix solved a complex join of two high-volume event streams using Flink. They also talk about managing out of order events and processing late arriving data, exploring keyed state for maintaining large state, fault tolerance of a stateful application, strategies for failure recovery, data validation batch vs streaming, and more.

Featured in Culture & Methods

Tim Cochran presents research gathered from ThoughtWorks' varied clients and projects, and shows some of the metrics their teams have identified as guides to creating the platform and the culture for high performing teams.

Getting More Work Done in Fewer Working Hours

When Jason Lengstorf’s body was actively falling apart because of the way he was working, he decided to limit his computer usage to 40 hours per week work in 90-minute blocks to create pockets of high-focus, time-boxed effort. Working fewer hour prevents you from becoming overtired or not focused. We need to treat downtime with the same level of care as we treat our uptime, using breaks to make creative connections, recharge, and to remember why we work.

Jason Lengstorf, developer at Gatsby, spoke about how he gets more work done after cutting his working hours in half at Craft Conference 2018. InfoQ is covering this event with interviews.

InfoQ spoke with Lengstorf after his talk and asked him what made him decide to reduce working hours and how he did that, and how to increase productivity in fewer working hours.

InfoQ: What made you decide that you needed to reduce your working hours?

Jason Lengstorf: I was running an agency and putting in a ton of hours — 70–90 each week — and it was starting to take its toll on every other aspect of my life: my health, my relationships, my happiness — everything was getting worse. Then, after a particularly stressful project, my beard started falling out.

This was a wake-up call. My body was actively falling apart because of the way I was working. Something needed to change.

Willis: Christina Maslach (...) is one of the leading researchers on occupational burnout. In her original research she codified the three aforementioned areas as burnout indicators (Exhaustion, Cynicism and Efficacy). Exhaustion is typically more obvious than Cynicism and Efficacy. Indications of clinical related burnout/cynicism typically look more like withdrawal (for example, I just want to do my job so please leave me alone). Efficacy is a little harder to identify. Efficacy typically is related to self worth or a perception of an organization not recognizing an employees worth.

InfoQ: How big is the problem of burnout in the software industry?

Lengstorf: I’ve seen a trend toward cultures that encourage burnout through a bunch of seemingly positive habits. For example, someone who works through a weekend to meet a deadline might get praised as a team player or a hero. Missing sleep is seen as dedication. Prioritizing work over all else is seen as a good thing.

All of these help to hit short-term goals, but in the long-term they lead to burnout. And while burnout takes a huge toll on employees, it’s also really terrible for employers: the cost of turnover is extremely high, and the risk of losing someone who worked hard enough to burn out — which means they likely held a lot of institutional knowledge — can be devastating, up to and including the loss of entire systems because no one else knows how to work on them.

The problem of burnout isn’t because companies are evil and trying to extract as much as they can out of employees. (At least not usually.) The problem is really that we work in an industry that’s often assigning us work that was our hobby before it was our job. That makes it really easy to push too hard, and if no one is actively working to counterbalance that drive, we tend to burn ourselves and our teams out entirely by accident.

InfoQ: You decided to put restrictions on your business life. Which were they, and how did they work out?

Lengstorf: I installed software called RescueTime and make a concentrated effort not to spend more than 40 hours in a given week using the computer. This includes my Netflix, social media, and other non-working activities.

I also work in 90-minute blocks using a timer to create pockets of high-focus, time-boxed effort, which helps me do complicated, meaningful work, but without being unavailable or frying my brain from overexertion.

As a result, I’m more productive than I’ve ever been before. In both 2016 and 2017 I averaged fewer than 40 hours each week of total computer time, while accomplishing more on average than I ever did when I was working 70+ hours.

InfoQ: What are the drawbacks of working long hours? Why is working fewer hours more effective?

Lengstorf: There were studies done back in the Industrial Revolution that proved people are most efficient at 40 hours a week. Beyond that, exhaustion and a lack of urgency start to creep in, causing more errors, which ultimately means that more time is spent fixing errors. After a pretty short window of time, the extra hours worked are completely canceled out by the error correction — in fact, productivity often decreases due to time lost to additional error correction.

In knowledge work, being mentally engaged is the most important part of our job. If we’re overtired or not focused, we aren’t putting 100% of our mental effort into the work, and that means we’re creating lower quality output.

By limiting our working hours, we have plenty of time to recharge. That means we’re putting in our best effort during working hours, creating fewer errors, and generally generating a high-quality product.

When I was working at IBM, my team focused on avoiding overtime. We emphasized healthy working schedules and taking real vacations. Despite being one of the teams working the fewest overall hours, we were one of the highest performing teams in our business unit. I can’t prove that this was because of our style of working, but I’m convinced it played a major role in our success.

InfoQ: What do you suggest to software developers who want to increase their productivity?

Lengstorf: Start treating downtime with the same level of care we treat our uptime.

We need breaks to make creative connections, to recharge, and to remember why we work. Even the most enjoyable things will do damage if we don’t get the right balance in place: I love ice cream, but if all I do is eat ice cream I will both get sick of ice cream and make myself sick.

We should treat work the same way: each of us has a safe range where we can work. If we work below that range, we feel restless and bored; if we work above that range, we burn out and resent our jobs. By striking the right balance, we’re able to not only create a lot of success for ourselves in a sustainable way, but we’re able to actually take time to enjoy that success.

And if we’re not able to enjoy our success, what’s the point, anyways?