For as long as I remember, fear of not being good enough has haunted me like a shadow in the distance. Its silhouette, blurred enough to engage my imagination but close enough to be intimidating, can even paralyse me at times. To this day, if I’m asked to do something I have never done before and that I lack carefully detailed, failure-proof instructions to, I am tempted to simply announce “I can’t”. I am sure many can relate. And there is an obvious logic to it: if I have never done the thing, how can I truthfully say I am able to do it? I would rather not make a promise I can’t keep. However, recently I’ve started to find myself comfortable with another response, one obvious and completely natural to some: to just try and do it.
This approach requires no proof or promise of success — not even a belief in your ability to do the thing — but a willingness to give it a shot. But building confidence in your own self-sufficiency and combatting fear of failure are exhausting activities. Trusting the process of figuring it out doesn’t come easy — but I’ve found one thing that facilitates this particular aspect of personal development: getting a job as a software developer.
Programming more or less demands of you to abandon all hope of getting it right the first time. It’s a hands-on, trial-and-error-natured craft. Should you happen to ‘blind code’ (coding away without testing as you go) a feature or fix successfully and production ready on the first try, new demands are sure to arise from the business department, customers, or other teams. The inundation of new frameworks and coding styles means enticing opportunity for limitless growth, but also feeds into ever evolving industry standards at a superhuman rate. Still, you adapt. Continually you weed out obsolete code and update the still relevant parts. Your code base is very much alive, and it is your job to keep it growing and living healthily.
At its core, programming is baby step problem solving. As a beginner, you kind of have to just stumble forward and find your way. The foundation of the modern software development work process is an incremental methodology, starting with the formulation of a minimum viable product (MVP) and iterating the solution towards greatness. It’s called an agile way of working and you are bound to encounter at least some flavour of it at any modern tech company. It made me grow a mindset of drafting and iterating as a means to reach quality.
Yet I still struggle with ‘beginner perfectionism’, and so do many others. It seems to be especially common among women. In her TED talk Teach Girls Bravery, Not Perfection, Reshma Saujani talks about how we are indeed taught to strive for perfection, which in turn is irreconcilable with another disposition: that of being brave. Saujani shares a story about teaching girls to code. The girls tried meticulously to reach the right results, but if the code didn’t work, they erased it all without showing it to anybody. On the other hand, boys faced with a difficult task would bite into the challenge with vigour. How come some see a shameful failure in all but a perfected end product and others just do things regardless? Without doubt, a good deal of courage goes into any initiative for creativity or growth, and especially so if failure means anything short of perfect. A certain shame comes with producing anything that betrays a beginner’s touch, one that can have us question if what we made is even allowed or appropriate to exist. (For further reading I refer you to Elizabeth Gilbert’s brilliant take on David Whyte’s “the arrogance of belonging”, in her book Big Magic.) This is how we learn to say “I can’t”. Perfect is unattainable and we have lost sense of what else would constitute an acceptable result.
I have occasionally taught programming to other women and while some are fearless and exploratory, many need constant affirmation that they are going in the right direction. But when learning something new, that direction is usually the one where you make the most mistakes. Making a mistake merely advances you to a new take-off point. We need to relearn how to get better gradually; even if it’s just making a first onClick function work (or not work, and instead learn how to interpret errors in the browser console), celebrating every tiny step forward is more often than not a sound approach when leading anyone into the realm of coding. There is a constant tug-of-war between the fear of shame for not getting it right and looking stupid, and the joy of making it work. It’s a good idea to let the latter side know we’re rooting for them.
For someone afraid of failure, the healing power of programming is also a matter of exposure therapy; ‘coding’ usually entails endless interruptions for figuring out why your code isn’t working. In fact, the tendency of programmers to err is so unwavering that programming editors have come to incorporate advanced systems automatically fixing easily-recognisable errors, telling coders exactly what went wrong, and patiently showing the state of the program one line of code at a time for us to discover the exact point of screwup (the process known as debugging). We use these systems throughout our days, as a way of steadily moving toward our goal and making sure we are writing high quality code. No need to lose all hope over an unsuccessful first try. Step by step, we iterate our solution until we arrive at our destination.
Programming helped me quench my inhibitory perfectionism by teaching me how to work in MVPs, which is the same as saying that it taught me the power of drafting. Drafting is scary, because it means putting unfinished, unpolished work out there for scrutiny (from yourself or others). But drafting sets you free, because it also means intentionally stating that whatever unhelpful criticism the voice in your head has to offer, doesn’t apply. Then you can start to get productive. Whatever a draft consists of, it is the result of a creative process, and elusive as the purpose of any creative process may be, that purpose is surely closer to merely making something, than making something that is perfect. Considering a result a failure is interesting; it signals something about your goal or your method. In fact, both goal and method are also just drafts, and we can iterate them too.
Drafting is a highly transferrable skill. When writing, for instance, the inescapability of the mediocrity of my first drafts sets me free to write whatever and however I want. I rest in the knowledge that I will tweak and adjust this substance when revising. Just like a potter must first somehow produce some clay, a writer must first produce some text. Yes — my first drafts are horrible, but they are, at least, produced. That is all anyone should require from a first draft.
What I used to be most afraid of, what I deemed would bring that lurking shadow upon me in an instant, was winging things: making first drafts in real time, which end up being the end product. Here, the current moment is your material. Each previous move becomes a stepping stone for the next. That’s what winging something is all about: giving up control and letting your self-sufficiency guide you. When your perception of your ability is aligned with your ambition, you can start trusting the process. To me, it still seems like a high-risk game, but by purposeful drafting and treating errors as clues to how to make things right, I have been able to start enjoying its rewards.