Podcast appearances and mentions of leah silber

Leah Silber is the CEO of Tilde, and she and her company have been involved in various open source projects over the years, from jQuery and Rails, to Ember and Rust. Her belief is that open source work is more than just the programming: it's also corralling issues, finding the right people for the right problems, and more "real world" tasks such as setting up events and conferences. Because of this, she doesn't believe there's a strong delineation between "skills for a business" and "skills for a project." Allowing employees to explore new roles in projects that they love helps their skill set grow, and those skills can in turn make them better employees. The key to this dynamic is demonstrating OSS values at work. When you treat someone's contributions to projects as an essential parts of their role, there isn't a direct correlation with the relationship between the company and the project. You are investing in the person and the technology, and in the long run, this will benefit the business. Leah also believes that it's important for open source communities to not have a single point of failure by way of a single company being invested in a technology. If, for some reason, a business' needs shift away from a particular language or tool, the last thing anyone would want would be for an open source project to wither as a result of it. This is another reason why a company backing an open source project should be much more receptive of accepting contributions for contributors. Finally, by having companies more involved in open source projects via their employees, they can direct and guide the project to satisfy their own business needs. The two entities--company and project--can discuss their needs and arrive at solutions together, rather than introducing fragmentation. What's good for a company may also be good for the community, and what's more, the community may have more stable and reliable implementations for any single company's ideas. Links from this episode Event Driven is Leah's book about running memorable tech conferences

