The Frontside Podcast

In this episode, Sarah Mei, founder of RailsBridge, Director of Ruby Central, and Chief Consultant of DevMynd Software, talks about the way we write software: What’s right? What’s wrong? How can we do better?

The conversation examines changing code and reassessing needs. i.e.: "Does it bring me joy? Should I get rid of this thing? Do I understand this code?" She also talks about what these needs mean for others on a team.

Sarah Mei:

Links:

Transcript:

CHARLES: Welcome to the Frontside Podcast. I am Charles Lowell and with me is Robert DeLuca. We have a very special guest this week. One that I'm really excited about because the things she says and the ideas that she has - open eyes and minds all over the place, in all different types of areas that are so pertinent to the way we do our jobs. So, we'll get to it. Our guest today is Sarah Mei.

SARAH: Hi. Thanks for having me.

CHARLES: Like I said, we are super excited to have you here. Before we get started talking about some of the things that you've been thinking about recently, why don't you just give like a very brief introduction of how you got started with development, where you've been, and how has that brought you to where you're going right now?

SARAH: You know, I actually was not one of these people that got started with it real early. I came to programming in college. I was an Engineering major. I wanted to build bridges. I wanted to be a Structural Engineer. I want to build things. I had a weird schedule the first couple of quarters of college, so I ended up taking an elective earlier than most people take it. It was a programming class in Fortran that was required for the structural engineering program. I took my class and I was like, "This is really cool."

CHARLES: Wait, Fortran is what set the hook?

SARAH: Yeah, and the professor of the class was like, "Well, if you think Fortran is cool. I've got some other stuff that you might like." I mean, the language and whatever doesn't really matter. What I liked about it was the fact that I could build something. I can get that same feeling of building something that you get if you build a bridge but you can do more than like one or two in your career, like you do if you're a structural engineer. I like the constant feeling of building. That's what I liked about it.

So I ended up switching my major and graduating with the CS degree and coming out and doing a bunch of different things, mostly like starting in a large company and sort of doing smaller and smaller companies over time.

CHARLES: Yeah, there's a lot of people in the industry who are career switchers, where they started out in something else and moved into Computer Science but I actually feel that a lot of people, like myself included, I have the degree in CS too, but that was not what I set out to do at all. It totally derailed, like the course of my life in a good way. But in that way, it’s like a career switch within a career switch.

ROBERT: I'm a little odd in that aspect. I came out of high school like ready to go in software. It worries me a little bit for the later half of my life. I'm like, "Oh, am I going to do software for the entire time?"

CHARLES: Probably not.

SARAH: That might be a good thing. You'll never know.

ROBERT: Yeah.

CHARLES: Yeah, seriously, what lies ahead?

ROBERT: Who knows?

SARAH: I feel like in a lot of places that are like, for example, in public policy and in other places where we need more people that understand tech so if we can send you out into other parts of the world knowing a whole lot about programming, that can only be good.

CHARLES: Yeah.

ROBERT: Yeah, this is actually kind of funny. I was telling CHARLES about this the other days, like I'm starting to view programming more as a tool to do the things that I really want to do and less as like the thing that I'm going to be doing forever. I wanted to augment and make things that I have a passion about easier.

SARAH: Yeah, absolutely.

CHARLES: Yeah, it's like software is eating the world so what you're doing now is just learning how to chew.

ROBERT: That's a great way to put it.

SARAH: You should tweet that.

[Laughter]

CHARLES: All right. Please continue. I'll ignore the typing sounds.

SARAH: [Laughs] Switching careers is a really interesting thing because you end up with a bunch of experience that you wouldn't have had otherwise. I'm really excited actually about the next five years as we have all these folks that switched into programming from something else who are all becoming mid to senior level because they're bringing just such amazing experience from other parts of the world.

CHARLES: Yeah, I know, right? It's like, "Where've you guys been my whole career?"

SARAH: Right.

CHARLES: It's like you understand these things, just almost like it's second nature of these things that are opaque and completely inaccessible to me. So anyhow...

SARAH: That's how I got here.

CHARLES: So then, after you kind of switched in college, you went out and did you just start working in programming immediately thereafter?

SARAH: Yeah, I worked in a bunch of different product companies. I built products for a while. My first job actually out of college was at Microsoft up in Redmond and then I have worked at smaller and smaller and smaller companies. Then I spent about 10 years doing product stuff and then about 10 years ago, I switched into doing consulting mostly because I realized that I have a fairly short attention span for projects. And that working on a product, there wasn't anything wrong with me exactly but what would happen is when I was working with a product, I would get six months to a year into it and I'm starting to get antsy. I started to get bored and decided that I should just embrace that. And I switch to something where I am going to be on a new project every three to six months. I've been a lot happier since then.

ROBERT: That's interesting. I wonder if that comes with seniority in software development and knowing your way around because consulting for me is I've gotten the experience of, "Oh, wow, I'm just finally getting a hang of this person's product or this client's product or app or whatever we're building," and it's, "All right. It's time to rotate off." It's like you just get in there and understanding everything.

SARAH: There is that aspect of it for sure but even when I was much less experienced, even with my first couple of jobs, I noticed this tendency in myself to just get bored after six months on the same code base. For a long time, I thought it was because I'm not cut out for software or maybe I'm not very good at it or something. Eventually, I just realized now actually, it's just that I just need to switch projects. I'm just one of those people. That's how my brain works.

I get a lot out of switching projects because the one that I switch on to, I see an entirely different way of doing things like code bases are so different. Even if you look at a hundred different Rails apps or a hundred different Ember apps, they're all so different. So switching on to somebody else's app, I learned a ton just out of that switching process.

CHARLES: It sounds like the actual kind of studying the meta-level of the software is what really engages you and kind of understanding how the software came to be the way it is and not some other way. One of the factors that gave rise to that and kind of 'that's the problem' that really sunk its teeth in you, as opposed to individual business problem. Is that fair to say?

SARAH: It has certainly been interesting to see different business problems and to understand different parts of industries and so on. That's definitely part of it for me but what really gets me interested is the different ways that people organize their code and by how they make the decisions that they make.

ROBERT: Yeah, you get to see different problems that they've maybe put themselves into because of the way they structured something, which you wouldn't see if you wrote yourself but somebody else did and get to see, "Oh, I understand this pattern now." That's kind of been my experience out of it. I don't want to speak for you, but yeah, that's kind of how I've seen other client projects like, "Oh, this is really cool. I didn't think of a way to do this," and you get to experience many different things in many different ways.

SARAH: You get to see a lot of the tradeoffs. Like a lot of times in a single code base, what would happen is I'd make a decision or we'd make a design decision of some kind. Then I'd see how it turned out. But there's no way for me to see how it would have turned out if I did it the other way.

The nice thing about switching projects for me is just being able to see all of those tradeoffs, like the tradeoffs that you make tend to be pretty similar. You can see very similar situations where people do different things and how does it turn out for them.

ROBERT: Right, and like one of my favorite things is where you go into a project that is totally against something, like for me it was object-oriented CSS and then you go in and you actually see it in practice, and you're like, "Oh, wow. This is turning a whole new light on it. I like this in this case."

SARAH: Microservices are like that for me, where it's generally I am anti the microservice bandwagon. But then I went on one project where I was like, "Wow, they actually figured it out. This works really well. I can see why people like it," because I've seen so many work that was horribly executed. When you go on to the one where it's good and you're like, "Oh, this is why people do that. Okay."

ROBERT: Yeah, it's like that light-bulb click, "Oh, yep. There’s another side of this."

CHARLES: Once you actually see it done right, it helps you avoid every other situation where it was done wrong and you can say, "Oh, this this was the one differentiator that made it all go right." I mean, sometimes it doesn't always boil down to that. But there's these one, two, three things that we could have done. But they were just completely and totally hidden from you because you didn't have that context.

I would love to talk to you about microservices because I've certainly never seen it done right. I've heard it talked about and I've seen this beautiful world, picture-painted that looks so fantastic on the whiteboard. But I see --

SARAH: Oh, it's so beautiful, isn't it? It's like an object-oriented design diagram. I'm like, "Look at all the boxes and lines. They all line up."

CHARLES: "They're beautiful."

SARAH: "I can do this in Visio," and they're all like, the line, they are on the same shape. It was great.

CHARLES: "And when I move this one over there, it just tells me that these two are exactly the same distance apart from that other one." Ah, so satisfying.

SARAH: Yeah, and then you try and do it, is the problem.

ROBERT: Then you build it and you cross your errors and everything.

CHARLES: Which actually I think that brings us, recently -- we're talking on Twitter. I think that's actually very recently about kind of the difference between when we talk about software and the meta conversations we have around it. When we do talk about these abstract and perfect worlds of boxes and lines versus the actual code bases, which is the things that you’ve kind of been observing many, many, many since you've started consulting, and kind of the vibe between those and you know what that means. I think a lot of people aren’t even aware like I certainly, before kind of reading that, wasn't really aware that that is a very, very distinct difference, like these are two very different modes for software. One that exists and one that is kind of perfect world.

ROBERT: Kind of academia versus the real world, I guess.

SARAH: In some ways, yeah. I remember when I was in college, we had a software design class as part of our degree program. We studied how you define objects and you write a little bit of [inaudible], like we did all this stuff. When I got out and I got into the real world and I had a job, I found it very difficult to actually apply that stuff successfully, to be able to draw a diagram and then turn it into code and have it work out the way that the diagram said it was supposed to work out. I initially thought that was because I was just not experienced enough to figure it out.

But eventually, what I realized is that it doesn't work because it doesn't work. It really doesn't work to design things ahead of time and then just do them. I think there might be a certain type of person that can do that. I am not that type of person and most people aren't. I think that it takes a very unusual type of brain to be able to just draw a diagram that has already taken into account all of the things you're going to encounter once you start making it.

CHARLES: Yeah, I would even go so far as to say there's probably a brain that solved that problem many, many times, that just could skip a bunch of steps.

SARAH: Right, and they're not aware they're skipping them necessarily. Unless you have an entire team full of that type of brain, it’s probably not a good idea in general, for the software that you're building as a group.

I feel like I've been trying to talk about that concept between the difference of how we talked about software in books, in blogs, and in conference talks and then how we build the software we actually build. I feel like I've been trying to articulate that for 20 years, like since I have my [inaudible] and I was like, "This doesn't work. Why can't I make a diagram and then make it into code?"

Like two days ago, I feel like I finally found a way to articulate it that captures everything that I've been trying to communicate and it was a really strange feeling. I'm like, "Wow, I finally kind of got it." One of the reasons that I came up with that, I think, is because I haven't really been thinking about it for a couple of months. I've been off and not really thinking about software stuff for a while.

There’s actually some interesting problems there like, "How do I make sure that all of the stuff that I need is at hand that I use all the time? All stuff that I need occasionally is still around and accessible, and then things that I don't use, I should probably just get rid of." I have this problem that I think probably a lot of people have which is that I have trouble getting rid of stuff once I have it. I live in a small apartment in San Francisco and that's not a good thing to be able to unable to get rid of things because in an apartment this size, I can let it go for a week or two maybe, but like I got to be very vigilant about it because otherwise, it just overwhelms the space.

CHARLES: Yeah, there's a bunch of research that the people estimate vastly different the cost of acquisition versus the cost of loss, and they’ve [inaudible] way too much, like irrationally unbalanced like not wanting to lose something that they already have.

SARAH: Even if I bought it for a need that I don't have any more or the need has changed or shifted. I don't buy things I don't need. There are some people that have that problem, that they buy a bunch of stuff that they don't have any particular plans for it. I don't have that problem, thankfully. I've had people in my family that have that problem which I think is why I have avoided that.

But the problem I have is that once something is here, I find it very difficult to get rid of it. I look at it and I'm like, "I can think of all these reasons why I shouldn't get rid of it." Oh, that was expensive so the sunk cost fallacy of like, "Oh, I paid a lot of money for that even if it's not useful and I don't like it, I shouldn't get rid of it." Or, there'll be like a dress in my closet that I haven't worn for two years and I'm like, "Ah, maybe I should get rid of it," and I take it out and I'm like, "Oh, my God. But it looks really good on me. I like it. I should wear this. I should really wear this." So I'm going to keep it even though I haven't worn in for two years for some reason, but I should keep it anyway because it looks good. I have all these stories. I tell myself about why I can't get rid of things.

A couple of weeks ago, I read a part of a book, to be totally honest with you, called The Life-Changing Magic of Tidying Up. It's written by this woman from Japan who's a professional organizer. Her name is Marie Kondo and her method is called KonMari. Basically, what it does is when you're trying to figure out whether you should get rid of something, you don't ask yourself, "Should I keep it?" What you ask yourself is, "Does this thing bring me joy? And if it brings me joy, then I keep it. If it doesn't, then I'm going to get rid of it."

So that made it really easy, going back to the dress example. I'm like, "Does this dress give me joy?" And I thought about it, I was like, "No, the reason I don't wear it is because I went out to dinner and I had a bad experience at dinner so every time I look at that dress, it reminds me of that experience." And so it looks good and everything but I'm not going to wear it because it doesn't make me happy. So that was just like, "Okay, fine. I'm just going to give it away." And changing that question that I ask away from 'should I keep it' towards 'how does that make me feel' was a huge change for me because it's like, that's really easy to answer, where 'should I keep it' is a much harder question. There's these bunch of sort of ifs and maybes or what-ifs and what happens. I feel like that applying this KonMari question to stuff has changed the way that I calculate what stays and what goes in a very positive way.

CHARLES: Yeah, boy, I need to get this book for several family members who will go [inaudible].

SARAH: Well, you know, I've got two kids and so there's a constant flow of stuff coming into the house. Because of the amount of space I have, there has to be a constant stuff going out. So this is something I just need to be very vigilant about and this has made it so that it takes up a lot less of my time and a lot less of my brain space, which is really awesome. It feels like it's moving my house in the right direction.

I've been thinking about that sort of in various ways, on and off, for a couple of months and I haven't been thinking about software. I have this fear that like, maybe that means I'm never going to think about software again. I go through these phases where I've got like, "Oh, I'm going to come up with a bunch of new ideas," where I'm coming up with new ideas for some whatever reason. Maybe I'm making new conference talks, I'm doing stuff, and I'm thinking about software a lot. Then I go through these phases where I don't do that, like I sort of retrench and maybe... I don't know. I think about other stuff for a while. So it's been home organization for several months now. I was like this, "I'm never going to think about software again," because it's just that --

[Laughter]

CHARLES: Career change.

ROBERT: Oh, man. This sounds so much like my life since I moved down to Austin.

SARAH: You know, I live in San Francisco and I'm not 25, I'm 40. A lot of it is like maybe I'm just too old for software now. I should just give up and live out the rest of my career doing quiet, maintenance work --

[Laughter]

SARAH: Somewhere. I don't know. Then suddenly, this thing happened on Monday, where I was just like, "Oh, code, an organization." And boom! There it was. I realized, I was like, "I basically just had to give my brain some time off," like my conscious brain needs some time off from software and it wasn't that it had disappeared because what I came up with on Monday was really just how home organization applies to code because I realized that the feelings that I get when I'm trying to figure out what I should do with code are very similar to the feelings that I get what I'm trying to figure out whether I should get rid of a thing. I look at this piece of code and I'm like, "Should I change this? Should I get rid of this? Should I refactor it?" You know, why I can't get rid of that? We just spent two weeks refactoring it so I can't change it again.

[Laughter]

SARAH: We just put in a story for refactoring this and we spent three days and I can't go back to the [inaudible] people and tell them, "I need to change it more." Or, "I really like this code because I wrote it with someone that I really liked."

CHARLES: So I don't want to get rid of it.

SARAH: I don’t want to get rid of it because then I would lose the memory of working with, you know.

CHARLES: I actually can say that I have experienced that.

SARAH: Yeah, there's a lot of reasons why you don't want to change code. What I was thinking about, like maybe I was asking the wrong question, in the same way that 'should I keep this' is the wrong question when you're talking about stuff. Maybe 'should I change this' is the wrong question when you're talking about code. Maybe it's sort of leading you in the same way with stuff that leads you down this conversation of reasons that don't really have anything to do with the essential quality of why the code is there or why the thing is there. We need something that helps us reassess our needs. So if our needs have changed, maybe you don't need that thing anymore because your needs have changed.

Same way with code. If your needs have changed, maybe you don't need that code anymore, at least not in the form that it's at now. I think that question for code that, "Does it bring me joy," because joy is not something that I think is concrete enough when we're talking about code. I think the question for code is do I understand this? Do I understand what it's doing? Not just understand it like a very surface level of like, "Can I figure out what this syntax means?" But understand it more like the grok level of like, I understand this at a very deep level. I understand why it's here. I understand what problem it's solving. I understand why this abstraction is necessary. I understand how it got here.

CHARLES: Yeah, how it fits into the bigger picture.

SARAH: How it fits into the bigger picture, exactly, like the application.

CHARLES: How it fits in with like our conventions that are just purely stylistic.

SARAH: How does it fit in with the other stuff that we've been doing? How does it fit in with the product needs and the features we're trying to build and the business goals and all of that stuff, all of these different levels of understanding of why this code is here and what it does?

CHARLES: Do other team members' understanding factor into that? Like, "Do I understand the way that other people understand it," so to speak?

SARAH: I think that it can. But I think the important thing is whether you personally understand it.

CHARLES: Okay, like it's a very personal decision.

SARAH: I think it is. Hopefully, what you do is you want different people looking at the same code. You don't want just one person on a piece of code that no one else ever sees, whether it's pairing or code review or whether it's something else. It need to be really clear to someone is coming in and looking at that code what it does, what it means, and why it's there?

CHARLES: Right. I guess the reason I asked the question is because a lot of times when I look at a piece of code, I try and really step outside of myself and say, "What will someone else think who has never been on this project before?" Or, "Who is on this project and they see this code, will they understand it?"

SARAH: Absolutely. It's definitely a part of it when you're on a team.

CHARLES: Yeah, so I'm just trying to figure out how that question factors into this framework.

SARAH: I think that it depends a lot on how you distribute tasks. For example, if you work in a shop where you're pair programming most of the time, so there's always two people looking at a piece of code, 'do I understand this' is a reasonable question just for the two of you to consider, both from the fact that you can pool your knowledge but also from the fact that 'are there pieces of this that you understand that I don't understand' and vice versa.

On the other hand, if you work in a shop where it's more like, "Here's the piece of code that you work on like you own this section of code." Then I think it's more important for you to be able to step outside and be like, "Okay, do I understand this? Would other people on my team understand this?" That can be a very difficult thing to assess and that's where I think it's very helpful to do things like code reviews, call people in and be like, "Hey, can I run some stuff by you. I'm trying to figure out if this is good or not," because what you want is you want a code base that is comfortable and understandable for you and for your team.

Just like the thing that makes the KonMari Method powerful for stuff is that it doesn't tell you what you're going to end up with. It doesn't tell you what level of clutter versus cleanliness is good for you. It doesn't tell you. You either end up like something in one of these simple living magazines or end up something like Quarters, the TV show. There's a bunch of places in the middle, they're all fine. Everyone's going to fall somewhere differently along that line.

