The Myth of Sisyphus, Failure, & the Meaning of Imperfect Code

For years as a student and into my first few years as a junior engineer, I felt dirty. Something felt wrong about the code I wrote. No matter how hard I tried, things just didn't always line up and it bothered me. "What is the point of writing code if its not the best it can be?" I would ask myself. If my editor was a pencil and paper, I would have gone through all of the world's supplies of erasers before ever coming to a solution, because I felt like the code I was writing wasn't good enough to give to a client or to deserve a job. This made certain parts of my early career miserable, slowed down projects, led to burnout, and even made me reconsider my life choices a few times.

As I've grown and learned from the experienced individuals around me, I've come to accept my imperfect code and imperfect solutions. While coming to this acceptance, I was able to draw some notable comparisons to one of my favorite ancient Greek myths, the tale of Sisyphus the king. He was tasked with rolling a boulder up a hill for all of eternity only to have it fall back to the bottom, all because of a con he attempted where he tried to cheat death. Sounds pretty grim, right? But there's a lot to learn from this myth and a lot to be optimistic about when digging deeper into it. Even thousands of years later, we can relate this myth to the daily grind of software engineering and programming.

A Note Before Going Further

“There are three things I have learned never to discuss with people... Religion, Politics, and The Great Pumpkin.”

• Charles M. Schulz, Creator of Peanuts

I'm going to mention a piece of writing throughout this post titled The Myth of Sisyphus by Albert Camus that talks about existentialism and the absurdity of life. I cannot stand on a soap box and argue whether or not Camus's thinking on life, death, and the meaning of it all is correct, I simply find the story interesting and drew some conclusions to my own thinking about the Software Development Life Cycle and what it means to be a Software Engineer. It is however an extremely interesting book no matter your background, so I recommend giving it a read if you are looking for some crazy deep philosophy and just a few minor cases of existentialist dread.

Two Common Scenarios of Mine

The two following situations seem to occur a lot as a junior engineer, and I know many colleagues and former classmates who let these situations get to them, chasing them away from the software industry.

Changing & Misunderstood Requirements

Have you ever had those days of programming when you seem to be on a roll, and then suddenly you realize any one of the following: 1) you missed an important edge case, 2) misunderstood either the problem or the solution, or 3) the requirements were changed out from under you? After working long enough in the software world, one, if not all three of these situations will happen to you, and its just upsetting, especially if you have already have been deep into the project or a particular implementation. This causes you to reevaluate, start over, and reset your entire thinking on the problem, potentially burning away hours or even days of time from your previous attempt.

Solution Stinks of Code Smell

"Code smells are a set of common signs which indicate that your code is not good enough and it needs refactoring to finally have a clean code."

• Mohamed Aladdin post on Writing Clean Code

Quite frequently I will design a solution that seems perfectly reasonable and easy to explain in my head, only to find that it is difficult to implement in real life. I'll tell myself something along the lines of "Oh yea, I'll just create class X and parent interface Y and the code will be awesome!"

...then you go to write this perfect implementation, annnnnddddd just nothing seems to come out as well as it looked in your head? Either interface Y just doesn't seem to be working, or maybe the dependency injection you thought would be smart in class X is backfiring in your face.

Code is the Boulder

"[A]ccording to the Greek myth, [Sisyphus] was punished for all eternity to roll a rock up a mountain only to have it roll back down to the bottom when he reaches the top."

• SparkNotes on The Myth of Sisyphus

Don't tell my high school literature teachers that I quoted SparkNotes, but as previously mentioned, Sisyphus's punishment was to role a boulder up a hill, only to watch it roll back down as he approached the top. After all the time and effort he put in, he would watch himself fail and have to start back from the beginning again.

The aforementioned mental blocks and difficulties are the problems that I face in my personal and professional life; they are my boulder(s).

Software development is a lot like the myth of Sisyphus; it is never-ending, is always pushing forwards, and has the potential to hand you big failures when you are least expecting it.

I think the Dev user jacksonelfers says it pretty well in his comment below.

Jackson Elfers • Mar 6 '19

Programming is a lot like the Greek mythology of Sisyphus. Never ending, never complete, sometimes things go up in flames you were completely confident about. Then there are moments that remind you the perks of being able to talk to computers.

Our responsibilities with programming are never-ending, and sometimes burn us. Even if we "complete" a project, there may be bug fixes, patches, new features, or at least another project behind it waiting to fill more time and space in our lives. In this regard, we as programmers are always pushing our boulders up our own hills. There's always tech debt, the next project, the next requirement, or a bug fix that needs to be done. These are our responsibilities and our duties in the software and programming industry.

Iterative Progression, Not Immediate Perfection

Since we know there is always work to be done, it becomes impossible to write perfect code, because perfect code would mean there is nothing left to do. That lifts a massive burden off of our backs to feel like we have to be perfect. Since we know that we will always be rolling our metaphorical boulders up the hill of software development, that opens us up to allow for failures, learning, and so much more.

As a junior engineer, I've messed up projects, missed deadlines, and have seen my "boulder" roll back down the hill as represented by my failures. Previously, I would let myself be defined by these failures, and I beat myself down every time something went wrong. What I failed to notice is that everyone around me - including the hot shot senior engineers - are pushing their own boulders, occasionally failing and watching them fall down the hill.

This is what makes software engineering fun for me now; I recognize that it is a human process. Code is imperfect because we are imperfect. Failing is just a part of the game. Everyone has failed before, and everyone will continue to fail. What makes this struggle all worth it is that every time we fail, we can hope to learn from these mistakes and make it just a little bit further up the hill before failing again.

Writing imperfect code is okay as long as it works, because all code is imperfect. If it works, then that is better than what was there before. There will always be time to redesign and refactor. I love the quote that my manager(s) use occasionally when I fall into the trap of attempting to write perfect code; "Chances are, what you expected to last forever will last a year, and the hack you put in will stay in production 'til after we die." We can't foresee the problems we'll encounter in the future, so we need to just take small steps forward up the mountain to get closer to the top.

This means that instead of reaching for immediate perfection in my projects, I have started to force myself to build iteratively and progressively. Whereas I could have spent six months working on a project in my basement only to realize it sucks, I can spend one month writing a crappy project, release it, and spend the next five months getting valuable feedback and improving upon it slowly and iteratively. That is software development.

We Must Imagine the Programmer Happy

One of Camus's strongest points is that we must imagine Sisyphus is happy pushing the rock up the hill, because it is absurd to think otherwise. Since he knows that is all he can do, he gets enjoyment out of it, because there is no better alternative. Instead of seeing the rock as his punishment, he begins to see the challenge as his life purpose and the boulder as the vessel to accomplish that goal.

As a software engineer, I take great pride in the code that I write. Even though I know most of it will be refactored, rewritten, or won't even be needed in a few years when the next thing comes around, it fills me with a happiness and purpose to know that for the meantime, my code is out there doing some really cool things. Past that, it doesn't matter for me. Even if I commit only a few lines of code to a project, that's better than nothing, and makes me a better developer than before.

The challenges that present themselves in software development are not unlike Sisyphus pushing the rock up the hill. There are challenges, mistakes, and failures that can be represented by the boulder rolling down the hill. While this is true though, I always come back to programming. I always find joy in the challenges and the struggle. Through the grunt work, the nitty-gritty details, and the imperfect solutions, I find meaning and solace that I am making a difference in the world.