Support Engineering = Enlightenment

by Brittany Martin

Last week, I returned to Pittsburgh for a wedding, a baby shower and to do a tech talk at Pittsburgh's Code & Supply meetup. I was really excited about my talk because it gave me a chance to fill in the Pittsburgh startup community what I had been up to in San Francisco. 

I pitched several ideas for my talk to Justin Reese, the lead organizer of Code & Supply and we agreed on a talk around how I've been enlightened by helping others. My current position as a Rails Support Engineer has me troubleshooting networking, load balancing, firewall and online storage issues, and configuring deployment toolsets for advanced developers. 

As I promised the audience, lots of hilarious memes ensued -- kangaroo included! If you are interested in hearing my talk, Justin recorded and posted it here:

Slides are available here:

TLDR of what I've learned: 

#1 Local Production - no matter what language you code in, it is important that you know how to mimic a production environment locally. For Rails, that is $ rails s -e production. Being able to see what will happen in production will stop a lot of dev specific code from breaking prod. 

#2 Staging Server - as soon as you are taking your app seriously, please set up a staging server. It is amazing/awful how many good apps bite it when bad changes are pushed straight to production. 

#3 LMGTFY - this one is fairly straightforward. If you get an error, before you panic, Google it. A great suggestion I heard at a conference is if you Google it, don't find the answer but solve it, create an entry on Stack Overflow and solve it. That way, if it happens again, you have a public forum to refer to. Imagine all the karma you'll rack up!

#4 To PaaS or not to PaaS - when you are getting ready to deploy your app, it is important to consider whether you want a lot of control or to have your app managed for you. Once you choose which one is important to you, try not to rig it where you try to optimize both. You'll lose a lot of coding time. Choose wisely. 

#5 The Shoe Has to Fit - a lot of developers will blindly pick an infrastructure setup without doing any research into what their app needs. It's sad when an app is beautifully architected but won't run because the memory or the I/O is maxed out. Take advantage of awesome tools like New Relic, BlazeMeter or Flood IO

Am I missing anything on the list? I'd love to hear your thoughts! Big thanks to my awesome Ninefold teammates who helped me pick the lessons of the talk.