So I've managed now that I've thought about this a lot to set up my kitchen in a way that is very comfortable for me, like I know where things are, I can find them really easily, things that I use are at hand. But other people come in, they're just like, "I have no idea where everything is," like it's very personal. The organizational system you end up with [inaudible] that you have is a very personal thing and that's why, if you look at something like staged houses, so you're selling your house, you hire someone to put in rugs and furniture and stuff and make it look like somebody lives there so that people can walk in and sort of imagine themselves in this space, they don't put any of that clutter into the stage. They don't put any books on the coffee table except the big picture books. They don't leave the remote controls on the couch. There’s no plunger by the toilet. There's no like --

CHARLES: There's no Legos on the floor.

ROBERT: Everything that looks good.

SARAH: Everything that makes it more personal, they leave out because it looks like somebody else's mess. You go into something like that and you're like, "This is not my mess. This is somebody else's mess. It can't possibly be my house and I'm not going to buy it.

ROBERT: Oh, do we do this for software in conference talks and posts?

SARAH: Absolutely, we do. That's sounds very similar when you get someone new onto a project, especially if they're more senior and they'll walk in and be like this, I can't live like this.

[Laughter]

SARAH: This is somebody else's mess and clearly we need to make some changes. But that's the reason why they leave it out of the staged houses is because you want people to be able to imagine their own level of clutter and disorganization that superimposed on the skeleton. But real life is not that. Real life is somewhere between that and hoarders.

There’s a very interesting parallel there with code, which is like when we look at code, if we look at the object-oriented design textbooks, you look at conference talks, you look at blog post, sample code, it's all very staged house. It's very uncomplicated. It has no clutter in it and that's because you're supposed to be able to look at that.

CHARLES: I mean, that clutter can distract the sales process so to speak.

SARAH: Exactly, like they have an idea they're trying to get across and the clutter would distract people from the idea. But the problem there is the same with the staged house which it's very difficult to tell what it will be like once you move in. It's very difficult to take some of these ideas that you see demonstrated in these staged environments and take them and apply them to your code base which is probably closer to a hoarded house than to a staged house especially if it's a code base that existed for a while over time, that has been worked on by lots of different people. This is the problem that I've noticed with a lot like there's some really amazing books about software design that have come out in the last couple of years. Of course, Sandi Metz's book is at the top of my list.

But the thing that people have trouble with, like they love the book. They love the book. I love the book. But then they find it very difficult to apply those principles when they sit down in front of a code base that has already been worked on for six or seven years, in some cases by maybe 50 different people, who knows, over time. How do you take those principles and start applying them in a way that moves you in the right direction? That’s where people are just like, "I can't do this. I can't do this and I'm not going to do this." And it's very similar to a problem where you've got a very dirty house and you don't know where to start in order to move it towards something from the Simple Living magazines or are more like a staged house, you don't know how to start to get it in that direction and so you just kind of give up.

The powerful thing about KonMari is that it doesn't give you like, "Here's what you're going to end up with it," but it gives you a way to get started on something that gives you a very easy question to answer. It moves you in the right direction. It moves your house in the right direction without being overly prescriptive about what you'll end up with.

CHARLES: Yeah, what that direction even is.

SARAH: What you'll end up with is personal for you, anyway. I think the question about 'do I understand this code' is similarly helpful and that it moves you and your code base in the right direction without necessarily giving you a lot of prescription about how you do it or where it goes or even where it's going to end up. It just gives you a question to ask that it tells you whether or not this code needs to change and a question is, "Do I understand it?" If I don't, it should probably change, and if I do, okay, we can just kind of leave it for now.

CHARLES: So now, if you're working on a team where you have two different people, maybe different skill levels, maybe just a different temperament or different set of preferences, what do you do when the answer to that question is two different things for two different people?

SARAH: Well, sort of like when you move in with someone. This is the hard part about living with somebody else, is that you have to mutually agree upon a method of keeping your house that is agreeable to both of you. Sometimes, when they say that working through a startup is like being married to someone, there’s some elements of that because you basically have to figure out like, "Okay, we're going to live in this code together. If we're going to live in this code together, we better both be happy with it. How can we both be happy with it?"

It involves usually, some compromise, like I really hate doing the dishes but I don't mind cooking and vice versa. You have to figure out. It really bothers me when there's socks on the floor but I don't care if you leave dirty dishes in the sink or whatever it is. You just have to have these conversations about, "What is going to make the code livable for you?" You basically want to end up with a code base that's understandable where all parts of it are understandable to everyone on the team.

Now that's like an ideal. You're not going to get there. But that's kind of what you're going for. If you have two people in the code and you have disagreements about what is the right way to go, sometimes it can help to just be like, "Hey, I don't really understand this," versus, "I don't think this is the right decision and here's why I don't understand this."

Sometimes, reframing the question in that way can prompt them to communicate reasons that they have for doing this that they maybe weren't able to articulate before, for example. Just like when you move in with someone, you need to have sort of this commitment to finding a level of housekeeping that you're both happy with. When you're working on the team, you do have to have sort of a mutual commitment to having a code base that everyone can live in.

CHARLES: Right. I like that because having like, "I just don't understand this and here's the reason why," that being a completely totally valid answer because sometimes in a code base, where someone's brand new or maybe they're at a more junior level, they don't quite have the tools to understand it or there's a lot of steps that haven't yet taken. It's like understanding is not going to be accessible to them immediately.

SARAH: And maybe that means that's the wrong decision for that code base, is that right?

CHARLES: Right.

SARAH: Because if something is abstracting to the point that a lot of people on the team don't get it, then it's probably not the right abstraction for that code base. That abstraction might be totally appropriate in a code base in which you've got folks that are more experienced who understand why it's there, who have the scars from previous times when they didn't do it, et cetera, et cetera, and they understand why it's there.

There is sort of like intellectual understanding of like, "Yes, object-oriented design is a good thing," and then there's, I would call it almost emotional understanding of like, "Oh, yeah, there's this time that we didn't do that and that worked out badly for us."

I think that folks that don't have the sort of experiential understanding, sometimes they just need to have that. They need to get that. Sometimes, what that means is you want to let them see what happens to a certain extent. Let them see what happens when you don't do that.

CHARLES: Right. This reminds me actually, I've got three kids and the way our house is now versus the way it was seven years ago is wildly different -- the way that we live. You know, with our first child, I'm ashamed to admit it, like our strategy was just to kind of put safety locks all over everything: every cabinet, on the oven, not on the refrigerator, but just kind of 'childproof' the house so that we wouldn't have to change the way that we lived but it made the house really uncomfortable for our children. And kind of having observed that over the course of having the second and the third, there's not anything that we childproof really. We put the dangerous chemicals way up high, where only we can get them.

It's a little bit more inconvenient if we need to access the bleach but that level of discomfort is something that we live with. We've always got cups that are set out on a cabinet that sits below the counter so we've got water cups set out so that the children can get water and stuff anytime that we want, and we try, for things that they're going to need, make sure that it's accessible if you happen to be four feet shorter. That's just a condition of who you are. So it means that the actual configuration of our house, even though it's the same house, is just radically different and it is more optimized or it's optimized as a compromise for the fact that there are people living in this house now that haven't learned how to operate everything but they just need to learn that the oven is hot and you don't go there rather than slapping a lock on it.

SARAH: Your house is probably more comfortable for you as a group, right?

CHARLES: Yes.

SARAH: And what that means is that as the 'senior' in the house, it's slightly less comfortable for you in some ways but it's worth it. It's worth being less comfortable for you in order to increase comfort across the board for everyone in the household.

CHARLES: Right, because it means that if the child needs water, I don't have to stop what I'm doing to get a cup out of the cabinet and fill it for them.

SARAH: And they feel [inaudible] over the stuff in their house. They feel like they live there, like the house is for them.

CHARLES: Yes.

ROBERT: That builds comfort and confidence.

SARAH: Yeah, I think that's a very good analogy. Anytime you have a group of people living together, everyone makes compromises in order for the house to be set up in the way that's optimized for the group.

CHARLES: Yeah. "So man, how are we going to apply this to software? What's the next step? What are the concrete steps?" I guess it's just asking those questions, like asking, "Did I understand it?"

SARAH: It is asking those questions and it's also, if you are one of the more experienced folks on the team, it’s your job to elicit the answers to that from other people that are less experienced. They’re not going to tell you. A lot of times, sometimes, they may or may not feel comfortable saying that they don't understand something. So it's your job to really try and figure out like, "Do they get this at a level that is acceptable? Do they understand why this abstraction is here at an intellectual level or at an experiential level, at an emotional level? Do they get it?" Which is not something you can really just ask. In many cases, it's your job to --

CHARLES: To just observe it.

SARAH: To observe and to see how it works. If people are having a hard time understanding where things are in the code base, it could be because everything is so cluttered that you can't see anything or it could be that everything is so hidden that you can't see anything.

It’s sort of the staged house equivalent where everything is too abstracted, or is it the hoarded house equivalent where everything is just obscure and under piles of junk. Either way, no matter which direction you need to move towards the middle, the question is always, "Do I understand this?"

ROBERT: I like this a lot. I keep on coming to the analogy of if you put a chef in a different kitchen where everything is just totally rearranged and they don't know where their knives are, where their measuring cups are and stuff, I think that plays perfectly in a software of like you put somebody into a code base that they don't know, "All right, I'll figure it out." It's not their home. It's not what they're comfortable with or used to. Yeah, I think this is making my brain work on how I can apply this.

SARAH: Or if they're moving in like when you hire somebody and they 'move into your house', you need to be ready for things to change. And this is one of the reasons why I've been saying for many years in ways that I think maybe didn't quite connect as well as they could have, that really the team is the code and vice versa. Every time you add someone to the team or someone leaves the team, teams are not mutable. You get a completely new team. So, it's not like you can just sort of carry on like you did before.

Every time you get someone new onto the team, everything gets reimagined, every breakdown of responsibility, every decision. You look at it in a new way when you have someone new come on to the team. If they're going to stay, like in your chef example, if this person is moving in and this is going to be their kitchen and they're sharing it with other people, then what you're going to end up with is probably something in between what it is when they get there and what they had before. They’re going to bring in some ideas, you're going to keep some of your ideas and you're going to end up with something in the middle. The same thing has to happen with your code when you bring someone new onto the team.

CHARLES: I really like the way that this just focuses the discussion and I know that you've talked about this a lot before, whether it's a kitchen or a house, this idea of the code not being so much the shrink-wrapped product. It’s a structure, yes. It is definitely that but it's a structure that you, as people, inhabit. It protects you from certain things and it provides you certain things that you need to live.

When people ask us why is a continuous delivery pipeline so important in automating all these things for deploying your software it's because the idea is this is going to be a living thing that your team will actually be living in. And every member of that team will be living in from the time they start with the company or start with the project until the time that they exit and the time that they leave. It's the actual living process that you want to make comfortable and pleasant.

SARAH: And what comfortable and pleasant means will be different depending on who's on that team? It’s not something that you can have like a --

CHARLES: It's not.

SARAH: Right. This is why all of these things are like, "Here's how you design things." It always seemed to fall flat. I think it would be better titled like, "Here's how I did one thing once."

[Laughter]

SARAH: Or, "Here's what works for me." I feel like every conference talk that is about design could be, "Here's what works for me. I did this one thing once."

CHARLES: You might want to try it.

SARAH: You could try it. It might work for you, it might not, right?

CHARLES: Right.

SARAH: A lot of times where conference talks fall flat and blog post and everything else was why they're more like, "This is how you do it. This is the right way to do it." You're like, "Well, it certainly works for you."

[Laughter]

ROBERT: The one time I gave a conference talk, the night before I went through every slide and scrutinized it as much as I thought somebody out in the public would do it. And I think that might be where we go through in a 'stage our code'. It's like we're trying to make it perfect for somebody that might come through and scrutinize it or criticize. Because I know when I was going up to put those slides up, I wanted to make sure it was the best foot I could possibly put forward.

CHARLES: Right, we don't want to be wrong but I think that's where it actually, thinking of it as 'this is what worked for me' and this is an example from my house that worked. This is a way that I organize my code and my space. That'll not take a lot of pressure off of not having like, "I am right and I'm an authority at saying that this is the right way." That's a lot of pressure.

SARAH: I don't even like that. I try and frame a lot of the things that I talk about as like, "Here's the thing that works for me really well. Maybe it'll work for you too. Let me know."

CHARLES: Yeah.

ROBERT: Yeah, that's how I give it.

CHARLES: Up until really about two years ago, I felt like that was the expectation that was put on people is to say the right thing.

SARAH: That's true. And I think that there's a lot of teams where that is an unspoken requirement and that's something that we should examine. Because even within a team like 'here's a thing that works for me or here's a thing that worked on my last project' isn't very different from saying something like, "Well, industry best practice --"

[Laughter]

SARAH: And I think that like you get to a certain level of experience and people expect you to say things like that. In my experience, the best way to do it is 'blah'. I mean, it's not actually a super useful statement because your past experience may or may not be directly applicable to the thing you're looking at right now, no matter how experienced you are. I think that it's much more friendly to have a range of experience levels to say things like, "Well, this worked for me on this project. Let's talk about whether it could work here."

CHARLES: Right, yeah.

ROBERT: I really like that.

CHARLES: I do. It’s so hard because your human nature is to try and boil things down into a simple binary.

SARAH: People would love to have a list of rules, I'll tell you that. This is a problem. This is one of the reasons why I think it's important for us to come up with these questions that you can ask that will move you in the right direction without giving you rules, that will move you in the direction of finding the rules that work for you. Because rules themselves, people really, really, really want them. But they're always misused. They’re always misunderstood and what you really need are the questions that led you to those rules in the first place. That's what people really want, although maybe that's not what they are asked.

ROBERT: Ah, the Steve Jobs approach.

SARAH: [Inaudible] to start wearing black turtlenecks. I hate turtlenecks.

ROBERT: And New Balance shoes and the jeans.

[Laughter]

SARAH: But yeah. I think it's one of those things where people are very hungry for guidance. But we've been giving them the wrong kind of guidance. We’ve been trying to give them rules. When what we really need to do is give them questions to help them develop their own judgment.

ROBERT: Right. Like when I was coming up, I thought, in everything, there was a right way to do it and a wrong way to do it. I've been slowly, sadly figuring out that it's not all black and white and it's not all just logic. I've always treated programming as like, "Well, they wrote this and it's just logic so I should be able to understand this."

It's been a long road to come to this conclusion that kind of like what you're talking about and this has been enlightening for me. Like you are going to solve your problems your own way, your own person, and you'll think about things differently. I really like the analogy of 'this is your house and this is how you work and live in your house'.

SARAH: Right, and no one would tell you in order to be a proper human being, you have to set up your house this way.

ROBERT: Exactly.

SARAH: We feel comfortable telling people, in order to be a professional developer, you need to set up your code this way. I think that those are very similar statements and we should really examine a lot of these 'should' statements that are all over the place when you're talking about software.

Think about whether or not they're actually serving us in our mission of doing more things with tech. Like overall, my mission here is for people to be more effective with code so that we can do more interesting things with it. I live in the TV show, Silicon Valley, essentially so I'm surrounded by these companies that are solving these little tiny problems and I'm tired of it. I want us to solve bigger ones.

In order to do that, we need to get better at coding. We need to get better at managing code over time and that's what I'm trying to do.

CHARLES: Because it's not going to scale, otherwise. We’re out of time. We’re going to have to have you on the podcast again because I don't think we've got to... what? About 15% of the things that we want to talk about?

SARAH: Oh, we are overtime, aren't we?

CHARLES: Yeah. But thank you so much, Sarah, for coming on and talking with everybody. You drop real quick your Twitter handle so that if people want to have follow on discussion, they can reach out to you that way, or your other preferred means of contact.

SARAH: Yeah, Twitter is probably the best. My Twitter is @sarahmei, and that's mostly where I am.

CHARLES: All right. Well, fantastic. As always, feel free to reach out to us too. I'm @cowboyd on Twitter. And what are you, Rob?

ROBERT: @robdel12.

CHARLES: All right. It’s a wrap. Thank you so much, Sarah, and we'll see you in Ether and hopefully we'll have you on the podcast again sometime.

In this episode, LaToya Allen, developer at Big Cartel and founder of SheNomads talks about apprenticeship and mentoring, finding community while working remotely, how companies can be more inclusive for hiring women and people of diverse backgrounds in technology, and avoiding burnout and maintaining balance.

LaToya Allen:

Links:

Resources:

Transcript:

BRANDON: Hello everybody and welcome to Episode 44 of the Frontside Podcast. I'm your host Brandon Hays and I help run the Frontside.

STEPHANIE: Hello, I'm Stephanie Riera and I am a developer at the Frontside.

BRANDON: Awesome. And we have a special guest today, LaToya Allen. So you're a developer at Big Cartel, is that right?

LATOYA: That is correct, yes.

BRANDON: Cool. We wanted to talk a little with you today about your day job, your work with SheNomads, your recent blog post about inclusivity and how you balance all that stuff for people. We wanted to start, if we could, by having you introduce yourself for the listeners that don’t already know you.

LATOYA: Sure, my name is LaToya. I am a software developer at Big Cartel and I'm also the founder of SheNomads.

BRANDON: Cool. We actually listen to your podcast and found out some cool stuff about you. One of the things is you used to tend bar. Would you be okay telling us a little bit about your story about how you got into software, what you did before that, and why you're doing this now?

LATOYA: Absolutely. I was bartending in Chicago, trying to figure out what I wanted to do with the rest of my life because I knew that it wasn’t staying up until 5 in the morning, making Martinis for folks even though it was fun and I do appreciate that time of my life. One day my yoga class got cancelled and I needed something to do. I ended up stumbling upon some coding tutorials and I really fell in love with it. I noticed that hours had gone by, I wasn’t bored, I really felt engaged, and it didn’t really feel like work to me. It felt like something that would be a cool hobby.

I, like many people at that time, felt that you needed a college degree to become a software developer, so I really looked at it as more of a hobby. I started going to different meet-ups in the city and I discovered that wasn’t true. And I was lucky enough to find people that are willing to help teach me when I was very early in my career.

BRANDON: Cool. And I guess the rest is history now, right? You've had a couple of jobs since then and you went through an apprenticeship program and after the apprenticeship program, you're developing lots of different kinds of software. Are there any software projects you're working on now? I know I met you at Ember Conf but you're doing less of that now. Are there any software projects now that you're fun and exciting, like what languages are you using?

LATOYA: At work, we are primarily a Rails app. I've been doing a lot of work in Rails, a little bit of JavaScript. I had the opportunity to learn Ember when I came on to Big Cartel. So, that was pretty cool.

As far as side projects, I started an open-source project for SheNomads as a way to help teach folks how to do simple things like create a pull request in GitHub or just the basics of working with Rails. But SheNomads has become an entirely different thing since I started that, so I don’t do any coding outside of work right now, unfortunately. [Laughs]

STEPHANIE: How long was your apprenticeship?

LATOYA: I was an apprentice at 8th Light in Chicago and I was there for one year as an apprentice.

LATOYA: No, when I left 8th Light, I landed a job working in FinTech for 6 months. And then after that, I went to Big Cartel and Big Cartel is actually where I learned Ember.

