The Exit Interview

Blog Logo

on
05 Aug 2014

read

One week ago today, I started teaching Ruby on Rails at The Iron Yard. Three days before that was my last day at Emcien. It’s been a whirlwind and I’ve barely had time to catch my breath, but today John Saddington reminded me how important it is to take time to reflect, so I’m doing that.

Looking Back

First and foremost, my time at Emcien was absolutely amazing. It’s hard to remember now, but I started there having never committed a line of Ruby, having never written software with other people, and not altogether sure that I’d like the day-to-day business of being a professional programmer. That almost seems like a different person now. I couldn’t have asked for better people to learn from or more interesting problems to tackle.

It’s impossible to distill down everything that I’ll take away from that experience. But here are a few of the most important -

Coding Is a Social Activity

It’s all about communication. In the scheme of things, telling the computer what you want is the easy part. Good code should clearly communicate its intent, so that people reading it later (the team after you’re gone, you in six months, or whoever) can quickly and unambiguously discern what’s happening and fix or change it with minimal fuss. Outside of code, developers need to be able to interface with product owners to nail down requirements and options - all the better if that’s an easy two-way dialogue.

Always Be Learning

One consistent piece of feedback that I got from management was that they were “never afraid to throw me at a new problem” to see what I’d come up with. That just seems silly to me - “Would you be willing to play with this bright new shiny thing?” “Uh, yes please”. This doesn’t mean you have to have a second full-time job of hacking on new stuff after work (but it doesn’t hurt if you love it enough to do so). It does mean not being afraid to roll up your sleeves and dig into (and probably break) a system that you’re unfamiliar with.

Hire Good People, Get Out of Their Way

As developers, our job is solving problems (with code, but that’s largely incidental). It’s a waste of time for management to prescribe solutions, and the work would be stultifying if they did. I was lucky enough to have some incredible management - you should see what a team of talented people can accomplish together when they are informed about a problem and then let loose to solve it.

Moving Forward

I accepted a position at The Iron Yard for a few different reasons. In part, I love mentoring - there’s nothing quite as rewarding. In part, I was hugely impressed by the people and culture they’re building. In part, I think that you don’t really understand something until you can explain it simply. I hope to be able to explain software simply one day.

Ultimately, we are moving into a world where “everyone should code”, where everything is online. I can envision a future wherein technical literacy is as important as literal literacy has been in the past. As a profession, we have to figure out how to build our systems[1] in ways that are accessible to outsiders and neophytes; as a society, we have to figure out how to teach people the skills that will matter. I’d like to think I’m in a good position to do both.

If you happen to be one of those neophytes (hello, students), I think these are my biggest takeaways to keep in mind as you take your first steps into this world -

Get Used to Being Lost

I started at Emcien having never done any Ruby (coming over from Python / Django). You had better believe I felt overwhelmed getting started. But - as with any new concept - you bite off a small piece, you work until you understand that, and keep chipping away. Don’t be afraid to fail; every error message is a learning opportunity.

Ultimately - especially as a junior dev - you won’t be hired for what you know. I’d take a co-worker who was excited to code, quick to learn, and easy to work with over one who can recite the Rails guides any day. That’s what Google and Stack Overflow are there for.

Collaborate and Listen

If you haven’t worked on a team before, start now. Start yesterday. You’ll learn so much more from other people (even little stuff - editor setup, keyboard shortcuts) than you will from years of self-study. You can also skip hours of pounding your head against a wall by just asking the right person the right question. I wish I had done this so much sooner.

If you don’t have a group around you to code with, you have options: check out Code Triage for projects in need of help; go to a Hackathon and make a difference; check out a Meetup and make some friends.

We live in very interesting times, and I don’t claim to have all the answers. But for my part, I’ll keep learning.

1. I think Haskell’s type system is on to something here. I recently wrote a Worker monad analogous to Yesod’s Handler monad, barely understanding what I was doing, and the type system just would not let me make a mistake.↩