Flickr / Michael Valli Photography
Sasha Laundy recently reached out to me as part of a new project she's working on (I'll share more when it's public! :). She was curious if I'd seen any good tech talks recently, and if I'd be willing to share them with a larger audience along with why I thought they were great.
Although I do listen to a fair amount of tech talks (usually on 2x speed in the background while I'm working on tasks that requite little cognitive overhead), I've recently been more interested in technical/engineering management talks than talks about specific programming languages, frameworks or constructs.
I chose these talks not only because the speakers are excellent and very compelling, but they touch on a couple themes I have been thinking about recently.
general themes in these talks
- Hiring is really hard. Let me clue you into a secret: hiring is hard regardless if you're hiring engineers or sales people or community managers or executives. Across all the organizations I am involved with (large and small, for-profit and not-for-profit) hiring is the #1 priority and the #1 challenge.
For engineering specific hiring, keep in mind: you’re not hiring a “Rails Engineer” or a “Python Programmer” - you’re hiring someone who can help you change the world. It is very important to communicate the opportunity and the unique challenges of the job you're hiring for, not just describe a set of prerequisite skills the person should have. Raffi describes the unique scaling challenges on the Twitter platform team and how he communicated those to candidates. Harper and Dylan also touch on this when they were recruiting and hiring for the 2012 Obama for America Campaign.
- Rewriting systems is really hard. We believe we are going to replace our old Honda with a Tesla (so much improved! better than we ever could have imagined!) and this often ends in disaster.
As someone who has gutted and rewrote several production systems (all many magnitudes smaller than Twitter and Rent the Runway) not only was redesigning the architecture difficult, but what proved just as tricky was designing the database schema (which requires thinking through data access patterns in your new application that no one yet uses), how to migrate all the data to the new schema and how to verify that it actually worked.
Successful system rewrites require an incremental approach that takes months/years and often runs way over schedule. Both Raffi and Camille discuss rewriting Twitter and Rent the Runway respectively, not only from a technical perspective but a cultural and management perspective as well.
Without further ado, my favorite engineering management talks of 2014!
Two Developers, Many Lines of Code, and A Campaign that Made History
Harper Reed (CTO of Obama for America, now CEO of Modest) and Dylan Richard (Director of Eng of Obama for America, now CTO of Modest)
- 30 min talk + questions
- From an cultural perspective, Harper and Dylan were working at the intersection of two very different worlds: US politics/presidential campaigns and the technology/startup world of building highly scalable, fault tolerant systems.
- Harper speaks during the first half in an overview of the technology and process behind the 2012 Obama for America Campaign from how they recruited engineers to how they designed their technical infrastructure.
- Dylan then goes over Modest’s interview process (taking lessons learned from the campaign). He gives several tips around how they ensure they don't just hire "people who look like them." I found this very valuable as I am changing and refining our recruitment process in real time.
So You Want To Rewrite That
Camille Fournier (CTO of Rent the Runway)
- 42 min talk
- She focuses on rewrites within startups. This isn't a talk about rewriting very old, legacy software within large organizations, although in my opinion the lessons could be applied to rewrites of any size.
- This is not a talk focused on which technologies to use, but rather how to approach a rewrite (Rent the Runway went from monolithic Drupal to Java services).
- Rewrites are dangerous because:
- There are significant temptations along the way to build the Best System Ever. In other words: why build a car when you could build a plane? Why build a plane when you could build a rocketship? etc.
- It is hard to know how exactly your new system should work, what it should look like, etc. since it doesn't exist yet and has no users. You can model it off your old system, but you're rewriting that for a reason.
- If you're doing a lot of firefighting and afraid to change much then you likely don’t have time to think about the new system’s constraints. This is a very tough place to be when you’re just trying to keep the old system up (e.g. not release new features, just reduce downtime).
- Camille suggests changing as little as possible and bringing as much stability as you can to the current system. Swap out small parts, do one thing at a time.
- Also be aware of the cultural implications of a rewrite: people will be upset if you are rewriting “their baby." She does an excellent of talking about how you might approach a rewrite (and if you should even do one!).
EVERY PROBLEM IS A SCALING PROBLEM
Raffi Krikorian (former VP of Engineering at Twitter, now at Uber)
- 60 min talk + questions
- Raffi gave this talk at Etsy on how scaled the Twitter platform team from a culture/hiring/management perspective (not from a nitty gritty technical perspective, although he does weave some of that into the talk).
- He joined Twitter when it was 50 people and a giant monolithic Ruby app and left when it was 3K people and split into many different services. He was in charge of the team that rewrote Twitter; they never launched the first attempt (supposed to take 3 months but took 10 months) but did launch the second.
- One of the parts I particularly enjoyed: he talks about how writing software is an art, not a science: "You can rarely be trained for the exact path you’re going to take."
- A good portion of the talk is dedicated to recruiting and hiring: don’t use outside recruiters (they make you lazy). He was always the “closer”: the last person who talks to the candidate to ensure they understand the opportunity. Again, great advice on hiring/sourcing candidates and how to convince them to join.