STEPHANIE: What was your apprenticeship experience like? Do you have any advice or anything that you think really helped you along the way?

LATOYA: I got to learn from some pretty great people such as Mike Ebert, Colin Jones, just off the top of my head. I learned from a ton of people when I was there. Ginny Hendry was also very helpful. Basically at 8th Light, they really focused on test-driven development and pair programming which test-driven development is a lot of fun and tests are great, that they're very in these days. I got to learn how to test-drive applications and languages such as Ruby, JavaScript, Clojure which is probably my favorite language that I'd never get to work in because it's not popular enough, I guess. I think I did a little bit of REST while I was there as well. And then I was working in frameworks such as Sinatra, Rails, and I worked in ClojureScript as well.

STEPHANIE: Nice. I also wanted to ask if during this journey of becoming an engineer, were there any experiences that helped shape the way that you think today? And I'm asking this because I'm curious to find out where the 'She' in SheNomads comes from. And why not just make this a very general digital nomad type thing? Why was there a focus on being a woman?

LATOYA: Because I am one. [Laughs] I'm a woman. I think that people tend to think in gender in terms of their own. So for me, it was just fair enough for all to come up with the name SheNomads.

STEPHANIE: Gotcha! Obviously, there is a difference, it seems like, in becoming an engineer when it comes to being a woman. I've participated in a lot of events and usually I have women come up to me afterwards and talk to me. And they usually tell me their experiences and how they know that they haven’t been participating. They know they haven’t been going to hackathons and other events. And I asked them why and 90% of the time, their answer is they're just intimidated. They don’t want to be the person raising their hand in a room full of guy developers and hoodies. They don’t want to be seen as the amateur or the person that doesn’t know.

So, I wanted to see how your experience was if it was similar to that or if it was any different and see if there is anything you learned along the way.

LATOYA: Look, we all know that tech has problems. I live at two different intersections in the majority of people that are in tech being I am both a woman and I am black. Being a woman – not just a woman, but being a woman of color in tech does come with its challenges. For me personally, I have never been one to shy away from raising my hand in a room or speaking up in a room. But I think that tech in a lot of ways did dole that part of my personality because I wasn’t being listened to. I wasn’t being considered.

For example, there are plenty of times where I've been in a meeting, I've been showing my code and someone else takes credit for my work. And I just don’t even bother to say anything because honestly, it’s like, "What's the point?" At that point, you just find another job. Or I've been in situations where I say something to someone about the code or about a test or about a change that we should consider and then someone who happens to be male turns around and says basically the exact same thing. And while no one really reacted to what I said, people say, "Oh, that’s such a great idea."

I have also been in meetings where people don’t even look me in the eye for the entire meeting which is very awkward when you're sitting in a room for an hour and you're the only woman in that room. And the person leading the meeting can't even bother to look you in the face.

So I think that it’s been an interesting journey. [Laughs] And don’t get me wrong, there've definitely been a lot of positives with it. But to your question, those are some of the things that I've experienced and it certainly made me aware of how women or people who live at different intersections of the majority of folks in tech get treated and how we need to do better.

STEPHANIE: Yeah. I think you and I are kind of outliers. I'm also a woman of color, I would consider, I'm a Latina. Nothing really stopped me from attending meet-ups and hackathons and I've always been very straightforward about what I know and what I don’t know. So, that’s never really been an issue for me but usually, I'd be probably one of two women out of a room of like 40 people. It's not very comforting. So that’s why I'm wondering is there anything for women that aren’t like ourselves, do you have any advice for women and for companies that want to be more inclusive, what can they do, how can they be more proactive or get over that fear or intimidation?

LATOYA: Absolutely. So, one of the first things that I tell them to do when they are thinking about getting into tech is find communities that will be supportive of you because there weren’t a lot of boot camps because Chicago was full of meet-ups. And because there were meet-ups like Chicago Women Developers, I was able to find that community [inaudible] and women were very forthright in sharing their experiences, both good and bad in tech. So, it definitely helped to prepare me a bit. [Laughs]

But also when I had bad days, when I had times where I knew I wasn’t being treated equally, it was easy to say, "You know what? I'm going to a meet-up after work because I can knock with you people." So, definitely finding a community.

STEPHANIE: Sometimes, I feel like those negative experiences where you feel like you're not being respected or you're not being treated equally, at least for myself, that was like adding wood to the fire. That just made me want to succeed more. It made me want to become a developer. It just made me more passionate. I guess for other people, it can have the opposite effect. But I feel like the best revenge is to have them see you succeed.

BRANDON: I wanted to ask kind of a follow-on question there about SheNomads. You talk about finding community being really important and you were lucky because you're in Chicago. But now, it seems like you're doing more travelling and there are other people that travel a lot. Is that where you found kind of a hole, the people that travel sort of nomadically? It can be difficult for those people to find a community. Is that where that comes from? Or what was the genesis of SheNomads?

LATOYA: SheNomads started because when I landed the job at Bog Cartel, I knew – and I discussed this when I was interviewing with them as well, so it’s very transparent. I knew for me working remote from home, that working remote from wherever I wanted home to be within reason as long as there's WiFi and espresso, I promise you I can work from there. [Laughs]

So, I started my podcast actually because I had no idea how to work remotely. I had no idea how to pack a suitcase for three months and I didn’t know how to find good co-working spaces. I didn’t want to feel isolated while I was in the road. So, it kind of evolved. I started a Facebook group for it as well and that was very helpful because for example, I was in Tel Aviv, I was there for two weeks and I didn’t know anyone and I really wanted to meet other women who worked in tech. And through the Facebook group, I was able to meet someone who ended up taking me to a co-working space that's sponsored by the government there with free food, free coffee, free WiFi where a lot of other people who happen to be digital nomads who work in tech were as well.

For me, it ended up being this thing. It ended up being like an international community but that wasn’t the intent when I started it. It's just like a lucky coincidence.

BRANDON: And so now, you're putting a retreat together around that. Can you tell us a little bit about that?

LATOYA: Yes. After I started the podcast, I started talking to them about their experiences. I knew that I wanted to really dive into it. I wanted to find a digital nomad retreat. But the thing is that the ones that I was coming across were very reflective as the tech industry as they are now. They're very young, people working for like 18-hour days and drinking beer for the rest of the time. And I looked at the attendees and it's like, "Okay, you're all men." [Laughs] And I didn’t really want this thing for a week or two in a house full of drunk 22-year old dudes. It's just not for me.

BRANDON: You don’t want to stay in the front house, huh?

LATOYA: Yeah. For me, I like my sleep, I like my yoga, I really like doing things like journaling and standing a long time. And I also enjoy what I do. So for me, I was like, "Okay, I want to be somewhere beautiful where I can have free WiFi, where I can practice yoga, and where I can talk to other people who want to work remotely but maybe want to explore a city."

So I was working for Mexico City and I happen to have found the most beautiful house just south of the park. And I was speaking to one of my friends who was a yoga instructor and she said, "Yes, I will come. I will lead morning yoga. I will lead candlelight yoga at night. We could do some [inaudible] actions of people who are into it."

And then I had been working in a co-working space in Mexico City and I told them about my idea. They offer to sponsor 30 hours for each attendee and that’s Garage Cowork, it's in Polanco which is a gorgeous neighborhood in Mexico City. And then I used to work with a friend who's now the CTO of MealSharing.com. He said, "Hey, first of all I wish I could be at this retreat." But since it's women only, we talked about MealSharing.com sponsoring an authentic Mexican cooked meal for us. So, that’s how they got involved.

BRANDON: It sounds like things kind of fell together in a way that actually is going to create an experience that, I have to imagine, you're happy with the idea of.

LATOYA: Absolutely. I'm very excited because if this already existed, someone else will be getting my money. But since it didn’t, I just said let's make this happen and I feel very lucky that it all just kind of come together very organically.

STEPHANIE: You recently had an article on Medium. I wanted to ask about that. What made you feel compelled to write this article about how companies approach what they write on their careers page?

LATOYA: I had been talking to a friend who started tech a little after I did. And we had both attended the Sandi Metz POODR workshop together which is amazing. If anyone listening to this is a Ruby dove and you want to up your skills, I would highly recommend it.

So we attended that workshop together, it was a great experience. I keep talking to women who are significantly underpaid, underappreciated, and are having all of these problems in tech. And so, I was just lying in bed on a Sunday night, working at careers pages and I was thinking about reasons that women leave tech because they keep coming in but it almost seems as if we're losing them too quickly. And I was thinking about these reasons why. I was looking at careers pages and it dawned on me that the careers pages of these companies were not very inviting and that I would not want to work on the companies based on those careers pages. Even though some of them, I knew people that worked at them and I knew that they were all about diversity and inclusion and they were paying women practically, if not the same, as what they're paying men. And I knew that they were positive work environments, so I knew that people were learning from them but the way the companies were presenting themselves was so different.

So I thought, "If I was applying for jobs," and I'm not, I'm very happy at Big Cartel and I'm very happy with what I'm doing with SheNomads but if I was, I wouldn’t apply at their company and this is why. And I just sat there that Sunday night in my bed, flipping through careers pages and I just noticed a common theme and it was that they weren’t very inviting. They seemed to think that alcohol was a bigger selling point to the people they wanted to attract than things like maternity or paternity leave.

Their pictures looked like they were trying to throw a party or something. I don’t know. It was just – I was very surprised.

STEPHANIE: Yeah, it seems to be the popular thing right now like this whole Silicon Valley vibe culture type thing. But it's interesting. I have two friends that are both recruiters for tech companies and mainly trying to find developers here in Austin. And last weekend, we were having the same conversation about how they don’t like to admit it, but they have seen over ageism and just general discrimination. How they have seen countless times people that were definitely qualified for the position but because – I think one of their examples was a young lady but she was Indian. And this company that was looking, they were all white guys and they had rejected her because she wasn’t "culture fit".

But I find that very interesting because I think, as a company, you would actually benefit from having people of all kinds of backgrounds, someone who's 20 years old to someone who's in their 50's or 60's. They must have different sets of knowledge and experiences that could benefit the grander picture.

LATOYA: You would think so, you think companies would think that way but unfortunately, a lot of people don’t. For starters, if you are a person who isn’t interested in working with women or people of color, you're going to look at a careers page in the opposite way that I would. You don’t want to work with people over the age of 35, people with brown skin, people who identifies varying genders. Those careers pages are going to attract you.

STEPHANIE: Right.

LATOYA: Which is unfortunate but that’s just the world that we live in right now, and I have had people say this to me as someone who is a woman and someone who is a person of color. But a lot of companies, unfortunately, once they have a base of all straight cisgendered males, for them it becomes a liability to bring in women or people that live at other intersections because they have to worry about things like the woman getting hit on because she's the only woman that these 30 or 40 men can look at all day which is ridiculous, I think. But at this point in time, sometimes they just say it's a culture fit thing when really this is a law-suing happen thing.

BRANDON: I saw this rag regressive 1940's thing about a woman in the workplace.

[Laughter]

BRANDON: And it's both hilarious and really sad because that actually sort of regressive feeling has just kind of morphed into that law suit type of thing. It's the same exact thing of just like breaking that sort of mono-culture and people are fearful of it because they don’t know what the consequences are going to be. That cost-benefit calculation doesn’t happen because a lot of people in tech haven’t experienced what a diverse workplace is and does and the benefits of bringing people from different backgrounds would care about different things.

And so, I'm curious. We kind of talked a little bit and one of the things I want to ask you about we already kind of covered is why people don’t do that. Why do people continue doing that if it's not that productive? I'm curious to see if there are things that you’ve seen companies do like what attracted you to Big Cartel and other companies that would be able to bring some people from different backgrounds? What are the things that companies do currently or you'd like to see them do that would make it more attractive and more inclusive?

LATOYA: I think one thing right off the bat that I noticed about Big Cartel and one thing that I noticed about many companies in tech that I'm really excited about is that they put people first. And I think that when you operate from that standpoint, you're not going to have problems that come with creating a diverse or inclusive workspace. You're not going to have women wanting to leave because you're treating them like human beings. So, that’s first and foremost.

I think some companies really care about the people that work for them. They really care about their client base, their user base. So, for me personally, I always recommend that if people aren’t happy at their current situations and they want to find something more inclusive, look for companies that put people first. That’s the first thing. I think the benefits that they offer and the way that they talk about their benefits are really important. I have no intention of being a mother; there are lots of great mothers out there and it's a lot of work in the world's best [inaudible] in my mind, anyway.

I also wouldn’t ever interview with a company that didn’t have a good maternity leave policy. It’s one of the things that I look for upfront. So, even just putting your maternity leave policy and paternity leave, if you have it, on your careers page can be a really big seller.

I think starting early on, once you have your core team in place, if you haven’t already had women or people of color or someone who isn’t like you, this may be a good time to stop and think about why that is and what you can do to pull in diverse candidates.

And there's also reaching out to communities that do have them, like SheNomads is one example of many communities that exists. There are also bigger more established communities like Girl Develop It, for example. Reach out with them, host a couple of meet-ups at your space, if you have it. If you don’t, figure out a way to work with them.

BRANDON: Right. So you're saying if you make it a top-of-mind goal, you will find ways to reach out because there are people out there looking.

LATOYA: Yeah.

BRANDON: But they may just not be in your immediate vicinity. In my experience, that’s the actual problem. The problem is that it's not in my proximity to see and know these people that are involved in these communities. And so, connecting into those communities naturally, organically, and through effort is a way that I've actually seen people grow that. That’s how you can kind of go from saying 'I care about diversity' to actually growing a diverse and inclusive workplace.

LATOYA: Absolutely. I think another thing that folks that can do is have a remote position. You get a remote culture going if it's something that you're comfortable with. I understand not everyone wants to work from home and not every company will do well having remote positions open. But if it’s something you're open to, that is a great way to do it because you might be living in an area where all the people are like you. So, you're going to have trouble getting someone to drive in a car.

So, there are two other ways that I was thinking that people can attract diverse candidates. I'm actually launching a Job Board for SheNomads. I got to the point -- it's actually once the article came out on Medium that a lot of people were emailing me wanting to know how they could find jobs and a lot of companies were emailing me wondering how they could find diverse candidates and like what they could do to be more welcoming to other communities. So I said, "You know what I'm going to do? I'm putting together a job board."

BRANDON: So where is the job board?

LATOYA: The job board you can find on SheNomads.com.

BRANDON: Cool. There are a lot of things – and this is really what I wanted to drill into was the blog post helps kind of point at the problem, "Hey, your careers page is sending messages that are actively turning away people that you want working for you. You say you want a diverse workplace but it's so far down the list of your actual priorities, or at least whoever it is that’s running your careers page, that you're actively turning people away that you don’t even realize you're losing people through that funnel that are bouncing out before you even have a chance to meet them and know them and know what they can bring to you." And so, that’s actually a really big deal and a big problem in tech.

I also appreciate your jumping in and that we have some sort of concrete things a person can do. Get involved with GDI or with Women Who Code.

We had a thing here in Austin and I ran the local Ember meet-up for several years and it's a lot of work and it was really challenging. One thing we noticed was that there were only two or so women, on the average, at a meet-up of 30 people. And I recognized it as a problem but I didn’t feel like there was anything I could do about it. And so, I handed the reins of running the meet-up over to a group of people that included the women. And sure enough, the women were like, "You know, we might be able to do something about this." Stephanie actually got involved with this, and they held an event for women and it's changed the makeup of that meet-up significantly. You can have an impact on this stuff. You just, sometimes, have to step out and think differently about the problem.

LATOYA: Yes.

BRANDON: I'd like to shift gears a little bit and talk about – you're involved in so much stuff. Running SheNomads, running retreats, you have a full-time job, you're traveling a bunch and balancing all of that stuff, I have to imagine, is really tricky. And I'd like to dive into that and have you kind of talk about like do you ever get burned out? Do you feel like giving up? What do you do to manage that? Do you have preventative maintenance that you do? What is it that you do to try to keep all that together?

LATOYA: One thing that I find very interesting is you asked me specifically about burn out because burn out is something that I recently experienced. I am not good at knowing that I'm setting myself up for burn out. I'm not even good at knowing that I'm in burn out until I'm there. For the most part, I think that I've gotten better as my tech career has evolved. So for example, when I first started, I was working a lot of hours. There were days when I had to be in the office at 7 in the morning because I was mentoring people who were in London even though I was in Chicago. So for me, there is no more of that. [Laughs]

One thing that I really like about working at Big Cartel is that most of the team is on the West Coast, so I get to do things like sleep and if I want, I can go to the gym, I can run all of my errands before I even start my work days. Once I start my work day, all of I have to do is worry about work as opposed to waking up and not having time to do nice things for myself, not having time to run errands and I'm starting my day having all of these stuff on my mind.

For me personally, working remotely allowed me to become a more balanced person as well. I don’t like riding trains with crowded people. When I was working downtown, it would take me an hour to get to work every morning. If I have to go downtown in the middle of the day, it might take me like 20 minutes or half an hour just because there's not as many people running around. Also for me, I didn’t particularly like going to the grocery store. At times, you can go to the grocery store if you have a 9 to 5 job. If I realize that I don’t have anything for dinner, I can just tell my pair, "Hey, do you mind if we take a 20 minute break?" And then I can go to the grocery store and get whatever I want, knowing that I'm the only person at the grocery store. I mean, it gets a little bit to my inner introvert but I know myself well enough.

Let's see here. Practicing yoga is something that’s very important to me and taking walks as breaks is something that’s very important to me. I think when you love what you do, it can be hard to take breaks. So, it's always nice to be pair programming with someone and have them say, "We haven’t taken a break in a while." I find that when I work on my own, I don’t take as many breaks. When I take a break, I pop my yoga mats always open. So, I'll do yoga for 10 minutes or take a nice little walk outside or just get away from my computer for a while.

BRANDON: It sounds like working remotely kind of gave you the flexibility you need to implement your own self-care regimen, the one that works for you.

LATOYA: Yes. And I would not have even thought to implement this regimen had it have not been for working remote, I think, because it's not as easy. It's bad enough being one woman amongst a hundred men but then you're that cliché woman with a pink yoga mat walking around the office trying to find some space.

BRANDON: I actually did use to work in an office that had a yoga studio on site.

LATOYA: That is so nice.

BRANDON: Things like that do exist but I have to imagine that’s about as uncommon as it gets.

LATOYA: Absolutely. I had the idea of starting a meet up which I started in Chicago called Women in Tech Wellness. Basically, we get together and we practice yoga for an hour. And then after that, there's a little bit of networking.

Luckily for me, Braintree is sponsoring the event which is so great because it allows us to keep it free. I think having free and low cost events in tech are really important because there are people that are trying to figure out how to break into this and if they have to spend $10 or $15 to go to a meet-up, they're not going to go.

Also, it's nice to go to a meet-up where you might be stressed when you show up because you just left work but you know in an hour, you're going to be feeling really good.

Plus the Braintree office in Chicago has this amazing atrium where we do the yoga. So when you're lying on your mat, you're looking straight up into the sky and you see plants and you see all of these amazing stuff. It's just a great place to do yoga. So, thank you Braintree. [Laughs]

