Always learning

Maybe I shouldn't be a programmer

File under: pytn imposter_syndrome

TL;DR: Bah! of course you should be a programmer.

I presented this talk at PyTN2016 this year and it got some positive feedback because I think this strikes a chord with all programmers at some time or another. I think it makes more sense as a blog post rather than a series of slides, so here you go.

This talk came out of my own issues I had about a year ago. I was on a new small team and it was decided that we were going to write our api in Node.js. The thing was, no one on the team knew Node, not to a comfortable degree. We had a variety of language backgrounds and all of our current work was in python so Node was a bit of a roadblock, but we jumped in and got things going and wrote a few endpoints and were feeling ok about things. Then came time to back fill the tests we had skipped over. I won’t go into the technical details of trying to figure out how to properly test Promises given that none of us had worked with asynchronous code before, but suffice it to say, I entered my Long, Dark Tea-Time of the Soul. I spent 5 times as long getting tests to work as I spent getting the code to work. Every PR I submitted came back to me multiple times filled with errors that ranged from simple linting problems to bugs, to completely missing parts of the acceptance criteria. I was falling apart and every single day for two weeks I thought about resigning rather than face the inevitable discussion I’d have with management where they let me know that maybe I wasn’t really a good fit for the job.

I wish more than anything else that I had gone to someone and talked about these issues, that I had overcome the fear of exposing myself to someone else and trusted that my co-workers knew and understood what I was going through. Luckily, I had really great co-workers and they recognized that I was struggling and individually and in their own way, they both talked to me and re-assured me and helped me see my way through the crushing weight of the imposter syndrome that had set in on me. I made it through (although I still hate Node) and engaged in some introspection to try to find out why, with a Master’s in CS and over three years as a programmer, why I was just now hitting this road block. This is what I came to realize.

I never learned this in school!!

Theory does not equal application. In fact, there is a lot less theory in day-to-day programming than you might assume given how much it gets emphasized in school. You may never implement your own linked list or quicksort,  because you work in a modern programming language that already implements those things, so instead you’ll learn the api for them in your language. You probably won’t need to calculate the big O notation of some bit of code and that recursive call you could write looks cool and all, but you’ll pop your stack if you don’t do it right at scale, so maybe just play it safe with an iterative approach. Of course learning is vital in this field, whether it’s through a college or software school or even just on your own and every programmer I know is naturally inquisitive, someone that wants to keep learning and growing their skills; but knowing what parts of your education are directly applicable to your job is something no one ever teaches you.

Along with that is the reality that your work environment is almost infinitely more complex than your learning environment. To get you local environment running you’re going to need to spin up vagrant and then set up a virtualenv, rebase the master branch this sprint branch, make sure you have elasticsearch, cassandra and mysql running locally, you’ll want to ssh into the api server to tail the logs, but the other processors will print to logstash. And remember, no more than a scoop and a half of coffee in the machine or it overflows! That’s my set up every day. In school I never worked in more than one language at a time, and the complexity of my projects rarely grew so large that I couldn’t keep a map of them in my head. Also, I never had to deal with build tools, continuous integration, log servers or multiple data stores. On top of that, my work is now measured in hours or days, sometimes even in minutes (usually in those minutes right before we have to demo) rather than weeks or semesters so the time crunch is never ending.

And now, rather than staying up all night and writing code alone in front of my computer, I have to work with team members, not only making sure my code works with theirs, but getting my workflow to work with theirs. When I’m in a new codebase, I usually  walk through every function I hit to fully understand the codebase and make a mental map of everything; that’s what I need to feel comfortable. But I ask a senior about something and they jump from function to function like their doing parkour because they’re more comfortable taking in the highlights. Their workflow is vastly different than mine and it made me feel inferior to move so slowly, like I wasn’t running on all my cores.

The secret in all of this is to remember that just because you do things different, that doesn’t mean you’re doing it wrong. With time and experience you’ll figure out how to read new material and decide what parts are too much theory and what parts are germane to your work. You also need to remind yourself that no one expects you to pick up the details of half a dozen new pieces of technology all at once. It’s absolutely reasonable to forget the archaic incarnation you need to get elasticsearch to start up locally when that’s one step in 10 that you have to complete to get things running. And don’t worry if you move more slowly through code than more experienced developers because the fact that you’re going through the code and learning it is the most important part. And who knows, someone may ask about some obscure function call and because you spent an hour taking it apart, you’ll have the answer, and that’s an amazing feeling.

Why’s everybody always picking on me?

One of the pain points for me during my dark times was getting feedback in code reviews. I kicked myself for missing the things like leaving in print statements or not deleting commented out code, but when I got feedback like “hey, can you clean up these extra blank lines” or “can you remove these unused imports”, I felt like the reviewer was just being nit picky. I’m trying to work on the next ticket, I don’t have time to go back and worry about this petty shit!

But the worst were the reviews asking me why I used a for loop to create a list instead of a list comprehension. Or why I wrote these 30 lines of code to do this thing when I could have just called an existing method and filtered the results. And did I know about how this method from the standard library and how to use it? Fuck you! I spent a lot of time working out the details of my code and it fucking works. I’m trying to feel proud of the work I’m doing and all you do is tear me down!

