Seth Godin recently wrote,

Role models are fine. But not when they get in the way of embracing our reality. The reality of not enough time, not enough information, not enough resources. The reality of imperfection and vulnerability.

There are no movie stars. Merely people who portray them now and then.

I always appreciate Seth Godin’s candor. Someone as successful and respected as he is could pitch their advice as a fool-proof framework for excellence and success in one’s work—indeed, many do.

“Imposter syndrome” is a term that gets thrown around a lot amongst software developers. It’s the mindset that we are not good enough, not a “real” programmer. We could think this way for any number of reasons—lack of formal CS education, lack of experience, lack of knowledge around the cool new framework that everyone is talking about on Hacker News, lack of concern about what anyone even says on Hacker News, etc.

It’s easy to look at other, more experienced programmers and think that they have it all figured out. Yet some of the most profound things I’ve learned have come from hearing senior devs admit they don’t have an answer for the technical or architectural problem at hand.

My boss once told me that as I progress in my software development career, I’ll come across increasing problems for which there is no blog post, no tutorial, no Stack Overflow answer, and that that is where the most interesting growth happens.

Although we should work against the shame and deleterious effects it entails, “imposter syndrome” shouldn’t be confused for humility. Rather, by embracing our not-enough-ness and vulnerability, we can avoid hubris, learn, grow, and make something good.

Aside from blogging here, I’ve been trying to build my writing habit by working on a short story. I wrote some short stories while in college, and thoroughly enjoyed it.

My best friend, Collin, writes quite a bit. He credits me with initially inspiring him to write, but he has since far surpassed me in quantity of output, and, I would argue, quality. Although he doesn’t code, he said he imagined storytelling and programming to be similar disciplines, or for there at least to be an overlap in skills and practice.

I think his hunch is true.

A bit of advice sometimes given to writers is to stop writing in the middle of a scene, or a point of tension in the narrative. That way you have something to work with when you return to it.

I’m finding a similar practice has been helping me with programming lately. I’m currently working on a tool for importing legacy configurations into a new schema in a new system, and trying to use test-driven development while doing it. The whole export/import system is fairly involved, taking me more than a day to build, and starting the day with a new function or component to write without knowing exactly what you want it to do, let alone how, can be fairly daunting.

In the spirit of true TDD, I write a failing test that expects a certain output, and then code the feature until the test passes. But, instead of spending tomorrow morning determining the “shape” of data I want and writing a new test, I ended today by writing a failing test, giving me an explicit objective to complete in the morning. I’ll admit it felt uncomfortable leaving this undone, but having something clear to accomplish in front of my when I start my day tends to be very motivating, and provides fuel when moving on to each successive task.

Never underestimate the power of interdisciplinary insights.