Emmett Butler is a web and video game developer and an NYU senior studying computer science and music technology. In this post, he reflects on his time as an intern at Parse.ly

Today, I leave  Parse.ly  after 20 months of work that took me from writing web scrapers to diving deep into semantic web standards to designing mobile SDKs. Here is some advice and emotional primer for the incoming Parse.ly intern. I can only speak from my own experience, and while I try to generalize, all of my advice is heavily colored by what I went through when I started.

When I started at Parse.ly, I was working 20 hours a week alongside another part-time work study job. I was entering my 3rd year of an NYU double music technology/cs degree, and my technical skills were rudimentary. I had no “real world” experience to speak of, and the extent of my outside experience was a few hackathons, schoolwork, and a handful of personal projects. I actually remember thinking during my first few weeks at Parse.ly that I had no idea what I was doing – I didn’t delude myself.

In the course of my time here, I’ve gone from mechanically writing 4-6 web crawler scripts per day to developing  semantic web tools  and  mobile SDKs  for Parsely’s customers, as well as contributing to the main analytics product, Dash. I gained experience in most of Parse.ly’s codebases circa mid-2012, primarily as a result of my own exploration. I personally feel that I’ve come a long way.

Parse.ly was both my first “real” job and my first time collaborating with other professional developers. Knowing that I was extremely inexperienced, it was easy to assume that everyone else on the team had all of the answers. In my mind, there was no question I could ask the other developers that would challenge them – the rest of the team was light years beyond me as far as I was concerned. This was my mindset for probably the first 2 or 3 months I spent at Parse.ly, and it didn’t really change until I had done something I saw as substantial enough to warrant being taken seriously by anyone else. Of course, this is a poisonous mindset and it can (and did) lead to all kinds of negative emotions and behaviors. Primarily, it stopped me from contributing meaningfully to discussions, since I was convinced that I had nothing to offer.

What I came to realize about this mindset is that it is (obviously?) not founded in fact. I’m sure this realization is something everyone has to go through at some point or another, but the most important thing for me to personally understand was that  there is no worldwide programmer race. I am prone to operate under the assumption that there is a race going on between all programmers in the world to see who can be the “best” the fastest, and I’m losing. The fact is that nobody actually thinks this way about anyone other than themselves – everyone is worried about their own skills, but they don’t spend time comparing other people.

The point is that everyone has their own expertise and skillset, and it’s very unlikely (no matter how much you want to believe it) that the sum of your own knowledge is fully duplicated across the rest of the Parse.ly team. You know something someone else doesn’t, and this simple fact invalidates the “race” idea. Skill sets are vectors, not scalars – you can’t just “rank” people based on the entirety of what they know or don’t know.

The upshot for me was to stop comparing myself to other developers, especially the Parse.ly team. There is nothing to be gained from worrying about “how good you are”.

As for contributing to discussions, I think about it like this: you are very familiar with yourself. You probably have a constant internal monologue in which you acknowledge your own thoughts about the discussions and teams activity happening around you. You’re comfortable with this. If you’re anything like me, you tend to forget that other people (especially people who don’t know you very well) are not familiar with your internal monologue. To me, it seemed that the worst consequence of not contributing to discussions was having to go along with whatever decisions were made. It turns out, though, that since the rest of the team doesn’t hear your thoughts, the worst consequence is, in the long term, gaining a reputation on the team as unengaged. This applies, as far as I can tell, to any tech team, not just Parse.ly. If you don’t actively contribute in group settings, people may see you as unengaged, or they  might  give you the benefit of the doubt and assume that you’re still paying attention. If you do contribute, though, you remove all doubt as to whether you care about being a productive team member. Ultimately, contributing to conversations is bound to make you look better, not worse.

My first project at Parse.ly was the data exporting feature (what became Dash’s “save page as” buttons). My first day was consumed by haphazardly setting up virtualenv, python, pip, mongodb, postgres, and dash on my laptop, and the assignment came on my second day (in my experience, this is a typical timeline for Parse.ly interns). The environment setup consisted mostly of Andrew guiding me through the setup processes (which were at the time alien to me) over a google hangout. When Andrew told me my assignment, it was presented as a verbal list of customer-facing requirements and a few technical pointers (for example, “try using  tablib  for converting to CSV”).

I had no idea where to start. The project was an exercise in smart google searching and lots of trial and error. It felt weird at the time to be given a project that I would have to learn a lot to complete, and the distributed nature of the development team made it even more intimidating to ask for help when I needed it. A distributed team is a great environment for seasoned engineers to collaborate asynchronously, but it leaves something to be desired for a novice developer in the  process of learning. In a non-distributed environment, I could lean over and ask another engineer to look something over or give a pointer – this becomes less natural when you’re collaborating over IRC.

As a result of the team’s geographic separation and my above-mentioned mental blocks, I learned how to figure things out for myself. I started spending more time searching online and participating in StackOverflow than I did wondering when some team member could find time to help me learn. Honestly, I think the distributed environment contributed positively to my learning, as it forced me to break out of the comfort of more experienced devs and learn to fend for myself, so to speak. If I wasn’t already an autodidact, I certainly became one around this time.

There is a lot that you can do as an incoming intern at Parse.ly to make the experience most worthwhile for yourself. Most importantly, learn how to teach yourself. Don’t let insecurity about your skills stop you from sharing your thoughts. React to intimidating projects with curiosity, not fear. Do not be afraid of  this man, he is  scarier than he looks. I mean, not as scary as he looks. He may be the most opinionated member of the Parse.ly team, but he will teach you to challenge your assumptions and defend your positions. Take every opportunity to learn bits of the codebase you’ve never seen before, in languages you’re unfamiliar with.

In short, do not let any real or perceived lack of expertise stop you from being the developer you can be. Contribute often, teach yourself whenever you can, and allow yourself to be supported by the amazing team you’re entering.

I’m more than happy to provide personal or techincal advice if you’re the target audience for this post. You can email me at emmett dot butler three 2 one at g mail dot com. (Change all number-words to digits and all “dot” to .)

Thanks to Andrew Montalenti, whose encouragement to self-reflection helped these thoughts crystallize.