Parent Driven Development Episode 013: Babies at Work?! 00:15 Welcome, Leah Silber! (https://twitter.com/wifelette) Leah is the CEO of Tilde Inc. (https://www.tilde.io/) She is also an organizer of EmberConf (https://emberconf.com/), RustConf (https://rustconf.com/) and RailsConf (https://railsconf.com/), and Ember.js Core Team (https://www.emberjs.com/team/) Member, a jQuery Core Team (https://jquery.org/team/) alum, author of Event Driven: How to Run Memorable Tech Conferences (https://leanpub.com/eventdriven/), and all around technophile. 01:08 KWu is Planning Her Son's 1st Birthday Party! + How Old Are They? Don't let first birthday parties get out of hand. Not worth it. Get a cake. Let the kid smash. Also, please stop referring to your child's age in months when they turn 2. 04:05 Babies at Work: It’s Weird that it’s Weird (https://hackernoon.com/babies-at-work-its-weird-that-it-s-weird-b285b070d456) In August 2017, Leah wrote this blog post and it was super well received. In the blog post, she talks about a lot of the objections and concern she had at first that turned out to be unfounded. It turns out, bringing her baby to work changed the mood and culture of Tilde in a positive way -- even among self-proclaimed "non-baby people". 09:26 What About The Fussy Days? Working from home can be an option especially on days like vaccination days. Having a quiet area like a conference room or an empty office gets people through short fussy spells. If that doesn't work, going home is encouraged. Leah says that having the babies at work made actually for a much happier baby! 17:56 Nursing Up to the mom! Breastfeeding in public is acceptable, and there are dedicated nursing rooms/spaces to keep it legal (and more private) It becomes normalized! People don't even notice Squatty Potty (https://www.squattypotty.com/) 23:53 Culture From The Core Stating expectations for parents/non-parents during the interview process Scaling as children age Bring the Nanny to work too! Older children must be up to date on vaccinations Becomes a routine 32:43 Does Company Size Matter? Just because there are 50 people in a company does not mean that the volume of babies is going to go up Setting a limit is an option: luck of the draw The bigger the company, the more space non-baby people have to stay away from the babies 35:02 Program Evolution Effects on Nannies Beneficial for dads too! 42:37 Avoiding Judgement Turns out, people (who aren't the child's parents) are more helpful than judgemental Pets are not babies...no, your dog can not come to work because my baby is here 48:31 Genius / Fail Moments KWu: Water coming out of the tub faucet is fascinating and acts as a baby magnet to draw them to the bathroom for a bath! (#Genius) Allison: Creating an insane schedule of hodgepodge childcare that involves massive amounts of logistics. (#Fail) Leah: Shoutout to the parents who think their kids will never walk. Her son started walking at 18 months! (#Genius) Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Our website is at ParentDrivenDevelopment.com (https://parentdrivendevelopment.com). We are listener supported. Please consider Supporting us via Patreon (https://www.patreon.com/parentdrivendev) and gaining access to our our kind Slack Community. Panel Allison McMillan (https://twitter.com/allie_p) Katherine Wu (https://twitter.com/kwugirl) Special Guest: Leah Silber.

Organizing Technical Conferences TableXI is now offering training for developers and products teams! For more info, go to http://tablexi.com/workshops (http://tablexi.com/workshops). Get your FREE career growth strategy information and techniques! (https://stickynote.game) Summary I've been attending technical conferences for years, and I've always wondered about the hidden challenges involved in putting a conference together. In this show, four of the best conference organizers I know join me to share their secrets and stories. Marty Haught, organizer of many conferences including RubyConf and RailsConf, Jen Remsik and Jim Remsik, who organize the Madison+ family of conferences, and Leah Silber, who organizes EmberConf and RustConf. Learn about budgets, picking talks, and managing facilities and vendors. Guests Marty Haught (https://twitter.com/mghaught): President at Haught Codeworks (https://haughtcodeworks.com/), Director at Ruby Central (http://rubycentral.org/) organizing RailsConf and RubyConf Jen Remsik (https://twitter.com/jenremsik): Director of People Operations at Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby) Jim Remsik (https://twitter.com/jremsikjr): President of Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby). Leah Silber (https://twitter.com/wifelette): CEO at Tilde Inc. (http://www.tilde.io/). EmberConf (https://emberconf.com/), RustConf (http://rustconf.com/), and RailsConf (https://railsconf.com/) Organizer. Author of Event Driven: How to Run Memorable Tech Conferences (https://leanpub.com/eventdriven). Notes 03:12 - Getting Things Right and Having Empathy for Attendees 11:16 - Budgetary Aspects 14:53 - Planning Conferences in Other Cities 18:22 - Putting the Program Together and Selection Processes 29:25 - Crafting a Conference Proposal 31:12 - Encouraging and Enabling Attendee Interaction 40:03 - Conference Mentorship 41:26 - Words of Advice Special Guests: Jen Remsik, Jim Resmsik, Leah Silber, and Marty Haught.

Tweet this Episode Allison is a developer in the Washington DC area. She is a non-profit executive turned developer. She helps organize the RubyConf and RailsConf Scholar Program. She organizes a local meetup call Silver Spring Ruby. She works at Collective Idea. The Rogues talk to Allison about being a mom in coding and work-life balance.  They also talk about transitioning from non-profits to coding.  This episode goes into depth on: Prioritizing your family and still having a great career Goal setting, focus, and growth Team collaboration Contributing to open source and much, much more... Links: Delayed Job Allison's Blog Baby Driven Development talk Rails Girls Ruby Dev Summit RSpec Minitest RailsCasts Interactor Gem Leah Silber from Tilde tweet Tilde article on Baby at Work Mother Coders RailsBridge Allison on Twitter Picks: Eric: Gallup Strengths Test Metabase Allison: Sticky Note Game by TableXI WriteSpeakCode Ruby Jewel Crystal DISC Assessment Dave Rails Guides

Tweet this Episode Allison is a developer in the Washington DC area. She is a non-profit executive turned developer. She helps organize the RubyConf and RailsConf Scholar Program. She organizes a local meetup call Silver Spring Ruby. She works at Collective Idea. The Rogues talk to Allison about being a mom in coding and work-life balance.  They also talk about transitioning from non-profits to coding.  This episode goes into depth on: Prioritizing your family and still having a great career Goal setting, focus, and growth Team collaboration Contributing to open source and much, much more... Links: Delayed Job Allison's Blog Baby Driven Development talk Rails Girls Ruby Dev Summit RSpec Minitest RailsCasts Interactor Gem Leah Silber from Tilde tweet Tilde article on Baby at Work Mother Coders RailsBridge Allison on Twitter Picks: Eric: Gallup Strengths Test Metabase Allison: Sticky Note Game by TableXI WriteSpeakCode Ruby Jewel Crystal DISC Assessment Dave Rails Guides

Tweet this Episode Allison is a developer in the Washington DC area. She is a non-profit executive turned developer. She helps organize the RubyConf and RailsConf Scholar Program. She organizes a local meetup call Silver Spring Ruby. She works at Collective Idea. The Rogues talk to Allison about being a mom in coding and work-life balance.  They also talk about transitioning from non-profits to coding.  This episode goes into depth on: Prioritizing your family and still having a great career Goal setting, focus, and growth Team collaboration Contributing to open source and much, much more... Links: Delayed Job Allison's Blog Baby Driven Development talk Rails Girls Ruby Dev Summit RSpec Minitest RailsCasts Interactor Gem Leah Silber from Tilde tweet Tilde article on Baby at Work Mother Coders RailsBridge Allison on Twitter Picks: Eric: Gallup Strengths Test Metabase Allison: Sticky Note Game by TableXI WriteSpeakCode Ruby Jewel Crystal DISC Assessment Dave Rails Guides

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: Leah Silber: EmberConf 2016: The Morning-After Post-Mortem Event Driven: How to Run Memorable Tech Conferences 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. I started with my co-founders, I started my own company about five years ago which I'm always pleased and astonished to still be existing. Obviously, I watched companies spin up and die down overnight in the fast-paced technology sector. So, I'm a fan of stability and continuing to exist, is basically the top of my list. But that was about five years ago now, and it's been really great. I would never previously have identified myself as an entrepreneur. I had this, I want to say now, misconception that I was a support person, that I was the perfect second-in-command that I needed somebody at the top of the food chain who had these brilliant ideas and then I would be the person who would come in and say, "Great idea. Let me make it happen for you," and like operations and execution. 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. The first and most obvious is your idea gets better because people point out things that you didn't think of or don't necessarily personally have the experience or have noticed. But also, people just feel consulted in a way that is more critical. I like to think people want to feel consulted in work environments also. But I guess when you're the boss, you can get away with just saying, "This is the policy. I made the policy." 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. Like, when you say they want to have their needs represented and they want to be a part of the RFC process, there is some part of it where I guess a lot of it has to do with just any kind of connection with other people who do the same thing or probably do the textbook one. But I also feel for a lot of people, there's a desire to be able to have their needs represented and met and feel like they are somehow a part of the direction of this thing, as well. 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. You can always sort of ride the ship most of the time. But if you start out on the right path to begin with, you're going to be able to accomplish so much more because you don't have that much course correcting to do. There is obviously, also always course correcting in Ember, in Rust, in Rails, everywhere, where somebody not speaking about code but somebody takes a misstep and the whole community sort of has to figure out like, "Okay, this is not the way we want. This is the kind of interaction to go. How are we going to fix this?" Or, "This is not the way we want. There's kind of major technical decisions to be made. How are we going to fix this?" 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. There's a lot of stuff that can get done for a project that doesn't involve writing a line of code. Now, obviously you want to have somebody around who understands open source and the strategy. It is in fact challenging to find people who don't have to be coders but also appreciate all this other stuff and want to be involved in it. But when you can find people like that, that's the really magical key to this more well-rounded community. 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. But I sort of forced myself to write it anyway because it was just such a big endeavor and there were thoughts even for myself that I wanted to preserve for later. Then I was pleasantly surprised by how many people read it and had comments and had useful things to say, or even just like, "I appreciate how much thought went into XYZ. I wouldn't have thought that. 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. So basically, I looked at the conference in 2015 and it was great. I was really happy with most areas of it but I was not happy with the representation of women. There's so many groups that in fact, the conference would benefit from that representation of, but women was obviously a target that I thought I could potentially bring something to the table on being a woman in technology and in Ember. 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." Now, I think there's certainly ways to do it and there's a lot of clever ways to meet people and encourage people. But when push comes to shove, and it's in that moment, you would just run into a lot of organizer saying, "Well, I don't know what to do. It's an open process. Anyone can submit." And now, they could look at our conference and see there's a dozen women who are clearly talented and capable. I'm going to go to all 12 of those people and ask them to submit to my conference. Maybe some of them will and maybe that will help. 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. We're focusing a lot on that this year or I should say, we're going to start on how can we expand the program to be a resource that helps women take leadership roles and speaking opportunities across the JavaScript ecosystem so that Ember is really truly well represented by the people who actually make up the community. 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. It's the same thing as being a CEO or being the second-in-command. You just need to have the boldness to decide that you're going to try and make a difference. In the Women Helping Women program specifically, I've been talking to a lot of the women that I met last year about how can you take more of a leadership role in the program? For example, I was talking a week ago to somebody who's a student in the Women Helping Women program and I was like, "I can't represent your concerns as well as you can." I was in college at some point but that was a very long time ago, and there are just perspectives that you're going to have that I'm not going to have. 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.

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: The Conjoined Triangles of Senior-Level Development Don't use animal names as an insult 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. I want to provide a little background. The cool thing is, I already wrote a blog post so I don't have to sit here and talk at your face about these things. I was going to tell you some additional thought I've had about this. But basically, the point of this blog post was that we generally categorize what it is to be senior developer in three broad categories that have a little bit of overlap. 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. Anyway, so it's not something we look for. It doesn't make sense. It's not sustainable and it's actually something that in a senior developer has stabilized enough that you're not going to see it. 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.

Check out Newbie Remote Conf!   02:38 - Yehuda Katz Introduction Twitter GitHub Blog Tilde Peter Solnic: My time with Rails is up Peter Solnic: Abstractions and the role of a framework (Follow-up) Ember.js The Skylight Blog: Inside Skylight 05:37 - Batching Updates 10:04 - Naming Fastboot Services glimmer 14:19 - Communication Skylight 16:21 - Decorators 19:46 - “Junior Developer” and Knowledge Bias CodeNewbie Ep. 90: Creating EmberJS - Part I with Yehuda Katz CodeNewbie Ep. 91: Creating EmberJS - Part II with Yehuda Katz 28:25 - Termanology in Tech 29:23 - Diversity Women Helping Women   Picks Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Yehuda) TypeScript (Yehuda) emberjs/rfcs (Yehuda) rust-lang/rfcs (Yehuda) Pretty Pull Requests (Aimee) Full-Stack Redux Tutorial by Tero Parviainen (Aimee) The mountains (AJ) The quadruple click in iTerm2 (Dave) 2016 UtahJS Conference (Dave) Start With Why by Simon Sinek (Chuck)