BRANDON: I think that’s really cool. I have one question, though. Do you ever have the ironic circumstance of the things that you create to help you and other people find balance wind up actually contributing to your overall sense of being overwhelmed?

LATOYA: Oh, absolutely. There's only 24 hours in a day and right now, I am all of SheNomads at SheNomads party of one. [Laughs] I would love to get to the point where I can afford to hire a couple of people just to help even if it's part time. So, absolutely.

Doing a podcast is a lot of work, booking guests is a lot of work. I would say that organizing the meet-ups is fairly easy just because I'm lucky enough to have people that wanted to step in and help there. But yeah, I think having a few things on your plate other than work is always going to contribute to a little bit of imbalance.

BRANDON: Stepping back and looking at the arc, you haven’t been in tech for a million years but you’ve been in it long enough to start drawing some themes through it. If you look at your career like where it's been and approximately where it's going, are you starting to feel like there are some themes to the stuff that you do and some themes that are kind of common threads in it?

LATOYA: I can tell you some themes in common threads. Yes, for my personal tech career. For me, I really care about code and I really care about people, so I'm glad that I was able to early on learn clean code and learn how to refactor and learn test-driven developments.

First job I had at 8th Light taught me all those things. I think for me, that is a theme that will be throughout my career. Test-driven development, who knows, 10 years from now there could be a better way to write clean code, but for now, it's the best way I know how. And finding community, even though I am absolutely happy with where I'm working. Big Cartel does a great job at creating an inclusive space, but still I like being a part of a tech community. I know that’s not for everyone but it's something that I think I will continue to do.

BRANDON: From just my casual place of observation of seeing what you do, definitely finding and creating the communities that you want to see exist certainly seems to be a theme. And I think it's really cool that you do the SheNomads stuff. I think it's really cool that you run that podcast. For a person that hasn’t been doing this for 15 years, I think it’s really awesome that you found a community early on. It's something that certainly has accelerated my journey as a developer. I haven’t been a developer forever, either. So I appreciate seeing you do all that stuff. I think it’s a really good example for other people that getting involved can benefit everybody and you can have an impact in ways that are sort of uniquely yours. I mean, certainly the stuff that you do is sort of unique to you and your perspective and I think that’s really cool because it winds up benefiting a lot of other people.

LATOYA: Thank you. I wish I would have said that as my answer.

[Laughter]

BRANDON: It's sometimes easier to see from the outside in, even as a casual observer.

STEPHANIE: I did want to make a comment about balance. That’s something that’s very important for me. It's something that I've been trying to implement in my daily life. I recently started going to the gym and I try to work out either early in the morning or in the afternoon after work. Sometimes, I realize that even when you try to do something, you still don’t accomplish what you're trying to do like keeping that balance.

I started this about two months ago. And last week, I realized that I was not in balance at all. I spent Monday, Tuesday, and Wednesday really focused on trying to learn certain things. I was going over Clojure actions and trying to destructure and get rid of components and change the actions from where they originally were.

I'm a junior developer, so I feel like if you are an apprentice, it's really hard to not be in this state of overdrive of like you really want to accomplish things. You really want to learn as much as you can and just be a sponge and absorb everything. But if you're spending eight hours, give or take, going over these things, at the end of the day, I just feel sometimes my brain is just like it’s done. I can't even formulate sentences. I can't function. I just get home and I want to keep working on this but I just literally can't. I think on Wednesday, I just had a horrible headache and I got home and I was like, "I'm just going to lay down for a little bit." Laying down turned into a 3-hour nap and I will go [inaudible] 8:00 and I felt so much better.

And then on Thursday, when I came in, everything just made sense to me. All of the problems and everything that didn’t make sense before made sense. And I hadn’t reviewed, I hadn’t done anything, all I did was I got a nap. But I feel like there's definitely this struggle when you are wanting to achieve and prove yourself and to get to this next level, it’s really important to try to remind yourself to give yourself breaks even during the work day because if you can't continue, if you're at this point of mental fatigue, it doesn’t matter how much longer you're sitting in front of the computer, trying to read about it in the documentation, it's just not going to do anything.

So, I wanted to ask if perhaps you ever had those moments of frustration especially in the beginning as you're trying to learn all of these difficult concepts.

LATOYA: For me, yes. I love taking naps. I consider myself a professional. Luckily, Big Cartel is very flexible, so if I feel like I need a nap instead of lunch, I might take a 2-hour lunch break because I'm taking a nap. And for me, there's just something about resetting my brain through sleep that allows me to be more productive in a way that’s just walking away from my computer and doing something else.

Also, I spent two months this summer working abroad. So, I worked from the UK, Israel, Spain, Portugal, and Norway. So I worked abroad for two months and because of the time difference, I would wake up in the morning and work for three hours and then I would have all day to do whatever I wanted which primarily meant being a tourist in some of the most beautiful places, I've been very lucky to place my eyes upon. And then I would do another three or four hours pair programming at night and I think that I was able to get more done and I had a greater sense of clarity because I had such a big break. I was only working for three or four hours and that’s it and you're taking three or four break because no one else is awake yet. It’s almost as if you're working two separate days.

I think I would like to go back sometime soon, actually, and do that again because I'm not getting up at three in the morning here to work for three hours and then take a break.

STEPHANIE: Definitely. And that makes sense. It makes sense to stimulate your brain in a different way. Looking at the beautiful buildings and reading about the history and walking around and being outside. Even just a 30-minute break can just be just so wonderful and be like a refresher for the brain. Nice.

Before we go, I wanted to ask if you have any shout outs.

LATOYA: I do. I will give you three resources that I tell everyone who’s a junior developer, where they should look in to break into tech and what they should look for.

Number one, I kind of already mentioned a little bit, but Sandi Metz has a great book called POODR. She also has a POODR workshop. If you can go to that, I highly recommend it. I know that she offers scholarships for that as well, so you can apply.

Number two would Katrina Owens' Exercism. It's a great way to learn how to code. It's also an open-source project. So not only can you go to exercism.io and pick a programming language and work with people on teams to learn how to code. But if you want to contribute to the open-source project, you can.

And the third thing would be the CodeNewbie twitter chat. I love it. I really need to get my stuff together and be there on Wednesday nights. I believe it's Wednesday at 8 or 9 Central – don’t quote me on that. But those are the big three things I like to shout out, even though you only asked for one. [Laughs]

STEPHANIE: That’s perfectly fine. I was going to ask you anyway if there were any open-source projects or programs that you are involved in.

LATOYA: Yes, I have been involved in exercism in the past. I think I might have mentioned this, but I tried doing open-source project with SheNomads but I would need someone who's like at least a mid-level developer to come in and help out all of the juniors and the people that are trying to get started to learn how to code because my time is very thin these days and I'm trying to maintain some level of balance.

STEPHANIE: Right. And that’s a huge challenge too. So, lots of time management and just time is a resource itself.

BRANDON: There are a lot of mid-level developers out there that are looking for, "Hey, how can I contribute to open-source?" So, it sounds like you have a project that if people out there are looking for a way to contribute to something meaningful, then you have stuff that you could certainly use help on.

LATOYA: Absolutely. If you want to contribute, you can email me or tweet me, find me on Facebook, do whatever, and I will happily add you as a contributor to the project.

BRANDON: That actually is the last question I want to ask. How do people get a hold of you to volunteer for this or ask additional questions or find out more about the retreat?

LATOYA: The three best ways are number one, you can go to SheNomads.com and if you wanted to find out about the retreat or the job board, there are contact forms there. Number two, I am always on Twitter. You can tweet me at either accounts. My personal account is @HashtagLaToya and then I have a SheNomads account, so it's @SheNomads for that. And then the third way is email. My email is [email protected] and I always am up for answering any questions you may have.

BRANDON: Awesome. LaToya, thank you so much for coming. I really appreciate you sharing your experiences with us and you’ve certainly learned some unique things. I think your take on self-care actually is really sharp and something that people don’t think were talked about enough. And it probably [inaudible] as a developer in lot of ways and I think people can learn a lot from that.

I wanted to thank everybody else that’s listening to this. I'm Brandon Hays. I'm on Twitter also @tehviking. We are @thefrontside on Twitter. And Stephanie, you are also on Twitter, is that right?

STEPHANIE: Of course. I'm Stephanie Riera and I'm @stefriera. And thank you so much, LaToya. It was a pleasure talking to you.

BRANDON: Absolutely. Thanks everybody and thank you, LaToya. We will see you all next time.

In this episode, Leah Silber, CEO of Tilde, Inc. and Ember.js core team member talks about what she's learned building communities, organizing events, and running a business. We talk about how people can move from "observer" to "participant" and grow their own healthy communities and companies.

Links:

Transcript:

CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 43. I am Charles Lowell. I'm here with Brandon Hays, and a very, very special guest. Brandon, do you want to introduce her?

BRANDON: Yeah, we're here with Leah Silber. She runs Tilde? 'Tild’? I always say this incorrectly.

LEAH: You can't be saying it incorrectly. When we named the company, we knew we were choosing one of those names where people are going to say it and you just have to accept it. That's fate and that's how it goes. We usually say 'til-de' here.

BRANDON: Okay, I'll say Tilde, and you can say 'Frontsi-de'.

CHARLES: The way you say Tilde says more about you, than it does about us.

BRANDON: Yeah, it's a verbal Rorschach test. We were really, really glad to have your time. We know that people actually work with you as a consultant for these kinds of things to help with communities, conferences, build their businesses. So, you have a lot of gathered expertise around these things. Would you tell us a little bit about yourself, about your background, what you do and kind of how you got involved in tech and running businesses?

LEAH: Sure, not unlike an elevator pitch but I have been working in open source startups and companies, I want to say it's probably been like 10 years now or crazy something like that. But my first open source project that I was seriously involved in was jQuery, and that was a long time ago and it was pretty magical in retrospect because jQuery was, at the time, it was like coming out of nowhere. Nobody thought it was going to really make a dent in technology.

John Resig was this clearly brilliant but still this nobody, sort of working on this project in his spare time, and Yehuda Katz jumped in and a bunch of other people earlier at the beginning. It was a time in the ecosystem where they were a little bit laughed at the room. In retrospect, there was a time when the ecosystem was a little more rude, like some of the competitive behaviors that happened back then. Thankfully, it just wouldn't fly right now. But it's been super cool to be involved with something and be able to witness something at the ground floor where this little idea and project that nobody takes seriously because there are these seemingly massive projects and landscape, and then just sort of watch it take over the world.

It was a process obviously that took a little while. But again, in retrospect, it didn't take all that long, so that was really an amazing experience to watch. It was also my first really intense open source community learning experience. Everything from witnessing what kind of personalities got involved and how they did it, to watching John who sort of -- I want to say he's a consummate politician, but he's not a political person. I guess what I mean, he's just really good at people.

CHARLES: He's like a diplomat?

LEAH: He is. But like the sort of diplomat where you're in a battle and then suddenly a treaty happens and you just don't even know what happened but everybody's happy and you vaguely remember that you all hated each other a few minutes ago. He's really talented. Obviously, also having the technical chops to build something impressive helps with that. But watching how different personalities in open source interacted with each other, and even just for myself, like learning how to be a good open source citizen and learning how to contribute to a project and finding a way as a non-coder at the time to be useful in an open source project was really amazing. That was something I was involved with for a number of years. Then, slowly as time went on, I got involved in other projects and other events. And along the way, I was like, "This is really fun. Why am I working not in technology but doing this at night."

Well pretty early on, I moved out from New York to California which is, I guess, the rite of passage or at least was. Got a job at my first startup, spent a couple years there, sort of again learning everything in fast forward because that's how startups work. I've done that a couple of different times over the years, thankfully not that many. I've managed to have what I consider impressive stability in a startup land where people can end up needing to change jobs, projects and positions very rapidly.

Nowadays, I mostly focus on Ember work. There was a big chunk of time in the middle where I was focused on Ruby on Rails work. I do events, conferences, meet up groups, community management. A lot of the less glamorous stuff involved in once a project does become more successful, like figuring out a governance strategy, and figuring out how you protect your brand and what happens when lawyers and PR people and all these other different industry people start coming at you with all these questions that you hadn't thought about. How much infrastructure is too much infrastructure? What happens when the project starts having money? All these sorts of things.

I feel like I've lived through a bunch of projects and their growing pains, and have a really solid understanding of the different routes. I'm still learning every day, and that's kind of why I love it.

At some point, I realized that that's not real. There's no reason that the person who has ideas has to be more in-charge than the person who makes ideas happened, like these two skill sets, if they're not in the same person are equally necessary. I think that was probably a little bit of standard sort of impostor syndrome kind of stuff. And also, there's a lot of pressure involved in thinking about yourself as in-charge of something important with high stakes.

But I don't know. At some point, I think I watched enough people do the job and I served as that second-in-command or upper management kind of role for a lot of people. I realized that primarily, the difference between the people who were running the show as figureheads and the people who were actually running the show day to day, the difference primarily was just boldness. Like one of them had the audacity to say, "I can be in charge. I'm going to start a company. I'm going to do this." And that's not actually that big of delta so 'fake it until you make it'.

BRANDON: I kind of want to lock in on that concept a little bit. I don't want to let that just float by on the river. That is something that has been such a profound lesson in my life over the last six months or a year that I think, a lot of us that wind up running companies kind of fall into that by accident or happenstance or something. You always have this weird left over hope from times where you work for other people, that somebody will step in and be in charge.

It's a deal where everybody stands on the line and like, "Okay, whoever wants to step forward, step forward, and everybody steps back but you." And that feeling of being the last person standing when everybody else has backed, just by nature of not stepping back, you realized, "Oh, you know what --” Like there is such a thing as an operationally oriented CEO. So it really is the idea that you just said, it really is a matter of boldness and being willing to be the person, where the buck stops, is really the only difference between a person that feels like a really great second-in-command versus the person that feels like they could be running things.

LEAH: There's just this magical myth of the big important idea person. Anything that's going to be successful or most things are going to be successful I guess, they're rarely just one person sitting on a mountain. One person starts with a shred of an idea, and then everybody around them sort of helps turn it into something real. So it could really be anybody who has that first instinct that it doesn't mean that that person has to be in-charge.

CHARLES: I'm wondering, if there's any parallels there between, "Have you borrowed any of that boldness through community?" Or has there been any bouncing back and forth about lesson in terms of somebody has to take the lead on something.

LEAH: Actually, it's harder a little bit in community stuff because taking a lead typically means or we think it typically means making a decision. I think that's where in open source, a lot of people go wrong, and a lot of open source projects end up with a top down management strategy where somebody is in-charge and that person tells them what's going to happen and then everybody, for example, freaks out about backwards compatibility. Then they're like, "Oh, yeah. I got a plan for this."

But part of that is like you see a power vacuum and you think like, "Okay, I can step up and take this." But in open source, that's not really the ideal way or at least not in the philosophy of most of the projects that I've been in which is you only need to ask people what they think along the way, differently than in a professional environment.

Like in Ember, we have the RFP process where we source a feedback before we make massive changes. That just makes everything, like you can even really say, "This is the exact thing I want to do," and you can lay out a really great plan and take that leadership role. But in a framework where it's not an edict, in a framework where it's like, "Okay, now everybody else, what do you think about it? How can you improve my idea?" And there's a whole bunch of things that happen.

In open source, people won't really let that fly. You can't just say, "This is a feature set. I've made this. That's the rule." Certainly not if you want them to use your project and contribute to your project and help you be successful. There are some similar things to think about when running a company versus running an open source project. But essentially, the project has to be a significantly more collaborative environment that makes people feel invested in the project and want to stick around and want to become other contributors so that the project can grow, succeed, and have a lot of people involved rather than just one-idea person.

BRANDON: I was listening to a podcast recently that I can't remember which one it was but the people were talking about a different tech community and their definition of community really surprised me and it made me realize that people have different definitions for what a community is.

LEAH: Wildly.

BRANDON: Yeah, and so I'm curious about what your definition, in terms of an open source community, what it is and what it's job is for that open source project?

LEAH: I don't have a dictionary definition and in a lot of cases, it's kind of a feel. Like I like to talk about sometimes how the different communities I've been involved with had a different feel. In an indirect fashion, a lot of what your community is comes from the people who are theoretically in charge, be that your core team, or your benevolent dictator, or whoever sort of the thought leader. That person or people really influence the kind of community that you create with their behavior.

For example, the kind of community where the person in charge just tells you what the project is going to do next and does it, has a very different feel where the person in charge says, "Here are my thoughts. What do you guys think about it? How do you want us to do this? Do you have suggestions? Did I miss anything?"

I think if there's enough premeditation and consideration that goes into the decisions that that person makes, that he or she can really shape a positive community, a collaborative community, and a supportive community. In Ember, we have managed to collect a group of amazing people who want to help each other, want to support each other, and who are enthusiastic about what's happening, and on most good days who don't freak out when they get a little worried that something isn't happening the way they want it to because they can trust that they're going to have a period of input and their needs are going to at least be considered. You don't always get the exact thing that you want. But it's a lot better if you know that your concerns were heard, evaluated, and maybe there's some other plan or way to sort of not completely screw you, basically.

Ember's been really good at taking care of people and their needs even as the user base is more needy in different changing ways. I guess a community is a living breathing thing. For sure, it changes. I'm oftentimes sort of paying attention to the undercurrent of what happened, what's going to be the outcome of this? Having chats with people, especially people in theoretical leadership roles, about different ways to handle different situations that will keep as many people as possible, happy and supported.

BRANDON: As you were describing that, to me, it feels like you've highlighted something interesting about communities, which is, you can use a theme and not be a part of its community. Somebody could use Ember and not choose to be a part of the Ember community. But participating in a community is kind of the desire to influence that thing in some way.

LEAH: Yeah. It totally varies based on your personality. Some people just want to feel like they are a part of it. Even if they feel like their interests are well represented, you see people all the time looking for small ways to contribute because it's fun. It's exciting. There's progress happening, there's success, it’s something that isn't like a lot of other opportunities that you have especially if you've been in some other industry, or some other kind of job. You don't always have this thing where you can sort of be part of an organism and a community and watch something evolve and maybe even have input in it, or just have 40 friends around the world who want to chat with you about it at any given time. It's fun.

BRANDON: A question that I have in terms of following up on that is your role on the Ember side of things, I'm assuming and I want you to clarify if I'm not hitting it properly. My understanding of your role in the Ember ecosystem, in addition to handling a lot of the unglamorous logistical components is to help kind of grow and foster that style of community and Ember's become pretty well-known for having a unique focus on quality of community. I'm wondering if that's intentional or if there are things that you do or if it's sort of been luck. I don't know how much intentionality has gone into that or how much the community design has gone into that.

LEAH: For sure, it's mixed. There's a lot of things where select events are really good example of setting the tone. And there's like an evolution of events that I like to follow in some of my newer growing communities that I'm focusing on where you start out with a little more of a campy feel, it's a little scrappy. And slowly, you iterate to get into a much more professional feel. But all along the way at those stages, having that event, the logistically top quality really sort of changes the tone of everything.

