“I’ve been around the block twice, now my shot nice
No referee but best believe out here I got stripes
Now that they finally consider me a legit scorer
Would you believe I started off as a bench-warmer?
Have me feelin’ like Master Splinter
Now the haters and commentators say ‘there’s a winner’
Hey, hard work pay off, now I don’t take a day off”
— J. Cole The Plan
A little over four years ago, I was sitting in my office in a U.S federal government agency bored out of my mind. Thinking about an idea I had during a recent trip home to Pennsylvania, I started researching web development. I joined a bunch of e-mail lists and bought a whole slew of books. After a while I reached out to some engineers, and many of them suggested I look into Ruby on Rails. So I did.
I spent hours scouring docs, reading Stack Overflow, and reviewing some code a friend of mine wrote. After two years and some skepticism that I was doing the right thing, I entered LivingSocial’s Hungry Academy. It was, as the Washington Post described, an experiment. More late nights ensued, and after five months I became a full-time engineer at LivingSocial.
Looking back, while my path was a bit unusual at the time, my gravitation towards web development makes sense – especially considering my prior career in government. Facing the same options, Jack Dorsey described his rationale for choosing computer science over political science in a talk at Stanford:
I was deciding between political science at the time and computer science because I have always been fascinated by cities and at some point want to maybe potentially go into government. I’m still not quite sure if I have more effect there or more effect in programming. But I went away from political science because I realized that there are a lot of parallels between what you do in politics and what you do in government and writing policy and laws and what you do in programming. But the difference is the time scale. So, I could write a policy as a senator or as a mayor and I could see the effect maybe in eight years. But I could write that same policy and write a simulator around it and write populations around it and I could see that effect instantly with a computer. So, I went down the computer science route.
Dorsey’s observation is spot-on. If I were in my previous government job, it might take years to see something come to fruition. Now I can go home with an idea, crank out some code and have a working prototype, all in a matter of days. (Granted there’s still a ton of work to go into making a prototype a reality, but I digress.) That satisfaction is what attracted me to web development and it’s one of the reasons for which I’m grateful for having been a part of Hungry Academy. But like everything else, the road to becoming an engineer wasn’t without its challenges.
Much like the experiences that come from them, the challenges that code schools provide are unique. While you’re going through it, you’re aware of how much the skills you’re learning are in-demand. Then when you leave, you don’t know how in demand you are because you’re new. Looking back, there were things that were new to me that I struggled with as well as things that I had experienced before but were reinforced.
First, the things that were new:
Imposter syndrome is real
Coming out of a code school, it can be quite difficult to not suffer from imposter syndrome. You graduate and end up working alongside incredibly talented people who are on your same team, but whose journey getting there was very different: years programming as a child, college degrees, etc. Believe me, I get it. Hungry Academy wasn’t your typical code school experience. We had a sweet deal thanks to LivingSocial. If there was an ideal way to learn to code, Hungry Academy was it.
It’s hard to remember, but no matter how you got there you have to do the job you were hired to do. Period. As Mike Tomlin says, “The Standard is the Standard”. If I’m given the job title of Engineer, then I have to contribute to my team just like any other person with that title.
It’s up to your manager and company’s performance-based processes to address your performance and make sure you are judged on your current and future work as opposed to your past.
Empathy is necessary
One of the things I struggle with as an engineer is the concept of efficiency. I’m not opposed to it. As a matter of fact, I’m well aware that a part of my job revolves around creating it. However that doesn’t mean it always sits well with me when I do.
This is because, in software development, creating efficiency sometimes correlates to someone else’s job being made obsolete. I get that this is all a part of change and innovation. I get that it is the outcome of a changing workforce that is adapting to the challenges of an information economy.
But it’s still tough.
A word that’s mentioned in a good number of blog posts of late is empathy. More often than not it is in respect to the people who you deal with directly. To me, it’s just as important to practice empathy with those who are both directly and indirectly affected by your work.
I’ll save this for another post, but while we all believe in the power of the internet that doesn’t mean we can – and should – dismiss what it can do to existing jobs through our work.
While the importance of empathy and the reality of imposter syndrome were eye-openers, the following lessons were reinforced during (and after) Hungry Academy and have been just as important to my growth as an engineer:
Learning is failure
And vice versa.
Simply put: you likely won’t be able to get through a code school if failure scares you. After all, code school is like climbing a very high, steep hill at a frantic pace. It’s worth it at the end, but going through it just sucks at times.
Reminding yourself that failure is a part of learning and accepting it goes a long way in the life of a new engineer. That applies to code school and beyond.
Diversity is important
During Hungry Academy, one of the hardest things to do was to not compare myself to others. There was my friend who wrote Java in his last job, and my other friend who was picking up Ruby like she had written it for years. It wasn’t by design, but when you’re in an environment where everyone knows they are vying to look attractive to an engineering team, some of us compared ourselves to each other. We knew who was doing the best and we wondered where we’d end up when the music stopped.
The problem with that is that we lost sight of something: Everyone brought something to the table. That’s why we were selected in the first place.
When you have a good team, it is rarely the case when a part of that team doesn’t add something to the whole. So for me to constantly get caught up in whether I was as good at something as one of my peers wasn’t productive. On its own, it didn’t really matter whether I excelled in the technical or interpersonal aspects. What mattered was that my contributions helped the team move forward in the best way possible.
Balance is paramount
Sometimes, to compensate for imposter syndrome you end up working around the clock. I know I do. If you can relate to that, do yourself a favor: stop reading this article. Go for a walk. Go call someone you care about. Do something.
Seriously, this article will be here when you get back. So will the new feature that might get you promoted. So will the language you think you have to learn in order to get a better job. It will all be here.
What may not be is your sanity.
Unlike with imposter syndrome, I wouldn’t rely much on managers doing much here. Your managers might want you to take vacation and encourage you to do so, but you’re the one who has to prioritize your life and well-being. Burning out is as real as imposter syndrome, and it won’t help your team if you do.
So those are a few of the takeaways I took from my time in – and my career since – Hungry Academy. I don’t pretend to think that I speak for everyone, but I hope my perspective helps. Especially if you’re thinking about engineering as a career or even going into a code school for the first time. If you have any questions, you can find me on twitter @travisvalentine.
This post is cross-posted from Growing Devs.