Check out Newbie Remote Conf!   02:38 - Yehuda Katz Introduction Twitter GitHub Blog Tilde Peter Solnic: My time with Rails is up Peter Solnic: Abstractions and the role of a framework (Follow-up) Ember.js The Skylight Blog: Inside Skylight 05:37 - Batching Updates 10:04 - Naming Fastboot Services glimmer 14:19 - Communication Skylight 16:21 - Decorators 19:46 - “Junior Developer” and Knowledge Bias CodeNewbie Ep. 90: Creating EmberJS - Part I with Yehuda Katz CodeNewbie Ep. 91: Creating EmberJS - Part II with Yehuda Katz 28:25 - Termanology in Tech 29:23 - Diversity Women Helping Women   Picks Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Yehuda) TypeScript (Yehuda) emberjs/rfcs (Yehuda) rust-lang/rfcs (Yehuda) Pretty Pull Requests (Aimee) Full-Stack Redux Tutorial by Tero Parviainen (Aimee) The mountains (AJ) The quadruple click in iTerm2 (Dave) 2016 UtahJS Conference (Dave) Start With Why by Simon Sinek (Chuck)

Check out Newbie Remote Conf!   02:38 - Yehuda Katz Introduction Twitter GitHub Blog Tilde Peter Solnic: My time with Rails is up Peter Solnic: Abstractions and the role of a framework (Follow-up) Ember.js The Skylight Blog: Inside Skylight 05:37 - Batching Updates 10:04 - Naming Fastboot Services glimmer 14:19 - Communication Skylight 16:21 - Decorators 19:46 - “Junior Developer” and Knowledge Bias CodeNewbie Ep. 90: Creating EmberJS - Part I with Yehuda Katz CodeNewbie Ep. 91: Creating EmberJS - Part II with Yehuda Katz 28:25 - Termanology in Tech 29:23 - Diversity Women Helping Women   Picks Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Yehuda) TypeScript (Yehuda) emberjs/rfcs (Yehuda) rust-lang/rfcs (Yehuda) Pretty Pull Requests (Aimee) Full-Stack Redux Tutorial by Tero Parviainen (Aimee) The mountains (AJ) The quadruple click in iTerm2 (Dave) 2016 UtahJS Conference (Dave) Start With Why by Simon Sinek (Chuck)

