Talks

Summarized using AI

Microtalk: Working with Rubyists

Aaron Quint • June 08, 2013 • Earth

In the video titled 'Microtalk: Working with Rubyists', Aaron Quaint shares his experiences and insights about managing a team of Ruby developers. The talk addresses common misconceptions about management, especially regarding technical leaders like CTOs.

Key Points Discussed:
- Transition to Management: Aaron reflects on his journey from developer to manager, emphasizing that a manager's role should not be viewed negatively but as one that develops people rather than simply directing tasks.
- Programmer Specificities: He notes that programmers, particularly Rubyists, have unique traits and preferences, such as a focus on testing, beautiful code, and the importance of innovation in their work.
- Misconceptions About Management: He challenges the stereotype of managers as out-of-touch figures, advocating for a model of management that involves active collaboration and code-writing alongside team members.
- Trust and Autonomy: Aaron highlights the importance of treating team members like adults, fostering an environment of trust rather than micromanagement. This encourages professional growth and respect among team members.
- Feedback Culture: The practice of giving and receiving feedback is important for team development. Aaron shares personal experiences of feedback with his colleagues, reinforcing that it should be a two-way street.
- Knowledge Sharing: He encourages a culture of sharing knowledge within the team, refuting the notion of competition among team members and emphasizing collective growth.
- Team Ideals: Setting shared values or creeds is vital for team coherence, which fosters an understanding of priorities and work ethics among team members.
- Learning from Mistakes: Aaron asserts that being wrong is part of the learning process and encourages creating a safe environment for team members to make mistakes and learn from them without fear.
- Balancing Roles: He concludes that it is possible to be a developer while advancing in a managerial role, advocating for a blend of technical and managerial skills without sacrificing passion for programming.

Overall, Aaron’s talk emphasizes that the biggest challenges in the tech industry often relate to interpersonal dynamics rather than technical issues, and successful management hinges on empathy, trust, and collaboration.

Microtalk: Working with Rubyists
Aaron Quint • June 08, 2013 • Earth

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!

http://amara.org/v/FG95/

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!
Explore all talks recorded at GORUCO 2013
+6