I ended my last post with this question:

"When the movie is first screened to the cast and crew, when the opening scene illuminates the faces of the main actors and directors, what's the location assistant thinking? Does he feel a sense of ownership of the movie in front of him? The same emotions as the protagonist and producer? Is he proud of his work or is his job so specific, so far removed from the big picture, that he feels like a stranger in the audience, simply enjoying the free popcorn and daydreaming of weekend plans?"

At first, my answer to this question was a resounding no, there's no way the location assistant could feel satisfied. He shows up early, needs to clean up after whatever divas were on set, and "dealing with complaints from neighbors" is explicitly listed in his job description. It's everything no one else wants to do.

If you're reading this and are a location assistant, I'm sorry if I offended you. But also please tell me the silver lining of your job because I'm incredibly curious.

I carried this mindset to my internship at Dropbox and it was the source of a lot of frustration. For my first few weeks, I refactored wholly uninteresting update code that had been written a decade ago and barely touched since. This often involved going on scavenger hunts through layers of untyped python code, similarly named classes, and a hazy execution path, to find the types of each object I touched and explicitly annotate them with MyPy.

Then, around halfway through, I learned that Dropbox was planning on creating an out-of-process updater for their mac client, so most of my code would barely be used anyway.

And so, my work day degenerated. I'd roll in around 11:30, pretend to check emails for a bit until lunchtime, gorge myself, and then waddle to the coffee bar where I'd pound Americanos and eat pastries until I was so artificially stimulated that I was too restless to keep wasting time. I'd jitter back to my desk and re-organize classes, hunt for types, and try to comprehend neglected functions with my sweaty fingers. Eventually, the caffeine would leave my system, and with the corresponding flood of adenosine, the fact that I had just spent 30 minutes trying to figure out whether "func" returned a "NSFileAdapter" or a "FileSystemWrapper" would become painfully apparent and those feelings of absurdity and anxious frustration would return. I'd leave right after dinner, the guilt of not trying my best nagging me for the rest of the day.

My mentor tried to stress the importance of refactoring-- of taking ownership of touched code, of leaving things better than when you found them, but I couldn't find pride in what seemed like the programmer equivalent of the location assistant.

This continued for a while and whatever excitement or hope I had for a lifetime of programming 8 hours a day quickly deteriorated. Even when I finished refactoring, my work was limited to small, simple, changes, and the time spent waiting, debugging, searching, and cleaning overshadowed any time spent actually thinking.

Then, one weekend, while wandering around the Mission, I stumbled upon a bookstore (Dog Eared Books, if you're looking for recommendations). While perusing the aisles, I spotted one of my favorite books, The Myth of Sisyphus, a collection of essays by Albert Camus. The main essay is about Sisyphus, a Greek mythological figure, condemned by some Greek God to push a boulder up a hill, only to have it roll back down again, for the rest of eternity. While this sounds awful at first, Camus likens this absurd task with the also absurd, but less obviously so, tasks that plague our own lives. To find happiness in life when the ridiculousness or emptiness of our tasks becomes apparent, we must imagine Sisyphus happy. We must believe him to ignore the absurdity and become acutely aware of each crack, bump, and indentation, focusing so intensely on his task that he is absorbed in this "project" and it becomes his own.

I'm being over-dramatic comparing refactoring code to Sisyphus pushing a boulder up a hill for all of eternity, but the takeaway of the Myth of Sisyphus can be applied to anything.

From then on, I relaxed my mind, focusing on each character typed, on the rhythmic cycle of wait, search, type, debug, clean, without dwelling on its significance or challenge or excitement. It was then that I began to feel embarrassingly satisfied after crafting a exceptionally modular class or implementing an elegant design pattern. Of course, I pretended to continue to hate my work, as I couldn't admit that I enjoyed these trivialities to anyone, but I quietly eased into a pleasant remainder of the summer.

(I talk more about the Myth of Sisyphus here and the Stanford Encyclopedia of Philosophy has a great interpretation of the conclusion here.)

The views, opinions and positions expressed by the authors and those providing comments on these blogs are theirs alone, and do not necessarily reflect the views, opinions or positions of UT Computer Science, The University of Texas or any employee thereof.