02:52 - David Herman Introduction Twitter Blog JavaScript Jabber Episode #54: JavaScript Parsing, ASTs, and Language Grammar w/ David Herman and Ariya Hidayat JavaScript Jabber Episode #44: Book Club! Effective JavaScript with David Herman Effective JavaScript by David Herman @effectivejs TC39 Mozilla 03:50 - The Rust Programming Language [GitHub] rust 06:31 - “Systems Programming Without Fear” 07:38 - High vs Low-level Programming Languages Garbage Collection and Deallocation Memory Safety Performance and Control Over Performance 11:44 - Stack vs Heap Memory Etymology of "Foo" RAII (Resource Acquisition Is Initialization) 16:52 - The Core of Rust Ownership Type System 24:23 - Segmentation Fault (Seg Faults) 27:51 - How much should programmers care about programming languages? Andrew Oppenlander: Rust FFI (Embedding Rust in projects for safe, concurrent, and fast code anywhere.) 32:43 - Concurrency and Multithreaded Programming 35:06 - Rust vs Go 37:58 - servo 40:27 - asm.js emscripten 42:19 - Cool Apps Built with Rust Skylight Wit.ai 45:04 - What hardware architectures does the Rust target? 45:46 - Learning Rust Rust for Rubyists by Steve Klabnik Picks Software Engineering Radio (Dave) How Will You Measure Your Life? by Clayton M. Christensen (Dave) The Presidents of the United States of America (Dave) Design Patterns in C (AJ) Microsoft Edge Dev Blog: Bringing Asm.js to Chakra and Microsoft Edge (AJ) The Web Platform Podcast: Episode 43: Modern JavaScript with ES6 & ES7 (AJ) Firefox Fame Phone (AJ) iTunes U CS106A (Programming Methodology) (Aimee) Valerian Root on Etsy (Aimee) The Dear Hunter - Live (Jamison) Designing Data-Intensive Applications by Martin Kleppmann (Jamison) Fogus: Perlis Languages (Jamison) Galactic Civilizations III (Joe) Visual Studio Code (Joe) Tessel 2 (Dave) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Dave) Plush Hello Kitty Doll (Dave)

