Becoming a better developer, day by day
I’ve been experiencing a lot of anxiety lately about my life as a developer. The narrative will be familiar to anyone who’s ever pursued programming in a meaningful way; even if you write code every day, and learn something new every day, the nagging feelings of inadequacy are hard to escape.
It’s easy to be overwhelmed by the depth and breadth of material out there. There are hundreds of programming languages, libraries, frameworks, design patterns, and philosophies, all of which have their own associated jargon, preachers, and naysayers.
Similarly, there’s your peers, all of whom seem to know and understand more than you. You know that feeling you get when you browse Instagram and all your friends are in exotic places, meditating and/or eating gelato, and you just have to close the damn app before you work yourself into an envious knot? That’s how I feel about programmers most of the time.
‘Comparison is the thief of joy’.* I know that I should stop comparing myself with others and start comparing myself with myself. Of course, that only works if my rate of development is ‘satisfactory’. The problem is that I am the one who defines exactly what satisfactory progress looks like, and I tend to be pretty hard on myself.
This isn’t the first time I’ve written about Imposter Syndrome, and it likely won’t be the last. Like anyone who experiences Imposter Syndrome, I have a hard time internalising my own successes, which makes tracking my own progress difficult. If you have strategies for this, I am completely open to suggestion. Generally, though, I try to learn something new every day, and apply it to my daily programming.
In a day-to-day sense, though, what does that mean? It varies. It depends on my mood, energy levels, and state of intoxication (I’m kidding, somewhat). Some days progress means going to a MeetUp and chatting with other devs. Other days it’s as trivial as learning a new zsh command. Sometimes it’s blogging about my struggles and hoping that someone else out there understands. Occasionally, I’ll reflect upon where I was three months ago and try to consider my progress… this strategy generally doesn’t work, though (see previous paragraph re: internalising success).
A few things I’ve found helpful:
Setting a focus
At the moment my focusses are Rails APIs and React. This happened quite organically when I picked up a Rails API/React project at work, while also working on a Rails API for my own project. When your peers are all gabbing about Ember, Swift, functional reactive programming, and Node.js, it can be easy to feel like an idiot for knowing next-to-nothing about those things. In the midst of that panic, reminding yourself of your focus can be a useful centering technique.
Reading technical books
I’m a champion reader. Recently I’ve put my sci-fi and pop-sci mainstays aside in favour of programming books. If that sounds desperately dull to you, let me reassure you that I love reading them. The trick is absorb and understand what you can, and let the other noise wash over you — it’ll eventually make sense later.
Watching programming videos
If you’re a visual learner, watching others code can be a useful way to absorb some knowledge in your downtime. Embarrassing confession: I’ve been glad lately when a TV show I watch has either ended or turned so crap that I don’t bother to watch it anymore, thus removing that obligation from my life and allowing me more time to watch programming videos. Yes, obligation. *hangs head in shame*.
Learning to love the theory
I’ve always been a very practical programmer. As a self-taught php gal turned bootcamp graduate, my focus has always been on producing code that works. Which is good, but I can definitely feel my lack of theoretical knowledge creeping up on me. Embarrassingly, I’ve avoided doing much about this for several years because… well, no real excuse except fear of living up to my own expectations, I guess. Which, again, is silly. So I’m making an effort now to read more computer science theory. If you have recommendations, tweet them at me.
This one almost goes without saying. You know the old theory ‘See one, do one, teach one‘? It works. In my spare time, I do a bit of volunteering for Railsn00bs. The other week, I did some live code for group and I was a lot more nervous than usual as the topic of the session was rspec, something I’m…not great at. I fucked up several parts of the presentation and felt like a total idiot while doing it. But, since then, my rspec has gotten a lot better. In the past two weeks I’ve written over 50 rspec tests, and I keep referring back to the material I prepared for Railsn00bs. We’ll call that a win.