And you should feel proud of your work. As professionals that are building a career, we should all produce code we are proud of. The problem is when we become emotionally attached to our work, when we start to see it as a direct reflection of ourselves and so we take any feedback as a slight against who we are, not only as programmers, but as people, as individuals, as ourselves. Don’t get caught in the trap of thinking that you are your code, because you are so much more than that. Your life is not summed up in one pull request, or one hundred pull requests. That is a moment in time, a thin cross section of your life as a developer and that alone can’t be used to define your abilities now or your potential for the future.

At possibly the darkest part of my downward spiral, a co-worker said to me “code reviews are a discussion.” And that was the point when I started to turn around. Code reviews are a discussion. Look at a pull request on github, it says it right there. Sure, there are some hard facts, like this bit of code doesn’t follow Pep 8 styling or you didn’t catch this edge case in your code, but a lot of it is more of a conversation, a starting point for the reviewer to find out how you made the decisions you made and to suggest a different direction; sometimes better, sometimes not. And since it’s a discussion, you get to be an active participant, you get to have a voice and decide that you are going to take their advice or not. And if feedback really doesn’t make sense, ask questions, find out why someone suggested a change if you really don’t see the benefit. Not every bit of feedback is valid.

Of course, you need to keep in mind that if everyone is used to Pep 8 styling, then it’s easier for them to scan consistently styled code and list comprehensions are faster to mentally parse than for loops, so there are valid reasons for making such changes. And keep in mind, that being proud of your code doesn’t mean you have to seal it in amber and never let it change. Figuring out why a change was suggested and seeing how it can improve your code should also be a point of pride, not only for this PR, but for future PRs that are made better because you learned something new.

How do I cope with this?

So, how do we get through these feelings of inferiority? Sure, we can try to remind ourselves that the PR comments aren’t personal and that as new developers, no one expects us to know every detail of scaling microservices. But no matter how much we tell ourselves that every developer at every level wrestles with imposter syndrome, it’s still hard to know it’s true. Maybe we’re just lying to ourselves, right? Rationalizing our own incompetence. To me, the best way to push through this is to actually see other people are struggling through the same issues, not as some form of schadenfreude, but as a way of connecting and commiserating, as seed for building community. So, try these things.

At work

Find a mentor. If your company doesn’t have mentors, ask to start a program and if they won’t do it officially, try to get a senior dev to meet with you; even crusty old neck-beards like to talk to up-and-comers occasionally. Having someone to meet with on a regular basis can be invaluable. Being able to look forward to opening up and asking questions and feeling vulnerable to someone who is on your side and can relate to you, that can do a world of good for your sense of self. Meet on a regular basis and keep a set agenda so you know you’ll always have something to talk about. Bring something that stumped you and something you’re proud of and something that made you feel inferior; ask for feedback, advice on what to study, what blogs to read, what books inspired them. But also, make sure you have time between meetings to make improvements. Meet too often, and you won’t see the big changes that have taken place; consider it a sprint of your career.

In the community

I can’t say enough about the development community in Nashville, especially in python. Those people are just awesome; there’s always someone around to answer a newbie’s question with legitimate care and no ounce of disdain. I feel incredibly lucky to have them as a support system, even though I’ve moved away from the city. And Chattanooga is looking just as fruitful. My favorite way to interact with the community on a regular basis is through meetups. If there are no meetups where you are, start one; I can almost guarantee you’ll find people that share your interests and they will have war stories that are incredibly similar to yours. (Side note, if you start one, find a good Code of Conduct to implement. If you join a meetup, push to have a CoC if they don’t already. Leave things better than you find them).

Beyond meetups, there’s Teh Interwebz. Slack and IRC are great ways to interact with people and ask questions. But they are also great palces to watch and learn from the struggles that other people are having. You’ll see that a lot of really smart, really talented people, struggle with not knowing all manner of things. Mailing lists for languages or frameworks or applications can be a good way to directly interact with people who share your passion for a particular technology. Just keep in mind that as you wade deeper and deeper into the internet, “thar be dragons”, or more likely trolls. If wander into a nest of negativity and spite, just walk away; there are places of light out there, find them.

And my favorite way to overcome my lack of knowledge? Write about it. Write a blog or better yet, give a conference talk! Regional conferences are amazing places for new people to learn and to teach. When I submitted a proposal to my first conference, I had a passing familiarity with the subject, but a desire to learn more, so I used that as a way to push myself to learn the material well enough to talk about it. And while my blog is woefully under utilized, I’ve made it a goal this year to write more and that means learning more about the things I want to write about.

And sometimes you have to create a hybrid between work and community. A guy I met after giving this talk told me he worked for a university and was the only developer in his department, so he wasn’t able to find a mentor or get really good feedback from his co-workers or boss. He did, however, have a regular meetup with other programmers in his situation, people in his university that were lone developers in their departments. I suggested they mentor each other, they open up a bit and confess their concerns and insecurities and share stories of feeling lost or not good enough or frustrated. Finding a community of like-minded people means supporting them and having them support you, even if you only connect occasionally.

As a discipline, we have historically been shit at exposing ourselves to each other, at talking about our fears and frustrations and lack of knowledge or understanding. All too often we’ve forced ourselves to live out the stereotype of the isolated hacker, siloed away from each other, doing things on our own and suffering in silence with our insecurities. We’re starting to break that habit, we’re starting to open ourselves to the larger community and share our stories of self doubt. Because beyond languages, beyond frameworks and libraries and vim vs emacs and datastores, beyond all the technologies that we choose or that choose us, the one constant that affects us all is that we will falter and fall from time-to-time. It’s the great equalizer and helping to pick each other back up can be the seed of our community.