02:52 - David Herman Introduction Twitter Blog JavaScript Jabber Episode #54: JavaScript Parsing, ASTs, and Language Grammar w/ David Herman and Ariya Hidayat JavaScript Jabber Episode #44: Book Club! Effective JavaScript with David Herman Effective JavaScript by David Herman @effectivejs TC39 Mozilla 03:50 - The Rust Programming Language [GitHub] rust 06:31 - “Systems Programming Without Fear” 07:38 - High vs Low-level Programming Languages Garbage Collection and Deallocation Memory Safety Performance and Control Over Performance 11:44 - Stack vs Heap Memory Etymology of "Foo" RAII (Resource Acquisition Is Initialization) 16:52 - The Core of Rust Ownership Type System 24:23 - Segmentation Fault (Seg Faults) 27:51 - How much should programmers care about programming languages? Andrew Oppenlander: Rust FFI (Embedding Rust in projects for safe, concurrent, and fast code anywhere.) 32:43 - Concurrency and Multithreaded Programming 35:06 - Rust vs Go 37:58 - servo 40:27 - asm.js emscripten 42:19 - Cool Apps Built with Rust Skylight Wit.ai 45:04 - What hardware architectures does the Rust target? 45:46 - Learning Rust Rust for Rubyists by Steve Klabnik Picks Software Engineering Radio (Dave) How Will You Measure Your Life? by Clayton M. Christensen (Dave) The Presidents of the United States of America (Dave) Design Patterns in C (AJ) Microsoft Edge Dev Blog: Bringing Asm.js to Chakra and Microsoft Edge (AJ) The Web Platform Podcast: Episode 43: Modern JavaScript with ES6 & ES7 (AJ) Firefox Fame Phone (AJ) iTunes U CS106A (Programming Methodology) (Aimee) Valerian Root on Etsy (Aimee) The Dear Hunter - Live (Jamison) Designing Data-Intensive Applications by Martin Kleppmann (Jamison) Fogus: Perlis Languages (Jamison) Galactic Civilizations III (Joe) Visual Studio Code (Joe) Tessel 2 (Dave) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Dave) Plush Hello Kitty Doll (Dave)