If you show up to an event and it sort of haphazard and no one knows what's happening, you might all love each other and you probably will have a good time. But it's a different experience than one where it's sort of run like a well-oiled machine where you get a sense of people take this seriously. This is real. This is impressive. We're building big, amazing things together. We can accomplish together.

So some of it is just on all the little things. Event is just one sort of example. But all the little things that go into the well-rounded ecosystem, I try and focus on quality so that obviously, there's a whole bunch of people focusing on the quality of the code. But I also want to focus on the quality of the events and the website and helping meet ups run quality events around the world and helping people show off that they use Ember and are proud. Any sort of these peripheral things -- the better you execute them, the more of an overall, "Wow! This is real. This is serious. I can stake my professional future on this." The more of that kind of a feeling that you're going to get.

Community growth is organic in a lot of ways, obviously. But there are certainly things that you can do along the way to help foster the community growth. There's like personality things like making sure everyone's actually welcoming, and that people want to come and get to know you and work with you and get involved in your technology. There's things like the tactical processes of our RFC. Making sure there are ways for people technically to get involved. There's things like a focus on documentation, which again just makes it easy.

So, it's really an overall quality thing every step along the way, and a lot of community overlook the parts of building community that aren't code. You can do that but you end up on a different trajectory than a project where you pay attention to all the peripheral things.

CHARLES: So, I'm actually curious because I've witnessed the things that you've done like on a grand scale which definitely have had that air of quality that you're talking about. But I'm curious about these kind of nascent communities that you're talking about and kind of just, one, just curious about what they are because I'm curious. Then the second is, for people who might be speaking of doing something similarly, like starting something small that they want to grow into something huge, but actually that concrete, small scope. What are the things you can do with limited resources, if you have limited resources and you've got a small scope, what can you do to imbue it with that sense of quality that will carry you to higher places?

LEAH: I guess the first thing to think about, and I hope this does not sound bad, but is whether or not your project actually needs a community. By that I mean I certainly think open source projects should all be actual open source projects. So you should accept pull requests, you should let people file issues, you should have collaborators, etcetera.

But there have been a lot of projects along the way that I've been involved with helping with where we looked at it and said this doesn't need to be a community. This doesn't need to have a conference every year, or it'll have some sort of community right just amongst people who contribute but it doesn't need to be like Ember, like Rails. We're a whole giant ecosystem that spins up.

For example, over the years, there have been projects like Handlebars, Bandler, and Thor. These are projects that tremendous numbers of people use. You don't run into anyone who says like, "I'm a member of the Thor community." And that's perfectly fine, right? There's sort of a version of a project where you have an MVP, you have a good website, you have good docs, you have a bunch of contributors, and that's all you really need. Then there's the version where you want it to be a much bigger, more involved setup.

So one community that, I would say, in a nascent stage right now is the Rust community, which I've been peripherally involved with. I'm not on the team. I'm not doing significant community masterminding but I have been working with some people in the project to do agree with me on the value of this quality. And so, I've helped them.

We just ran Rust Conf this last weekend which was their first conference. It was 250 people in Portland. It was really, really fantastic. I've worked with them on, for example, making quality swag over the years and trying to figure out what level of control over their brand. It's not too much but still protects the brand enough, things like that.

They've also modeled some of their governance kind of stuff after the Ember community which makes sense. Yehuda is involved in both projects and he's a big proponent of a lot of that stuff. But it's been really cool to watch. Like first Rust was saying, "Oh, this how Ember does it. Let's crib some of that stuff." Now, in a lot of cases, Ember is saying, "Oh, wow! Look how Rust is doing that. Let's take that back." It's been a very good symbiotic back and forth relationship. But it really just does take the people who are leading intellectually to decide that they care about quality, to decide that they care about a collaborative community environment, to decide that they care about diversity, to decide that they care about all of these little things along the way. The earlier people recognize that these are things you need to care about, the better job that you can do.

It's an evolution. It's a collaboration. I'm absolutely a fan of the core team entity and of that core team being a medium sized group. Not tiny but a medium sized group of people who bring really, really different things to the table in terms of who they are, their backgrounds and their skills. For example, this serves me well but I am a fan of core teams that have non-coders on the core team.

I like to say, engineers are basically superheroes. They can sort of think of something and then create it and that is the power that most other kinds of people don't have. I mean, maybe contractors and welders, but if you are working at a desk job somewhere, there's not really much that you can conceive of where you have an idea, you write it down, you spend a couple months then it exists, it works, it actively changes your life.

One of the downsides of that amazing superpower is that engineers can oftentimes get into a position where they think anything is possible and they don't recognize that just because they can figure out how to do something doesn't necessarily mean that they are the best people to do that thing. That comes into play a lot with these other qualitative things in an ecosystem. So, you can go to a lot of technical conferences and wonder, sort of, why is the quality not quite there? In a lot of cases, the answer is because the person in charge is not particularly skilled in this area. They are coder. They can write brilliant code but do they know how to think about where the lunch line is going to queue up and make sure that it's going to go through the phase, and that there's enough bathrooms and stuff like that. These are very vastly different skill sets. One of the past successes there is to sort of realize, "Yes, I can probably pull this off." But if I can find somebody for whom this is a natural area of expertise and I can focus on my area of expertise. Like, wow. We'll be able to accomplish so much more and everything will be better all around.

BRANDON: I think you've hit on something there again that I've seen since moving into technology from -- I come from a non-technology background and there is a sense outside of this industry that people kind of have different areas of expertise. When you are an engineer, your job -- I actually think a lot of it stems from the fact that your job is to become an expert in the field of other people's jobs. So, your job is to automate something so you have to know enough about marketing to do marketing software. Then you have to know about enough about this other thing to do this other thing.

So you think that you can learn anything and it's true that you can learn anything but there's a skill tree associated with each of those things. You don't realize, you're a junior level conference organizer, and maybe it might be worth talking to a senior level conference organizer. We've definitely fallen victim to that many times where we thought, "Oh, you know what? I'm pretty good at the technology side. I can give a conference talk. I must be probably pretty good at education." And it turns out that education is a multi-thousand year old skill tree that is pretty well-defined.

LEAH: One of the hard parts in thinking about this for me is, I really like the MVP concept that I have taken from technology, which is you don't have to get it right. Get something out there. Figure out what the bare minimum version of whatever it is you're trying to accomplish is. Ship it, iterate. I like that and I talk about a lot of things in my life in that frame which is kind of weird when I talk to my parents about iterating on things and what not. For example, in a decision about child rearing. "Oh, my God. The first one is this way."

It's a very useful way of thinking about things and I am a fan in many things of actually applying it to areas all over your life. But for something like how to run a small conference, you oftentimes don't need an MVP. You don't need to go through the stage of that level of quality because you can just work with somebody who's already learned all those lessons and already done those things. It's not like a greenfield code project where somebody has to actually start from the baseline every time it's a new project and build up all the infrastructure. You can just skip right to the front of the line. Find someone who's good at this and start out initially at a much higher level of quality.

BRANDON: I want to kind of dig into that a little bit and ask about you wrote a really great blog post earlier this year about your experiences running Ember Conf. It's so obvious the amount of effort and kind of thought, not just effort, but like directed effort and thought that goes into building a really great experience for people. I'm wondering if you have like certain areas that you look for and noticing whether somebody has really put a lot of thought into designing a good conference experience for somebody. If somebody were hoping to do something like that, what are some of the areas that tell you that you're dealing with like a really good, thoughtfully designed conference? Or where does that effort go basically when you run through the process? You only have so much time and effort you can put into this thing to create that experience, not the minimum viable conference, but the conference when you look at the division of your time and doing conference stuff. I think people wind up being surprised how much goes toward one thing or another.

LEAH: I'm not entirely sure how to answer that question because you don't usually get insights into what people are doing along the way. I go to fewer conferences these days because I find myself irritated. I don't even like the way it sounds but it's kind of true, where I go to a conference and I'm really trying to focus on the content and I'm really trying to focus on the goodwill of the people who are organizing it. Oftentimes, it's just so many moments where I'm like, "That should be better quality." Like it is very easy to get that right. You just need to have thought about that. You just need to plan for that.

I don't think there's many opportunities to sort of figure out those things ahead of time from somebody else to make an assessment of how a show is going to go. I can say that there are sometimes things that I see on just the websites where I'm like, "Oh, that is not a good sign." There are tools around for most of the things that you would want to do like selling your tickets and collecting information, and the online pre- event functionality. It's rarely a good sign when you see someone build their own. It's sort of another engineer foible kind of thing.

You don't need to reinvent the wheel. It takes substantial energy to reinvent the wheel. If you go with something that already exists, you can focus for example, on all this other quality stuff. But there's also sort of the way in which people build the content of their conference, like that's super telling. Maybe not even so much about logistics but it is pretty telling about the community or at least the people running a show as a representation of the community.

For example, I think it's pretty much conventional wisdom these days that you want to have blind call for papers. It's not reasonable to me when I see someone not do it that way. I understand that small events maybe just go invitation in the first year or two. I think that's actually a pretty justifiable thing. We don't have the critical mass yet to get enough submissions in for a program, or we're not really sure how to execute on that, and our community has these specific people who we know are really talented and will do a good job.

I think you end up with usually a subpar roster that way because you don't have the variety of experience that you'd be able to attract in a call for papers. But what's super weird to me is, yes, we're going to do a call for papers but we're not going to go the classic extras steps that open source and technology as a whole has learned that will really help this task go better and help eliminate latent biases and things like that. That's kind of weird. I still see it sometimes. I find myself confused by it.

I suspect more than anything that people just haven't thought of it or don't know how to execute on the strategy that a lot of other conferences has figured out a successful. I don't know, part of the reason I don't like to go to conferences so much is I remember when I was making all these mistakes, and I don't want to be that person who's really critical of someone who's trying to do something good but it's hard. Once you have that experience and once you sort of know better, it's hard to watch somebody else stumble over the same things you stumbled over. You feel like, "You should know that. I know that."

CHARLES: So, is there a community of conference organizers? It seems like they need to be some sort of meta conference or some sort of meta community of community organizers.

BRANDON: There is Conf Conf.

CHARLES: Are you serious?

LEAH: I might not be impressive enough to go to something called Conf Conf. I don't know. A lot of those things actually when you get to, "Oh, it's industry, upper-tier collaborator events." They're often times invitation kind of things and I'm not very cool. I don't know. I see things like that sometimes. There's this conference about speakers. It's like speakers conf –

CHARLES: Oh, speakers conf, yeah, and it's like in Aruba.

LEAH: It seems cool but I'm always like, "How do you get invited to that?"

CHARLES: Yeah, that's the part --

BRANDON: How do you get into that club?

LEAH: I know people who should be there and don't know it exists, or people who should be there but just - I don't know, no one has invited them, and it's invitational. It's hard to say. But I guess what I was going to say is over the years, I have at times belonged to different online forums that were trying to scratch that itch. The most successful one was probably for a good five, six years. There was a very active community of conference organizers in the Ruby space. But I think most of those people have either stopped doing conferences or gotten to a place where they just don't need that much help anymore, and there hasn't been like an influx of new people doing it. So there isn't really any strong community like that that I belong to today. That's a challenge in anything you face, where once you don't need the help anymore, people don't stick around to help the other people and it's hard to sort of organize that way.

BRANDON: That sounds like a big opportunity to me. But it sounds like an opening or a hole for providing something like that. Do you do any consulting for people on this? Do people hire you to help design a conference experience? Because I know that the ones you've put together -- you're pretty well-known for being one of the best in the business for this.

LEAH: Thank you, I think. No pressure at all. I do consulting, though obviously, that's mostly for companies and not communities because communities don't typically have money for that sort of thing. In communities, you need to create your own experts, and in an ideal world, there are people who recognize that when they're at the beginning of the learning curve, they should reach out to people who are further along and benefit from their experience and do things like read blog post and books and what not.

The blog post that you mentioned earlier, it was absurdly long. I was surprised that anybody read it and then a lot of people read it. I was surprised because of the length but I was also surprised in the way that it's difficult to come up with a conference talk where you're sort of like, "I know all this stuff," but I don't know what amongst this knowledge base is interesting to other people, and I don't know what other people don't know and I know the stuff so obviously, it's not impressive.

It was value that came out of that blog post that I didn't think of at the beginning. The value of other people getting a chance to recognize what kind of thought and planning needs to go into having something like that execute flawlessly, or dealing with things when they don't execute flawlessly.

BRANDON: One thing that that was an obvious expenditure of effort, because you started so early in the process, many months before the conference was the Women Helping Women Initiative. I saw that really early on. I actually don't think that was precedented in conference organizing. Can you tell us a little bit about that? I don't remember how far in advance it was, I just remember thinking it was absurdly far in advance and very well thought out and very well designed.

LEAH: Well, it was early. For example, I actually have to email the Women Helping Women group today with a long list of thoughts and activities for next year. I feel like I'm super behind because it's September 15th and the conference is at the end of March. Last year, I think we were already talking basically like 2, 3 weeks after the previous year's conference had ended.

I spent some time thinking about all the various women in tech efforts. I have been involved over the years in a lot of things that felt good and said good things but at the end of the day didn't seem to accomplish very much. Right from the beginning, I wanted it to be a tactical effort. I wanted it to be like a short term pipeline of, "We put this in one end and we get this out the other end, and we have accomplished XYZ." Because it's important to have lots of organizations that make people who are under-represented in any community feel good and feel welcome. But it's also just as important and a little bit less prominent, in most cases, to have those same people then become leaders in that community. That' sreally sort of a signal to everybody else that they're welcome and that they can accomplish things.

I looked at our community and I thought there are already, actually, really awesome women here. Not as many as I'd like. But I know a lot of women who are impressive and who are like, "Why aren't they on stage?" So, I sort of approached the effort last year from the perspective of there's a lot of organizations out there working on the women in technology pipeline problem, and it's a very real problem. Hopefully, they're going to do a solid job. There's a lot of insights and I'm watching and it's cool. But I want to focus on the problem of -- let's not call it a problem -- but I want to focus on the situation of the people who are already here and helping them take those leadership roles and step up and really join the community at every level. Not just at the entry level. We've come in through the fix the pipeline problem setup.

CHARLES: And then hope everything kind of magically works itself out from there.

LEAH: Yeah, which shockingly, it doesn't. I don't know... We spent many, many months basically supporting people at every step along the way from, "I want to go to this conference," to, "I'm a speaker at this conference." And we did things like brainstorming about what kind of proposals people could submit. We helped each other once we had a critical mass of a bunch of talented women. We helped each other with our proposals. We helped each other with our ideas. I organized podcasts where the program committee did question and answer sessions with the women. We did some hangouts where women who had more experience than the rest of us came and talked about their first time speaking or their experience getting to know a community or their experience learning to code and we encourage each other in a lot of ways. It's just a really positively pushy support group. We encourage each other.

It's funny because it was hard along the way sometimes because you don't want to be too pushy. I was always worried and sort of dancing on that line of, "I want to repeat to you, you can clearly do this. You have said things. You have accomplished things, look at your education, look at your career. You are obviously, obviously good enough and impressive enough to be on the stage and I want to keep reminding you of that so you do it. But I also don't want you to feel like you are being bullied into it."

Not everybody wants to be a leader. Not everybody wants to be in a role of getting up on stage and giving a talk. I had a couple of the participants come talk to me or email me after the program saying, "That was really helpful. That was the nudge that I needed." So that made me feel good about the various interactions along the way and it's always just going to be something that you have to do in a very sensitive manner.

But there are women that I knew that were here that were talented and then so many women that just came out of the woodwork where I was sort of like, "I know your name or I didn't know you at all," and like, "Why don't I know your name? You're incredible. You're better than half the people I see on stage at a conference." And so we worked on this for months and months and months. I got a bunch of women in the community who were in sort of transitional leadership roles which is I thought, "Hey, you're a community leader," but they weren't sure they were a community leader yet.

I got a lot of people like that involved to help nudge along all the other people who could potentially be our next batch of community leaders. I don't know... It was really amazing and you have to pad the numbers every step along the way and at the end of the day, you actually want a conference with impressive representation of anyone. So you have to get significantly more than you need into the pipeline thinking about it, and then significantly more than you need actually submitting and then hopefully at the end of the tunnel when everything shakes out, you'll get a reasonable number of people right. Because obviously things get filtered out and at every step of the way. There's a lot of other people that you're competing with.

Overall, the quality of the proposals from the women was astonishing. It was a blind call for papers process in terms of the program committee. But as the administrator, who doesn't get a vote in these things, I was managing the app that handle the voting during the process of picking our speaker and all that kind of stuff. I was just astonished by watching quietly in the background how all these ratings came in and nobody knew they were doing this but the proposals from the women were on average, like dramatically better than everybody else.

I'm not like saying, "Oh, yay! We're better." I'm sure a lot of that had to do with the amount of thought that went into it because even a seasoned conference submitter who spoke in a lot of conferences might get to a point where they're sort of cranking out a proposal in a week or even a month, and a lot of these women spent six months thinking about it. But all that hard work showed in the proposals, all that hard work showed in the roster, and I really want that hard work to show around the community.

Part of what I'm trying to focus on this year is how do we take that from being the EmberConf Women Helping Women program to being the general Ember Women Helping Women program. Because after EmberConf, I felt like I could really help other conferences change their way that their rosters grew. Specifically before that EmberConf, you did have a lot of well-meaning organizer saying, "I want more women represented at my conference but I can't find them."

It's a small step but I started seeing the women who spoke at EmberConf who a lot of them hadn't spoken anywhere beforehand, pop up at conferences all over the place. So, I sort of felt like the effect was magnified and we were able to really... I don't want to say like we, all of us women together, were able to help each other not just at Ember Conf but in a larger way.

BRANDON: I think it's super clear that the thought process that you put into this was well designed enough and the work that went into it was consistent enough that you both got a huge uptick in the number of women represented at the conference. But also actually overall, the quality of conference talks went up year every year as a result of all of that additional preparation. And the encouraging people from backgrounds that had something to say that maybe felt like they didn't have something to say, instead of seeing the same faces over and over again, they went all the way across the board and it ended up showing and being a better quality conference experience for attendees for that.

LEAH: It turns out the diversity is actually awesome. It's not just the thing that you should talk about and put on a list because it's politically correct. But in fact, things will be better if there are more people represented from different backgrounds with different experiences, different skills, different everything. You felt it everywhere you went and felt like you were hearing new things, interesting things, and perspectives that maybe weren't always as well represented.

My biggest sad point about things is I'm trying to tackle the community of women but there are so many other communities that could also be better represented in Ember and in technology at large. And I would really love for more people to step up and sort of focus. It's hard to get involved in an effort like this because it's hard to get any traction and also because honestly, there's a lot of concern about, "Am I going to do it right? Am I going to make the problem worse?" All those sorts of self-doubt issues that are legit and based on having seen other people out in the world make a good faith effort trying to fix a problem but like say something wrong and get in huge trouble. It's just challenging and it requires a lot of thought. Even me, as I talk about this right now, I'm stressed out and I'm like, "Am I using the right words? Am I going to say the wrong thing?" But it's still worth doing. And if you're persistent and you work hard, you can really, really change things and have a positive impact.

