I worry a lot when I’m in Disneyland.
I worry about heat exhaustion. About getting sunburned. About whether I should be supporting a megacorporation that owns way, way too much of our culture.
But mostly, I worry about the pee.
For 2017 (when last I went), there were on average ~56,000 people in the park on a given day (20.45 million annually). Humans pee on average 6 to 10 times daily, for a volume of 400mL to 600mL.
This means that there are anywhere between 134,000 liters (36,000 gallons) and 336,000 liters (89,000 gallons) of pure urine that have to flow through the pipes beneath Disneyland. Mind you, this is just the urine, not the water or anything else that is flushed down the pipes along with. This doesn’t account for having enough stalls or urinals which serve as the input for the pipes. This doesn’t account for how well hydrated people are, or how you get the water to people so that they can drink enough to pee in the first place. This is simply how much pee that Disneyland has to handle. On average. Every day.
I worry about the river of pee flowing in the sewer beneath us. I worry about what happens if that river ever stops flowing. Or if the pee doesn’t make it to the river below.
I worry that with 56,000 people, all of which pee at least 6 to 10 times a day, that means that there are between 336,000 and 560,000 opportunities for someone to not quite make it. If 1 in 1000 attempts to pee don’t succeed, that means that between 336 and 556 attempts fail. That puts us somewhere between 35 and 88 gallons of pee that didn’t make it where it needed to go.
Considering a large portion of the attendees of Disneyland are young children, I worry that 1 in 1000 failed attempts to pee is conservative.
I stand in the middle of those seas of people, milling about, planning their days around lines, and fast passes, and park hopping, lunch. Bathroom breaks and bathroom proximity are a distant priority in their planning. They greedily drink from their bottled waters, their water bottles, the tubes coming out of their backpacks I hope have been cleaned thoroughly after every use. Condensation slowly builds and drips down the sides of those chilled containers. The drops evaporate the second they hit the blacktop. But the bladders… the bladders slowly fill.
I know that Disney and their army of engineers, architects, and designers have taken this into account. Long before the millionth park guest had passed the turnstiles, they would have had to solve the pee problem. Accounting for basic human needs like food, shelter, and potty breaks would have to at the core of any park design. It’s the same problem that has to be solved over and over again by designers of public transport, public spaces, public services, or anything that has to handle (literally) tons of humans.
The problem is this: humans, individually, are intelligent, widely-adaptable, and largely self-sufficient tool-using mammals, able to manage their own urine. But humans, in volume, scaled up to the tens of thousands or more, cause huge goddamned problems. Problems like pollution. Like extinction. Like global, irreversable climate change. Or having gallons of pee distributed randomly around Disneyland on a daily basis.
Okay. Cool. At this point, I ‘m ready to stop talking about pee. I’m ready to move on. I didn’t start out wanting to talk about pee. Maybe it’s not the best example. But pee is what I have, an activity that we all have to do, and isn’t usually a problem, but can become a problem if you, your parameters around the activity, or the environment for the activity, change significantly. That is the analog for what I wanted to talk about.
What I want to talk about is writing fatigue.
Writing fatigue happens slowly. It doesn’t happen the first time you sit down to write. Or the second time. Or the tenth time. It happens slowly. Slowly accumulating. Slowly filling.
For me, Josh, at time of writing, I fatigued at the 836,487th word I added/subtracted from Skysail.
Of course, it’s not that word, exactly. Words 836,486 and 836,487 were pretty mundane. Instead, it’s much like the slowly accumulating gallons I mentioned before. It’s the 1 word in 1000 that was particularly hard fought. The difficulty around which you weren’t expecting, and that you weren’t ready for. It’s the 1 change in 1000 that took more time and energy than the rest of the 999 changes.
I’ve hit ‘Commit’ to submit my changes at least 13,188 times over the course of Skysail. I know that there have been a lot of hard fought edits. If we’re going with 1 in 1000, that means there were somewhere around 13 that were worse than the rest of the 13,175.
I know that there were more than 13 troublesome edits. The probability of 1 in 1000 may be conservative estimate.
Writing fatigue happens slowly. But it does happen.
Fatigue happens for computer programmers. I know this, because I am a computer programmer, and I’ve experienced it. When it happens to us, we call it ‘burnout.’ It sounds way more dramatic, but I think it’s referring to a similar place on the same spectrum.
As programmers, we may have started with a company, or on a new project. The programmer mind devours new information and ideas, the greedy pseudopodia of learning and exploration reaching in every direction. Every nail can be hammered, and with all of the amazing creative energy radiating from us, rest assured that every nail will be hammered.
That’s what it feels like the first few times. The first few times, it’s great. The next few times, it’s also great. It’s one of the best feelings in the world. It’s why we become programmers. It’s why we keep coming back.
But the feeling doesn’t come back as strong. And eventually, the juice runs out.
Speaking from experience, your 1 time in 1000 is usually the first time you show your stuff to the end user. Somebody takes one look at your beautifully, lovingly, exhaustively crafted tool, and they cringe. They see a mistake. One that somebody should have seen a long time ago. That someone who truly understood the nature of the problem at hand would never have overlooked.
Your pride is hurt a little, but otherwise, it’s not a hard fix. You weren’t able to solve everything up front, but your design was such that modifications like these should be pretty easy. And they are. You make the fix. Probably within the span of few minutes. You send off that apologetic but triumphant email. Your response time is amazing. Your job satisfaction is through the roof. The universe is knowable and you have forged something beautiful from silica and sweat and your very special mind powers.
Then it’s six years later.
You’re in the same meeting. With the same people. You’re looking at a screen, much the same as it was in the beginning, but now it’s worse. They’ve done things to it. They’ve made you do those things. What was once elegant and streamlined is now artless and knobby. Things stick out, protrude. Nothing flows right anymore. The users tell you they don’t understand the reason why the thing they are asking for is such an issue. It’s not that complicated, they say. It used to do this just fine, they claim. We’ve got iPhones and it’s 2018, why is it so complicated?
Burnout doesn’t happen the first time you’re looking at this screen. It doesn’t happen on the tenth. It’s the hundredth, the thousandth time you fight with the teleconference software, just so you can talk with people that aren’t being paid enough to want to talk to you, about something you’ve long since stopped caring about, and could have been over and done with but for the whining and the paperwork. It’s hearing that tinny, downsampled hold music streaming from your speakerphone as you wait. It’s wondering whether what you’re doing is important, if it helps people, or if you’re just part of a massive machine that is building itself on the backs of poor people in a far off place.
The hold music drones on for the thousandth time.
(Quick pause. For those reading, and in particular, Mike: I’m not talking in metaphor, I am talking about actual people at my work, and not our writing partnership and process. Yes, I know it’s a very specific, very conspicuous “six year later,” but I assure you, it’s a coincidence. Love ya, buddy.)
It’s awful to reach burnout. It’s awful to have that taste of existential dread come back every time you sit down to do that thing you love. In my experience, it is quickly followed by your standard-issue impostor syndrome. And then, right after that, you’re staring at that spreadsheet you built the last time around that calculates just how long you could survive on savings alone if you quit everything and just ate yogurt.
Burnout, when you get there, is hard to come back from. It’s hard, because just the act of sitting back down has the chance of reinforcing whatever is burning you out. Without a significant change in the environment, or what you’re working on, you’re much more likely to just spiral deeper into that negative feedback loop.
Programmer burnout has pretty awful consequences not only for the programmer, but also for the people they work for. Software sits at the center of nearly every industry. Technology is a necessity for every organization, and its effective implementation is the expectation of its customers. And with the trend toward automation and data analytics in order for companies to remain competitive, programmers tend to be at the center of every problem, new and old.
Being fairly useful cogs, it’s in the best interest of those with codemonkeys in their employ to avoid burnout. And because of that, the problem tends to be of interest, and somewhat addressed, if not researched.
If you Google “programmer burnout”, there are any number of helpful articles. They all enumerate similar advice:
- Be willing to take a break
- Actually take a break when you need to.
- Make choices to prioritize health and wellness.
I think all of that is solid advice. As someone working the U.S. in 2018, these are the things that we are asked to let slide, and even worse, we are applauded when we do. I wish I had internalized more advice like this when I was younger and was starting to experience burnout. I definitely would have taken more sick days, and never would have let my yearly alotted leave time expire without taking it.
There’s a hitch, though. Burnout, as it seems to be implied in burnout articles, comes from overwork. But I’ve never worked a 60+ hour week in my career. The times I’ve had to come in on the weekend are few and far between, and have usually been matched with overtime pay or being able to take off time to make up for it. And as much as I joke about the things I’ve written for work running flawlessly after I’ve gone, nobody’s made me feel expendable or replaceable. The times I’ve left, people have wished me well, and wished I’d stayed.
I’ve honestly been pretty comfortable. So what caused the kind of fatigue that made me want to leave?
I think it’s a lot of little things, but at scale.
I could write about this at length. In fact, in the first drafts of this article, I did. But it got out of control. It’s a problem I have, getting into the weeds. I live in those weeds. I come from the weeds. I bring the weeds with me wherever I go.
Anyway, the nice thing about having already written a lengthy diatribe is that I can boil it down. After so many years in the industry, I can summarize what happens in the IT industry at scale, after long enough, after being on enough projects, after enough time spent listening to hold music on a speakerphone:
- IT leave policies, benevolent as they may seem, don’t really provide a work life balance, but instead incentivize IT workers (at scale) to take less time off, and in smaller increments so as not to impact the sleepless, unblinking systems they support.
- Programmers who manage many systems, many projects, and many users (at scale) are interrupted constantly. These interruptions, whether from phone calls, emails, meetings, etc., subdivide a workday to a point where it feels like no time slot is large enough to accomplish certain tasks. And so, smaller, less important tasks can be completed, but larger, more important tasks are deferred. Priority is placed on important tasks, but the ability to accomplish them is outside of the control of the programmer. Agency diminishes, and deadlines pass by.
- Programmers are asked to be the glue between the human and the inhuman. We are at once supposed to be motivated and impassioned about the craft, creating well-tested, well-performing, well-designed applications that people use to save time and actually enjoy using. But we are also asked to be distant and impassive toward the things we create, coding fast, and failing faster, with the hopes of being as efficient as possible. This strain is continual, and builds over time as the things we create go misused, misunderstood, or unused.
Programmers want to feel like their work is important, and accomplishable, but also not have that work and the time required slowly erode what happens outside of work. And, I think, that pretty much applies to everyone who ever had a job, ever. Which means that these issues have an analog for writing careers as well.
After years working on Skysail, making every goddamn rookie mistake one can make while writing, I feel like I can summarize the problems that come up after a long time, in short quantities, but inevitably fill that bladder.
See here:
- Writers can suffer from the same diminishing leave time that other careers do, even if working as a full-time writer. Deadlines, along with sleepless, unblinking readers demand more time from writers, and less time to have a break. This is even worse if a writer has to support themselves with one or more jobs.
- The time it takes to finish a draft, to finish a chapter, or to finish a paragraph, can easily exceed the time slots available in which to work on them. Smaller, less important work can be done, but the larger, more important tasks loom in the distance, impossible and daunting.
- Writers are asked to be the conduits between the worlds and characters they create and any one of the other billion or so humans that might read their work. They are asked to pour their heart and soul into something, making it well-structured, well-written, well-thought-out, well-researched, new, subversive, and poignant, but then are asked to drop their work and go back to the drawing board if agents / publishers / sorting algorithms / readers don’t appreciate their work.
I don’t think I’m saying anything new here by comparing the effects of stress and limited leave time on people. Spoilers: it doesn’t turn out well. First, they fatigue, then they burn out.
What I’m trying to get at is that the perception of this process between engineering and artistic pursuits is pretty wildly different. With engineering, and specifically in my experience with programming, burnout is something awful and dramatic and harmful to the programmer, leaving them a shadowy husk of their former self. As much as their employers may suffer from the malfunction of an important team member, corporate culture still affords applause to the dedication and endurance of those who sacrifice and suffer.
In my experience, the perception of writer’s fatigue and writer’s block is that it’s just writer’s block. There is sacrifice in time and effort, but there is no applause. After all, it’s not the end of the world if you can’t write. There are few consequences outside of that of the well-being of the writer. You can’t bring yourself to sit down and crank out a few words, so what? It’s just art. Anyone can make art. Someone else will make more of it.
This is the perspective I found I had internalized at some time in the distant past. It’s one that I feel is fairly common. That in the grand scheme of things, my art is a frivilous pursuit, of little value, and that art and the artists are expendable. That the chances of success are too low, and that you’ll never be able to make anything better than what is already abundant and immediately accessible.
I don’t have a lot of answers toward this. I hope that if you’re dealing with this sort of philosophy, that you remember that anyone who ever made anything great made a lot really awful stuff first. And the only way they could make something great was by getting the awful stuff out of the way. But that’s a hard sell when you’re tired of making (what you feel is) awful stuff. It’s hard to argue against when you’ve reached burnout.
My hope is that you never reach fatigue or burnout. I hope that you finish your project long before you have to learn how to come back to it. I hope that you take the following advice.
- Don’t always do one type of thing.
The fast-track to writing fatigue, I feel, is to do the same task over and over. This is especially true if that task is of the same “type”, which is to say a task that involves the same skills or actions. The longer you repeat tasks of the same type, the more fatigued you become of tasks of that type.For instance: doing edits is awful. Doing edits for two years is very, very awful. You’re just scanning words, over and over, knowing that for each 100 problems you fix, you’ll introduce at least 1 new problem.You don’t get to explore, to create, to outline, to make an eBook, to code up new features of Giterary, to make maps, do characters sketches, or anything like that. You don’t get to have fun. You just… edit.
There is no shortage of work that goes into writing. And that work tends to include things that are vastly different from writing and editing by itself.
I recommend trying to maintain a ratio. I recommend you experiment to find what the appropriate ratio is. 2 hours writing, 1 hour editing? 1 hour writing, 2 hours managing your social media presence? 6 hours spent coding up a feature in Giterary that only saves about 15 minutes in the long run? I don’t know.
But if something feels awful, don’t keep doing it. Find a way to stay productive, just in a different direction.
- Map Your Time.At some point, you’re going to feel like there simply aren’t enough hours in the day. This may be true for a given, day, but consider the following:
M[________EEMM __] T[________EEMM __] W[________EEMM __] H[________EEMM __] F[________EEMM __] S[________EEMM __] S[________EEMM __]This schedule says, “After 10 hours of sleep a day (
_), exercise for two hours (E), eat and/or do meal prep for two hours (M), then do whatever you want for the rest of the day.This was the “baseline” schedule my girlfriend and I came up with for a given week if we had a) no work, b) an awesome exercise routine, and c) an emphasis on doing a good job preparing food (rather than just eating snack food all day). This schedule will never happen, of course, but I wanted to build it so that we could do the math. This schedule yields: 168 possible hours of which 70 sleep are hours, and 70 free hours. That is, with a very generous sleep schedule, and reasonable exercise, you can still have 70 hours in a week to do with as you please.
The following was a schedule I drew up this last June:
M[_______?$$$$W$$$$CCMW __] T[_______?$$$$W$$$$MMMEW__] W[_______?$$$$W$$$$MGGGG__] H[_______?$$$$W$$$$M CC__] F[_______?$$$$W$$$$M __] S[______EEEEEM M SSS_] S[_______?M M M __]That is, of the 168 available hours in the week:
- I slept 61 sleep hours. (
_) - Worked my normal 40 hours for my job. (
$) - Wrote for 7 hours during lunches and evenings. (
W) - Played 4 hours of D&D. (
G) - Exercised for 8 hours. (
E) - Did social activities for 3 hours. (
S)
Your mileage will, of course, vary, with your job situation, your not-job situation, and how often you can sit down to write.
The point in coming up with a schedule like this isn’t to fill every waking hour. The point, for us at least, was to demonstrate that it’s possible to balance things like work, writing, and exercise. Much like creating a budget for money, you can create a budget for time. Then, at a glance, you can see what needs to be done to maintain good sleep, exercise, and eating habits that support the other time slots in your life.
Without a schedule, without mapping it out, all assumptions as to how you want to spend your time and how you actually spend your time are invalid.
- I slept 61 sleep hours. (
-
Keep Reading Other Stuff.
Honestly, I don’t know how it happened, but I’ve all but stopped reading. By “stopped,” I mean that I’m down to about a book a month, but by comparison, that’s down quite a bit.
I feel like I used to read quite a bit. At least two dozen books a year, which, for someone who likes to write, is still pretty abysmal. Looking back, for the records that I have my dozens-of-books-a-year figure would have been during the times of my life where I would have been watching plenty of TV, doing plenty of
Eand$andS. But also during those times, I was not writing.Now that I’m writing, I’m not reading dozens of books a year. I’m reading one book dozens of times a year. Writing has, to a significant degree, reduced the time I have to read other work. This is because every time I sit down to read, I feel guilty that I’m not finishing the book I’m writing. I feel like I should be reviewing something. Revisiting edits. Finding somewhere that I haven’t been a while and see if I can find something to improve.
This maintains productivity, to some degree. But I don’t think it improves how I write. It doesn’t teach me new things, or new ways to think. It doesn’t provide alternate solutions to problems that I wouldn’t have come up with just by myself.
Re-reading just improves what I wrote.
My recommendation is to keep reading. Because there’s a lot to be excited about out there. And being excited is a great way to avoid fatigue.
-
Sidewrite.
Pretty much as the list item says: write something on the side. Something that you’re excited about. Or an issue that you’re dealing with. Either way, the altered focus will help when you come back to your other projects.
You can write a story from a character’s past (Mike and I do this with our ‘tellings’). Write the history of a fictional country. Write about what was happening down the street on the same day you meet the protagonist. Write a D&D campaign about fantasy startup companies trying to disrupt the questing indsutry. Or spend a month writing a wandering blog post about writer’s fatigue that talks a lot about pee.
You know. Whatever works for you.
Theme park designers don’t have the luxury to think at the scale of the individual human, the smallest quantum of their problem set. I mean, they know that park guests are indeed individual humans, with hopes and dreams and loves. But the park isn’t designed for individual humans. There will never be a single human attending the park.
Instead, park designers have to think at scale. They have to design around worse case scenarios. The height of summer. Or just before Christmas. School is out. Rides are malfunctioning in blistering heat. Tens of thousands of people wait impatiently in line, too hot to not drink water, but too stubborn to step out of line. And two hours wait for a ride is a long, long time to hold it.
I guess what I’m trying to say here is to think ahead. Writing a novel is an incredible amount of work, the scale and scope of which you simply cannot draw a circle around. You can try, but until it’s done, you’ll watch that project creep out of that tight, tidy circle again and again.
Think like a park designer. Know that your individual words and paragraphs are the smallest units of your project. But also know that they become something else at scale. Something much bigger. And with different problems entirely. Problems like fatigue, and burnout.
Anyway. We’re still here, toiling away in the word mines.