02:52 - David Herman Introduction Twitter Blog JavaScript Jabber Episode #54: JavaScript Parsing, ASTs, and Language Grammar w/ David Herman and Ariya Hidayat JavaScript Jabber Episode #44: Book Club! Effective JavaScript with David Herman Effective JavaScript by David Herman @effectivejs TC39 Mozilla 03:50 - The Rust Programming Language [GitHub] rust 06:31 - “Systems Programming Without Fear” 07:38 - High vs Low-level Programming Languages Garbage Collection and Deallocation Memory Safety Performance and Control Over Performance 11:44 - Stack vs Heap Memory Etymology of "Foo" RAII (Resource Acquisition Is Initialization) 16:52 - The Core of Rust Ownership Type System 24:23 - Segmentation Fault (Seg Faults) 27:51 - How much should programmers care about programming languages? Andrew Oppenlander: Rust FFI (Embedding Rust in projects for safe, concurrent, and fast code anywhere.) 32:43 - Concurrency and Multithreaded Programming 35:06 - Rust vs Go 37:58 - servo 40:27 - asm.js emscripten 42:19 - Cool Apps Built with Rust Skylight Wit.ai 45:04 - What hardware architectures does the Rust target? 45:46 - Learning Rust Rust for Rubyists by Steve Klabnik Picks Software Engineering Radio (Dave) How Will You Measure Your Life? by Clayton M. Christensen (Dave) The Presidents of the United States of America (Dave) Design Patterns in C (AJ) Microsoft Edge Dev Blog: Bringing Asm.js to Chakra and Microsoft Edge (AJ) The Web Platform Podcast: Episode 43: Modern JavaScript with ES6 & ES7 (AJ) Firefox Fame Phone (AJ) iTunes U CS106A (Programming Methodology) (Aimee) Valerian Root on Etsy (Aimee) The Dear Hunter - Live (Jamison) Designing Data-Intensive Applications by Martin Kleppmann (Jamison) Fogus: Perlis Languages (Jamison) Galactic Civilizations III (Joe) Visual Studio Code (Joe) Tessel 2 (Dave) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Dave) Plush Hello Kitty Doll (Dave)

02:26 - Aimee Knight Introduction Twitter GitHub Blog Message Systems 02:48 - Figure Skating => Programming Persistence Balance Between Mind and Body 05:03 - Blogging (Aimee’s Blog) 06:02 - Becoming Interested in Programming Treehouse @treehouse Code School @codeschool Rails Girls @railsgirls RailsBridge @railsbridge 08:43 - Why Boot Camps? 10:04 - Mentors Identifying a Mentor Continuing a Mentorship 13:33 - Picking a Boot Camp 16:23 - Self-Teaching Prior to Attending Boot Camps 20:33 - Finding Employment After the Boot Camp Baltimore NodeSchool Passion Interview Prep 26:27 - Being a “Woman in Tech” 30:57 - Better Preparing for Getting Started in Programming Be Patient with Yourself 32:07 - Interviews Getting to Know Candidates Coding Projects and Tests 41:05 - Should you get a four-year degree to be a programmer? Eliza Brock Picks Aarti Shahani: What Cockroaches With Backpacks Can Do. Ah-mazing (Jamison) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Jamison) The Hiring Post (Jamison) Kate Heddleston: Argument Cultures and Unregulated Aggression (Jamison) Axios AJAX Library (Dave) Unbroken: A World War II Story of Survival, Resilience, and Redemption by Laura Hillenbrand (Dave) [YouTube] Good Mythical Morning: Our Official Apocalypse (AJ) Majora's Mask Live Action: The Skull Kid (AJ) The Westin at Lake Las Vegas Resort & Spa (Joe) Alchemists (Joe) Valerie Kittel (Joe) The Earthsea Trilogy: A Wizard of Earthsea; The Tombs of Atuan; The Farthest Shore by Ursula K. Le Guin (Chuck) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Freelancers’ Answers (Chuck) Drip (Chuck) Brandon Hays: Letter to an aspiring developer (Aimee) SparkPost (Aimee) Exercise and Physical Activity (Aimee)