BRANDON: Well, I think it sets forward a lot of good patterns for other people trying to do this thing and I think when you talk about this being scary, the point is that it's not going to be scary. It's very scary so it makes it super brave that you're attempting that stuff. I think the impact is certainly on me. I found that pretty inspiring. Certainly at the Frontside, we found it inspiring. I hope it inspires other people in other communities to follow the same patterns.

LEAH: Yeah, I hope so. I mean if there are women or anybody else that feels like they have something to contribute to really improving the landscape of who our leadership is and making sure each they are represented, I guess I would encourage those people to step up.

Even within the women's group, there's like different perspectives and I've been working with people and encouraging them to try and work with me on taking leadership roles within the program itself. So many well-meaning programs like this, by the way, like spin up, have some success and then go away because the person-in-charge got busy and that's the end of that. It's similar to a community in that if it's going to be a long term successful effort, or at least as long term as it's necessary, I'm really going to need other people in the community to step up and find ways to be involved so that I'm not actually important to the success of this anymore. Instead, it's a whole group of people and there's no one single point of failure.

BRANDON: When that happens, I can't wait to read that particular blog post. When you're able to kind of demonstrate the process for other people to be able to follow and, "Hey, look at this thing. It kind of runs itself now." That sounds really awesome and you're definitely --

LEAH: Fingers crossed.

BRANDON: Yeah, you're kind of off road because you're helping to find some of the things that may influence other communities, as well. So, I think that's super cool.

LEAH: I hope so.

BRANDON: All right. We need to get let you get back to CEO-ing. You have a company to run and you have a whole life and everything.

LEAH: I'm going to put on my business jacket as soon as I hang up on you and get back to work.

BRANDON: You're in Portland. It would be a like a business hoodie probably, right?

LEAH: Sort of. I have this really nice blazer. It literally changes my mind some days. I'm like, "Oh, I'm not getting enough done." I'm going to put out my business blazer. Then, they shift into over drive.

BRANDON: All right. We'll get your business blazer and get to business-ing. That actually sounds like a cool little business life hack.

LEAH: Yeah.

BRANDON: Well, thank you so much for your time on this stuff. We got about halfway through the questions I want to talk to you about so I hope we get a shot at doing this again. I really love learning from you on this stuff. I've learned a ton from your writing. I've learned a ton from watching you work and I really appreciate all you do for the Ember community, the JavaScript community, all the stuff you've done for the Ruby community. You've had a really big impact, and so it's really great to talk to somebody that kind of sets a pattern of how these things are possible. I hope that good fortune continues to follow you as you're bold in doing these things. So, thank you for all the stuff that you do.

LEAH: Thank you. I hope so, as well. It's been fun.

CHARLES: Thank you. All right, goodbye everybody.

BRANDON: So, bye everybody. If you have any questions or anybody else that you'd like us to talk to, let us know. If you have any additional questions for Leah, hit us up on Twitter at the Frontside.

CHARLES: We usually ask for people's contact information. Where can youl be found on Twitter?

LEAH: I do have a Twitter account. I'm not super active because I'm busy wearing my business blazer. But my handle is @Wifelette and I try to be as responsive as I can certainly to people who reach out to me, even if I'm not broadcasting all that much.

BRANDON: Awesome. Okay, well thank you again Leah, and thanks Charles. I hope everybody listening has an awesome week.

In this episode we cover how to handle apprenticeship, share with listeners how they can start participating in mentoring and apprenticeship in their companies and communities, and help people to understand the impact apprenticeship and mentoring can have on everybody involved.

Links:

open-source-ember-apps: A list of open source Ember apps

Transcript:

CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 42. I am Charles Lowell and with me is Brandon Hays, as well as some other really, really, really, really special guests, which I'm really excited to have on the show today.

BRANDON: Really?

CHARLES: Yeah.

BRANDON: Just really?

CHARLES: Really, really.

[Laughter]

CHARLES: I was thinking of 'really, truly' but no, I wanted to go back to 'really'. I don't know, Brandon, are you pretty stoked about the show today?

BRANDON: I am. I'm really excited today. We've actually wanted to do this for a long time and we finally were able to line it up once we've figured out that we can record a podcast more than once every six weeks. So yeah, we're really --

CHARLES: Really.

BRANDON: -- Really excited to have Taras Mankovski and Lennex Zinyando with us. We'll have you each introduce yourselves. But basically, the point of this podcast is we want to talk to you and you're doing some really cool stuff with apprenticeship through us, and Lennex is one of your earlier apprentices. From everything I've seen tremendously successful, Lennex, you're an awesome developer. So we wanted to talk to you, find out how you're doing that stuff but we'd love to have each of you introduce yourselves and talk a little bit about your background. So we'll start with you, Taras.

TARAS: I'm really excited to be here. I also feel like I need to point out the fact that this is podcast number 42. Right? That's the meaning of life and everything.

BRANDON: We would be very quite remiss to miss that. Thank you so much. We were so really excited that we forgot about this was the purpose of everything.

CHARLES: That's right. We're sitting on the main nerve right now. This is it people. This is it. It's everything.

TARAS: I'm really hoping that if you ask me questions, I'm going to answer them faster than this famous answer. I'm really glad to be here. I want to give a little bit of my story because I feel like a lot of things that I've doing over the last 10 years have been adding up to what I'm doing now. I have a pretty diverse background. Programming wasn't something I wanted to do because when I was 12, my dad gave me a Java book and he said, learn how to program and I'm like, "This is terrible."

[Laughter]

TARAS: That was a really rough introduction for me. Even though, I think I was always technically inclined and I did like [inaudible] for a long time. I did a lot of different things. Since I was a little kid, I always want to be a businessman before I think I even knew what that was. So my focus has always been on the business of things, and technology happened to be one of the only ways that I knew how to access that in a way that was actionable based on something that I could do.

I've tried a lot of different things. One of the things that I did before was a company called Positive Sum, where we spent about four and a half years trying to figure out how do you build relationships where everybody who works with you wins. When that Positive Sum company and the being as 'zero sum' for me, I end up leaving and starting from scratch.

I have another company called WRKTG, Inc which is like the mothership for EmberSherpa and that acronym refers to 'working together'. Everything that I've kind of have been doing has come from the perspective of how do we bring people to work together, and how do I make it possible for people to have a win-win-win scenarios. I think that's kind of what brings us to where we are today, with this conversation about apprenticeship.

BRANDON: Cool, thanks for that. Then Lennex, how did you get into software and what was your background? I don't know if you come from a computer science background or you were doing something else.

LENNEX: I'm Lennex Zinyando. I'm based in Harare, Zimbabwe. I've always wanted to work with computers since an early age. But then, access to computers was really hard to come by so I used to spend a lot of money going to internet cafes so that I could access the internet.

After a few years of [inaudible], I went to work with a bank for a few years and I decided to leave because I really, really wanted to become a programmer developing software. I joined a local company that does mobile marketing as a technical support person.

I worked with them for a few years and I met Taras on Twitter, sometime beginning of last year. Then, I paired with him so that he could mentor me. So now, I'm an apprentice at EmberSherpa.

BRANDON: You said you met him on Twitter and you said, "Hey, I'd like to be your apprentice," but how did that interaction actually occur? Was there like a tweet that went out and said, "Hey, I'm looking for apprentices," or you just kind of saw that he was knowledgeable and you said, "Hey, can you help me?" How did that interaction first happen?

LENNEX: Actually, I saw a conversation between him and another guy where the guy was - actually they're discussing how they could – I think they wanted to pair on it or something. Then, I just asked if I could join the process, be part of the team that was going to pair on it. Then Taras created this link for us and that's how it was started.

CHARLES: So you just said, "Hey, can I join that pairing session?" And the rest is history at this point?

LENNEX: Yeah, something like that.

CHARLES: Now, you're a world famous software developer so it seems it works.

[Laughter]

BRANDON: Well, that's really cool. I'd like to ask you, Taras. Was that sort of intentional on your part? You said your arc was bending toward community and 'greater than zero sum' type work. As you were bending that arc toward that, did you have the idea of- I mean, your name was EmberSherpa on Twitter so clearly, you had some sort of training or guidance aspect to what you're doing. Was apprenticeship part of that model by then? Or is that something you kind of stumbled on?

TARAS: I always imagine what things might look like. I imagine that there might be a scenario- I tried to do this with WordPress before which is create a scenario where I'm helping people learn and in the process they cultivate a community of people that follow what I do through helping them become like an engineer.

It didn't work very well with WordPress but it seems to have worked with Ember. It's very much an [inaudible] process. I kind of went through a bunch of hardships trying to figure out a structure that is actually sustainable. That's the really hard part, I think, about creating like win-win scenarios is that you need to be sustainable and finding a way to make sustainable. That was really tricky.

CHARLES: Yes, that's something that we're discovering as well, right? You identify these values and you say, "Hey, these are the things that I value," and then you discover how expensive they are in the process of trying to implement them and trying to do that in a way that you can keep going that doesn't basically require everything from you all the time. That's really hard.

So it was something that clearly, like you cared about, you were trying to do it in WordPress. You said you ran into a lot of painful lessons there. I'd actually be curious and dig into a couple of those things that you are finding were not sustainable.

TARAS: It's ironic actually, I found mentoring to not be very sustainable. From a business perspective, I think mentoring is a really great service but because it relies so much on people like myself who have to be like people that get to certain levels through their hard work, you end up wanting to get paid well for the work that you do. Then in that scenario, it becomes very difficult. Like offering mentoring services is very valuable but it's also a very premium service. So to be able to sustain myself and be able to offer a service, the businesses you want to pay for, and in a way that is going to benefit the company is going to benefit the apprentice and benefit me, those were difficult.

But it seems to be shifting towards apprenticeship turns out to be the answer, for me at least. It was like one of things that was right under my nose but it took a really long time for me to see that actually apprenticeship is the answer to creating this scenario. It’s really funny how something might be right in front of you but you might not see it for a year and a half.

BRANDON: What's different about apprenticeship from mentorship, basically?

TARAS: Mentoring for me is supporting a company that has a team of developers. Basically, the company is paying me to mentor their developers. It seems like a very fine distinction but the difference with apprenticeship is that the focus is on the individual and all the other things are kind of secondary.

BRANDON: So basically, by defining the problem scope as, "Hey, this is about an apprentice and not about how good a mentor I am," you basically discovered -- I think all businesses go through this at some point too, like anybody with a purpose ends up discovering that the thing that doesn't scale is your time, and the only way out of that is to develop a process that's focused on achieving an outcome. So apprenticeship is the definition of the process by which somebody gets better and focusing on them rather than non-scalable Taras' time.

TARAS: Exactly.

BRANDON: Lennex, you basically came on as an apprentice about a year ago. Can you describe the process, from your perspective of like what that apprenticeship has entailed and maybe even how that evolved over time?

LENNEX: Initially, we worked on small apps. When I was trying to get the basics of Ember and to be honest, I didn't know a lot of JavaScript. So that process was kind of painful for me. It took a bit of time for Taras and myself to admit that and then I tried to focus a bit on knowing my JavaScript properly.

BRANDON: So basically, you have commits on open source projects now out there in the world?

LENNEX: Yes, I do.

BRANDON: And how long have you've been developing software before you were basically doing that?

LENNEX: Not that long. It was just a few HTML sites, a bit of PHP, then Ember is like the first programming thing that I've done.

CHARLES: I think that's really interesting. Like part of the process, you seem to be describing as you kind of got thrown into the deep end of the pool. Like this is a new language for you, we're going to be doing open source projects that people actually use, and you were actually contributing working code into a real life. You know, thousands of people are using the code that you actually wrote in very early stages of your development career, which I think is a really interesting model.

Taras, would you say that that is part of the model or is that just sort of a coincidence of how this went down? Like is that part of the design of the apprenticeship model?

TARAS: It's certainly by design. I think there's something really beautiful about Ember, and it's the fact that it creates a possibility of an ecosystem of open source applications that solve the script problems and that is enabled by the fact that we have this collection of conventions. When I chose Ember as a technology to focus on, I kind of made a guess that this might happen. Then when I realized that Lennex needed to learn by doing real practical things, I went out looking for this applications and started off as being, first it was a HospitalRun, and I was kind of really uncertain whether the HospitalRun would even take it seriously because we're saying, "I'm going to help this person work on your application for free. Will you talk to us and tell us what we need to be able to make this happen and make it so that you can actually mark this code?"

But it's proven that this seems to be something that maintainers of open source applications are willing to do, and now we have something like... Oh, I don't know what it is, but plenty applications. I have a list of open source Ember applications that we're adding to on a regular basis, and they're all opportunities for our future apprentices to contribute and improve their skills. Actually, they have something that they can show and say, "Look, I did this."

BRANDON: So I'll grab that and put that in the show notes. That seems like something that just producing that list was important to your apprenticeship but actually, everything that you do when you do work on the public like this adds value elsewhere as well. Like that's a really cool and useful list for people to have of things that people can actually contribute to.

TARAS: Yeah, and I hope that there are other applications that we don't know about that are going to get added to this list because if we can have more apprentices helping more open source applications, I think that's something that's really great for Ember. It’s a win-win for everybody.

CHARLES: So I'm curious, you've got this big list, 20, 25 open source applications that's actually a big list and I assume there's a lot of people. You talked about how making the shift towards apprenticeship allowed you to scale but I actually am curious about that process because like how does it scale? There is only one of you so how do you manage more than one apprentice -- two, three? How many is reasonable? How do you bump that number up and get more people coming along?

TARAS: I think what's happening now is that my apprentices actually have their own apprentices. I think that's the key to scaling this because at a certain point what happens is, as I mentioned earlier, at one point, I paired with a hundred people and I realized that people have very common problems and depending on what stage they're in in they're learning, they all tend to have very similar problems. The way to scale [inaudible] a lot of people, I think, is to have the apprentice that just learned or apprentices that has a six months of Ember experience, they can support somebody who just started last week or started two months ago.

They’re actually really good persons to support that person. If I support somebody who just started Ember, it creates a situation where like I want to be able to help but I've answered this question so many times already that it becomes repetitive. It's actually takes away from the energy of me trying to explain this to the person. So having an apprentice support a new person is great for the apprentice because they get to grow. It’s great for the person because they get really personal attention.

BRANDON: I want to make a note. I feel like I should have noted this earlier. Part of the reason that we wanted to talk to you two about this is we've taken several swings at apprenticeship at Frontside, and we're in a sort of unique position in that. We don't see a lot of companies doing this very actively. I saw a company called Obtiva that had an apprenticeship model that I admired a lot. Then they got acquired by Groupon and everything that was good about that company died.

I haven't seen this done a ton and our attempts have been kind of shots in the dark on this. It’s been very challenging. Your approach to this seems to be working in a way that I have not seen happen elsewhere. What I'm hoping part of drawing out this conversation is the process of discovering what is working for you and what other people can adopt? Basically define how this is actually like it seems like a pretty successful case and how people might adopt that in their businesses, in their workplaces, and in even in their capacity. I love the concept of moving away from mentorship as a concept and toward apprenticeship where this becomes more of a defined process.

I'm sure to you it felt like you're kind of fumbling around as well. But you seem to be landing on a lot of things that really seems to be working. Are you noticing any patterns in terms of somebody you get them working on real world applications, they tend to support each other, what other tools, I guess, or patterns are you using to help that process kind of stick with people and scale because this seems to last longer than just a couple months too, which is important?

TARAS: I think one thing that I talk to our clients who - because we actually do sell apprenticeship. Part of the process of the apprentice evolving from someone who has never maybe done programming before or who is very new to Ember to actually being a good productive member of the team, is actually starting off doing something that is very low stress, doing something like open source contributions. Then, being in a situation where they're able to make a difference but there isn't a lot of pressure on them.

So one of the ways that I set that up is I tell our clients that this person is an apprentice. The reason why you would want to hire this person is because first of all, if they have a problem, they can ask me. But also, this person, like a lot of things that we do on Ember are very repetitive. Their patterns that once you've taught, you can use that pattern over and over again. I think, at a certain point, if you implemented a few tables, implementing a fourth or a fifth table isn't that different than the first three, and you don't get that much more effective at it because you're still limited by how quickly you can type.

What I've been doing is first, I've been very, very honest with people that I work with saying like, "This is what's going to happen. This is going to be the person working on your project, and this person is going to do be doing this work." Also kind of talking about the reality of Ember work which there are a lot of things that are really difficult that very smart and experienced Ember developers can solve, but there's a lot of work that we do in large Ember applications, that there's lots of paved paths for that, there’s lots of just like assembly kind of the ground work and I think that's a really great opportunity for people who are learning Ember to get the repetition, the kind of muscle memory of understanding how to solve problems.

I think the repetition of doing like 'data down, actions up', repetition of doing like working with computer properties, and repetition of writing tests. All these are things that apprentices need to do to become very good at writing Ember applications.

BRANDON: That's actually my experience as well. I come from a nontraditional background and I knew that I got a sense for when I was trying to learn a new thing that it was a certain number of projects before I felt like somebody could give me something and I felt comfortable saying, "Hey, I can probably do that." It wasn't my first project and it wasn't like a hundred so have you kind of discovered a number in there of projects that somebody might have worked on when you talk about that repetition. Is there a number of times of repetition that you find people become comfortable with something?

LENNEX: On number of projects, for being comfortable in Ember?

BRANDON: Yeah, at what point do you start feeling comfortable and a little more confident that somebody could hand you something that you haven't seen before, and say, "Hey, I could probably tackle that." Is there a certain number of projects that you've handle before you felt like you could just jump in on that?

LENNEX: Let's say for testing for example, writing an acceptance test. I wrote the initial test for HospitalRun. The next project that I did, I was really comfortable with acceptance testing. That was just one of those thing that I could do. I think just doing it once or twice is enough for you to feel comfortable doing something. I don't know about the other stuff, but then what I've done so far, that has been okay.

CHARLES: That's interesting. What I'm hearing is you weren’t doing like the whole slice of the application. You were focusing on, "Okay, the acceptance test. That is the thing that I'm going to take on. That’s the thing that I'm going to own. I'm actually just not going to worry about everything that lies underneath it, or how to implement the acceptance test but I'm going to learn acceptance testing in an Ember application. Then once I've got that skill, now it's in my pocket and I can take it to the next problem."

BRANDON: Lennex, at what point do you start feeling these things start to click together, where you have the tests over here and you have maybe understanding the router over there and you have maybe understanding components over here? Each of these things takes time, it's difficult, and it's a new concept. At what point do you start feeling that you have a full picture of how an application works and that you could kind of attack it from different angles?

LENNEX: In my experience for HospitalRun, I did the tests and I did a lot of [inaudible] from Ember 1.X to 2.X. So I got to touch a little bit of everything. The next project in [inaudible], I implemented a feature. That feature has required me to use all the previous knowledge that I gained from HospitalRun to do something that actually [inaudible] and [inaudible] properly.

In my next project, I'm now building an [inaudible] from the ground up using previous knowledge from all the other projects. So you're always building on top of what you got before.

