Podcast appearances and mentions of sarah mei

Fotograaf Sarah Mei Herman maakt analoge portretten van mensen die ze langdurig volgt en met tussenpozen van enkele jaren vastlegt. Het zijn verstilde beelden waarop de geportretteerden intiem en kwetsbaar ogen, met peinzende blikken of juist gesloten ogen, en in een liggende, zittende of een afwachtende staande houding.   Sarah Mei heeft een speciale interesse voor de relaties tussen mensen. Vanuit haar wens te ervaren hoe het zou zijn om met een broer of zus op te groeien, volgt ze bijvoorbeeld al zo'n twintig jaar drie koppels van broers en zussen, die steeds worden vastgelegd op momenten waarop hun levens aan het veranderen zijn. En voor de reeks Julian en Jonathan, begin dit jaar verschenen als fotoboek, legt ze het opgroeien van haar twintig jaar jongere halfbroer Jonathan vast, en de fluctueringen in zijn relatie met Sarah Mei's vader. Haar werkwijze levert ontroerende beelden op, die de geportretteerden uittillen boven de dagelijkse werkelijkheid en het verstrijken van de tijd zichtbaar maken. 

Welcome to Remote Ruby and thanks for joining us! It's a full house this week as Jason, Chris, and Andrew are back together! They also have a great guest joining them, Nadia Odunayo, who's the Founder, CEO, and Software Developer of The StoryGraph, a book tracking, and recommendations app. Nadia spoke at the Rails SaaS Conference and her talk was titled, “Getting to one million users as a one-woman dev team.” After listening to this episode, you'll understand why she's such an engaging speaker.  Today, Nadia shares her journey of how she got into programming and building software apps, to being the Founder of The StoryGraph.  She shares some interesting things about scaling and Elasticsearch, we'll hear about her project Speakerline, and we'll find out how she got into public speaking and how her approach to conference speaking is like product building. Download this episode now to learn more! [00:04:07] Nadia tells us her background, what she does, and why she created The StoryGraph app.[00:07:24] We hear a great story on how Nadia got into programming. [00:11:31] Nadia explains how she first experienced Ruby at the Code First Girls program, and at the boot camp that was Ruby and Rails focused.[00:12:19] We learn about Nadia's journey from working at Pivotal Labs to where she is today with The StoryGraph. [00:15:38] In Nadia's talk she mentioned “financial independence” and Andrew wonders what kind of journey she takes when she builds these kinds of software apps.[00:19:59] The StoryGraph is written in Ruby and Jason wants to know if Nadia is still happy with her decision to use Ruby all these years later. [00:22:55] Nadia shares some interesting things about scaling.[00:29:13] Find out about Nadia's journey with Elasticsearch. [00:36:00] Dark Mode is brought up which is the most requested feature on the app and Nadia tells us that she has been working on it. Andrew of course loves it, and he tells us about using Radix colors. [00:38:18] We hear how Nadia got into public speaking, a story about meeting Sarah Mei, her project Speakerline, and she shares advice to people who think public speaking is not for them.[00:47:42] Nadia tells us her approach to conference speaking is like product building, Jason tells us his talks got better when he started bringing other people in, and Andrew highly recommends Speakerline. [00:54:00] Find out where you can follow Nadia onlinePanelists:Jason CharnesChris OliverAndrew MasonGuest:Nadia OdunayoSponsor:HoneybadgerLinks:Jason Charnes TwitterChris Oliver TwitterAndrew Mason TwitterNadia Odunayo WebsiteNadia Odunayo TwitterNadia Odunayo InstagramThe StoryGraphThe StoryGraph TwitterThe StoryGraph InstagramThe StoryGraph TikTokThe StoryGraph MastodonCode First GirlsRadix colorsSpeakerlineSarah Mei-What Your Conference Proposal is MissingRuby Radar TwitterRuby for All Podcast

Carolyn and Seth talk about software development with Sarah Mei, Software Architect and Director of Design System Enablement at Salesforce. The conversation begins with a quick look at the software problems in the Iowa caucus system, then moves into a discussion of code schools as a method for filling the software development pipeline, then concludes with questions of how ethics are becoming a more critical part of software development.

Carolyn and Seth talk about software development with Sarah Mei, Software Architect and Director of Design System Enablement at Salesforce. The conversation begins with a quick look at the software problems in the Iowa caucus system, then moves into a discussion of code schools as a method for filling the software development pipeline, then concludes with questions of how ethics are becoming a more critical part of software development.