02:26 - Aimee Knight Introduction Twitter GitHub Blog Message Systems 02:48 - Figure Skating => Programming Persistence Balance Between Mind and Body 05:03 - Blogging (Aimee’s Blog) 06:02 - Becoming Interested in Programming Treehouse @treehouse Code School @codeschool Rails Girls @railsgirls RailsBridge @railsbridge 08:43 - Why Boot Camps? 10:04 - Mentors Identifying a Mentor Continuing a Mentorship 13:33 - Picking a Boot Camp 16:23 - Self-Teaching Prior to Attending Boot Camps 20:33 - Finding Employment After the Boot Camp Baltimore NodeSchool Passion Interview Prep 26:27 - Being a “Woman in Tech” 30:57 - Better Preparing for Getting Started in Programming Be Patient with Yourself 32:07 - Interviews Getting to Know Candidates Coding Projects and Tests 41:05 - Should you get a four-year degree to be a programmer? Eliza Brock Picks Aarti Shahani: What Cockroaches With Backpacks Can Do. Ah-mazing (Jamison) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Jamison) The Hiring Post (Jamison) Kate Heddleston: Argument Cultures and Unregulated Aggression (Jamison) Axios AJAX Library (Dave) Unbroken: A World War II Story of Survival, Resilience, and Redemption by Laura Hillenbrand (Dave) [YouTube] Good Mythical Morning: Our Official Apocalypse (AJ) Majora's Mask Live Action: The Skull Kid (AJ) The Westin at Lake Las Vegas Resort & Spa (Joe) Alchemists (Joe) Valerie Kittel (Joe) The Earthsea Trilogy: A Wizard of Earthsea; The Tombs of Atuan; The Farthest Shore by Ursula K. Le Guin (Chuck) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Freelancers’ Answers (Chuck) Drip (Chuck) Brandon Hays: Letter to an aspiring developer (Aimee) SparkPost (Aimee) Exercise and Physical Activity (Aimee)

02:26 - Aimee Knight Introduction Twitter GitHub Blog Message Systems 02:48 - Figure Skating => Programming Persistence Balance Between Mind and Body 05:03 - Blogging (Aimee’s Blog) 06:02 - Becoming Interested in Programming Treehouse @treehouse Code School @codeschool Rails Girls @railsgirls RailsBridge @railsbridge 08:43 - Why Boot Camps? 10:04 - Mentors Identifying a Mentor Continuing a Mentorship 13:33 - Picking a Boot Camp 16:23 - Self-Teaching Prior to Attending Boot Camps 20:33 - Finding Employment After the Boot Camp Baltimore NodeSchool Passion Interview Prep 26:27 - Being a “Woman in Tech” 30:57 - Better Preparing for Getting Started in Programming Be Patient with Yourself 32:07 - Interviews Getting to Know Candidates Coding Projects and Tests 41:05 - Should you get a four-year degree to be a programmer? Eliza Brock Picks Aarti Shahani: What Cockroaches With Backpacks Can Do. Ah-mazing (Jamison) Event Driven: How to Run Memorable Tech Conferences by Leah Silber (Jamison) The Hiring Post (Jamison) Kate Heddleston: Argument Cultures and Unregulated Aggression (Jamison) Axios AJAX Library (Dave) Unbroken: A World War II Story of Survival, Resilience, and Redemption by Laura Hillenbrand (Dave) [YouTube] Good Mythical Morning: Our Official Apocalypse (AJ) Majora's Mask Live Action: The Skull Kid (AJ) The Westin at Lake Las Vegas Resort & Spa (Joe) Alchemists (Joe) Valerie Kittel (Joe) The Earthsea Trilogy: A Wizard of Earthsea; The Tombs of Atuan; The Farthest Shore by Ursula K. Le Guin (Chuck) Traction: Get a Grip on Your Business by Gino Wickman (Chuck) Freelancers’ Answers (Chuck) Drip (Chuck) Brandon Hays: Letter to an aspiring developer (Aimee) SparkPost (Aimee) Exercise and Physical Activity (Aimee)