BRANDON: That actually sounds like an interesting pattern. Again, I don't know if this is sort of something you discovered or happens over time or even if I'm reading it right. But it sounds like you're really mixing up these tasks where some of them are kind of a deep dive on one small piece like, "Hey, I want you to write acceptance tests around this and you're familiar with acceptance testing." And then you have a thin slice of something like an Ember upgrade that touches all aspects of the code base but in a thinner area, as well as a ground up building of something, sounds like maybe later. Is that sort of mix of types of work intentional? Or is that just sort of something that, "Hey, if the work is there and if it seems like somebody can do then I'll grab it"?

TARAS: I think some of things are very intentional like the last project that

LENNEX is working on, I intentionally said that, "You now have enough experience doing all of them. You’ve been dealing with other people's problems for a while now. So I think it's time for you to make your own problems so you can actually understand that process a little bit better."

But other things that are actually just very practical things like the reason why starting with testing. Why we start with testing is because without tests in place, I don't have guarantees that the things that Lennex is doing are not breaking functionality. Then what that means is if I don't have that guarantee, that means that the chances of me being pulled into something randomly is very high and then that's the kind of risk that I can't take.

Actually what happens now is almost every conversation with new clients starts off with, "I know you guys want to do features but before we can do that, we need to build your acceptance tests suite." And so this is actually a very practical thing. I think part of apprenticeship program for us is actually teaching the things. It's a very practical thing. It's like we need to have tests to be able to do this work.

BRANDON: Yeah, I mean it's one of those things. There is some debate in the community around like, "Well, how soon do you introduce that to somebody? Is it something that is an advanced concept?" I was not introduced to testing until much later in my development career. Basically, my first introduction to testing was somebody handed me the 'can't back' book called Test Driven Development which is all written in Java before I had learned to program, and I was like, "I don't get it." So that was my last attempt at testing for about two and a half years.

It wasn't part of my process but when I did discover it, seemed like it did make everything easier. The fact that you're able to do that up front, I imagine probably saves a lot of time and frustration for people so they have something to like back up to during the course of their learning process. There's always like a place where they knew this thing was working.

TARAS: I think there's another pattern that is underneath this which is very important to give people what they need to build to move forward. So with Lennex, when he started working on HospitalRun, I spent almost half a week, maybe almost a week setting up because they never had tests so we had to make it possible for him to write test, so we need to actually read the first acceptance test. What that means is that you need to go in and find all the problems with the app that prevent you from writing acceptance test and actually fix those problems.

If I just said to Lennex, "You know, write an acceptance test for this," without giving him any paved path to do that, I think the chance of him succeeding would be very low.

BRANDON: So yeah, you basically have to pre-shave all the yaks around getting the first one going. And from that point forward, they're likely to be able to carry the ball further.

TARAS: Right.

BRANDON: I have a question for you, Lennex, in that sort of vein is how do you know when you're stuck on something that is like well outside of your capabilities versus when you're supposed to stick with something because you know there's something you're supposed to learn? Is that a skill that you've had to develop or is that something that... I don't know, like I'm not sure how to deal with that with our apprenticeship, and I'm wondering how you've dealt with that?

LENNEX: One thing that Taras has taught me is if I'm facing a challenge, I should work on it. Taras will say, "We're going for a day. If you fail, then come to me." It helps me to not give up easily. If it's beyond me, then after that day Taras is going to help me. By then, usually, I end up getting through that and finding a solution.

BRANDON: Interesting. I have worried that a day was too long of a feedback loop to let somebody bang their head. But it sounds like you've landed on a day as being kind of the approximate amount of time somebody could spend and try to solve something themselves. Taras, is that basically a fair, like wind up being a good place to land?

LENNEX: Well, for me and Taras, it will depend on different - a day usually means when you accept. So there isn’t that much [inaudible].

CHARLES: But it makes sense when I think about it. I actually wasn't thinking about it in terms of that being an appropriate size feedback loop. But when you think about what you're actually doing when you're programming, a day is actually a very reasonable amount of time to struggle with a problem. So before you say, "Oh, man. I just need to find someone to pair with this on. I've done my Googling or whatever but I need to try and like roll back and look at for some prior [inaudible] on this or try and find connect with somebody who's sharing a similar problem." I think that actually makes a lot of sense, right? That's something that we all encounter in our daily lives.

LENNEX: Yeah.

TARAS: We know from people with experience how long sometimes it takes for us to understand something.

CHARLES: Sometimes years.

TARAS: Yeah, and I think it's really tricky. It’s hard because learning takes time. That’s one of the things that I'm a little... I'm not sure exactly how this is going to work but I know if clients are paying me to mentor their team, I'm going to be available to them within half an hour to an hour to answer that question because if the client can't afford to wait a day for them to get that answer. But for a person who is learning as their primary deliverable, I think a day is reasonable amount of time for a person to try to like even sleep on it.

CHARLES: Right. It's true. It’s a tough line. I think, Brandon, one time you said something that always stuck with me. You said that learning only happens when you bang your head against the wall so that your brain is soft enough to accept the answer. And you don't achieve learning without the banging your head against the wall first.

BRANDON: Yeah, Brandon Hays, the king of violent metaphors.

[Laughter]

BRANDON: There is actually an important aspect to this that I don't want to drop onto the floor and that is the idea that part of this process is that you have people that have access to one another. That's part of how you are scaling it, that you're also kind of helping. It seems like you're helping build a small community of apprentices to help each other.

So Lennex, my question is this, how often do you wind up using that network of people versus you feel like you'll just handle it on your own? How much do you want to have accessing that?

LENNEX: I access it a lot. I usually get stuck, and then I know someone working on projects which is similar to what I'm doing. So again, I just easily ping him and then a few minutes or a few hours later, we're pairing on it.

BRANDON: That seems like a way where you're able to do that without reaching out too much to Taras. It feels like you're asking for help and figuring it out. But it means that you don't have to roll up to the most experienced person for every single question, that you kind of started to build a network of people that stitching together your own mentorship in effect, I guess.

LENNEX: Yeah, that's true. It's easier to understand the concept when someone is on your level or slightly above you when they explain it to you. Maybe for me, it's easier to understand.

BRANDON: Actually, that jives with a lot of our experience. I can't remember what book this is from. I'm pretty sure it's stolen from another book but I read it from the book 'Pragmatic Programmer' where they talk about the zone of proximal development, where it's easier to learn from people who have just a bit more experience than you because they haven't completely forgotten how they learned the thing that you're trying to learn.

After a while, expertise means that you actually internalize that to the point where you can no longer remember not knowing it. That can be really tough. I think that's actually something that a lot of mentor should probably know and recognize and understand. People that want to take apprenticeship on need to understand that you probably have lost a lot of the empathy. I know I have and it really bums me out because it doesn't feel like that long ago that I was a brand new developer. But I'll sit with somebody who's brand new and I forgot how I learned the thing that I'm sitting there trying to teach somebody, and you start getting that little burning sensation in the back of your head like, "How can you not know this?" You know that at one point you did not know this, but you don't remember not knowing it. It’s a very strange sensation to have gone through all of that and then lose that empathy. So I feel like that's must be a really important concept.

Another question I have for you Lennex is how much of your time do you wind up spending helping other people do that kind of stuff as well? Do you wind up doing participating as a mentorship stuff at this point?

LENNEX: Yes, I do. Actually now, they are about three people that have reached out to me on Twitter, wanting my help. I've paired with them when they have their own projects. They're asking me questions. One guy that I helped with Ember stuff in our local community, and maybe because of the apprenticeship that I'm doing with Taras, they think I'm an expert in Ember. But I'm actually helping other people a lot.

BRANDON: I think that's really phenomenal. That sounds like success to me.

CHARLES: Yeah, I'm actually curious. Having been through this process and experienced success at it, were there any times where you kind of felt you wanted to throw up your hands and be like, "This is not working." What were those moments of frustration or mistakes that... Not mistakes, but were there any moment’s frustration? What actually did you take to course correct on that? If not, that's fine too.

BRANDON: Yeah, if not, I'll just know you're lying.

[Laughter]

TARAS: There were definitely challenges. Lennex and I both went through some difficult learning and questioned whether we're be able to do this. I don't want to speak for Lennex but there are certain things that you have to learn to be able to work with people, and they're not programming things. I think that's because obstacles that Lennex and I had have been related to communication and being reliable for each other, I think that's the part that's been hardest. But the reality, I think, is that this is what programming is, talking to people most of the time and building a network of people. So I think we need to, as a mentor to an apprentice, I need to help my apprentice understand this, and help them understand what makes me successful in my work with our clients, for example.

BRANDON: You brought up one thing and I'm curious to get Lennex's perspective on this, which is being reliable for each other. I know it has been probably the single greatest challenge to our apprenticeship platform at Frontside, where we've brought apprentices on and the criticism that we had about our apprenticeship program is if I had 24/7 access to the mentorship that I needed, this process could have been done in three to four months. And instead, it's going to take seven or eight months.

LENNEX: Maybe the thing with me is I really wanted to be part of the apprenticeship program. So I had to work really, really hard to make this work. But given that for me, this apprenticeship program has been 100% remote. There's no one standing over my shoulder or someone chasing me, asking me what I've done or whatever. I had to discipline myself so that if I get tasks that I should do, I should do then on time. Even if Taras is not available, he's not there chasing up to me whether I've done that.

The other thing is I wasn't good at communicating early on. I would shy away from telling him when things are too complicated for me. I'll try to solve everything on my own until I discovered that some things you just can't learn on your own. You have to ask for help. Since then, things have been a bit better.

BRANDON: That sounds like something almost universal to me. Every time we've attempted apprenticeship of any kind, maybe it's because we tend to select the people that we come into contact that say, "Hey, I like to do apprenticeship," tend to be people that are kind of self-starters. But they always tend to try to solve everything on their own. It becomes this coaching exercise of having to have that person communicate back to you.

Is there a sort of a platform for that? Or is that just a style that you've developed where you're willing to reach out more frequently? Or do you have check-in points or something like that during the apprenticeship that are like standard?

TARAS: We don't have anything specific. Something that I use in projects is like if you're actively working on something, if you work in a project and that's your deliverable, like half an hour or so much time you get to play around with it, and then let me know. But the emphasis is on the person building the responsibility of the deliverable and knowing what's necessary for them to build to move forward. So I'm seeing that now from Lennex which I didn't see before in the beginning but I see it now.

BRANDON: It seems to me that that's the process of learning to own their own thing, learning to kind of develop their own paths. Again, that's one of those things that winds up being a better apprenticeship pattern for the person and also is a thing that lends itself to making this thing scalable where you can benefit more people and have them help themselves in each other, rather than having to be the nexus point for all questions and all accountability systems and everything. So it seems to be working really well for you.

I have one more question that I want to ask from both to Taras and Lennex. What you would say to people who are intimidated about taking on a role in mentorship knowing that, "Hey, that actually does sound harder taking on a role and trying to cultivate and participate in apprenticeship." What you would recommend to that person that is interested in it but maybe intimidated by it?

Then Linux, the same question for you but from the position of somebody that's trying to break in and kind of scared and nervous that it seems difficult or scary or opaque. So can we start with you, Taras? What would you say to somebody that is like 'hey, this sounds fun and cool and everything but it sounds too hard'?

TARAS: To be a mentor or to have an apprentice?

BRANDON: Take on the idea or participate in apprenticeship in some way. Is there some way that you know that people could get involved that would not necessarily be super intimidating?

TARAS: I'm curious what the person's intention is because if you want to help people and that's the emphasis, then you have things that are uncomfortable. Especially good things in a lot of times, they're uncomfortable until you get really good at them. If you feel uncomfortable, chances are you're not growing right now.

For a lot of people that are very good technically, helping others, understand these things is the next step for them to evolve in their personal growth. If they really want to get better, having apprentice is a very confronting and a very challenging thing but it creates real opportunities to see that you're actually getting better and you're improving as a person and as a technical leader.

BRANDON: Then, as far as [inaudible] said, "I don't see the opportunity for myself." My guess is there are people everywhere that could use help. Do you have any suggestions on where they can find people to help, ways that they can get involved? Do you have a place where - are you looking for additional people to jump in and get involved on the mentorship side or suggestions for ways that people might get involved?

TARAS: I would love to help people who want to build apprenticeship systems in their companies. I would love to help those people if they're able to do that. Otherwise, I think that creating more systems in Ember community around apprenticeship, I think would be really helpful like making more systematic because right now, it's something that I do but I'd love for it to be something to the Ember community does.

Then because from that, if we engage in that conversation, then we can create spaces where it will be easy for people to do this kind of things and find apprentices and find mentors. I'd love for this to be an Ember community thing.

CHARLES: Well, it seems like this would be as good a place to start as any. So, here we are.

BRANDON: Maybe after this call, we'll figure something out and put something together and tell people to look for that. If they want to participate in mentorship and they consider themselves Ember or Ember adjacent, I'd like to see something in the next little while that lets people participate in a more systematic fashion. That sounds like an opportunity, for sure. If there are people that want to participate in that, sounds like you're the person to reach out to.

Then Lennex, for your sake, for people that kind of want to break into technology and are really intimidated by it, obviously you're in a remote part of the world and your access has been somewhat limited. Sounds like you even fight for internet access in your life, as well, which is a foreign concept to a lot of people. So what would you tell to those people that are intimidated by doing this, scared that they're going to waste somebody's time, scared that they'll fail at it?

LENNEX: I think if someone really, really wants to learn, they should find a mentor or a good apprenticeship because learning from someone who's experienced, someone who has your best interest at heart, someone who's willing to put in the effort to teach yourself, you can beat that. If you find that that someone was willing to do that, then put in the effort and go through that program because usually, apprenticeship is tailored towards a specific individual helping the apprentice. Where else will you get that?

BRANDON: And there's not a ton of access to that in the world so it sounds like that's a big problem. That's what they are fixing in the tech industry. So having you on to come here and talk about it, lend some expertise to it, and start putting some ideas, process and pushing that conversation forward, it matters a lot certainly to me personally. But also to what the point of what we're trying to do at the Frontside.

If people want to get in touch with you all, how would they do that, Taras? How people get in touch with you?

TARAS: I'm @EmberSherpa on Twitter, and [email protected] via email. I always try my best to talk to people as much as possible and be available to people as much possible. If anybody reaches out to me, I'd love to talk to them.

CHARLES: Yeah, you definitely been accessible to us which is why we're talking today and I really appreciate that. I mean, you've been genuinely super helpful. We haven't really gotten into it in this podcast but we've worked with you quite a bit and are working to improve our apprenticeship program with your help. I can't tell you how much we appreciate it.

Then, for you Lennex, how do people get in touch with you?

LENNEX: I am @zinyando on Twitter, and [email protected].

BRANDON: Awesome. Well, thank you both very much. This was super enlightening. It's frustrating because I feel like we just barely scratched the surface. But I feel like there's some work that we need to do to put together some process around this. Maybe there's some blog posts or some further discussion around this to put this together. I would love to talk with you all again when we have something cool to share with people.

But what you're doing already is so awesome. I'd like for more people to know about it because I literally have never seen it done as successfully, as consistently as I've seen the EmberSherpa apprenticeship set up work.

Thanks very much for both of you all for putting that into the community and for sharing with us.

TARAS: It means so much to hear you, Brandon, say this because I respect both of you very much. I think you guys have a really great reputation in our community, and it means the world to me to hear you guys say that. Thank you so much for having us here.

Recently, there was a flurry of activity around one of Brandon's posts about defining the term "senior developer". But he left the purely technical aspects of the role for later discussion, which left a lot of lingering questions.

In this episode, Charles and Brandon dive into the technical side of identifying, hiring, and growing senior developers, and explain The Frontside's somewhat unconventional standards.

Links:

Transcript:

CHARLES: Hello everybody and welcome to the Frontside Podcast, Episode 41. I am your host, Charles Lowell. With me is our other host, Brandon Hays.

BRANDON: Hi, welcome back. It's been too long. It's been one week since you looked at me.

CHARLES: And we were actually talking right before the start off that we don't have any witty banter prepared for this episode.

BRANDON: Also, you just drop that hot Barenaked Ladies reference right on the floor, like an apple pie upside down.

CHARLES: Right, you got to prep me for that.

BRANDON: You're like, "Nope. Pass."

[Laughter]

CHARLES: Like I said, you got to prep me for that.

BRANDON: "In Second 7, I'm going to drop a Barenaked Ladies reference." I'm going to send you three or four music videos. I did send you one that you didn't have time to watch about don't use animal names as an insult. When you say, you're not going to be able to riff off me on that one just yet either, but yeah, I respect you and I respect dogs so don't use dog as an insult.

[Laughter]

CHARLES: Is that 'They Might Be Giants'?

BRANDON: It is not They Might Be Giants. It is three vegan randoes on YouTube.

CHARLES: Is that the name of the band or is that just the content of the band?

BRANDON: No, they're just three vegan randoes on YouTube.

CHARLES: Okay, three vegan randoes is a pretty good band name.

BRANDON: You'll immediately know they're from Portland so you could really pick a lot out of that from just the name of the band. We want to tight 30 today. We don't let people behind the curtain very much, Charles, where people don’t see what it is that you and I do behind the scenes. But one of those things that we do is sometimes we will record a podcast and throw it in the garbage because we hate it, and this is actually one of them. You and I sat down and recorded this podcast before. Just like the hot apple pie Barenaked Ladies reference that I served you earlier, we just dumped it right in the garbage.

We did not like the way that it tasted. We did not like its Barenaked Ladies references, and so this is our second attempt at this. Then the topic that we want to cover today is really important to us to not screw this up. So hopefully, we put a little more effort into preparing for this and thinking very deeply about this.

The idea is that we want to understand from a technical perspective largely what it is that a senior developer is, what they do, how we can find them, how we sometimes miss that, and basically how we define a senior developer so that we can build that as a track for our people to grow toward and find the ones that want to come work with us and may self-identify a senior, how we can kind of verify that. That's the poorly defined topic in our industry, interestingly enough.

CHARLES: Strange, because everybody seems to want that.

BRANDON: Yeah, right. Everybody put it on their job descriptions. Anyway, I wrote a blog post about it. It did all the things that blog posts do when they sort of struck a nerve with the tech industry and they got posted around. I got called literal human feces on Reddit.

CHARLES: Did they call you human feces or do they call you literal human feces?

BRANDON: They said literal --

CHARLES: Did you literally get called literally human feces?

BRANDON: I literally got called literal human feces.

[Laughter]

CHARLES: I shall wear it as a badge of honor.

BRANDON: I was kind of like Ron Burgundy. I'm like, "I'm not even mad, I'm just impressed."

[Laughter]

CHARLES: People had some strong, strong, strong feelings about that.

BRANDON: They did. So now, a skull in a cowboy hat and literal human feces are going to sit here and preach to you about what we think and how we're basically like willing to sink or basically, sink or swim for our business on this definition of senior developer because that actually is core to what it is that we're doing. I want to tee this up and then I'm going to let you just freakin' roll.

The three categories are technical skill, which is the one that people typically think about, evaluate for leadership and connectedness, which sounds all [inaudible] but the reality is it's actually very concrete and very important. The categories [inaudible] leadership is basically the idea that the more ownership you give someone over the broadest version of the problem you're trying to get them to solve, the better they perform.

