Aaron Quaint
Microtalk: Working with Rubyists
Welcome to the trials and tribulations of managing a Ruby team. Let me introduce you to the characters, the challenges, the high stakes rat race. I'll share as fast as possible, what I've learned and what I failed at and why management shouldnt be an evil word.
Help us caption & translate this video!
GoRuCo 2013
00:00:16.400
Okay, I'm going to go really fast. I'm a fast talker, so everyone has to listen to me really quickly. Hey everyone!
00:00:28.320
It's hard to say this, but over the past couple of years, I've become a manager. Yeah, like this guy and like this guy. By manager, I mean a guy with a smug expression who stands in front of other people, who are kind of blurred out in the background. That's what a manager is. Oh, and when I tell people I'm a CTO or a manager, what I hear back is, 'Oh, a suit! A guy who tells people what to do and doesn't do anything himself.' I want to rid this misconception about what a manager can be.
00:00:51.440
I've had good managers in the past, and I think I'm a pretty decent one. I'm not really a manager; I'm a developer. One of the things I develop is people. That's what I do. When I started thinking about it this way, it really changed my perspective on what my job is. People are a difficult set of infinitely complicated, never-perfect, always-different problems. And you know what? Programmers are a very specific kind of people. They're not just regular people; they're crazy people.
00:01:21.280
Guess what? Out of programmers, Rubyists are a very specific kind of programmer. I myself, as a Rubyist, and other people in this room care about a different subset of things than a lot of other programmers. We care about testing, we care about beautiful code, and we care about things that are new and shiny. We want to build with them, and guess what? Working with those kinds of people is really hard.
00:02:03.119
When I started as a programmer, I graduated college, and I think a lot of people went through the same path. I started as a junior developer, working at a small shop doing CSS. They actually didn't have enough desks for us, so I sat at a printer cart. They paid me like $30,000 a year, and I thought I was making so much money! It was cool. Eventually, I started working with more people, I became a lead developer, and I went to a different job where we hired more people. I directed how the codebase went and what was going on, and then eventually, I became a manager.
00:02:43.760
To a lot of people, this progression's end is the Sarlacc pit; you do all this stuff over here, and then eventually, you fall into gloom and doom and you just can't get out. But I don't believe this is true. I'm a CTO, and to me, CTO doesn't just mean Chief Taco Officer, which is my official title; it also means Creative Technical Outlook. This is what I'm really trying to do with my team and try to bring it to the company as a whole.
00:04:03.840
One misconception about being a CTO or a manager is that you can still write code. I still write a lot of code—some really bad code! My job is to write things that other people fix. You can lead by doing, not just by saying. Here’s our main Monorail application, and I am still number one on our contributor list. I really love writing code, and I never want to stop. So, the way I do it is, even though I might not work on day-to-day features, I work with other people on features and subsets of the application.
00:04:56.240
Over the past couple of years, I've learned some important things that I might not put into practice 100% because we're not all perfect. Here are some things that I've learned: the most important one is to treat people like adults. You can have your ball pit in your office, and you can ride around on a Segway and jump into it if you want. We don't have ball pits or Segways, but that's cool. What I mean is really trusting them like adults. Trust other adults to do the right thing.
00:05:56.240
If you constantly micromanage people and don't trust them, then they're not going to trust you back, and that's pretty much how it works. Another big thing is giving and soliciting feedback. I had the pleasure, when I started working at Paperless Post, of hiring the first couple of engineers, one of whom was a man named Mike Bernstein. His full-time job is trolling me—that's what he does for a living. He gives me a lot of negative feedback, and I give him negative feedback. We give each other positive feedback too.
00:06:33.440
At Paperless Post, we actually have a system of formal reviews that we do twice a year. This gives people the feedback they need to grow because that's really what we're talking about here. We are a group of people, programmers, Rubyists, who love talking about programming. That's why we're here. Not only should we talk about programming, but we have to be willing to share our experiences.
00:07:00.200
I encourage everyone on my team to always be willing to share knowledge. This is not a competition. I don't care who the rockstar on the team is. All I care about is that everyone is growing and doing good work. The way to do that is through sharing; it's really simple. Another important aspect is setting out ideals—how you think about programming. Every team is completely different. We have a very unique team that works on an old application that's constantly growing.
00:07:53.680
We've set a group of creeds to live by. Until a couple of weeks ago, these were general things we said to each other but weren't really written down. We finally wrote them down, like 'winning is less important than helping.' I don't care if you win, just get things done! For me personally, one of the biggest takeaways is admitting when I'm wrong and learning from it. I am wrong a lot, and that's how I learn. I learn by doing. I trust my team to learn from mistakes, and I'm there to support them when they do.
00:09:41.680
So, you know, being wrong is fine as long as you create a system where it's not the worst thing you can be. You can be wrong, learn from it, and move on quickly. The bottom line is that you can be a developer and move up in this world without sacrificing the things you care about. I love solving difficult problems in meaningful and important ways, whether that's writing a Ruby or JavaScript framework or hacking together some crazy graphing system. I enjoy solving problems. It's important to remember that your day-to-day job, no matter where you work, is filled with people, and learning to work with them is the biggest challenge. People are harder than any technical problem you'll face.
00:10:21.600
Hi, my name is Aaron, though people call me AQ. I work at a company called Paperless Post, and I'm a manager. Thanks everybody!