01:34 - Brian’s Superpower: Communicating and Listening 02:36 - The Role of Empathy in Teaching/Communicating * Process Empathy * Empathetic Report 04:11 - Learning and Teaching Functional Programming * Lawful Composition Thinking Functionally with Haskell (https://www.amazon.com/gp/product/1107452643/ref=as_li_qf_asin_il_tl?ie=UTF8&tag=therubyrep-20&creative=9325&linkCode=as2&creativeASIN=1107452643&linkId=b8c8bcf8f27165517d6b53a2b87fedd6) Compositional Thinking Category Theory (https://en.wikipedia.org/wiki/Category_theory) 11:13 - Compositional Programming in JavaScript 16:02 - Problems That Can Be Solved by Learning Functional Programming Livable Code by Sarah Mei (https://www.youtube.com/watch?v=lI77oMKr5EY) Scalable program architectures (http://www.haskellforall.com/2014/04/scalable-program-architectures.html) 25:03 - Category Theory Categories for the Working Mathematician (https://www.amazon.com/gp/product/0387984038/ref=as_li_qf_asin_il_tl?ie=UTF8&tag=therubyrep-20&creative=9325&linkCode=as2&creativeASIN=0387984038&linkId=0aa85e8a54efad0135dbd75f39abe43c) Reading Papers Finding Applications for Concepts 32:41 - Machine Learning and AI Generative AI L-Systems (https://en.wikipedia.org/wiki/L-system) Do be do be do (https://arxiv.org/pdf/1611.09259.pdf) 53:54 - Discrete Representations of Continuous Phenomena 56:17 - Making Teaching Fun, Engaging, and Interesting Learning as a Conversation Reflections: Brian: Looking into L-systems further and thinking in terms of ranges. Rein: Dimensionality is imperative. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks! Special Guest: Brian Lonsdorf.

El trabajo de manager en programación no es una promoción sino un cambio total de profesión. Hoy le dedicamos un episodio a la transición que vive un desarrollador de software cuando pasa de un rol de contribuidor individual a uno del lado de management. Explicamos las diferencias entre trabajar para uno mismo y trabajar dirigiendo a otros, por qué es erróneo pensar que es una consecución lógica del programador experimentado y cuáles son los mayores retos cuando asumes este nuevo rol. Te recomendamos: Fabiola Cazares, Sales Manager en la fintech Affirm, describe cómo es la transición de un rol de representante de ventas a Manager: https://soundcloud.com/learneducatediscover/ep-118-transition-from-ic-to-manager-fabiola-cazares-sales-manager-affirm What's a senior engineer's job? https://jvns.ca/blog/senior-engineer/ El concepto del péndulo ingeniero/manager, definido por Charity Majors (cofundadora de honeycomb): https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/ Hilo buenísimo de Sarah Mei en twitter sobre el tema: https://twitter.com/sarahmei/status/862582787966095362?s=21 El blog de Know Your Team: https://knowyourteam.com/blog/ El VP de crecimiento y marketing de Auth0, Gonto, y el CTO de Wolox, Guido, también llevaron el tópico a su show y sacaron en claro aprendizajes que les han funcionado en esta situación: https://inheritedcomposition.com/episodes/2018/2/26/wip-from-ic-to-mgmt

Nickolas Means likes to tell stories. His conference talks [1] often center around a curious anecdote, but he deftly weaves both technical and organizational relevancy into them. Nickolas talks about how he builds a talk from conception to execution and goes over some fundamentals of good presentation slides. The goal is to provide a narrative without overwhelming the user with too much textual content. He continues with advice for novices and experts alike, including how to craft a CFP that will increase the likelihood of your talk being accepted. He suggests that new speakers choose a larger conference to speak at, rather than a smaller one, as they have more capacity to provide mentoring. Even if you're not a Ruby or Rails developer, their conferences tend to be very welcoming, and he suggests taking a look at rubyconferences.com to find one that fits. Links from this episode Nickolas’ conference talks Nickolas Means on Confreaks TV How to Talk to Developers by Ben Orenstein What Your Conference Proposal Is Missing by Sarah Mei Better talk proposals in 3 easy steps

Your First Open Source Contribution with VM Brasseur TableXI offers training for developers and product teams! For more info, email workshops@tablexi.com or go to http://tablexi.com/workshops. Guest VM Brasseur (https://twitter.com/vmbrasseur): Open Source consultant, Vice President of Open Source Initiative (https://opensource.org/), and Author of Forge Your Future with Open Source (https://pragprog.com/book/vbopens/forge-your-future-with-open-source). vmbrasseur.com (https://www.vmbrasseur.com/). Summary The Open Source world is large. It’s also complex and difficult to manage, especially for a novice. Our guest this week is VM Brasseur, who is the Vice President of the Open Source Initiative and the author of a new book from Pragmatic called Forge Your Future With Open Source. We talk how Open Source is different from free software, and how to get started in Open Source, how to pick a project, how to navigate a new project to make your first submission. We’ll also look at it from the other side, and talk about open source projects can make themselves more contributor-friendly. And we talk about the state of Open Source in general. We want to hear from you. What was your first open source experience like? Or, how do you handle new contributors on your project? Notes 03:40 - Misconceptions Keeping People From Contributing to Free and Open Source Software 05:27 - Overcoming Impostor Syndrome (https://en.wikipedia.org/wiki/Impostor_syndrome) 08:27 - Why Contribute to Open Source? 10:15 - What Project Do I Start With? - Valentia (https://valentinaproject.bitbucket.io) - Free Sewing (https://freesewing.org) 12:32 - Why NOT To Start With Documentation 14:24 - Getting Started With Your First Contribution - Code Triage (https://www.codetriage.com/) 20:20 - Advice For Navigating the Open Source Community 22:40 - The Importance Codes of Conduct 24:44 - The Evolution of Open Source - Open Source Initiative (https://opensource.org) - Open Source Definition (https://opensource.org/osd-annotated) - Updating GitHub From Rails 3.2 to 5.2 (https://githubengineering.com/upgrading-github-from-rails-3-2-to-5-2/) 35:29 - Join VM at the Seattle GNU/Linux Conference (https://seagl.org/) on November 9th & 10th! 36:33 - Advice For Maintainers Wanting to Make Projects Welcoming Related Episodes 20 Years of Web Development with Avdi Grimm and Sarah Mei (https://www.techdoneright.io/46) Open Source and Companies with Nell Shamrell-Harrington (https://www.techdoneright.io/28) The Social Responsibility of Coding with Liz Abinante (https://www.techdoneright.io/25) Open Source: The Big Picture with Nadia Eghbal (https://www.techdoneright.io/16) Open-Source Community Management and Safety With Coraline Ada Ehmke and Yana Carstens (https://www.techdoneright.io/8) Special Guest: VM Brasseur.

Panel: Charles Max Wood Chris Fritz Erik Hanchett Divya Sasidharan In this episode, the panel talks amongst themselves on the topic: how does one contribute to opensource work? They discuss the various ways that they contribute, such as speaking at conferences, recording videos for YouTube, podcasting, among others. Check-out today’s episode to get some insight and inspiration of how YOU can contribute to YOUR community!  Show Topics: 1:11 – We have decided we haven’t completed this topic 1:23 – Last time we went around the panel and see how we contribute? One of the ways I contribute to opensource is organizing events and conferences. Divya, you write some code – a little bit? 2:05 – Divya. 2:11 – Panelist: Divya, you speak at conferences, write blog posts, and code. Super top-secret project? 2:33 – Divya: I am trying to grow. Maybe I can talk about the secret project later? 2:56 – Panelist: Yes, I contribute through videos and education. I’ve tried in the past seeing issues in opensource, but I find that I am better at teaching. Charles you run a Vue Podcast? 3:29 – Chuck: Yeah, that’s what they say. I work on the podcasts, online conferences, eBooks, and online summits. Lastly, Code Badges that is on Kickstarter. 4:06 – Panelist: How we can contribute to opensource and still make a living. What is free and what we charge for? Finding a balance is important – we covered that last time. How to get into opensource in a variety of ways: How do you start speaking at conferences? How to you write code for opensource? Divya, how do they start? Do you need a public speaking degree? 5:29 – Divya: It might help. To get started with public speaking – it’s deceptively easy but then it’s not at the same time. You submit a proposal to a conference and it’s either accepted or declined. You have to learn how to CRAFT your ideas in a CFP to show the panel that this topic is RELEVANT to the conference and that you are an expert. It’s not the speaking that’s the hard part it’s the writing of the proposal. 7:00 – Panelist: You have talked about CFP – what is that? 7:09 – Divya: It’s a Call For Papers (CFP). It’s just a process of being accepted at a conference. Sometimes conferences have an open call – where they might have a Google form or some software to fill out some details. They will ask for your personal details, a short draft, the title of your talk, and a longer description (why you should be the speaker, etc.). It’s a multi-step process. Even though YOU are the right person to talk about X topic – you don’t have to be – you just have to SOUND like you know what you are talking about. Show that you’ve done your researched, and that you have some understanding. Also, that you are capable of presenting the information at the conference. That’s what I mean by being “THE BEST” person. 9:33- Charles: They aren’t looking always for the expert-level of explaining X topic. Even if it’s at the basic level that’s great. If you can deliver it well then they might pick your proposal. I have spoken at a number of conferences, and I started talking at Meetups. Most organizers are desperate for people to give talks. If you talk at these informal settings – then you get feedback from 10:47 – Divya: Yes, lightning talks are great for that, too. This way you are flushing out what you do and don’t want to talk about. 11:07 – Charles: A lot of people don’t realize that they are good speakers. The way to get better is to do it. I am a member of Toast Masters. You gain experience by talking at many different events. 12:23 – Panelist: I don’t know much about Toast Masters – what is it? 12:29 – Charles: Toast Masters, yes, they collect dues. As you sit in the meeting you have time to give feedback and get feedback. They have a “MM” master, and a grammatical master, and another specialist that they give you feedback. It’s a really constructive and friendly environment. 13:42 – I’ve been to Toast Masters and the meetings are early in the morning. 7:00 or 7:30 AM start time. Everything Chuck just said. I went to a couple and they don’t force you to talk. You can go just to see what it’s about. 14:21 – Charles makes more comments. 14:48 – Meetups is a great way to get into the community, too. What if Toast Masters sounds intimidating, and you don’t think you can speak at a Meetup just, yet. Are there more 15:18 – You can be the town crier. Stand on the soapbox and... 15:32 – There is someone sitting on a soapbox and screaming to a crowd. 15:43 – Chuck: You can do a YouTube video or a podcast, but I think getting the live feedback is super important. Toastmasters are so friendly and I’ve never been in front of a hostile crowd. You get up and they are rooting for you. It’s not as scary as you make it out to be. You aren’t going to ruin your reputation. 16:48 – Local Theater! That helps a lot, to me, because you have lines to read off of the script. You are a character and you get to do whatever you want. Also, teaching really helps. You don’t have to be a professional teacher but there are volunteer areas at a local library or your community centers and libraries. Find opportunities! 18:18 – Divya: Improvisation is good for that, too, back to Chris’ point. Improvisation you don’t have the lines, but it forces you to think on the spot. It helps you practice to think on the spot. 19:04 – Teaching is good for that, too. It makes you think on the spot. You have to respond on the fly. Life teaching is Improvisation. 19:31 – Charles: You learn the patterns that work. 19:57 – Panelist: There are some websites that can track your CFP due dates. You can apply to talk to 5-6 different conferences. You pitch the same idea to 5-6 conferences and you are bound to get picked for at least 1 of those conferences. 20:51 – Divya: There is an account that tweets the CFP due dates that are closing in 1-2 weeks. Check Twitter. 21:25 – Chuck: Take your CFP and have someone else look at it. I know a bunch of conference organizers and ask them for their feedback. 21:48 – Title and description need to be there. 22:48 – Divya: Look at past events to see what was already done in past conferences. This is to see what they are kind of looking for. Divya talks about certain conferences and their past schedules. 23:52 – Eric was saying earlier that you could send in more than 1 proposal. Another one suggests sending in 3 proposals. Someone would love to accept you, but say there is someone else you beats you by a hair. 24:31 – Divya: The CFP process is usually blind and they don’t “see” you until later. Most conferences try to do this so there is no bias. They will ask for no name, but only focusing on content. 25:28 – Sarah May has some great suggestions. Look at the show notes under LINKS. 25:57 – Advertisement – Get A Coder Job! 26:34 – We have talked about how you submit your proposals. Maybe let’s transition into another topic, like education. Eric – do you have any tips into writing blog posts and such? 27:36 – Eric: Find a topic that you want to learn and/or you are expert on. Going out there and putting out content for something you are learning. If you get something wrong then someone will probably call you out. Like Reddit you might get more criticism then vs. your own blog. I look for topics that interest me. 28:30 – Panelist: How do you get people to see it? 28:40 – Eric: Consistency – sharing on your social media channels. Reddit, Frontend, and/or other sites. I’m doing this for myself (first), and secondary I am teaching other people. 29:23 – Getting feedback from people is great. 29:40 – Eric: It’s a process to build that audience, build quality content, and keep up with it. Facebook groups – hey I put this content out there. Another way you can do it is work with a publisher and try going to a site called PluralSite. 30:47 – Do you have to be famous, like Joe, to get onto their site? 31:09 – Chuck: The audition process I got screwed on. They ask you to record a video, fix anything in the video, and then they will tell you if they will accept your courses or not. 31:37 – People who will distribute your content, there is a screening process. Guest blog, too, will get your name out there. 32:23 – Chuck: You just have to be a level above the reader. 32:37 – Odds are that you can explain it better than someone who learned it 5 years ago. Even if it’s a basic JavaScript thing that you JUST learned, who cares put it out there. If you made X mistake then I’m sure thousands of other developers have made the same mistake. 33:17 – Twitter is a great platform, too. A short and sweet Tweet – show them your main idea and it can get 34:01 – Comments. 34:04 – I use Ghost for my blogging platform. You can start off on Wordpress and others write on Medium. 34:25 – Divya: I like to own my own content so I don’t write on Medium anymore. 34:40 – I like my content on my OWN site. That’s why I haven’t been using Medium anymore. There are more pop-ups and such, too, so that’s why I don’t like it. 35:06 – Divya: If you don’t want to start up your own site, Medium is nice. Other users pick it up, which is an easy way to spread content right away. 37:13 – Chuck: Some of them will pay you for that. 37:23 – Sarah Drasner on the Vue team is an editor of CSS tricks. Good way to get your content out there. 37:48 – Divya: Sarah will work with you. Not only do you get access to put content out there, but then you get feedback from Sarah, too! 38:19 – Remember if you are doing a guest post – make sure to put out solid examples and good content. You want to put time and effort into it, so put more 39:02 – Any more advice on educational content? 39:11 – Chuck: I am always looking for guests for the podcasts and topics. You reach out and say I would like to be a guest on such and such a show. 39:39 – I thought back in the day – oh those podcast hosts are for THOSE famous people. They must have some journalism degree, and here I AM! It apparently is not that bad. 40:19 – Chuck: When I was coding semi-professionally for 1 year and my friend Eric Berry (Teach Me To Code – website) he was looking for someone to record videos for him. I submitted a video and I just walked through how to do basic routing. Basic for Ruby on Rails users, and I said that this is my first video. I tweeted that information. Screen Flow reached out to me because I mentioned their name, and I got a license and a microphone to help me record my videos! That gave me the confidence to start podcasting. It’s scary and I’m thinking I will screw this up, I don’t have professional equipment, and look at me now! 42:46 – To be a podcast host it isn’t much. 42:55 – Chuck: I am trying to make podcasting easier. The hard part is preparing the content, get it edited, getting it posted. It’s all the other stuff. Recording and talking isn’t that bad. 43:28 – What are my steps if I want to start a new podcast? 43:39 – What microphone should I get? 43:48 - $100-$130 is the Yeti microphone. Do I need a professional microphone? People can’t tell when guests talk on their iPhone microphone or not. Especially if you already have those then you won’t be out if you don’t want to continue with podcasting. Record for free with Audacity. Have something to talk about and somewhere to post it. 45:01 – Panelist asks Chuck more questions. 45:13 – Divya. 45:29 – It’s easier if everyone is in the same room. If the sound quality is good enough then people will stay, but if the quality is poor then people will go away. I recommend Wordpress - it’s super easy. You can host on Amazon, but if you will host long-term then use Libsyn or Blubrry. Great platforms will cost you less then some others. 46:58 – iTunes? 47:04 – Podcast through iTunes you just give them a RSS feed. All you do is fill out some forms. Submit that and it will run – same for Google Play. You might want to get some artwork. In the beginning for me I got a stock image – edited it – and that was it. One I got one of my headshots and put the title on there. 48:06 – Then when people will hear this... 48:23 – Summary: microphone, content, set up WordPress, submit it to iTunes, and record frequently. Keep improving. 48:46 – Anything you are doing anything online – make sure your mantra is “this is good enough.” If you spend tons of hours trying to perfect it – you might drive yourself crazy. 49:18 – Not everyone will enjoy podcasting or YouTubing – so make sure you don’t invest a lot of money at first to see where you are. 50:06 – Educational content topic continued. Contributing to coder depositories. What’s the best way to get into that? 50:28 – Chuck: Some will say: This one is good for a newbie to tackle. You just reach out – don’t just pick it up and tackle it – I would reach out to the person first. Understand what they need and then work on it, because they might have 2 other people working on it. 51:11 – Divya: Hacktoberfest – Digital Ocean – they publish opensource projects. 52:22 – Yeah check it out because you can get a free t-shirt! 53:50 – Chuck: Doing the work that the hotshots don’t want to do. It helps everyone out, but it might not be the most glamorous job.  55:11 – Spelling mistakes – scan the code base. 55:43 – Divya: If you do small contributions that people DON’T want to do – then these contributors will see you and you will be on their radar. You start building a relationship. Eventually people will start giving you more responsibilities, etc. 56:59 – Chuck: I have seen people been contributors through Ruby on Rails. They got the gig because the core team sees your previous work is reliable and good work. 57:26 – Is there a core contributor guideline? 57:37 – Good question. If Divya likes you then you are in. 57:47 – It’s Evan who makes those decisions, but we are working on a formal guideline. 58:52 – Will they kick you out? 59:00 – Unless they were doing bad stuff that means pain for other people you won’t get kicked out. 59:33 – Representing Vue to some degree, too. The people who are representing Vue are apart of it. We are trying to get a better answer for it, so it’s complicated, but working on it. 1:00:02 – How did you get on the team? Well, I was contributing code, I was discussing ways to better x, y, and z. Evan invited me to come into the core team. Basically he did it so he wouldn’t have to keep babysitting us. 1:01:06 – Chuck. 1:01:20 – Panelist. 1:01:48 – Panelist: One of our core team members got his job because he was answering questions from the community. He is not a software developer by training, but his background is a business analyst. You don’t have to contribute a ton of code. He was a guest so check out the past episode. See show notes for links. 1:03:05 – Chuck: We need to go to picks and I think that topic would be great for Joe! 1:03:24 – Advertisement – Fresh Books! Links: Vue React Angular JavaScript DevChat TV GitHub Meetup Ghost.Org Miriam Suzanne’s Twitter Sarah Mei’s Article: What Your Conference Proposal is Missing WordPress Sarah Drasner’s Twitter CSS Tricks Netlify Sponsors: Get A Coder Job! Cache Fly Kendo UI Picks: Eric Headless CMS Dyvia Blogspot - Building a 3D iDesigner with Vue.js The Twitch Streamers Who Spend Years Broadcasting to No One Chris Cat Content Twitter Account https://www.patreon.com/akryum The Great British Baking Show Charles Embrace the Struggle SoftCover.io getacoderjob.com swag.devchat.tv

Panel: Charles Max Wood Chris Fritz Erik Hanchett Divya Sasidharan In this episode, the panel talks amongst themselves on the topic: how does one contribute to opensource work? They discuss the various ways that they contribute, such as speaking at conferences, recording videos for YouTube, podcasting, among others. Check-out today’s episode to get some insight and inspiration of how YOU can contribute to YOUR community!  Show Topics: 1:11 – We have decided we haven’t completed this topic 1:23 – Last time we went around the panel and see how we contribute? One of the ways I contribute to opensource is organizing events and conferences. Divya, you write some code – a little bit? 2:05 – Divya. 2:11 – Panelist: Divya, you speak at conferences, write blog posts, and code. Super top-secret project? 2:33 – Divya: I am trying to grow. Maybe I can talk about the secret project later? 2:56 – Panelist: Yes, I contribute through videos and education. I’ve tried in the past seeing issues in opensource, but I find that I am better at teaching. Charles you run a Vue Podcast? 3:29 – Chuck: Yeah, that’s what they say. I work on the podcasts, online conferences, eBooks, and online summits. Lastly, Code Badges that is on Kickstarter. 4:06 – Panelist: How we can contribute to opensource and still make a living. What is free and what we charge for? Finding a balance is important – we covered that last time. How to get into opensource in a variety of ways: How do you start speaking at conferences? How to you write code for opensource? Divya, how do they start? Do you need a public speaking degree? 5:29 – Divya: It might help. To get started with public speaking – it’s deceptively easy but then it’s not at the same time. You submit a proposal to a conference and it’s either accepted or declined. You have to learn how to CRAFT your ideas in a CFP to show the panel that this topic is RELEVANT to the conference and that you are an expert. It’s not the speaking that’s the hard part it’s the writing of the proposal. 7:00 – Panelist: You have talked about CFP – what is that? 7:09 – Divya: It’s a Call For Papers (CFP). It’s just a process of being accepted at a conference. Sometimes conferences have an open call – where they might have a Google form or some software to fill out some details. They will ask for your personal details, a short draft, the title of your talk, and a longer description (why you should be the speaker, etc.). It’s a multi-step process. Even though YOU are the right person to talk about X topic – you don’t have to be – you just have to SOUND like you know what you are talking about. Show that you’ve done your researched, and that you have some understanding. Also, that you are capable of presenting the information at the conference. That’s what I mean by being “THE BEST” person. 9:33- Charles: They aren’t looking always for the expert-level of explaining X topic. Even if it’s at the basic level that’s great. If you can deliver it well then they might pick your proposal. I have spoken at a number of conferences, and I started talking at Meetups. Most organizers are desperate for people to give talks. If you talk at these informal settings – then you get feedback from 10:47 – Divya: Yes, lightning talks are great for that, too. This way you are flushing out what you do and don’t want to talk about. 11:07 – Charles: A lot of people don’t realize that they are good speakers. The way to get better is to do it. I am a member of Toast Masters. You gain experience by talking at many different events. 12:23 – Panelist: I don’t know much about Toast Masters – what is it? 12:29 – Charles: Toast Masters, yes, they collect dues. As you sit in the meeting you have time to give feedback and get feedback. They have a “MM” master, and a grammatical master, and another specialist that they give you feedback. It’s a really constructive and friendly environment. 13:42 – I’ve been to Toast Masters and the meetings are early in the morning. 7:00 or 7:30 AM start time. Everything Chuck just said. I went to a couple and they don’t force you to talk. You can go just to see what it’s about. 14:21 – Charles makes more comments. 14:48 – Meetups is a great way to get into the community, too. What if Toast Masters sounds intimidating, and you don’t think you can speak at a Meetup just, yet. Are there more 15:18 – You can be the town crier. Stand on the soapbox and... 15:32 – There is someone sitting on a soapbox and screaming to a crowd. 15:43 – Chuck: You can do a YouTube video or a podcast, but I think getting the live feedback is super important. Toastmasters are so friendly and I’ve never been in front of a hostile crowd. You get up and they are rooting for you. It’s not as scary as you make it out to be. You aren’t going to ruin your reputation. 16:48 – Local Theater! That helps a lot, to me, because you have lines to read off of the script. You are a character and you get to do whatever you want. Also, teaching really helps. You don’t have to be a professional teacher but there are volunteer areas at a local library or your community centers and libraries. Find opportunities! 18:18 – Divya: Improvisation is good for that, too, back to Chris’ point. Improvisation you don’t have the lines, but it forces you to think on the spot. It helps you practice to think on the spot. 19:04 – Teaching is good for that, too. It makes you think on the spot. You have to respond on the fly. Life teaching is Improvisation. 19:31 – Charles: You learn the patterns that work. 19:57 – Panelist: There are some websites that can track your CFP due dates. You can apply to talk to 5-6 different conferences. You pitch the same idea to 5-6 conferences and you are bound to get picked for at least 1 of those conferences. 20:51 – Divya: There is an account that tweets the CFP due dates that are closing in 1-2 weeks. Check Twitter. 21:25 – Chuck: Take your CFP and have someone else look at it. I know a bunch of conference organizers and ask them for their feedback. 21:48 – Title and description need to be there. 22:48 – Divya: Look at past events to see what was already done in past conferences. This is to see what they are kind of looking for. Divya talks about certain conferences and their past schedules. 23:52 – Eric was saying earlier that you could send in more than 1 proposal. Another one suggests sending in 3 proposals. Someone would love to accept you, but say there is someone else you beats you by a hair. 24:31 – Divya: The CFP process is usually blind and they don’t “see” you until later. Most conferences try to do this so there is no bias. They will ask for no name, but only focusing on content. 25:28 – Sarah May has some great suggestions. Look at the show notes under LINKS. 25:57 – Advertisement – Get A Coder Job! 26:34 – We have talked about how you submit your proposals. Maybe let’s transition into another topic, like education. Eric – do you have any tips into writing blog posts and such? 27:36 – Eric: Find a topic that you want to learn and/or you are expert on. Going out there and putting out content for something you are learning. If you get something wrong then someone will probably call you out. Like Reddit you might get more criticism then vs. your own blog. I look for topics that interest me. 28:30 – Panelist: How do you get people to see it? 28:40 – Eric: Consistency – sharing on your social media channels. Reddit, Frontend, and/or other sites. I’m doing this for myself (first), and secondary I am teaching other people. 29:23 – Getting feedback from people is great. 29:40 – Eric: It’s a process to build that audience, build quality content, and keep up with it. Facebook groups – hey I put this content out there. Another way you can do it is work with a publisher and try going to a site called PluralSite. 30:47 – Do you have to be famous, like Joe, to get onto their site? 31:09 – Chuck: The audition process I got screwed on. They ask you to record a video, fix anything in the video, and then they will tell you if they will accept your courses or not. 31:37 – People who will distribute your content, there is a screening process. Guest blog, too, will get your name out there. 32:23 – Chuck: You just have to be a level above the reader. 32:37 – Odds are that you can explain it better than someone who learned it 5 years ago. Even if it’s a basic JavaScript thing that you JUST learned, who cares put it out there. If you made X mistake then I’m sure thousands of other developers have made the same mistake. 33:17 – Twitter is a great platform, too. A short and sweet Tweet – show them your main idea and it can get 34:01 – Comments. 34:04 – I use Ghost for my blogging platform. You can start off on Wordpress and others write on Medium. 34:25 – Divya: I like to own my own content so I don’t write on Medium anymore. 34:40 – I like my content on my OWN site. That’s why I haven’t been using Medium anymore. There are more pop-ups and such, too, so that’s why I don’t like it. 35:06 – Divya: If you don’t want to start up your own site, Medium is nice. Other users pick it up, which is an easy way to spread content right away. 37:13 – Chuck: Some of them will pay you for that. 37:23 – Sarah Drasner on the Vue team is an editor of CSS tricks. Good way to get your content out there. 37:48 – Divya: Sarah will work with you. Not only do you get access to put content out there, but then you get feedback from Sarah, too! 38:19 – Remember if you are doing a guest post – make sure to put out solid examples and good content. You want to put time and effort into it, so put more 39:02 – Any more advice on educational content? 39:11 – Chuck: I am always looking for guests for the podcasts and topics. You reach out and say I would like to be a guest on such and such a show. 39:39 – I thought back in the day – oh those podcast hosts are for THOSE famous people. They must have some journalism degree, and here I AM! It apparently is not that bad. 40:19 – Chuck: When I was coding semi-professionally for 1 year and my friend Eric Berry (Teach Me To Code – website) he was looking for someone to record videos for him. I submitted a video and I just walked through how to do basic routing. Basic for Ruby on Rails users, and I said that this is my first video. I tweeted that information. Screen Flow reached out to me because I mentioned their name, and I got a license and a microphone to help me record my videos! That gave me the confidence to start podcasting. It’s scary and I’m thinking I will screw this up, I don’t have professional equipment, and look at me now! 42:46 – To be a podcast host it isn’t much. 42:55 – Chuck: I am trying to make podcasting easier. The hard part is preparing the content, get it edited, getting it posted. It’s all the other stuff. Recording and talking isn’t that bad. 43:28 – What are my steps if I want to start a new podcast? 43:39 – What microphone should I get? 43:48 - $100-$130 is the Yeti microphone. Do I need a professional microphone? People can’t tell when guests talk on their iPhone microphone or not. Especially if you already have those then you won’t be out if you don’t want to continue with podcasting. Record for free with Audacity. Have something to talk about and somewhere to post it. 45:01 – Panelist asks Chuck more questions. 45:13 – Divya. 45:29 – It’s easier if everyone is in the same room. If the sound quality is good enough then people will stay, but if the quality is poor then people will go away. I recommend Wordpress - it’s super easy. You can host on Amazon, but if you will host long-term then use Libsyn or Blubrry. Great platforms will cost you less then some others. 46:58 – iTunes? 47:04 – Podcast through iTunes you just give them a RSS feed. All you do is fill out some forms. Submit that and it will run – same for Google Play. You might want to get some artwork. In the beginning for me I got a stock image – edited it – and that was it. One I got one of my headshots and put the title on there. 48:06 – Then when people will hear this... 48:23 – Summary: microphone, content, set up WordPress, submit it to iTunes, and record frequently. Keep improving. 48:46 – Anything you are doing anything online – make sure your mantra is “this is good enough.” If you spend tons of hours trying to perfect it – you might drive yourself crazy. 49:18 – Not everyone will enjoy podcasting or YouTubing – so make sure you don’t invest a lot of money at first to see where you are. 50:06 – Educational content topic continued. Contributing to coder depositories. What’s the best way to get into that? 50:28 – Chuck: Some will say: This one is good for a newbie to tackle. You just reach out – don’t just pick it up and tackle it – I would reach out to the person first. Understand what they need and then work on it, because they might have 2 other people working on it. 51:11 – Divya: Hacktoberfest – Digital Ocean – they publish opensource projects. 52:22 – Yeah check it out because you can get a free t-shirt! 53:50 – Chuck: Doing the work that the hotshots don’t want to do. It helps everyone out, but it might not be the most glamorous job.  55:11 – Spelling mistakes – scan the code base. 55:43 – Divya: If you do small contributions that people DON’T want to do – then these contributors will see you and you will be on their radar. You start building a relationship. Eventually people will start giving you more responsibilities, etc. 56:59 – Chuck: I have seen people been contributors through Ruby on Rails. They got the gig because the core team sees your previous work is reliable and good work. 57:26 – Is there a core contributor guideline? 57:37 – Good question. If Divya likes you then you are in. 57:47 – It’s Evan who makes those decisions, but we are working on a formal guideline. 58:52 – Will they kick you out? 59:00 – Unless they were doing bad stuff that means pain for other people you won’t get kicked out. 59:33 – Representing Vue to some degree, too. The people who are representing Vue are apart of it. We are trying to get a better answer for it, so it’s complicated, but working on it. 1:00:02 – How did you get on the team? Well, I was contributing code, I was discussing ways to better x, y, and z. Evan invited me to come into the core team. Basically he did it so he wouldn’t have to keep babysitting us. 1:01:06 – Chuck. 1:01:20 – Panelist. 1:01:48 – Panelist: One of our core team members got his job because he was answering questions from the community. He is not a software developer by training, but his background is a business analyst. You don’t have to contribute a ton of code. He was a guest so check out the past episode. See show notes for links. 1:03:05 – Chuck: We need to go to picks and I think that topic would be great for Joe! 1:03:24 – Advertisement – Fresh Books! Links: Vue React Angular JavaScript DevChat TV GitHub Meetup Ghost.Org Miriam Suzanne’s Twitter Sarah Mei’s Article: What Your Conference Proposal is Missing WordPress Sarah Drasner’s Twitter CSS Tricks Netlify Sponsors: Get A Coder Job! Cache Fly Kendo UI Picks: Eric Headless CMS Dyvia Blogspot - Building a 3D iDesigner with Vue.js The Twitch Streamers Who Spend Years Broadcasting to No One Chris Cat Content Twitter Account https://www.patreon.com/akryum The Great British Baking Show Charles Embrace the Struggle SoftCover.io getacoderjob.com swag.devchat.tv

20 Years of Web Development with Avdi Grimm and Sarah Mei TableXI is offering training for developers and product teams! For more info, visit http://tablexi.com/workshops. Guests Sarah Mei (https://twitter.com/sarahmei): Founder of RailsBridge (http://railsbridge.org/), Director of Ruby Central (http://rubycentral.org/), Software Architect at Salesforce (https://www.salesforce.com/). Avdi Grimm (https://twitter.com/avdi): Creator of the RubyTapas Screencast Series (https://www.rubytapas.com/) and author of Exceptional Ruby (http://exceptionalruby.com/) and Confident Ruby (http://www.confidentruby.com/). avdi.codes (https://avdi.codes/). Summary What has changed in web development in the last 20 years, and what do those changes say about the next 20? I recently realized that Avdi Grimm, the head chef of Ruby Tapas, Sarah Mei, of Ruby Central and Salesforce, and I all began our professional careers within a couple of weeks of each other in August 1998. I wanted to talk to them about what’s changed and what’s stayed the same. I was curious as to whether our different career paths led to similar observations. We talk about open source, agile, dynamic languages, distributed systems and how they’ve all changed or haven’t changed the developer’s experience. Notes 02:19 - First Software Job Education and Experiences 09:25 - What has changed? What is easier/harder? 20:16 - What has changed in Product Management? 27:22 - Processor Speed 32:24 - What has stayed the same? 40:20 - Typed Languages 42:48 - What is going to change over the next 5-10 years? - Code Complete: A Practical Handbook of Software Construction by by Steve McConnell (https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670) Related Episodes Rubyists in Other Languages with James Edward Gray II and Steve Klabnik (https://www.techdoneright.io/43) Ruby Tapas and Avoiding Code with Avdi Grimm (https://www.techdoneright.io/24) Livable Code With Sarah Mei (https://www.techdoneright.io/13) Special Guests: Avdi Grimm and Sarah Mei.

Chris is joined by Kane Baccigalupi, development director from thoughtbot's San Francisco office to discuss Kane's history in government working for 18F and California State and how those experiences have informed Kane's work since. Throughout the conversation Chris and Kane discuss their shared desire to hide all implementation details and their love of Ruby for how it allows us to do that, testing vs test driven development, and approaches for refactoring large untested systems. 18F - A consulting team within the government helping to introduce modern software development practices. Kane's tweet about the enjoyment of the refactoring and design parts of the process. Sarah Mei on The Bike Shed Uniform Access Principle Observations on the testing culture of Test Driven Development - TDD article that introduces the phrase "calling the shot" for the practice of TDD. Convenience class methods on service objects Testing Pyramid - A way to think about the cost and value of the various types of tests. Therapeutic Refactoring by Katrina Owen Katrina Owen on The Bike Shed Strangler Pattern - A systematic approach to refactoring and decomposing large-scale The encasement strategy: on legacy systems and the importance of APIs Martin Fowler on the Strangler Pattern

Panel: AJ O’Neal Aimee Knight Special Guests: Greg Whitworth In this episode, the JavaScript Jabber panelists discuss the effects of JavaScript on CSS with Greg Whitworth. Greg works on Microsoft EdgeHTML, specifically working on the Microsoft Layout team, is on the CSS working group, and is involved with the Houdini task force. They talk about JS engines and rendering engines, what the CSSOM is, why it is important to understand the rendering engine, and much more! In particular, we dive pretty deep on: Greg intro What is the Houdini task force? Extensible web manifesto DOM (Document Object Model) Layout API Parser API Babel jQuery Back to basics JavaScript engine and rendering engine What is the CSSOM? Every browser has its separate JS engine Browsers perspective Aimee ShopTalk Podcast Episode Why is it important to understand how the rendering engine is working? Making wise decisions Give control back to browser if possible When you would want to use JavaScript or CSS Hard to make a hard or fast rule CSS is more performant Overview of steps And much, much more! Links: Parser API Babel jQuery Aimee ShopTalk Podcast Episode JavaScript @gregwhitworth GWhitworth.com Greg’s GitHub   Sponsors Kendo UI Linode FreshBooks Picks: AJ Microsoft Surface Microsoft Cursor Aimee Greg’s Talk What Your Conference Proposal Is Missing by Sarah Mei Greg Aimee ShopTalk Podcast Episode Jake Archibald Tasks Talk

Panel: AJ O’Neal Aimee Knight Special Guests: Greg Whitworth In this episode, the JavaScript Jabber panelists discuss the effects of JavaScript on CSS with Greg Whitworth. Greg works on Microsoft EdgeHTML, specifically working on the Microsoft Layout team, is on the CSS working group, and is involved with the Houdini task force. They talk about JS engines and rendering engines, what the CSSOM is, why it is important to understand the rendering engine, and much more! In particular, we dive pretty deep on: Greg intro What is the Houdini task force? Extensible web manifesto DOM (Document Object Model) Layout API Parser API Babel jQuery Back to basics JavaScript engine and rendering engine What is the CSSOM? Every browser has its separate JS engine Browsers perspective Aimee ShopTalk Podcast Episode Why is it important to understand how the rendering engine is working? Making wise decisions Give control back to browser if possible When you would want to use JavaScript or CSS Hard to make a hard or fast rule CSS is more performant Overview of steps And much, much more! Links: Parser API Babel jQuery Aimee ShopTalk Podcast Episode JavaScript @gregwhitworth GWhitworth.com Greg’s GitHub   Sponsors Kendo UI Linode FreshBooks Picks: AJ Microsoft Surface Microsoft Cursor Aimee Greg’s Talk What Your Conference Proposal Is Missing by Sarah Mei Greg Aimee ShopTalk Podcast Episode Jake Archibald Tasks Talk

Panel: AJ O’Neal Aimee Knight Special Guests: Greg Whitworth In this episode, the JavaScript Jabber panelists discuss the effects of JavaScript on CSS with Greg Whitworth. Greg works on Microsoft EdgeHTML, specifically working on the Microsoft Layout team, is on the CSS working group, and is involved with the Houdini task force. They talk about JS engines and rendering engines, what the CSSOM is, why it is important to understand the rendering engine, and much more! In particular, we dive pretty deep on: Greg intro What is the Houdini task force? Extensible web manifesto DOM (Document Object Model) Layout API Parser API Babel jQuery Back to basics JavaScript engine and rendering engine What is the CSSOM? Every browser has its separate JS engine Browsers perspective Aimee ShopTalk Podcast Episode Why is it important to understand how the rendering engine is working? Making wise decisions Give control back to browser if possible When you would want to use JavaScript or CSS Hard to make a hard or fast rule CSS is more performant Overview of steps And much, much more! Links: Parser API Babel jQuery Aimee ShopTalk Podcast Episode JavaScript @gregwhitworth GWhitworth.com Greg’s GitHub   Sponsors Kendo UI Linode FreshBooks Picks: AJ Microsoft Surface Microsoft Cursor Aimee Greg’s Talk What Your Conference Proposal Is Missing by Sarah Mei Greg Aimee ShopTalk Podcast Episode Jake Archibald Tasks Talk

This week Jamison and Dave answer these questions: My job doesn’t seem to leave room to negotiate salary or raises for our year-end review. Is this normal? How do I negotiate in this process? Can working part-time, when it’s possible to work full time, to invest in personal development look bad to a future employer? This tweet storm by Sarah Mei is good and relevant. This is the video about making your own font and anagraphs that Jamison mentioned at the end. It is SO GOOD. This is a funny and enlightening video that people of taste and culture will appreciate. This one is also good. Ok fine, they are all good.

We go inside the RubyConf CFP review process before turning our attention to questions about the impact of code review. Stick around post credits for some spoiler-filled, lukewarm Game of Thrones takes. What Your Conference Proposal is Missing by Sarah Mei Add a configuration option to cause tests to fail if they write stderr or stdout Survivorship Bias Cultivating a Code Review Culture by Derek Goldilocks and the Three Code Reviews by Vaidehi Joshi

Livable Code With Sarah Mei Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right), leave us a review on iTunes, and please sign up for our newsletter (http://www.techdoneright.io/newsletter)! Guest Sarah Mei (https://twitter.com/sarahmei): Founder of RailsBridge (http://railsbridge.org/), Director of Ruby Central (http://rubycentral.org/), Chief Consultant at DevMynd Software (https://www.devmynd.com/). Summary Is your code the kind of cluttered house you might find on a reality TV show? Or the kind of sleek, minimalist house you might find in a architectural magazine. Neither one sounds like a place you could comfortably live. Sarah Mei joins the podcast to talk about Livable Code, what makes a codebase livable, how to negotiate tension between junior and senior developers and how Rails deals with developer happiness. Notes 01:33 - What is meant by “Livable Code”? 04:25 - Where does codebase abstraction go wrong? 05:41 - What makes a codebase livable? - Code Climate (https://codeclimate.com/) 09:16 - Calibrating the Right Level for Your Team: Retrospective Meetings 12:22 - Principles of a Codebase 18:21 - Alleviating Tension Between Junior and Senior Developers 22:57 - The Goal of Career Development 26:42 - Guiding Architecture Choices on a Team 30:37 - Does testing help? 34:23 - Programmer Happiness 37:42 - The Attitude Toward JavaScript 39:01 - The Right Design For Your Codebase is Subjective Special Guest: Sarah Mei.

In this episode, Sarah Mei, founder of RailsBridge, Director of Ruby Central, and Chief Consultant of DevMynd Software, talks about the way we write software: What's right? What's wrong? How can we do better? The conversation examines changing code and reassessing needs. i.e.: "Does it bring me joy? Should I get rid of this thing? Do I understand this code?" She also talks about what these needs mean for others on a team. Sarah Mei: @sarahmei Links: Sarah Mei: How We Make Software: A New Theory of Teams @ Brighton Ruby 2016 The Life-Changing Magic of Tidying Up: The Japanese Art of Decluttering and Organizing by Marie Kondo Transcript: CHARLES: Welcome to the Frontside Podcast. I am Charles Lowell and with me is Robert DeLuca. We have a very special guest this week. One that I'm really excited about because the things she says and the ideas that she has - open eyes and minds all over the place, in all different types of areas that are so pertinent to the way we do our jobs. So, we'll get to it. Our guest today is Sarah Mei. SARAH: Hi. Thanks for having me. CHARLES: Like I said, we are super excited to have you here. Before we get started talking about some of the things that you've been thinking about recently, why don't you just give like a very brief introduction of how you got started with development, where you've been, and how has that brought you to where you're going right now? SARAH: You know, I actually was not one of these people that got started with it real early. I came to programming in college. I was an Engineering major. I wanted to build bridges. I wanted to be a Structural Engineer. I want to build things. I had a weird schedule the first couple of quarters of college, so I ended up taking an elective earlier than most people take it. It was a programming class in Fortran that was required for the structural engineering program. I took my class and I was like, "This is really cool." CHARLES: Wait, Fortran is what set the hook? SARAH: Yeah, and the professor of the class was like, "Well, if you think Fortran is cool. I've got some other stuff that you might like." I mean, the language and whatever doesn't really matter. What I liked about it was the fact that I could build something. I can get that same feeling of building something that you get if you build a bridge but you can do more than like one or two in your career, like you do if you're a structural engineer. I like the constant feeling of building. That's what I liked about it. So I ended up switching my major and graduating with the CS degree and coming out and doing a bunch of different things, mostly like starting in a large company and sort of doing smaller and smaller companies over time. CHARLES: Yeah, there's a lot of people in the industry who are career switchers, where they started out in something else and moved into Computer Science but I actually feel that a lot of people, like myself included, I have the degree in CS too, but that was not what I set out to do at all. It totally derailed, like the course of my life in a good way. But in that way, it's like a career switch within a career switch. ROBERT: I'm a little odd in that aspect. I came out of high school like ready to go in software. It worries me a little bit for the later half of my life. I'm like, "Oh, am I going to do software for the entire time?" CHARLES: Probably not. SARAH: That might be a good thing. You'll never know. ROBERT: Yeah. CHARLES: Yeah, seriously, what lies ahead? ROBERT: Who knows? SARAH: I feel like in a lot of places that are like, for example, in public policy and in other places where we need more people that understand tech so if we can send you out into other parts of the world knowing a whole lot about programming, that can only be good. CHARLES: Yeah. ROBERT: Yeah, this is actually kind of funny. I was telling CHARLES about this the other days, like I'm starting to view programming more as a tool to do the things that I really want to do and less as like the thing that I'm going to be doing forever. I wanted to augment and make things that I have a passion about easier. SARAH: Yeah, absolutely. CHARLES: Yeah, it's like software is eating the world so what you're doing now is just learning how to chew. ROBERT: That's a great way to put it. SARAH: You should tweet that. [Laughter] CHARLES: All right. Please continue. I'll ignore the typing sounds. SARAH: [Laughs] Switching careers is a really interesting thing because you end up with a bunch of experience that you wouldn't have had otherwise. I'm really excited actually about the next five years as we have all these folks that switched into programming from something else who are all becoming mid to senior level because they're bringing just such amazing experience from other parts of the world. CHARLES: Yeah, I know, right? It's like, "Where've you guys been my whole career?" SARAH: Right. CHARLES: It's like you understand these things, just almost like it's second nature of these things that are opaque and completely inaccessible to me. So anyhow... SARAH: That's how I got here. CHARLES: So then, after you kind of switched in college, you went out and did you just start working in programming immediately thereafter? SARAH: Yeah, I worked in a bunch of different product companies. I built products for a while. My first job actually out of college was at Microsoft up in Redmond and then I have worked at smaller and smaller and smaller companies. Then I spent about 10 years doing product stuff and then about 10 years ago, I switched into doing consulting mostly because I realized that I have a fairly short attention span for projects. And that working on a product, there wasn't anything wrong with me exactly but what would happen is when I was working with a product, I would get six months to a year into it and I'm starting to get antsy. I started to get bored and decided that I should just embrace that. And I switch to something where I am going to be on a new project every three to six months. I've been a lot happier since then. ROBERT: That's interesting. I wonder if that comes with seniority in software development and knowing your way around because consulting for me is I've gotten the experience of, "Oh, wow, I'm just finally getting a hang of this person's product or this client's product or app or whatever we're building," and it's, "All right. It's time to rotate off." It's like you just get in there and understanding everything. SARAH: There is that aspect of it for sure but even when I was much less experienced, even with my first couple of jobs, I noticed this tendency in myself to just get bored after six months on the same code base. For a long time, I thought it was because I'm not cut out for software or maybe I'm not very good at it or something. Eventually, I just realized now actually, it's just that I just need to switch projects. I'm just one of those people. That's how my brain works. I get a lot out of switching projects because the one that I switch on to, I see an entirely different way of doing things like code bases are so different. Even if you look at a hundred different Rails apps or a hundred different Ember apps, they're all so different. So switching on to somebody else's app, I learned a ton just out of that switching process. CHARLES: It sounds like the actual kind of studying the meta-level of the software is what really engages you and kind of understanding how the software came to be the way it is and not some other way. One of the factors that gave rise to that and kind of 'that's the problem' that really sunk its teeth in you, as opposed to individual business problem. Is that fair to say? SARAH: It has certainly been interesting to see different business problems and to understand different parts of industries and so on. That's definitely part of it for me but what really gets me interested is the different ways that people organize their code and by how they make the decisions that they make. ROBERT: Yeah, you get to see different problems that they've maybe put themselves into because of the way they structured something, which you wouldn't see if you wrote yourself but somebody else did and get to see, "Oh, I understand this pattern now." That's kind of been my experience out of it. I don't want to speak for you, but yeah, that's kind of how I've seen other client projects like, "Oh, this is really cool. I didn't think of a way to do this," and you get to experience many different things in many different ways. SARAH: You get to see a lot of the tradeoffs. Like a lot of times in a single code base, what would happen is I'd make a decision or we'd make a design decision of some kind. Then I'd see how it turned out. But there's no way for me to see how it would have turned out if I did it the other way. The nice thing about switching projects for me is just being able to see all of those tradeoffs, like the tradeoffs that you make tend to be pretty similar. You can see very similar situations where people do different things and how does it turn out for them. ROBERT: Right, and like one of my favorite things is where you go into a project that is totally against something, like for me it was object-oriented CSS and then you go in and you actually see it in practice, and you're like, "Oh, wow. This is turning a whole new light on it. I like this in this case." SARAH: Microservices are like that for me, where it's generally I am anti the microservice bandwagon. But then I went on one project where I was like, "Wow, they actually figured it out. This works really well. I can see why people like it," because I've seen so many work that was horribly executed. When you go on to the one where it's good and you're like, "Oh, this is why people do that. Okay." ROBERT: Yeah, it's like that light-bulb click, "Oh, yep. There's another side of this." CHARLES: Once you actually see it done right, it helps you avoid every other situation where it was done wrong and you can say, "Oh, this this was the one differentiator that made it all go right." I mean, sometimes it doesn't always boil down to that. But there's these one, two, three things that we could have done. But they were just completely and totally hidden from you because you didn't have that context. I would love to talk to you about microservices because I've certainly never seen it done right. I've heard it talked about and I've seen this beautiful world, picture-painted that looks so fantastic on the whiteboard. But I see -- SARAH: Oh, it's so beautiful, isn't it? It's like an object-oriented design diagram. I'm like, "Look at all the boxes and lines. They all line up." CHARLES: "They're beautiful." SARAH: "I can do this in Visio," and they're all like, the line, they are on the same shape. It was great. CHARLES: "And when I move this one over there, it just tells me that these two are exactly the same distance apart from that other one." Ah, so satisfying. SARAH: Yeah, and then you try and do it, is the problem. ROBERT: Then you build it and you cross your errors and everything. CHARLES: Which actually I think that brings us, recently -- we're talking on Twitter. I think that's actually very recently about kind of the difference between when we talk about software and the meta conversations we have around it. When we do talk about these abstract and perfect worlds of boxes and lines versus the actual code bases, which is the things that you've kind of been observing many, many, many since you've started consulting, and kind of the vibe between those and you know what that means. I think a lot of people aren't even aware like I certainly, before kind of reading that, wasn't really aware that that is a very, very distinct difference, like these are two very different modes for software. One that exists and one that is kind of perfect world. ROBERT: Kind of academia versus the real world, I guess. SARAH: In some ways, yeah. I remember when I was in college, we had a software design class as part of our degree program. We studied how you define objects and you write a little bit of [inaudible], like we did all this stuff. When I got out and I got into the real world and I had a job, I found it very difficult to actually apply that stuff successfully, to be able to draw a diagram and then turn it into code and have it work out the way that the diagram said it was supposed to work out. I initially thought that was because I was just not experienced enough to figure it out. But eventually, what I realized is that it doesn't work because it doesn't work. It really doesn't work to design things ahead of time and then just do them. I think there might be a certain type of person that can do that. I am not that type of person and most people aren't. I think that it takes a very unusual type of brain to be able to just draw a diagram that has already taken into account all of the things you're going to encounter once you start making it. CHARLES: Yeah, I would even go so far as to say there's probably a brain that solved that problem many, many times, that just could skip a bunch of steps. SARAH: Right, and they're not aware they're skipping them necessarily. Unless you have an entire team full of that type of brain, it's probably not a good idea in general, for the software that you're building as a group. I feel like I've been trying to talk about that concept between the difference of how we talked about software in books, in blogs, and in conference talks and then how we build the software we actually build. I feel like I've been trying to articulate that for 20 years, like since I have my [inaudible] and I was like, "This doesn't work. Why can't I make a diagram and then make it into code?" Like two days ago, I feel like I finally found a way to articulate it that captures everything that I've been trying to communicate and it was a really strange feeling. I'm like, "Wow, I finally kind of got it." One of the reasons that I came up with that, I think, is because I haven't really been thinking about it for a couple of months. I've been off and not really thinking about software stuff for a while. Oddly enough, I've been thinking about organizing my house for the last three months. All of my free time outside of my job has been thinking about like, "I've been learning how to cook, so how can I organize my kitchen so that the things I actually use every day, I don't have to dig through a drawer every single time to find them?" There's actually some interesting problems there like, "How do I make sure that all of the stuff that I need is at hand that I use all the time? All stuff that I need occasionally is still around and accessible, and then things that I don't use, I should probably just get rid of." I have this problem that I think probably a lot of people have which is that I have trouble getting rid of stuff once I have it. I live in a small apartment in San Francisco and that's not a good thing to be able to unable to get rid of things because in an apartment this size, I can let it go for a week or two maybe, but like I got to be very vigilant about it because otherwise, it just overwhelms the space. CHARLES: Yeah, there's a bunch of research that the people estimate vastly different the cost of acquisition versus the cost of loss, and they've [inaudible] way too much, like irrationally unbalanced like not wanting to lose something that they already have. SARAH: Even if I bought it for a need that I don't have any more or the need has changed or shifted. I don't buy things I don't need. There are some people that have that problem, that they buy a bunch of stuff that they don't have any particular plans for it. I don't have that problem, thankfully. I've had people in my family that have that problem which I think is why I have avoided that. But the problem I have is that once something is here, I find it very difficult to get rid of it. I look at it and I'm like, "I can think of all these reasons why I shouldn't get rid of it." Oh, that was expensive so the sunk cost fallacy of like, "Oh, I paid a lot of money for that even if it's not useful and I don't like it, I shouldn't get rid of it." Or, there'll be like a dress in my closet that I haven't worn for two years and I'm like, "Ah, maybe I should get rid of it," and I take it out and I'm like, "Oh, my God. But it looks really good on me. I like it. I should wear this. I should really wear this." So I'm going to keep it even though I haven't worn in for two years for some reason, but I should keep it anyway because it looks good. I have all these stories. I tell myself about why I can't get rid of things. A couple of weeks ago, I read a part of a book, to be totally honest with you, called The Life-Changing Magic of Tidying Up. It's written by this woman from Japan who's a professional organizer. Her name is Marie Kondo and her method is called KonMari. Basically, what it does is when you're trying to figure out whether you should get rid of something, you don't ask yourself, "Should I keep it?" What you ask yourself is, "Does this thing bring me joy? And if it brings me joy, then I keep it. If it doesn't, then I'm going to get rid of it." So that made it really easy, going back to the dress example. I'm like, "Does this dress give me joy?" And I thought about it, I was like, "No, the reason I don't wear it is because I went out to dinner and I had a bad experience at dinner so every time I look at that dress, it reminds me of that experience." And so it looks good and everything but I'm not going to wear it because it doesn't make me happy. So that was just like, "Okay, fine. I'm just going to give it away." And changing that question that I ask away from 'should I keep it' towards 'how does that make me feel' was a huge change for me because it's like, that's really easy to answer, where 'should I keep it' is a much harder question. There's these bunch of sort of ifs and maybes or what-ifs and what happens. I feel like that applying this KonMari question to stuff has changed the way that I calculate what stays and what goes in a very positive way. CHARLES: Yeah, boy, I need to get this book for several family members who will go [inaudible]. SARAH: Well, you know, I've got two kids and so there's a constant flow of stuff coming into the house. Because of the amount of space I have, there has to be a constant stuff going out. So this is something I just need to be very vigilant about and this has made it so that it takes up a lot less of my time and a lot less of my brain space, which is really awesome. It feels like it's moving my house in the right direction. I've been thinking about that sort of in various ways, on and off, for a couple of months and I haven't been thinking about software. I have this fear that like, maybe that means I'm never going to think about software again. I go through these phases where I've got like, "Oh, I'm going to come up with a bunch of new ideas," where I'm coming up with new ideas for some whatever reason. Maybe I'm making new conference talks, I'm doing stuff, and I'm thinking about software a lot. Then I go through these phases where I don't do that, like I sort of retrench and maybe... I don't know. I think about other stuff for a while. So it's been home organization for several months now. I was like this, "I'm never going to think about software again," because it's just that -- [Laughter] CHARLES: Career change. ROBERT: Oh, man. This sounds so much like my life since I moved down to Austin. SARAH: You know, I live in San Francisco and I'm not 25, I'm 40. A lot of it is like maybe I'm just too old for software now. I should just give up and live out the rest of my career doing quiet, maintenance work -- [Laughter] SARAH: Somewhere. I don't know. Then suddenly, this thing happened on Monday, where I was just like, "Oh, code, an organization." And boom! There it was. I realized, I was like, "I basically just had to give my brain some time off," like my conscious brain needs some time off from software and it wasn't that it had disappeared because what I came up with on Monday was really just how home organization applies to code because I realized that the feelings that I get when I'm trying to figure out what I should do with code are very similar to the feelings that I get what I'm trying to figure out whether I should get rid of a thing. I look at this piece of code and I'm like, "Should I change this? Should I get rid of this? Should I refactor it?" You know, why I can't get rid of that? We just spent two weeks refactoring it so I can't change it again. [Laughter] SARAH: We just put in a story for refactoring this and we spent three days and I can't go back to the [inaudible] people and tell them, "I need to change it more." Or, "I really like this code because I wrote it with someone that I really liked." CHARLES: So I don't want to get rid of it. SARAH: I don't want to get rid of it because then I would lose the memory of working with, you know. CHARLES: I actually can say that I have experienced that. SARAH: Yeah, there's a lot of reasons why you don't want to change code. What I was thinking about, like maybe I was asking the wrong question, in the same way that 'should I keep this' is the wrong question when you're talking about stuff. Maybe 'should I change this' is the wrong question when you're talking about code. Maybe it's sort of leading you in the same way with stuff that leads you down this conversation of reasons that don't really have anything to do with the essential quality of why the code is there or why the thing is there. We need something that helps us reassess our needs. So if our needs have changed, maybe you don't need that thing anymore because your needs have changed. Same way with code. If your needs have changed, maybe you don't need that code anymore, at least not in the form that it's at now. I think that question for code that, "Does it bring me joy," because joy is not something that I think is concrete enough when we're talking about code. I think the question for code is do I understand this? Do I understand what it's doing? Not just understand it like a very surface level of like, "Can I figure out what this syntax means?" But understand it more like the grok level of like, I understand this at a very deep level. I understand why it's here. I understand what problem it's solving. I understand why this abstraction is necessary. I understand how it got here. CHARLES: Yeah, how it fits into the bigger picture. SARAH: How it fits into the bigger picture, exactly, like the application. CHARLES: How it fits in with like our conventions that are just purely stylistic. SARAH: How does it fit in with the other stuff that we've been doing? How does it fit in with the product needs and the features we're trying to build and the business goals and all of that stuff, all of these different levels of understanding of why this code is here and what it does? CHARLES: Do other team members' understanding factor into that? Like, "Do I understand the way that other people understand it," so to speak? SARAH: I think that it can. But I think the important thing is whether you personally understand it. CHARLES: Okay, like it's a very personal decision. SARAH: I think it is. Hopefully, what you do is you want different people looking at the same code. You don't want just one person on a piece of code that no one else ever sees, whether it's pairing or code review or whether it's something else. It need to be really clear to someone is coming in and looking at that code what it does, what it means, and why it's there? CHARLES: Right. I guess the reason I asked the question is because a lot of times when I look at a piece of code, I try and really step outside of myself and say, "What will someone else think who has never been on this project before?" Or, "Who is on this project and they see this code, will they understand it?" SARAH: Absolutely. It's definitely a part of it when you're on a team. CHARLES: Yeah, so I'm just trying to figure out how that question factors into this framework. SARAH: I think that it depends a lot on how you distribute tasks. For example, if you work in a shop where you're pair programming most of the time, so there's always two people looking at a piece of code, 'do I understand this' is a reasonable question just for the two of you to consider, both from the fact that you can pool your knowledge but also from the fact that 'are there pieces of this that you understand that I don't understand' and vice versa. On the other hand, if you work in a shop where it's more like, "Here's the piece of code that you work on like you own this section of code." Then I think it's more important for you to be able to step outside and be like, "Okay, do I understand this? Would other people on my team understand this?" That can be a very difficult thing to assess and that's where I think it's very helpful to do things like code reviews, call people in and be like, "Hey, can I run some stuff by you. I'm trying to figure out if this is good or not," because what you want is you want a code base that is comfortable and understandable for you and for your team. Just like the thing that makes the KonMari Method powerful for stuff is that it doesn't tell you what you're going to end up with. It doesn't tell you what level of clutter versus cleanliness is good for you. It doesn't tell you. You either end up like something in one of these simple living magazines or end up something like Quarters, the TV show. There's a bunch of places in the middle, they're all fine. Everyone's going to fall somewhere differently along that line. So I've managed now that I've thought about this a lot to set up my kitchen in a way that is very comfortable for me, like I know where things are, I can find them really easily, things that I use are at hand. But other people come in, they're just like, "I have no idea where everything is," like it's very personal. The organizational system you end up with [inaudible] that you have is a very personal thing and that's why, if you look at something like staged houses, so you're selling your house, you hire someone to put in rugs and furniture and stuff and make it look like somebody lives there so that people can walk in and sort of imagine themselves in this space, they don't put any of that clutter into the stage. They don't put any books on the coffee table except the big picture books. They don't leave the remote controls on the couch. There's no plunger by the toilet. There's no like -- CHARLES: There's no Legos on the floor. ROBERT: Everything that looks good. SARAH: Everything that makes it more personal, they leave out because it looks like somebody else's mess. You go into something like that and you're like, "This is not my mess. This is somebody else's mess. It can't possibly be my house and I'm not going to buy it. ROBERT: Oh, do we do this for software in conference talks and posts? SARAH: Absolutely, we do. That's sounds very similar when you get someone new onto a project, especially if they're more senior and they'll walk in and be like this, I can't live like this. [Laughter] SARAH: This is somebody else's mess and clearly we need to make some changes. But that's the reason why they leave it out of the staged houses is because you want people to be able to imagine their own level of clutter and disorganization that superimposed on the skeleton. But real life is not that. Real life is somewhere between that and hoarders. There's a very interesting parallel there with code, which is like when we look at code, if we look at the object-oriented design textbooks, you look at conference talks, you look at blog post, sample code, it's all very staged house. It's very uncomplicated. It has no clutter in it and that's because you're supposed to be able to look at that. CHARLES: I mean, that clutter can distract the sales process so to speak. SARAH: Exactly, like they have an idea they're trying to get across and the clutter would distract people from the idea. But the problem there is the same with the staged house which it's very difficult to tell what it will be like once you move in. It's very difficult to take some of these ideas that you see demonstrated in these staged environments and take them and apply them to your code base which is probably closer to a hoarded house than to a staged house especially if it's a code base that existed for a while over time, that has been worked on by lots of different people. This is the problem that I've noticed with a lot like there's some really amazing books about software design that have come out in the last couple of years. Of course, Sandi Metz's book is at the top of my list. But the thing that people have trouble with, like they love the book. They love the book. I love the book. But then they find it very difficult to apply those principles when they sit down in front of a code base that has already been worked on for six or seven years, in some cases by maybe 50 different people, who knows, over time. How do you take those principles and start applying them in a way that moves you in the right direction? That's where people are just like, "I can't do this. I can't do this and I'm not going to do this." And it's very similar to a problem where you've got a very dirty house and you don't know where to start in order to move it towards something from the Simple Living magazines or are more like a staged house, you don't know how to start to get it in that direction and so you just kind of give up. The powerful thing about KonMari is that it doesn't give you like, "Here's what you're going to end up with it," but it gives you a way to get started on something that gives you a very easy question to answer. It moves you in the right direction. It moves your house in the right direction without being overly prescriptive about what you'll end up with. CHARLES: Yeah, what that direction even is. SARAH: What you'll end up with is personal for you, anyway. I think the question about 'do I understand this code' is similarly helpful and that it moves you and your code base in the right direction without necessarily giving you a lot of prescription about how you do it or where it goes or even where it's going to end up. It just gives you a question to ask that it tells you whether or not this code needs to change and a question is, "Do I understand it?" If I don't, it should probably change, and if I do, okay, we can just kind of leave it for now. CHARLES: So now, if you're working on a team where you have two different people, maybe different skill levels, maybe just a different temperament or different set of preferences, what do you do when the answer to that question is two different things for two different people? SARAH: Well, sort of like when you move in with someone. This is the hard part about living with somebody else, is that you have to mutually agree upon a method of keeping your house that is agreeable to both of you. Sometimes, when they say that working through a startup is like being married to someone, there's some elements of that because you basically have to figure out like, "Okay, we're going to live in this code together. If we're going to live in this code together, we better both be happy with it. How can we both be happy with it?" It involves usually, some compromise, like I really hate doing the dishes but I don't mind cooking and vice versa. You have to figure out. It really bothers me when there's socks on the floor but I don't care if you leave dirty dishes in the sink or whatever it is. You just have to have these conversations about, "What is going to make the code livable for you?" You basically want to end up with a code base that's understandable where all parts of it are understandable to everyone on the team. Now that's like an ideal. You're not going to get there. But that's kind of what you're going for. If you have two people in the code and you have disagreements about what is the right way to go, sometimes it can help to just be like, "Hey, I don't really understand this," versus, "I don't think this is the right decision and here's why I don't understand this." Sometimes, reframing the question in that way can prompt them to communicate reasons that they have for doing this that they maybe weren't able to articulate before, for example. Just like when you move in with someone, you need to have sort of this commitment to finding a level of housekeeping that you're both happy with. When you're working on the team, you do have to have sort of a mutual commitment to having a code base that everyone can live in. CHARLES: Right. I like that because having like, "I just don't understand this and here's the reason why," that being a completely totally valid answer because sometimes in a code base, where someone's brand new or maybe they're at a more junior level, they don't quite have the tools to understand it or there's a lot of steps that haven't yet taken. It's like understanding is not going to be accessible to them immediately. SARAH: And maybe that means that's the wrong decision for that code base, is that right? CHARLES: Right. SARAH: Because if something is abstracting to the point that a lot of people on the team don't get it, then it's probably not the right abstraction for that code base. That abstraction might be totally appropriate in a code base in which you've got folks that are more experienced who understand why it's there, who have the scars from previous times when they didn't do it, et cetera, et cetera, and they understand why it's there. There is sort of like intellectual understanding of like, "Yes, object-oriented design is a good thing," and then there's, I would call it almost emotional understanding of like, "Oh, yeah, there's this time that we didn't do that and that worked out badly for us." I think that folks that don't have the sort of experiential understanding, sometimes they just need to have that. They need to get that. Sometimes, what that means is you want to let them see what happens to a certain extent. Let them see what happens when you don't do that. CHARLES: Right. This reminds me actually, I've got three kids and the way our house is now versus the way it was seven years ago is wildly different -- the way that we live. You know, with our first child, I'm ashamed to admit it, like our strategy was just to kind of put safety locks all over everything: every cabinet, on the oven, not on the refrigerator, but just kind of 'childproof' the house so that we wouldn't have to change the way that we lived but it made the house really uncomfortable for our children. And kind of having observed that over the course of having the second and the third, there's not anything that we childproof really. We put the dangerous chemicals way up high, where only we can get them. It's a little bit more inconvenient if we need to access the bleach but that level of discomfort is something that we live with. We've always got cups that are set out on a cabinet that sits below the counter so we've got water cups set out so that the children can get water and stuff anytime that we want, and we try, for things that they're going to need, make sure that it's accessible if you happen to be four feet shorter. That's just a condition of who you are. So it means that the actual configuration of our house, even though it's the same house, is just radically different and it is more optimized or it's optimized as a compromise for the fact that there are people living in this house now that haven't learned how to operate everything but they just need to learn that the oven is hot and you don't go there rather than slapping a lock on it. SARAH: Your house is probably more comfortable for you as a group, right? CHARLES: Yes. SARAH: And what that means is that as the 'senior' in the house, it's slightly less comfortable for you in some ways but it's worth it. It's worth being less comfortable for you in order to increase comfort across the board for everyone in the household. CHARLES: Right, because it means that if the child needs water, I don't have to stop what I'm doing to get a cup out of the cabinet and fill it for them. SARAH: And they feel [inaudible] over the stuff in their house. They feel like they live there, like the house is for them. CHARLES: Yes. ROBERT: That builds comfort and confidence. SARAH: Yeah, I think that's a very good analogy. Anytime you have a group of people living together, everyone makes compromises in order for the house to be set up in the way that's optimized for the group. CHARLES: Yeah. "So man, how are we going to apply this to software? What's the next step? What are the concrete steps?" I guess it's just asking those questions, like asking, "Did I understand it?" SARAH: It is asking those questions and it's also, if you are one of the more experienced folks on the team, it's your job to elicit the answers to that from other people that are less experienced. They're not going to tell you. A lot of times, sometimes, they may or may not feel comfortable saying that they don't understand something. So it's your job to really try and figure out like, "Do they get this at a level that is acceptable? Do they understand why this abstraction is here at an intellectual level or at an experiential level, at an emotional level? Do they get it?" Which is not something you can really just ask. In many cases, it's your job to -- CHARLES: To just observe it. SARAH: To observe and to see how it works. If people are having a hard time understanding where things are in the code base, it could be because everything is so cluttered that you can't see anything or it could be that everything is so hidden that you can't see anything. It's sort of the staged house equivalent where everything is too abstracted, or is it the hoarded house equivalent where everything is just obscure and under piles of junk. Either way, no matter which direction you need to move towards the middle, the question is always, "Do I understand this?" ROBERT: I like this a lot. I keep on coming to the analogy of if you put a chef in a different kitchen where everything is just totally rearranged and they don't know where their knives are, where their measuring cups are and stuff, I think that plays perfectly in a software of like you put somebody into a code base that they don't know, "All right, I'll figure it out." It's not their home. It's not what they're comfortable with or used to. Yeah, I think this is making my brain work on how I can apply this. SARAH: Or if they're moving in like when you hire somebody and they 'move into your house', you need to be ready for things to change. And this is one of the reasons why I've been saying for many years in ways that I think maybe didn't quite connect as well as they could have, that really the team is the code and vice versa. Every time you add someone to the team or someone leaves the team, teams are not mutable. You get a completely new team. So, it's not like you can just sort of carry on like you did before. Every time you get someone new onto the team, everything gets reimagined, every breakdown of responsibility, every decision. You look at it in a new way when you have someone new come on to the team. If they're going to stay, like in your chef example, if this person is moving in and this is going to be their kitchen and they're sharing it with other people, then what you're going to end up with is probably something in between what it is when they get there and what they had before. They're going to bring in some ideas, you're going to keep some of your ideas and you're going to end up with something in the middle. The same thing has to happen with your code when you bring someone new onto the team. CHARLES: I really like the way that this just focuses the discussion and I know that you've talked about this a lot before, whether it's a kitchen or a house, this idea of the code not being so much the shrink-wrapped product. It's a structure, yes. It is definitely that but it's a structure that you, as people, inhabit. It protects you from certain things and it provides you certain things that you need to live. When people ask us why is a continuous delivery pipeline so important in automating all these things for deploying your software it's because the idea is this is going to be a living thing that your team will actually be living in. And every member of that team will be living in from the time they start with the company or start with the project until the time that they exit and the time that they leave. It's the actual living process that you want to make comfortable and pleasant. SARAH: And what comfortable and pleasant means will be different depending on who's on that team? It's not something that you can have like a -- CHARLES: It's not. SARAH: Right. This is why all of these things are like, "Here's how you design things." It always seemed to fall flat. I think it would be better titled like, "Here's how I did one thing once." [Laughter] SARAH: Or, "Here's what works for me." I feel like every conference talk that is about design could be, "Here's what works for me. I did this one thing once." CHARLES: You might want to try it. SARAH: You could try it. It might work for you, it might not, right? CHARLES: Right. SARAH: A lot of times where conference talks fall flat and blog post and everything else was why they're more like, "This is how you do it. This is the right way to do it." You're like, "Well, it certainly works for you." [Laughter] ROBERT: The one time I gave a conference talk, the night before I went through every slide and scrutinized it as much as I thought somebody out in the public would do it. And I think that might be where we go through in a 'stage our code'. It's like we're trying to make it perfect for somebody that might come through and scrutinize it or criticize. Because I know when I was going up to put those slides up, I wanted to make sure it was the best foot I could possibly put forward. CHARLES: Right, we don't want to be wrong but I think that's where it actually, thinking of it as 'this is what worked for me' and this is an example from my house that worked. This is a way that I organize my code and my space. That'll not take a lot of pressure off of not having like, "I am right and I'm an authority at saying that this is the right way." That's a lot of pressure. SARAH: I don't even like that. I try and frame a lot of the things that I talk about as like, "Here's the thing that works for me really well. Maybe it'll work for you too. Let me know." CHARLES: Yeah. ROBERT: Yeah, that's how I give it. CHARLES: Up until really about two years ago, I felt like that was the expectation that was put on people is to say the right thing. SARAH: That's true. And I think that there's a lot of teams where that is an unspoken requirement and that's something that we should examine. Because even within a team like 'here's a thing that works for me or here's a thing that worked on my last project' isn't very different from saying something like, "Well, industry best practice --" [Laughter] SARAH: And I think that like you get to a certain level of experience and people expect you to say things like that. In my experience, the best way to do it is 'blah'. I mean, it's not actually a super useful statement because your past experience may or may not be directly applicable to the thing you're looking at right now, no matter how experienced you are. I think that it's much more friendly to have a range of experience levels to say things like, "Well, this worked for me on this project. Let's talk about whether it could work here." CHARLES: Right, yeah. ROBERT: I really like that. CHARLES: I do. It's so hard because your human nature is to try and boil things down into a simple binary. SARAH: People would love to have a list of rules, I'll tell you that. This is a problem. This is one of the reasons why I think it's important for us to come up with these questions that you can ask that will move you in the right direction without giving you rules, that will move you in the direction of finding the rules that work for you. Because rules themselves, people really, really, really want them. But they're always misused. They're always misunderstood and what you really need are the questions that led you to those rules in the first place. That's what people really want, although maybe that's not what they are asked. ROBERT: Ah, the Steve Jobs approach. SARAH: [Inaudible] to start wearing black turtlenecks. I hate turtlenecks. ROBERT: And New Balance shoes and the jeans. [Laughter] SARAH: But yeah. I think it's one of those things where people are very hungry for guidance. But we've been giving them the wrong kind of guidance. We've been trying to give them rules. When what we really need to do is give them questions to help them develop their own judgment. ROBERT: Right. Like when I was coming up, I thought, in everything, there was a right way to do it and a wrong way to do it. I've been slowly, sadly figuring out that it's not all black and white and it's not all just logic. I've always treated programming as like, "Well, they wrote this and it's just logic so I should be able to understand this." It's been a long road to come to this conclusion that kind of like what you're talking about and this has been enlightening for me. Like you are going to solve your problems your own way, your own person, and you'll think about things differently. I really like the analogy of 'this is your house and this is how you work and live in your house'. SARAH: Right, and no one would tell you in order to be a proper human being, you have to set up your house this way. ROBERT: Exactly. SARAH: We feel comfortable telling people, in order to be a professional developer, you need to set up your code this way. I think that those are very similar statements and we should really examine a lot of these 'should' statements that are all over the place when you're talking about software. Think about whether or not they're actually serving us in our mission of doing more things with tech. Like overall, my mission here is for people to be more effective with code so that we can do more interesting things with it. I live in the TV show, Silicon Valley, essentially so I'm surrounded by these companies that are solving these little tiny problems and I'm tired of it. I want us to solve bigger ones. In order to do that, we need to get better at coding. We need to get better at managing code over time and that's what I'm trying to do. CHARLES: Because it's not going to scale, otherwise. We're out of time. We're going to have to have you on the podcast again because I don't think we've got to... what? About 15% of the things that we want to talk about? SARAH: Oh, we are overtime, aren't we? CHARLES: Yeah. But thank you so much, Sarah, for coming on and talking with everybody. You drop real quick your Twitter handle so that if people want to have follow on discussion, they can reach out to you that way, or your other preferred means of contact. SARAH: Yeah, Twitter is probably the best. My Twitter is @sarahmei, and that's mostly where I am. CHARLES: All right. Well, fantastic. As always, feel free to reach out to us too. I'm @cowboyd on Twitter. And what are you, Rob? ROBERT: @robdel12. CHARLES: All right. It's a wrap. Thank you so much, Sarah, and we'll see you in Ether and hopefully we'll have you on the podcast again sometime.

Inspired by Nickolas Means' fantastic RailsConf keynote, we discuss the corollaries between Lockheed Martin's Skunk Works projects and our software development projects. Sean's DXRacer Chair Skunk Works by Nickolas Means Lockheed Martin F-35 Lightning II Big Design Up Front Kelly's 14 Rules and Processes Rules Made Up by You - Kelly's rules as applied to modern software development Factory, Workshop, Stage by Sarah Mei The Tyranny of Structurelessness How to Crash an Airplane by Nickolas Means

Sandi Metz joins us live from RailsConf to talk about the rules, the trouble with naming things, making the right kinds of errors, and conference speaking. The Bike Shed - Episode 1: Sandi and Derek's Rules Sandi Metz' Rules For Developers Sandi on the Ruby Rogues Don't Create Verb Classes Swift Proposal for Default Final GoRuCo 2009: SOLID Object-Oriented Design by Sandi Metz How to Talk to Developers by Ben Orenstein What Your Conference Proposal is Missing by Sarah Mei A big thanks to everyone who came out to our live show! A video version of this episode is available on the thoughtbot YouTube Page.

While at RailsConf, we talk with Katrina Owen about finding metaphors for software development, the successes and mistakes of Exercism.io, and the benefits of providing code reviews. Katrina Owen Katrina's conference talks Make the change easy, then make the easy change Skunk Works by Nickolas Means Factory, Workshop, Stage by Sarah Mei The Product Design Sprint Exercism.io Exercism GitHub Organization

Sarah’s Bio: Sarah is a Ruby and JavaScript developer based in San Francisco, California. As the Chief Consultant at DevMynd Software, she spends most of her time pairing with her clients’ developers, helping level up their team. Her particular areas of interest are Object-Oriented Programming, service refactorings, growing teams, and inter-developer dynamics. She has written about my experiences pair programming and...

Sarah's Bio: Sarah is a Ruby and JavaScript developer based in San Francisco, California. As the Chief Consultant at DevMynd Software, she spends most of her time pairing with her clients' developers, helping level up their team. Her particular areas of interest are Object-Oriented Programming, service refactorings, growing teams, and inter-developer dynamics. She has written about my experiences pair programming and...

Sarah’s Bio: Sarah is a Ruby and JavaScript developer based in San Francisco, California. As the Chief Consultant at DevMynd Software, she spends most of her time pairing with her clients’ developers, helping level up their team. Her particular areas of interest are Object-Oriented Programming, service refactorings, growing teams, and inter-developer dynamics. She has written about my experiences pair programming and...

Sarah's Bio: Sarah is a Ruby and JavaScript developer based in San Francisco, California. As the Chief Consultant at DevMynd Software, she spends most of her time pairing with her clients' developers, helping level up their team. Her particular areas of interest are Object-Oriented Programming, service refactorings, growing teams, and inter-developer dynamics. She has written about my experiences pair programming and...

What's it like to be a guest on Mentoring Developers? Sarah Mei special! Hello dear listeners! I'm your host Arsalan and I am really glad you could join me in Episode 19. This episode will be different from the first 18 episodes and we will look back at the way the podcast has gone in 2015...

What’s it like to be a guest on Mentoring Developers? Sarah Mei special! Hello dear listeners! I’m your host Arsalan and I am really glad you could join me in Episode 19. This episode will be different from the first 18 episodes and we will look back at the way the podcast has gone in 2015...

We talk about lessons learned from teachable moments both in the moment and decades later. Teachable moment Safe Operations for High Volume PostgreSQL by Paul Gross How to Create Postgres Indexes Concurrently in ActiveRecord Migrations by Dan Croak PostgreSQL COPY FROM Guarding against truncating the production database in Suspenders Have Some (Referential) Integrity with Foreign Keys "Inheritance is not for sharing code" tweet from Sarah Mei "Inheritance is for specialization, not for sharing code" from Sandi Metz' "Nothing is Something" talk at RailsConf Let's Not by Joe Ferris Mystery Guest by Dan Croak A modem pool Diesel née YAQB

Check out and get your ticket for Rails Remote Conf!   02:00 - Sarah Mei Introduction Twitter GitHub Blog Devmynd RailsBridge 06:11 - Why It’s Hard to be “The First Person” Biases Mind the Gap - On the unconscious bias we all carry, and how it applies to hiring Avdi Grimm: What it’s like to come back to a Ruby project after 6 months 13:27 - Transmitting Cultural Values 16:01 - What Companies Can Do Dev Team Diversity #Realtalk - On the unprecedented opportunity we have right now to diversify our small teams Everyone has something to learn; Everyone has something to teach (Mentoring) 22:35 - What do you look for in a person as a hiring company? Rubberducking 24:46 - Setting Expectations Around Pairing Sessions Pairing with Junior Developers - On making sure newer devs can be successful once they're hired 27:45 - Whisper Networks Tomas Chamorro-Premuzic: Why Do So Many Incompetent Men Become Leaders? 34:08 - Performance Review “How can we make you successful?” 42:15 - “I will help you find a better fit.” Investment and Risk 44:40 - Communication Culture Ask vs. Guess Culture 50:43 - Empathy How to Win Friends & Influence People by Dale Carnegie Picks troll-repellant (Coraline) Avdi Grimm: An alternative to `puts` in Ruby (Coraline) Alan C. Kay: The Early History of Smalltalk (Avdi) RubyTapas (Avdi) Rails Remote Conf (Chuck) Loot Crate (Chuck) Prints and Visual Communication (Sarah) Artful Making: What Managers Need to Know About How Artists Work by Robert Austin (Sarah)

Check out and get your ticket for Rails Remote Conf!   02:00 - Sarah Mei Introduction Twitter GitHub Blog Devmynd RailsBridge 06:11 - Why It’s Hard to be “The First Person” Biases Mind the Gap - On the unconscious bias we all carry, and how it applies to hiring Avdi Grimm: What it’s like to come back to a Ruby project after 6 months 13:27 - Transmitting Cultural Values 16:01 - What Companies Can Do Dev Team Diversity #Realtalk - On the unprecedented opportunity we have right now to diversify our small teams Everyone has something to learn; Everyone has something to teach (Mentoring) 22:35 - What do you look for in a person as a hiring company? Rubberducking 24:46 - Setting Expectations Around Pairing Sessions Pairing with Junior Developers - On making sure newer devs can be successful once they're hired 27:45 - Whisper Networks Tomas Chamorro-Premuzic: Why Do So Many Incompetent Men Become Leaders? 34:08 - Performance Review “How can we make you successful?” 42:15 - “I will help you find a better fit.” Investment and Risk 44:40 - Communication Culture Ask vs. Guess Culture 50:43 - Empathy How to Win Friends & Influence People by Dale Carnegie Picks troll-repellant (Coraline) Avdi Grimm: An alternative to `puts` in Ruby (Coraline) Alan C. Kay: The Early History of Smalltalk (Avdi) RubyTapas (Avdi) Rails Remote Conf (Chuck) Loot Crate (Chuck) Prints and Visual Communication (Sarah) Artful Making: What Managers Need to Know About How Artists Work by Robert Austin (Sarah)

Check out and get your ticket for Rails Remote Conf!   02:00 - Sarah Mei Introduction Twitter GitHub Blog Devmynd RailsBridge 06:11 - Why It’s Hard to be “The First Person” Biases Mind the Gap - On the unconscious bias we all carry, and how it applies to hiring Avdi Grimm: What it’s like to come back to a Ruby project after 6 months 13:27 - Transmitting Cultural Values 16:01 - What Companies Can Do Dev Team Diversity #Realtalk - On the unprecedented opportunity we have right now to diversify our small teams Everyone has something to learn; Everyone has something to teach (Mentoring) 22:35 - What do you look for in a person as a hiring company? Rubberducking 24:46 - Setting Expectations Around Pairing Sessions Pairing with Junior Developers - On making sure newer devs can be successful once they're hired 27:45 - Whisper Networks Tomas Chamorro-Premuzic: Why Do So Many Incompetent Men Become Leaders? 34:08 - Performance Review “How can we make you successful?” 42:15 - “I will help you find a better fit.” Investment and Risk 44:40 - Communication Culture Ask vs. Guess Culture 50:43 - Empathy How to Win Friends & Influence People by Dale Carnegie Picks troll-repellant (Coraline) Avdi Grimm: An alternative to `puts` in Ruby (Coraline) Alan C. Kay: The Early History of Smalltalk (Avdi) RubyTapas (Avdi) Rails Remote Conf (Chuck) Loot Crate (Chuck) Prints and Visual Communication (Sarah) Artful Making: What Managers Need to Know About How Artists Work by Robert Austin (Sarah)

Sean, Derek, and Sarah Mei talk about conference speaking, refactoring, and OO vs FP problems. Sarah Mei What Your Conference Proposal Is Missing Conway's Law Will Ruby 3.0 Be Statically Typed? Sarah on Twitter

Sarah Mei joined the show to talk through a recent article she authored titled “Mind the Gap” and why we’re missing our best chance for gender parity. We discussed our innate subconscious assumptions and prejudices towards one another, how we alienate women from the developer communities, and what we can do to step across this gap and make a conscious effort to combat those assumptions.

Sarah Mei joined the show to talk through a recent article she authored titled “Mind the Gap” and why we’re missing our best chance for gender parity. We discussed our innate subconscious assumptions and prejudices towards one another, how we alienate women from the developer communities, and what we can do to step across this gap and make a conscious effort to combat those assumptions.

Sara Mei joins us this week to discuss passion and whether it's a job requirement that you "love programming". She's a Chief Consultant at DevMynd, a co-founder of RailsBridge, and an all-around rad human. Today we talk about whether it's okay to get your motivation from things other than your sheer passion for programming, such as societal impact or what you can do with your code. The tweet that started it all Sarah Mei RailsBridge Sara at DevMynd Sarah's new book with Sandi Metz The Moderately Enthusiastic Programmer The Passion Gospel

Ben Orenstein is joined by Sarah Mei, RailsBridge co-founder, a developer at Pivotal Labs, and Diaspora core team member. In this episode, recorded at RubyConf 2012, Ben and Sarah discuss how communication patterns of your team manifest themselves in the code it writes, and how understanding those patterns can help you improve your code. They discuss RailsBridge, teaching, how teaching is an incredible learning opportunity, and how RailsBridge has helped expand the community of women developers in San Francisco and beyond. Finally, they explore how she got into Ruby, and women in technology. RailsBridge Pivotal Labs Follow @thoughtbot, @sarahmei, and @r00k on twitter.

The Rogues talk to Sarah Mei about the Rails Bridge program.

The Rogues talk to Sarah Mei about the Rails Bridge program.

The Rogues talk to Sarah Mei about the Rails Bridge program.