So if you give somebody a small task, they will maybe perform it. But if you give somebody ownership of the actual problem and the business problem that you're trying to solve or a user's pain point, they will find ways to solve that problem that you wouldn't have considered yourself. They will pull other people into their orbit to solve that thing. Basically, there's a sense of ownership and the experience they have in owning something all the way through to completion basically.

Then, the technical skill one which we'll dive into in this podcast, that's what I want you to kind of drive the conversation around, is basically the idea that the more difficult a problem you hand somebody, the better they perform. A lot of times, that's due to experience, some of it is personality type, some of it is muscles that they like to exercise.

Then, the last one is connectedness, which sounds like it's hard to define but it's actually the idea that the more people that are impacted and the more deeply people are impacted by somebody's participation in a task, the better that person performs. These people like to mentor, they like to be parts of communities, and they have a deep sense of empathy for the users that they build software for and the other developers that they're developing for alongside.

CHARLES: Right, and I think that one of the reasons you got such a negative reaction, you kind of, I think, were assuming technical skill and then really kind of unpacking the leadership and the connectedness as absolutely key components to be what we consider a senior developer. So, kind of pointing out that especially from the leadership aspect, it's like you need to be a wholly-formed developer, you need to have those headlights on the car to see where it is that you're going and you can have a huge engine and like four-wheel drive and like big mud tires that can dig into any surface. But unless, you can actually see where you're going and perceive the problem holistically, those skills aren't going to be put to as good of a use.

BRANDON: I think that's a good metaphor. The idea is that it's traction and direction in addition to the raw technical horsepower that you bring to the table. So pointing out and emphasizing these other areas, I think, made people - there was a lot of confusion. Some people reacted very positively to it like, "Oh my gosh, finally somebody understands that I bring more to the table than just my raw technical capability," especially people from --

CHARLES: I'm going to guess those were the people not in the literal human feces camp.

BRANDON: Well, I didn't set up a Twitter poll or anything but I hope I can assume so. Then there were people that felt very strongly that I was overlooking technical skill. I was like, "No, no, no. That's a fair question. That's Charles's job here." And so that's why, at this point, I am going to drop kick this entire conversation into your side of the metaphorical foot game ball field. I think, football pitch. Pitch, right? Quidditch pitch. I'm going to drop kick the Quaffle into your side of the Quidditch pitch.

CHARLES: Okay, all right. Well, let's unpack the technical skills that we look for. What we're looking for, I think, on the technical side, and this is going to seem obvious but what we're looking for is experience. We’re looking for the quantity of experience and the quality of experience. We can roughly subdivide that into four key areas.

First of all, what's the experience that you've developed around your curiosity? Maybe we should go and lay all these out. We look for curiosity. We look for rigor in your technical skill. We look for your ability and history for actually shipping things, and we look for you to be fearless when it comes to taking on new problems and sizing up the problems that you choose to attack.

When we break down those experiences, if you are a curious person, you have been exposed to a lot of different technologies. So we're going to be looking for, you have an opinion on a bunch of different languages, a bunch of frameworks. We're going to want you to have tried a bunch of different things. We don't want you to have knocked your head against a lot of different problems, and then tried a lot of different solutions. That's going to be very indicative of your ability to bring a diversity of solutions to any given problem that you face.

But it's not just the quantity of the experience that you develop. It’s also like the quality. Like how much in the solutions that you develop are you looking to find the whole solution that fits your problem? How willing are you to do A-Grade work where you consider every corner case and you are willing to dedicate the CPU resources to find the best solution.

Finally, what is the scope of problems that you're taking on? We've talked about the difference between quantity and quality of experience. You can make a career banging out WordPress apps. It's a great place to start but if you're doing it --

BRANDON: Or you can do a CRUD over and over again.

CHARLES: Yeah, you could do CRUD over and over again. Like I said, that's a great place to start at the beginning of your career. But if 20 years on, that's what you're still doing, then you're going to have a lot of experience but is it going to be a high-quality experience? Are you actually taking on bigger and bigger problems, and is the scope of the things that you're tackling growing as you move throughout your career?

BRANDON: It's interesting that's actually like fearlessness, that kind of technical fearlessness is actually a skill a person learns to practice. I was a very fearful developer a few years ago because I felt like if I charged into the bramble of a complex and thorny problem, that was going to cut me up and I die. It turns out, no, it just cuts you up real bad then you get back with thicker skin. And eventually you start going to the point where you start learning to tackle, you learn to take on things you don't understand because that’s literally the job.

CHARLES: I think it's important to point out that fearlessness is a skill. It is not a personality trait and it's something that you have to develop and you can actually take on problems that are too big for you at the given time and kind of have to know when it's time to step back from that. I know that's actually something that I even look for, anecdotally is asking a developer, "What are some of your greatest failures? What are the things where you took on way too much than you could chew? How did it make you fall down flat on your face?" Because that is an artifact and evidence that someone is practicing and taking on things that maybe are too big. Sometimes you're going to overshoot the mark.

You know, you don't want to be taking on too little but one of the ways that you're going to do that is by accidentally taking on too much. And so I find that most people who have a senior level of experience have some big failure story. There's a skeleton in their closet of something they did wrong and they know that they can acknowledge that. I don't know. That's certainly how I feel about it.

BRANDON: Yeah, I can agree with that. I guess you're saying you wrap all of those four things together like whether this person is willing to take on difficult problems, whether they actually complete them, whether they do them in a way that displays that they have enough experience to have kind of developed principles about how they approach stuff and whether they are continuously looking for new ways to approach problems.

Like if you combine all of those things together is this like cool technical Voltron that exhibits a directed, focused kind of practice that over the course of 5 to 10 years yields basically a person that you can throw at any kind of technical problem and they will act like, I don't know, like nanobots just destroying that problem from the outside and until the problem doesn't exist anymore. It's thoroughly solved.

CHARLES: Right. And I think that ties you to this propensity to ship. That’s something that we look for. If this is a skill that you have, if you are at a senior level of experience, you will have a set of technical achievements that we can look at, that you have shipped and we can study them.

Fantastically, as a happy coincidence you can see inside those things that a person has shipped. Are they rigorous? Are they curious and how fearless are they? What's the array of technologies? How unique are the solutions? How informed are they by different technologies and what is the scope of problem that you are trying to take on throughout the course of your career?

So, having actual things that you have shipped whether it's products, whether it's libraries, whether it's open source, something like that, you want to be able to look at those and it is important. We don't rest everything on the GitHub. But I think at a senior level, you should have some equivalent that you can point to, public or otherwise.

BRANDON: Yeah, there's some artifact that pops out of that, and if you made a career of 10 years and you come and say, "Hey, I have been doing this 10 years and I'm a very skilled senior developer but I can't show you anything." I understand that people will find themselves in situations like that but that's going to be, I think, the great exception of the rule.

If you really don't have anything to show, it probably means there's some sort of practice, one of these traits that likely could use a little more exercise on that particular muscle, and that you've been leaning on compensatory muscles in other areas. So that's going to ding you in terms of like, how we evaluate somebody as whether they'll sync or not. And we're open to being surprised. Well, I should probably hopefully get to that before we end our podcast.

CHARLES: I'd like to contrast it with what we look in, in a junior developer because it is very, very different. I think we've talked a lot about or there's a big conversation about, does passion matter in evaluating a candidate? I think passion is a word that's kind of fallen by the wayside but talk about maybe a less charged words like just caring deeply about a product or a solution or something like that.

In a senior developer, to be quite honest, passion and caring is something that we expect to be there but it's not something that we look for because it's not something that we need to look for because if they do care about diversity with technologies, if they have this propensity to ship and they're taking on big problems, then that evidence will be there. So we're not looking for passion because it's either there or it's not. That's something that we look for more in a junior developer because we're going to be looking for that enthusiasm in the same way that you kind of track a hurricane. You don't know exactly what path it is but based on the weather patterns and the basic trajectory, you can find out essentially where it's going to end up.

BRANDON: Yeah, I think there's a lot of talk in the industry about how passion, when people talk about looking for passion, what they're basically saying is we are looking to exploit people who are at the top part of their curve. When you look at how the undulations of a person's amount of passion over the course of their career, you have companies only want to clip off the top of that. As soon as you're not passionate anymore, you jettison that person. What we're looking for is somebody who's sort of stabilized that.

So the passion part of it is like, "Oh, that's cool. The passion is in your past or it's in your present." But we understand that that is a sine wave and we're looking for the line in there that says, "Hey, sometimes I care more than I care about other times but the main thing is I produce things."

Otherwise, instead of looking at as a sine wave of passion, you're like trying to exploit it at the top and then going, "Well, this is just going to keep going up and up and up," and you burn people out for that.

CHARLES: We look for, "Hey, here, we build things. So, if you're at the beginning of the career, are you following a path that will lead you to build good things and then at the end we're kind of towards the back half." We are looking at, "Hey, what are the things that you have built that are capable of building?" And that's the extent of it. I don't want to suck all the emotion out of it but the thing is that I want to suck the pressure out of it.

BRANDON: Yeah, and the way that we try to assess that right now is we do this in a full day pairing interview. We do a lot of stuff that leads up to that and hopefully, the ancillary stuff we do around that helps gauge like, "Hey, this person is active in the community in some way, or they try to make contributions to people this way." We do our best to get a sense of the stuff that is not pure technical skill because delivery, it takes longer than a day. So, how well does this person deliver? How well do they work with other people? That stuff is very difficult to suss out in a day but you can generally get a sense of like technical experience capability.

So I kind of want to focus on like during the course of the pairing interview, what it is that you're sussing out? How do you know a person in a pairing interview is exhibiting those technical leadership traits, technical skill traits?

CHARLES: I'll beat this drum again. I'm looking for quantity and quality of experience. It comes down to little things. How comfortable is a person with their tool set and that demonstrates both the experience and you can tell if it's good experience or not. How comfortable are they with the command line? How comfortable are they with Git? Are they taking baby steps with it or they doing large motions in one kind of fell swoop? Like, how effortlessly is the muscle memory there?

Whatever the tool set is, whether you're using iTerm, whether you're using C-shell or bash or whatever editor you're using, I do expect to see a familiarity that can only come through having done it again and again and again and again. So, if you're working with Git, for example, and you're kind of stumbling and stuttering at what commands to run or pausing, when you are parsing the output of a command if there's an error or something didn't go, what that says is either you don't have the experience which is most of the case or that has not been a priority in the experience that you do have. So there's like kind of a difference in the quantity and quality of experience.

Some people move fast. Some people live slow but I want to say continuity that I'm looking for, in the same way that you can play a piano quickly, you can play it slowly but when people are missing notes, you can detect that. That's what I'm looking for, kind of with the tool sets. When someone is moving within a code base, I'm looking for confidence of motion.

I remember an interview that we did recently where we were working in a code base. We're trying to get something running and this developer deleted like two directories at a time that caused like 10 files to be just missing from the code base. Just gone, at the stroke of a key. Then, we ran the test again, and lo and behold, like everything worked. Or the test that we were expecting to fail failed.

BRANDON: Or was that the test directory?

CHARLES: Sorry, what I meant was --

BRANDON: No, I know what you mean. They were comfortable enough in their understanding of the code base they were working in.

CHARLES: Right. There was a high level. We were not down in the weeds. There's like you're applying very light pressure to the code base to make it move in gigantic swings so you understand the pressure points and you can zero right in on it.

BRANDON: You can say you're looking for like, the aikido development strategy or whatever.

CHARLES: Right, and then the other thing is being able to -- and this is important because I don't believe that every coding session or every pairing session needs to be this dance across the keyboard. Certainly there are times when you recognize that it's natural to stop, to pause, and have a discussion and say, "Wait a second. What are we doing here? Let's hash this through," and be able to converse at the higher level of where exactly are we going because normally you have fallen into this rhythm, or you've got a driver, you got a navigator but then sometimes you have to stop. You have to take your bearing and realizing when that time is and naturally transition into that, and be able to discuss the problem at its highest level where the code really and the tools that you're using really fade away into the background. They're not important.

Then you can transition back and I'm looking for a pair in that conversation and I'm looking especially for someone who can teach me something. If there's a knowledge gap that I have or a perspective that I haven't seen, so when I'm looking for where it is that we're going, if someone helps me pair around a corner, that's a huge indicator that this person is senior. Because not only do they have that perception but they can also share it with me and they can effectively argue for it and make me see it, as well.

BRANDON: Another thing for me in that same vein is the ability to be challenged. Like, for a person to challenge and be challenged. So they go, "Hey, I have an opinion about this," and you go, "Well, what about this?" And they're like, "Gosh. I never really thought about that." Or they defend their position or they push you on something, "Why don't you do it this way?" And you're like, "Well, I've always done it this way but let's try it your way."

So the ability to challenge and be challenged particularly, that is sussed out in a pairing interview, you could probably do that asynchronously through a pull request and stuff like that. But just being able to suss out, whether somebody can challenge and be challenged as a part of the educational process means that this person sharpens the people around them and they're sharpened by the people around them.

CHARLES: Absolutely. I am looking for that ability to be collaborative at that level and to educate those people around them just by virtue of their interaction.

BRANDON: One thing that sort of heretical in some circles and it seems weird to me but if you look at 95% of jobs descriptions, they will tell you, "We are looking for X number of years in X technology," and I don't want to discount the years thing. The thing is gaining experience takes hours of practice, of dedicated practice and those hours add up to years. So you're typically you are talking in the scale of years when you're talking about experience so there's not really a way around the fact that you were going to be talking on the scale of years.

I think that's not worthy of too much debate. It can take some people two years to learn something. It might take somebody else 10. But that you are talking about a scale of years. The thing that I want to challenge is the idea that language and framework experience is the thing that you're looking for. We have a lot of counter experience so that where people cross those boundaries and lines so I didn't really have that thought before talking to you about this so you kind of pushed my thinking in this regard, like why don't we care about that or why do we care less about that than others might?

CHARLES: From my perspective, it kind of flies in the face of the way we operate. If we're requiring that someone have a certain number of years of one particular technology, we're asking them to be curious. We're asking them to be diverse. We're asking them to be able to be fluid and slot themselves into any problem space. So, why would we then demand all of those things and then, "By the way, you need to be able to be slotted into this problem space to come work here."

I think that something that gets overused in the industry. I think it does make sense in certain cases. For example, not for a developer position, it's less than $250,000. Like if you want someone with five years of MySQL experience or something to manage who has to do micro-optimizations for these huge scale things and you want to pay them half a million dollars, because that's the thing that you need, you really need somebody with that much experience in that technology. Well gosh, they'd better be charging you a lot of money for that experience. Like, "You literally want to buy five years of my life? Okay. I can do that. But I'm going to think if that really is your need, that's what I'm going to be charging you for."

But we're looking for people who will be able to move into any problem space that we come across and that necessarily implies language and framework. In fact, one of the things that I like best, I talked about evaluating for the ability to teach and that was inside the context of the one project that we're looking at, but I've had great experiences where someone has taught me something completely outside of certainly my level of expertise, and sometimes outside of what I've even heard of before.

That's a much better like if we're working on a JavaScript project, and you can say, "Oh, this is how we do things in Scala, and maybe we can apply that here." Man, that is so valuable, and that has nothing to do with JavaScript experience and everything not to do with it. So what we're looking for is you to be able to bring to bear the arsenal of tools that you have developed throughout the course of your career and all zero them in on a problem and just blast it out of the water. So why would you limit that? Why bring one gun when you can bring 30, and one of them is a howitzer.

BRANDON: That makes a ton of sense. It's the idea that is connected to our purpose which is like one of our purposes in existence is to advance the state of the art in UI engineering. That may sound like BS but it's very true. That is very much why you get up in the morning and come to work. It's like half of it is about creating a generation of leaders, and half of it is advancing the state of the art in UI engineering.

Advancing the state of the art in UI engineering is not going to happen if you only bring people in who already think the things that everybody else is already thinking in UI engineering. So, we need people with orthogonal experience in other things so it's the diversity of experience that actually helps us get closer to that goal. Bringing tool sets from alternate languages and frameworks is a huge way to bring that to bear.

I also think it's a way that our industry is like an adorable little baby. It's adorable. Basically, 95% of the people in our industry are generalists, and we hire, as if we're all hiring for the 5% that is a specialist because we don't know how to do this as an industry. We're just a baby. When you think about it, it is kind of adorable. We're all kind of making this up as we go along so if we can start like the goal here is to kind of push this conversation forward and understand, maybe it's counterintuitive to hire a passionate specialist when what you're looking for is a stable generalist, primarily as an industry.

Start understanding, maybe these are some of the ways that we've accidentally been making our industry narrower and less diverse is we're looking for people that started programming on a TRS-80 back in 1984 or whatever. And so the problems that come along with that, we're starting to have to struggle and cope with now. So, anyway, in our own tiny little corner of the universe just for our local maximum of trying to build a better software consultancy, it makes a ton of sense for us to look for generalists.

CHARLES: Yeah, that's definitely fits right with our value proposition is that we do UI but we can apply our UI skills to any number of problems. But it might not make sense. Like I said, if you're managing some gigantic database cluster and you need really, really, really specific skills, I just hope whoever that is you're charging a lot of money.

BRANDON: Yeah, you can get away with generalizing and going, "Hey, I'm going to select for a lot of things." But if you're going to specialize, you basically have to go for money. I think we're getting into the place where we're pulling this into a tight 30 minutes. We've got to wrap this up.

There's always a million more things to say on these topics but I feel like, I've learned a lot through the course of preparing and then doing this with you today to around like why we do what we do? What we're looking for technically? It'd be really cool, 'Hint, hint', that this turned into a blog post on your part. Because I do feel like it was the piece that was missing in people that kind of riled them up a little bit. It is an important piece like not to just --

CHARLES: It's okay people, we do care about technology. We do care about technical skill. In fact, we are a company dedicated to developing it.

BRANDON: Yeah, that's true. People have to walk out with more of that than they walk in with or we fail. But that's not going to stop the people from yelling at you.

CHARLES: Hey, it's fun. It's fun to yell on Twitter.

BRANDON: It is funny. It's fun. All right, man. Well, this was really cool and I hope we get to do this again. We basically are in the process of kind of rebooting our podcast and getting in on track while we record it. Every two weeks at least, we have guests lined up --

CHARLES: Do we want to share like a sneak preview?

BRANDON: Oh, gosh. Yeah, I mean with the people that we're talking to soon, we're going to have a conversation with Ember Sherpa about apprenticeship. We're going to have a conversation with Leah Silber about building communities. Then, there's a ton more in the hopper. This is going to be a really good rest of the year for this podcast and we're going to get consistent about it and we've hired help with it. We're really excited to have Mandy Moore. She's @DevReps on Twitter, if you are looking for any assistance with stuff like this. And we're really excited to start kind of kicking off a new --

CHARLES: A new era.

BRANDON: But for those of you --

CHARLES: For those who like the intermittent, unreliable, yet sometimes pleasing dead cast, we'll interleave a few of those too.

BRANDON: We'll do our best but this is yeah, for those people, I must apologize. I really liked how infrequent it was. Like, oh man. Maybe just check in every once in a while.

CHARLES: Yeah, it's cool. All right.

BRANDON: Charles, it's been great talking to and I can't wait for next time.

CHARLES: Yep, likewise, man.