My wife is an artist. If you’re curious, she is an encaustic painter, and you can follow her blog at www.kathryndart.com. If you’re still here and are interested in anything I have to say, she brought home a book one day last year – a 119 page paperback- that she simply couldn’t finish because every few pages she had to stop and reflect. The book was called Art & Fear by David Bayles and Ted Orland, and it’s about the self-imposed road blocks that accompany creative endeavors. It inspires the artist to continue creating even when she feels like a fraud, when her work doesn’t feel groundbreaking, and when people aren’t buying. If you know an artist, buy them this book. But for me it spoke to me as a developer, especially as I see myself in relation to open source software.
First, allow me to begin by saying that this post is an open letter to myself, not a human-interest story of a man overcoming his fears. I share them to aid in my own personal accountability as well as to have a reminder of the lessons I have learned. Second, I want to acknowledge the gaping chasm between being a developer and being an artist. Yes, both jobs require creativity, but the war stories and struggles don’t compare. I’m not trying to say it’s as hard being a dev as it is being an artist, but I felt the advice and many of the personal struggles matched the way I feel every time I try to make a contribution, every time I think about pushing a repository to github, every time I post a comment on a blog or reply in a newsgroup. And I’m also saying that the words in Art & Fear are as inspiring and encouraging to me wanting to be a contributer as to my wife as an artist.
Only the Talented May Play
Open source terrifies me, but simultaneously I desperately want in. That’s one of the phrases I started with when writing this post. It’s obvious from my rhetoric that there’s a self-inflicted feeling of exclusion. To me as an “outsider,” and I will assume I am not alone, there is a mystique surrounding open source contributers. They have weekend hack-a-thons where they churn out amazing systems and should you find a bug in their system, they furiously type at the terminal and then say “try it now.” Mozart wrote his first symphony at the age of 8.
There is genius in the world and raw talent, and, if we are to be honest with ourselves, we- and I’m speaking to those of us without- don’t have it. We know from societal hero worship that art is made by the talented, the Mozarts, and I feel that same reverence towards the hackers, the contributers. I am a very capable programmer, but I am no parallel to Mozart. Therefore, I could not be a contributor.
But this distinction is flawed in its definition. Saying a symphony pales in comparison to Mozart’s in no way makes it less of a symphony. If I were to release code, saying it’s not very good in no way cancels its code-dom. Ordinary people write code, and ordinary people make art (4). So simply being ordinary doesn’t categorically exclude.
On being an imposter
Many have been quoted saying that it’s better to keep your mouth shut and be thought a fool than to open it and remove all doubt. This is another reason to stay out of open source. I keep seeing prominent community members asserting they’d take a github commit log over a resume. This works in favor of the true programmers, but where does this leave imposters like me?
Making art can feel dangerous and revealing. Making art is dangerous and revealing. Making art precipitates self-doubt, stirring deep waters that lay between what you know you should be and what you fear you might be (13).
These words cut right through me: “what you fear you might be.” The problem with putting your code out there for all to see is that everyone is then able to see the code you write. You’re naked and vulnerable. At least in the United States, we put an extraordinary amount of our identity in our work. After asking your name, the standard introductory question is “what do you do?” It would be awful to learn such a critical piece of your identity (“I’m a developer”) is an overstatement.
Impostership, under guise of several categories, makes up a good portion of the book. Artists have to prove their work is true art and not mere “craft.” They have to prove that they are real artists with vision and not carbon copies of those who came before them. During dry spells, as customers are not buying, they must prove that producing art serves a purpose that is not wasting everyone’s time. Interestingly enough, these proofs are necessary only to the artist herself. Continually, Bayles and Orland refute these doubts, assuring the artist that despite the frequency within fellow artists the fear is completely unnecessary. Artists are defined by making art as chess players are defined by playing chess (25).
There will be insecurity in choosing a path, and there will be frustration when your code isn’t as elegant as someone else’s. In the book, a young pianist complains that his execution isn’t living up to his vision and his Master replies “What makes you think that ever changes?” (15). If you watch commit logs, the Masters fail as well, and they rewrite and refactor and change. The power of open source is that you are not limited by the performance of your vision in the moment. Your performance and vision are refined by the combined performance and vision of everyone.
Making a difference
There are thousands of years of beautiful visuals, words, and music. Today alone there are thousands of brilliant people making extraordinary pieces of art. There are many many extremely talented and intelligent open source contributers. Some even have found ways to make direct contribution their day jobs. So given the current resources, what makes me think I have anything constructive to add.
We’re talking art metaphors here, so, if I were to hang my chicken scratches up in an art museum, few would argue the point that this art adds very little to the exhibition. This is a fair assessment, and the unpracticed hand does not produce quality work. The lesson to take, though, is to write code more. The book reflects upon a study done where the teacher graded students by either quantity of work or by quality of a single piece and found that students graded by quantity also produced higher quality work. There is much work to be done in the open source community, so there are many opportunities for you to improve.
To be sure, just because you submit a patch doesn’t mean it will make it into the project. Sometimes, there will be bugs you didn’t catch, and sometimes there will be style and/or consistency issues you need to address. Sometimes the feature you’re adding is only useful to too few people to justify adding the complexity to the API. Do not judge your efforts as successes or failures based solely on whether the patch lands in core or by project adoption. Learn, make changes, and resubmit.
If the process takes time, let it take time and be resolute. It is a dangerous trap to believe your “next effort is already doomed to fail” (10). Be wary and don’t fall for it. Another trap is to believe that if it doesn’t come easily, you aren’t talented. Yes, the masters will write better code than you write. They will write code faster than you can write it. To be sure, they’re more talented and experienced than we are, but that shouldn’t stop us.
“By definition, whatever you have is exactly what you need to produce your best work” (26).
No good comes from worrying about how good you are. Write code.
I’m very proud of my wife for her ability to face her fears daily. It takes a lot of guts to deal with all these insecurities, especially when she cannot fall back on the economic reward of the job. So what’s our excuse? If you are like me and have been afraid of contributing, let’s take this encouragement to heart and give back.