How Coding Taught Me How to Wing It
For as long as I remember, I have been haunted by fear of not being good enough. Intimidating, like a shadow in the distance, this fear both engages my imagination and paralyses me. 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. Recently, however, I’ve found 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 self-reliance and combatting the 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: working as a software developer.
Programming more or less demands that you 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 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 growth, but they also make keeping up with industry standards a Sisyphean task. 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 living healthily.
At its core, programming is baby step problem solving. As a beginner you have to just stumble forward and find your way. The foundation of the work process of modern software development is an incremental methodology, starting with the formulation of a minimum viable product (MVP) and iterating the solution towards completeness. 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. Working in this way made me grow a mindset of drafting and iterating as a means to achieve 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 get 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, multiplying their efforts in order to figure it out. 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. There is a certain shame that 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 at all. 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, the right 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 learning to code. 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 (this process is 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 you are 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 inescapable 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 material, 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 final 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: letting your self-reliance 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 get things right, I have been able to start enjoying its rewards.
