Podcasts about tech done right

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.  Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.  Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components.  Panelists Andrew Mason David Kimura With special guest: Mike Schutte Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot  Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.  Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.  Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components.  Panelists Andrew Mason David Kimura With special guest: Mike Schutte Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot  Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

Mike Schutte is a fronted developer at TED conferences and was trained in code school at Turing in Colorado. He likes the idea of code as a communication tool, and in 2018 he gave a talk at RailsConf called Stop Testing. Start Storytelling.  Today the panel is discussing what Mike means by storytelling in testing. In order to combat the hesitancy to start testing, Mike believes that changing your mindset to think away from the implementation details while deploying these tests can help them be more efficient. In short, if the test isn’t readable by a non-developer, then it’s not telling a story, it’s just writing code. The test is almost the first point of contact away from the source code, so if that’s unwieldy in a test it will be hard to use elsewhere in the application. We have an intuition for stories, so use tests in order to communicate the intent of what the application should do under certain conditions. If it’s hard to set that up in a succinct way then maybe it should be written differently. This view is backed up by other experts as well. Sandi Metz and Noel Rappin talk about it in Tech Done Right episode 69. They say if your test isn’t easy to write and you’re having to create tons and tons of objects, then the system or the class your trying to test is too interconnected, so you might want to break that up into more separated concerns so each of your tests can be focused on what you’re actually trying to test. If you follow these principles, your testing will be a lot easier even if there are more classes and modules to test. David applies this approach to an online shopping cart and how to break it up. The idea is to abstract it away from the big picture, in this case the grand total, and breaking it down into smaller stories or things.  Mike shares methods to put this approach into practice and how to test. He finds that reading the code as if you were reading a section in a novel rather than code helps him sketch out what he needs to test. The panelists discuss different methods for testing, emphasizing keeping the models or classes you write very simple, minimizing the amount of full on feature specs. If you take time to think about the mindset and the process you use to write a test, the tools you use becomes interchangeable in a lot of ways. Andrew brings up a trend that he’s noticed of tools coming out that are taking mini tests or rspec and trying to morph it to the programmer’s preferences. Tools like this end up with a lot of weird syntax that is hard to maintain. The panelists acknowledge the challenges that stem from using a custom VIM, and believe that having an agnostic approach makes it easier to jump into different systems. Your focus shouldn’t be your developer preferences or what you’re used to, rather it should be your happiness when you have to update. They agree that because it’s easy to understand, it’s telling a story the reader can understand, which makes it easier to maintain in the long run. The Ruby Rogues panel talk about different methods for testing, particularly if they’ve ever tested JavaScript code in a Rails app. They talk about some of their preferred tools to test their code, such as StoryBook. Mike talks about what StoryBook is and what it’s like to use it. David talks about his experience using Cucumber, why his team used it, and how it works. The show concludes with Mike sharing some of the benefits he has found from using typed languages like TypeScript and the panel talking about their experience playing around with Actionview components.  Panelists Andrew Mason David Kimura With special guest: Mike Schutte Sponsors Sentry use the code “devchat” for 2 months free on Sentry’s small plan Cloud 66 - Pain Free Rails Deployments Try Cloud 66 Rails for FREE & get $66 free credits with promo code RubyRogues Elixir Mix Podcast Links Stop Teaching. Start Storytelling (RailsConf 2018) Tech Done Right episode 69 Law of Demeter Grumpy Old Man RSpec MaxiTest Minitest Spec Thoughtbot  Jest Stimulus Webpacker StoryBook Cucumber TypeScript Actionview component Follow DevChatTV on Facebook and Twitter Picks David Kimura: Rode Podcaster Andrew Mason: Drifting Ruby 196 VS Code Ruby Debug Mike Schutte: Follow Mike on Twitter @tmikeschu StoryBook.js

Karen Catlin on Retaining WIT, Jonathan Cutrell on Maintainable, Dr. Aneika L. Simmons on Hanselminutes, Sarah Wells on Engineering Culture by InfoQ, and Dave Thomas and Andy Hunt on Tech Done Right by Table XI. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting September 16, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. KAREN CATLIN ON RETAINING WIT The Retaining WIT podcast featured Karen Catlin with hosts Jossie Haines and Jordanna Kwok. Karen, who is a leadership coach and diversity advocate, got interested in tech when she saw an issue of Money magazine with a cover story about successful women with computer science backgrounds and her father pointed out the connection between a career in software and Karen’s love of crafting, puzzle-solving, and mathematics. She started her career in 1985, which was a peak year for women in Computer Science. In that year, 37% of the Computer Science degrees went to women. It dropped to a low of 17% but has started to go up again in recent years. Karen started a coaching practice because she wanted to help women who wanted to grow their careers and stay in tech. She soon realized that, even if she could be the most amazing coach on the planet, her clients would still be facing an uphill battle because they were working in companies that were not the meritocracies they claimed to be. This led Karen to explore an idea: “Instead of trying to fix the women, let’s start fixing the men.” She says there is a role for every man who is working in tech to create a more inclusive workplace on his work team and at his company. Karen says that mentoring programs are a great opportunity for people to pass on advice to someone who hasn’t had the same amount of experience, but there is a trap: studies have shown that most of us mentor people who remind us of our younger self. Karen’s advice is, if you’re doing mentoring, mentor someone who doesn’t look like you. Don’t have a mini-me protégé. Another piece of advice from Karen is to pay attention in meetings. Look out for interruptions. There is research showing that men interrupt women much more than the reverse and that women who are getting interrupted tend to step back and not participate in the rest of the meeting or future meetings. So, when you see people getting interrupted, say something like, “Jordanna was making a great point. I’d like to hear more about that.” Another thing to watch for is what Karen calls “bro-propriation”: a woman says something in a meeting that falls flat and then, later on in the same meeting, a man says the same thing and gets all the credit. An ally can say something like, “Hey, I see that you agree with the point that May was making earlier.” Discussing hiring, Karen says she used to grab old job descriptions and add new requirements to them, reasoning that all the old requirements are still relevant. She says that you should instead try to get your job description down to just five requirements. Research has shown that women apply for jobs when they have all the skills listed in the job description while men apply even if they have little more than half of the listed skills. Karen also says to have objective criteria to use for every single candidate. Ideally, use the same interview questions. She told a story about moving to Silicon Valley with her partner Tim and applying to work at the same company in the same software engineering role. The two of them had interviews the same day. Driving home at the end of the day, Tim related to Karen that his interviews were among the most difficult he had ever had while her own experience was that the interviews had all been easy. The interviewers had dumbed down the questions when interviewing her. They were both offered jobs, but she decided not to take her offer because the company didn’t respect her enough to ask her the same difficult questions they had asked men applying for the same position. She then spoke about the importance of public speaking in gaining visibility and how it can help with both recruiting in the case of giving external talks and with getting your ideas considered.  Apple Podcasts link: https://podcasts.apple.com/ca/podcast/karen-catlin-on-being-better-allies/id1458996260?i=1000440710563 Website link: https://www.retainingwit.com/karen-catlin JONATHAN CUTRELL ON MAINTAINABLE The Maintainable podcast featured Jonathan Cutrell with host Robby Russell. Jonathan is the host of the Developer Tea podcast and is a senior engineer at Clearbit. Robby asked Jonathan what he thinks are the characteristics of a healthy and maintainable codebase. Jonathan says testing and having a consistent way of testing is critical to maintainability. He also looks at the size of each concept the code expresses to see if it can fit in a person’s head. Robby asked how Jonathan’s teams have achieved consistent testing. Jonathan says that human beings are pretty good at being about 90% consistent, which is almost worse than being 0% consistent. He says to take the load off the human engineer and, for those times when you still need to put the load on them, have a way to proceduralize things such as by having a checklist or template. Robby asked what Jonathan thinks developers often get wrong when they talk about technical debt. Jonathan says that debt is an easy term to throw around because, in the financial sense, it is a very clear concept. Technical debt does not have so clear a definition. You need to evaluate what your team cares about and what has been costly from a business perspective. Some things that we may think are debt are just emotionally difficult to accept: code that we wish was different but isn’t actually causing any real problems or even forecasted to cause problems. One factor that Jonathan thinks should be consistently considered technical debt is code that is staying around but for which you don’t have any kind of validation.  I liked Jonathan’s metaphor for attempting to refactor code that is not under a lot of churn. Picking up code that isn’t changing much and improving its design, he says is like paying off low-interest mortgage debt. There are probably better places to expend our effort. Developers tend to treat decisions around technical debt like one would treat the decision to clean up your house. You have the sense of ownership over your home and, regardless of whether there is risk of future problems, we feel the need to clean things up. They talked about why Jonathan started the Developer Tea podcast. Jonathan wanted a podcast that he could listen to on an afternoon walk for five to ten minutes and learn something new. Most podcasts at the time were much longer and more entertainment-driven, and he wanted something that focused on the more human aspects of the job in a short, inspirational form. He says that the podcast has been one of the most rewarding things he has done in his career. The most rewarding experiences have been when people send him emails about how an episode or series of episodes have shifted the way they think about a topic or even about how they think about their career. They talked about whether there is a correlation between healthy code and healthy teams. Jonathan says there is data around teams in general that says teams that good relationships with their manager and the people they work with have the highest performance and the lowest turnover. These good team dynamics have visible effects on the code. Strong teams, Jonathan says, eradicate fear. These fears are things like fearing that someone is going to judge you poorly when they look at your code. Second, the best teams also know how to come up with the best ideas, which involves one or more team members being able to give up their own idea without attaching a sense of failure to letting that idea go. Third, members of strong teams recognize the humanity of everyone on their team. Robby asked what developers get wrong when evaluating their peers. Jonathan says that people, in general, tend to see everyone around them as inadequate as a way to containerize the rest of the world. This bias helps us to make decisions without being riddled with anxiety about them. The downside of this shows up when we are tasked with evaluating another person. This feeling that everyone else is inadequate combines in a bad way with our natural loss aversion when we try to make sense of things. Most failures are the result of factors that could not be controlled or predicted. With hindsight, when a project is late, we try to think of why it was late and we often come up with a reason, rightly or wrongly. We don’t often come to the conclusion that the project failed because something random happened. As a result, performance reviews tend towards the negative side unless we actively bias away from that. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear/id1459893010?i=1000447238745 Website link: https://maintainable.fm/episodes/jonathan-cutrell-healthy-teams-know-how-to-eradicate-fear-LgRTt32R DR. ANEIKA L. SIMMONS ON HANSELMINUTES The Hanselminutes podcast featured Dr. Aneika L. Simmons with host Scott Hanselman. Scott asked Aneika about the talk she gave with her husband Anjuan, “Managing The Burnout Burndown” at the Lead Dev conference: https://www.youtube.com/watch?v=e2dgOfedI3A. She talked about burnout having multiple dimensions including emotional exhaustion and depersonalization. When you are burned out, the people you work with start to lose, in your eyes, their personhood. Scott asked about how having a culture that depersonalized employees, such as by referring to them as “resources”, might lead to burnout. Aneika talked about how having a culture that values the highly-engaged software developer counter-intuitively increases rather than decreases burnout. She talked about managing burnout with the help of your relationships. When Aneika is looking burned out, Anjuan will often say, “Aneika, let’s go for a walk.” She talked about the American notion of the “protestant work ethic” and how the work itself is valued and makes the worker feel important and gives them a sense of meaning. Those that are not working are made to feel like they are not contributing. Scott connected this to how many Americans do not take all of their vacation days. Aneika talked about the difficulty of achieving work-life balance when pleasing your boss means disappointing your family and vice versa and she described how stress is the cause of many illnesses, telling her own story about getting a sore jaw while working on her dissertation because the stress caused her to start grinding her teeth. Aneika suggested building relationships with your boss and your team so that they see you as a person and not just as a contributor. When they see you as a person, they are less likely to attempt to make you feel small when you need to take time for yourself. Here's Aneika on the relationship between engagement and burnout. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/managing-the-burnout-burndown-with-dr-aneika-simmons/id117488860?i=1000447003518 Website link: https://hanselminutes.simplecast.com/episodes/managing-the-burnout-burndown-with-dr-aneika-simmons-1caMsclq SARAH WELLS ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Sarah Wells with host Shane Hastie. Sarah is the technical director of operations and reliability at The Financial Times. When Sarah joined FT in 2011, the company was full of smart people, but they were hampered by a frustrating set of processes. During the last eight years, they adopted a DevOps culture with a focus on automation. When she joined, it took an average of 120 days to provision a new server. They stopped tracking the improvement when they got it down to minutes. They moved from 12 releases a year to many thousand releases a year. This required pushing decision-making down to the individuals making the changes. Shane asked about how to achieve a culture of safety and experimentation. Sarah says it has to come down from the top. You cannot have a CIO or CTO is saying, “What went wrong? Who did this?” You optimize for the speed of release and for speed of fixing. You do incident reviews, but their goal is to improve things for next time, not lay blame. If you drop a database in production as a developer, that is not your fault. The fault is that it is too easy to do that. Shane asked what a culture of experimentation looks like at “the coal face.” Sarah referenced Linda Rising in saying that it is not an experiment if there is not a hypothesis and if it can’t fail. As soon as something costs a certain amount of money, very few organizations are willing to write it off, so if you’re going to experiment, it has to be something cheap and quick. Sarah gave an example of an experiment to test a design change in which they would show the star-rating on the list of film reviews. The thinking was that this would increase engagement. The experiment showed that engagement went down instead because people were less likely to click to see the full review once they had the star-rating. Shane asked about how Sarah limits the blast radius of changes. Sarah says that by releasing small amounts of code frequently and having an architecture like micro-services to keep components extremely decoupled, you are better able to understand the code you are releasing and the change is localized and less likely to affect distant parts of the product. You can also design your website to have graceful degradation when a particular service is not returning results. Shane asked about Sarah’s preference to buy rather than build. Sarah referenced Simon Wardley’s value-chain mapping and establishing the core thing a business does. For FT, the core business is news, so something like doing their own container orchestration is not part of that. Originally, they did their own container orchestration, but once Kubernetes was available, they moved to it. In discussing the sunk cost fallacy, Sarah says you always have to fight to invest in the technical stuff, so you need a good relationship between the tech leads and the product people to explain the benefits of particular technical decisions. You also need to accept that things change and you won’t always get it right. The flip side of moving fast is that sometimes you get it wrong. She related a quote from Jeff Bezos in a letter to shareholders about one-way door and two-way door decisions. For decisions that are likely a one-way door, invest time in getting them right, but for most decisions, you should just decide, commit, and revisit. Shane asked how the listeners who are working on monoliths that release once a month can get to where FT is at today. Sarah says that you need a continuous delivery pipeline so it takes no time at all to get a release out. The second thing is architectural changes. Get to zero-downtime deployments. The cultural aspects are things like process. Reduce anything that requires permission from an external team. It has to be possible for a team to just get going. She referenced Accelerate by Forsgren about the research that says not to have change approval boards. Architects get embedded in the individual teams instead. You want your engineers to be T-shaped, having one specialty but also having some skill in all areas. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sarah-wells-on-fts-transition-to-devops/id1161431874?i=1000446732957 Website link: https://soundcloud.com/infoq-engineering-culture/sarah-wells-on-fts-transition-to-devops DAVE THOMAS AND ANDY HUNT ON TECH DONE RIGHT The Tech Done Right podcast featured Dave Thomas and Andy Hunt with host Noel Rappin. I realize that this is the third time in as many weeks that I have included a podcast episode featuring Dave and Andy talking about the 20th anniversary of The Pragmatic Programmer, but they keep saying different and interesting things on each podcast they visit that I keep wanting to share it. In this podcast, Dave described what being pragmatic means to him. He says that being pragmatic means doing what works, but nobody knows what works. The cool thing about software, which is also the scary thing about software, is that we are constantly reinventing the entire field. Every project is new: it has new circumstances, new technologies, and new requirements. When you don't know what to do, being pragmatic means exploring as much as you can to find out what works, having in place a system of feedback to tell you whether it is working or not, and taking steps that are reversible so that, if you make a mistake, you can go back and fix it. This, Dave says, is the essence of the book. Noel added a fourth variable, the team, that is different every time, and asked what the pragmatic approach is for how a team works. Dave says that a team is a voluntary collection of individuals. You don’t have a team that you put people into; you start with a group of people and try to turn them into a team. The book dedicates a chapter to teams that echos the previous chapters on individuals because teams need to know all the things that individuals need to know: they need to realize that they are going to make mistakes, they need to figure out when they’ve made a mistake, and they need to know how to fix those mistakes and minimize them in the future. As a programmer, your job is not to write perfect code; your job is to create something that does what the customer wants. If there are bugs along the way, that is not an exception; it just the way it is. The same applies to teams. When teams adopt that approach, they lose the incentive to blame people for things and they take on collective ownership. Andy says that the one thing that is unique to teams is an underlying trust of each other member of the team. You are much better off with relatively small, stable teams. Every time you add someone to or remove someone from a team, it is a new team and you need to start over building relationships, building trust, and learning to work with each other. Noel asked how they would compare The Pragmatic Programmer with the Agile Manifesto since they were involved in the creation of both. Dave suggested thinking of Agile methodologies like XP as a roadmap and The Pragmatic Programmer as your car. Noel said that, in re-reading The Pragmatic Programmer, he was struck by the emphasis on taking small steps and “not getting in front of your headlights”. Andy says that is critical idea because we fall into the trap of taking on too much at once all the time. Small steps, Dave added, also mean you can more easily undo and you are less likely to fall victim to the sunk cost fallacy because your sunk costs are smaller. Noel asked if the way in which developers learn has changed in the last twenty years. In reference to books versus StackOverflow searches and watching videos, Dave made the point that the distinguishing aspect of a book is that the content is curated; putting it together was difficult; it took a long time for the author to organize their thinking to make it clear and approachable and to produce something authoritative and easy to read as a whole. Noel asked Dave about the pragmatic value of automated testing. Dave says that when he gets too comfortable doing something, he tries to stop using it so that he doesn’t get stuck in a rut and so that he doesn’t start to believe something religiously simply because he has been doing it a long time. He had been telling people for years that it is good to test and he had never done the experiment of not testing. He decided not to test for a period and was surprised by the result. He kept an eye on bug rates and it was just as buggy as ever, his productivity went up a little bit, and his designs were just as flexible as before. His explanation is that, having done the requisite ten thousand hours, it is now so ingrained that he doesn’t have to test to get the benefits of testing. He still feels that tests are useful when working with others and as a regression barrier. He sees his experiment with not testing as another example that nothing is sacred: if you’re truly being pragmatic, you should always be experimenting. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-68-pragmatic-programmer-at-20-dave-thomas-andy/id1195695341?i=1000446898661 Website link: https://www.techdoneright.io/68 LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

Food and Design Thinking TableXI is now offering training for developers and products teams! For more info, email workshops@tablexi.com. Guests Rex Chekal (https://twitter.com/rexerr): Director of Digital Strategy and Product Designer at Table XI (https://www.tablexi.com/). Jessie Shternshus (https://twitter.com/TheImprovEffect): Founder and Owner of the Improv Effect (https://improveffect.com/). Chemia Davis: Innovation Methods Conductor and Member of the Tyson Foods Innovation Lab (https://www.tysonfoods.com/innovation/food-innovation/innovation-lab). Santi Proano: Experimental Brand Dreamer for Yappah Foods (https://www.yappah.com/) and Member of the Tyson Foods Innovation Lab (https://www.tysonfoods.com/innovation/food-innovation/innovation-lab). Summary In this episode, we have a slightly different topic for Tech Done Right - food. Table XI has been working to adapt our design sprint process out of the realm of custom software and into more general product design. In particular, we've worked with Tyson Foods Innovation Lab on a few different projects including the creation of their Yappah brand which is designed to prevent food waste. In this episode, you'll hear from Chemia Davis and Santi Proano from Tyson, Rex Chekal from Table XI and Jessie Shternshus from the Improv Effect and we'll show you how we adapted design thinking and Agile process from software to food products. Notes 02:58 - The Scope of Work Between Table XI and Tyson Foods Innovation Lab 04:08 - The Goal of the Innovation Lab - Consumer Packaged Goods (CPG) (https://www.investopedia.com/terms/c/cpg.asp) 06:51 - Bringing Design Thinking to Product Development and CPGs 11:13 - Design Steps - Nduja (https://en.wikipedia.org/wiki/%27Nduja) - YAPPAH! Chicken Crisps (https://www.yappah.com/the-menu.html) 17:14 - Facilitating Communication 22:05 - The Sprint Week Experience - The Three-Hour Brand Sprint (https://library.gv.com/the-three-hour-brand-sprint-3ccabf4b768a) 26:40 - Next Steps After Sprint Week - Yappah on Indiegogo (https://www.indiegogo.com/projects/yappah-protein-crisps-rethinking-snacks-for-good#/) 29:32 - Learning From the Design and Coaching Process Special Guests: Chemia Davis, Jesse Shternshus, Rex Chekal, and Santi Proano.

Mary and Tom Poppendieck on The Modern Agile Show, Daniel Mezick on Agile Uprising, Jennifer Tu, Zee Spencer, Thayer Prime, and Matt Patterson on Tech Done Right, James Colgan on This Is Product Management, and Matt Kaplan on Build by Drift. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting March 18, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. MARY AND TOP POPPENDIECK ON THE MODERN AGILE SHOW The Modern Agile Show podcast featured Mary and Tom Poppendieck with host Joshua Kerievsky. Recorded at the ScanAgile 2018 conference in Helsinki, Mary and Tom talked about their keynote on proxies and permissions. Inspired by Bret Victor’s statement that creators need an immediate connection to what they create, Tom and Mary presented on how the most effective teams are autonomous, asynchronous teams that are free of the proxies and permissions that separate creators from their creations.  This led to a discussion of lean thinking and Mary pointed out that the interesting thing about lean is that fast and safe go together. She gave the example of a construction site where nothing slows things down more than the occurrence of an accident. Mary talked about how Jeff Bezos is a good early example of someone who understood that if you want to get really, really big, you need to have autonomous agents acting independently and thinking for themselves. iTunes link: https://itunes.apple.com/ca/podcast/interview-with-mary-and-tom-poppendieck/id1326918248?i=1000407584120&mt=2 Website link: https://github.com/modernagile/podcast/blob/master/ModernAgileShow_26_Interview_with_Mary_and_Tom_Poppendieck.mp3 DANIEL MEZICK ON AGILE UPRISING The Agile Uprising podcast featured Daniel Mezick with hosts Jay Hrcsko and Brad Stokes. Daniel told the story of how the OpenSpace Agility movement was born from ideas he brought to a Scrum Gathering in Paris in 2013 under the name Open Agile Adoption.  He described Open Space as an invitational, all-hands meeting format in which there is an important issue, no one person has the answer, and there is an urgency to reach a decision. The Open Space format then creates the conditions for high performance through self-organization. Brad brought up that he imagines that OpenSpace Agility can be terrifying to some leaders. Daniel noted that the fear is due to the fact that we have failed the executive leadership of the largest organizations. In the name of “meeting them where they’re at,” we’ve traded away our principles and values and haven’t taught them anything in exchange. Daniel says, “Self-management scales. Not the framework.” This echoes Mary Poppendieck’s comments from the Modern Agile Show on how self-managing, autonomous, asynchronous agents are the only way to scale. Using Scrum as an example, Daniel said that, for the Product Owner to be successful, everyone in the organization must respect his or her decisions. If you do that, he says, you will immediately get culture change because you’ve refactored the authority distribution schema. iTunes link: https://itunes.apple.com/ca/podcast/openspace-agility-with-daniel-mezick/id1163230424?i=1000430511928&mt=2 Website link: https://agileuprising.libsyn.com/podcast/openspace-agility-with-daniel-mezick JENNIFER TU, ZEE SPENCER, THAYER PRIME, AND MATT PATTERSON ON TECH DONE RIGHT FROM TABLE XI The Tech Done Right podcast featured Jennifer Tu, Zee Spencer, Thayer Prime, and Matt Patterson with host Noel Rappin. Noel started by asking the guests what they thought the biggest mistake people make when trying to hire developers is. Thayer said, “One of the biggest mistakes anybody makes in hiring is hiring people they like and that they want to work with because they’re nice as opposed to hiring against a spec of what the worker is supposed to be doing.” This comment matches my own experience because this practice was rampant on previous teams of mine. Jennifer asked Matt how his company attracts candidates and he described using their current employee’s networks. Thayer called this the number one diversity mistake that all companies make.  Noel asked about what to do at the end of the process where you need to go from multiple opinions you need to turn into a single yes/no decision. Jennifer has everyone write down their impressions before they talk to anyone else and write down specifically what they observed to support the conclusion you come to. This is how I always do it, but I’m always surprised at how few teams practice this. Noel asked about good and bad uses of interview time. I loved Jennifer’s example of what a bad use of time it is to say, “Tell me about yourself.” Sometimes I have candidates jump into providing this kind of information even though I hadn’t asked. Such people steer the interview into a well-prepared speech of all their best qualities that doesn’t give you a full picture of the candidate. Thayer then made a comment about the tendency of interviewers to try to make the candidates sweat. I agree with Thayer that this is usually the exact opposite of what you want if you’re trying to make the interview as much like the actual job experience as possible. iTunes link: https://itunes.apple.com/ca/podcast/episode-56-developer-hiring/id1195695341?i=1000430735771&mt=2 Website link: https://www.techdoneright.io/56 JAMES COLGAN ON THIS IS PRODUCT MANAGEMENT The This Is Product Management podcast featured James Colgan with host Mike Fishbein. James is a product manager for Outlook Mobile, which has 100 million monthly active users. James talked about his strategy for user growth being to make a product that is trusted by IT and loved by users. This led to their measures of success, such as usage and love for the product, measured by things like app store rating. James gave a great example of doing user research to create a product that is loved globally rather just in certain geographies. They did research in Asia and found drastic differences in the relationship between personal time and work time. They found North Americans and Europeans kept a strong delineation between work and personal time, but they found significant overlap between personal and work time among Asian customers. The data-driven nature of the product decisions payed dividends in both choosing the right features to work on and avoiding the wrong ones. They got the idea that they wanted to improve the ease of composing emails, but after looking at their instrumentation, they found that the average session length was 22 seconds. So instead they focused on consumption of emails over composition. iTunes link: https://itunes.apple.com/ca/podcast/188-listening-to-users-at-scale-is-product-management/id975284403?i=1000430581654&mt=2 Website link: https://www.thisisproductmanagement.com/episodes/listening-to-users-at-scale/ MATT KAPLAN ON BUILD BY DRIFT The Build by Drift podcast featured Matt Kaplan with host Maggie Crowley. Matt talked about how the book Creativity Inc. by Pixar founder Ed Catmull inspired him to see the similarities between creating products and telling stories. He says that every great story has a protagonist (the target user), starts with tension (the problem the product is trying to solve), has an end state (the vision for solving the user’s problem), has a core belief (the product differentiators), and consists of a sequence of events to get to that end state (the work we need to do to get the users from the tension to the end state). Maggie asked what the benefits are of thinking about products in this way and he explained that product management is about solving problems and telling stories. Stories could be used to convince salespeople that you’re doing the right thing, to tell engineers about what they’re going to build, or to tell customers about what your team has built. iTunes link: https://itunes.apple.com/ca/podcast/build-19-how-great-products-are-like-great-stories/id1445050691?i=1000430866513&mt=2 Website link: https://www.youtube.com/watch?v=swz0TnLwbrA&list=PL_sQbSaZtRqCn6JJSkjma79c8c4bLdaJH&index=4&t=0s FEEDBACK Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/channel/UCysPayr8nXwJJ8-hqnzMFjw Website:

In this episode we’re talking with Noel Rappin, Principal Software Engineer at TableXI and host of Tech Done Right, which is Table XI’s podcast about building software to develop better careers, companies, and communities.

Empowering Entry-Level Developers with Mercedes Bernard TableXI is offering training for developers and product teams! For more info, email go to http://tablexi.com/workshops. Guest Mercedes Bernard (https://twitter.com/mercedescodes): Senior Software Engineer at DevMynd (https://www.devmynd.com/). mercedesbernard.com (http://mercedesbernard.com/). Summary How can your company empower your entry-level developers to grow their skills and advance their careers? If you are an entry-level developer, what are skills that are important for growth. Mercedes Bernard, a Senior Software Engineer at DevMynd, joins Tech Done Right to talk about empowering entry-level developers. We talk about giving people scaffolding to support them in owning larger and larger parts of a software process, and how to align your entire company to support growth. Notes 02:15 - Misconceptions About What it Takes to Level Up and The Best Ways to Start Making That Journey 04:17 - On Being a “Domain Expert” or a “Sponsor” 07:52 - Job Switching, Career Advancement, and Promotion 13:48 - Determining Levels and Providing Support - Brandon Hays (https://frontside.io/blog/2016/07/07/the-conjoined-triangles-of-senior-level-development.html) 20:17 - Scaffolding 21:59 - Entry-Level Struggles: Confidence and Time Management 27:55 - Mentorship 31:01 - Giving Support to Entry Level Teammates: Feedback 33:44 - Signs People Need Support 35:06 - The Importance of Hiring Junior Developers Related Episodes Apprenticeship with Megan Tiu, Kara Carrell, and Alyssa Ramsey (https://www.techdoneright.io/41) Your First 100 Days Onboarding A New Employee With Shay Howe and John Gore (https://www.techdoneright.io/37) Managing For Career Development with Claire Lew and Dan Hodos (https://www.techdoneright.io/12) Career Development With Brandon Hays and Pete Brooks (https://www.techdoneright.io/002-career-development-with-brandon-hays) Special Guest: Mercedes Bernard.

Building New Products With Neil Patel Guest Neil Patel (https://twitter.com/neilpatel): Co-Founder of Crazy Egg (https://www.crazyegg.com/), Hello Bar (https://www.hellobar.com/), and Kissmetrics (https://www.kissmetrics.com/), Serial Entrepreneur, and Marketer. Blog (https://neilpatel.com/). Things we Do TableXI is now offering training for developers and products teams! For more info, email workshops@tablexi.com. Get your FREE career growth strategy information and techniques! (https://stickynote.game) Rails 5 Test Prescriptions (https://pragprog.com/book/nrtest3/rails-5-test-prescriptions) is updated and available for purchase! Summary How can you take an idea, find a development team to realize your vision, and then improve it? And once the vision is realized, how do you get people to find the product? Serial entrepreneur and digital marketing expert Neil Patel joins Tech Done Right to talk about his process for repeatably going from idea to product. Notes 02:23 - What makes a good relationship with a development team? / Initial Interactions 04:22 - How do you know things are going well? What defines success and what causes delays? 06:29 - Boundaries Between Product Owners and Developers 07:12 - Red Flags and Bad Indicators of Future Results / What are indicators that things are going well? 09:31 - How/where do product owners start projects? Design Deliverables 12:35 - Launching Products / How is this process changing? 15:12 - Getting People to Use Your Product(s) 16:33 - Onboarding Flow and Improving First Experiences 18:02 - Use Cases and User Feedback 19:56 - Dealing With vs Acquiring Users 21:29 - Tips and Processes for Marketing and Improving Products 23:48 - Getting Excited by New Products Related Episodes From Idea To Company With Maci Peterson (http://www.techdoneright.io/14) Design Sprints with Kai Haley and Zeke Binion (http://www.techdoneright.io/10) Agile UX Product Design with Yana Carstens and Jeff Patton (http://www.techdoneright.io/18) Special Guest: Neil Patel.

Marketing and Building an Audience With Suzan Bond Follow us on Twitter! @techdoneright (https://twitter.com/tech_done_right) Also, please leave us a review on Apple Podcasts (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341?mt=2)! Guest Suzan Bond (https://twitter.com/suzanbond): Host of the Indiedoes Podcast (https://www.betonyourself.com/podcast), Founder of Bet On Yourself (https://www.betonyourself.com/) and Bet On Your People (https://www.betonyourpeople.com/). Summary Are you a developer that wants to create your own content and build an audience? Suzan Bond joins the show to talk about how to bet on your self. We talk about how to be comfortable marketing, how to present yourself as a credible source for developer-focused content, and how to build and maintain an audience. It's the kind of advice you'd normally have to pay a coach for, offered for free because that's how we build our audience here at Tech Done Right. Notes Sorry, Suzan's audio has some glitches in the source track. We did the best we could, but there's still some words dropped. We're sorry about that, but hope you still find the conversation interesting. 02:25 - Developers, Companies, and Personal Growth 06:56 - Taking the First Steps to Betting On Yourself (Working Independently) 10:57 - Marketing: Effective vs. Comfortable 15:16 - Selling Books is Hard - Rails 5 Test Prescriptions (https://pragprog.com/book/nrtest3/rails-5-test-prescriptions) 18:35 - Approaching Side Projects and Presenting Yourself as a Credible Source 21:59 - Understanding Your Audience and Incorporating Information Into Planning - Take My Money (https://pragprog.com/book/nrwebpay) 30:31 - Tools and Techniques for Connecting and Re-engaging with Your Audience - Paul Jarvis (https://pjrvs.com) Related Episodes Ruby Tapas and Avoiding Code with Avdi Grimm (http://www.techdoneright.io/24) Building Trust and Building Teams with Jessie Shternshus and Mark Rickmeier (http://www.techdoneright.io/001-building-trust) Special Guest: Suzan Bond.

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

MRS 014 Noel Rappin Today's episode is a My Ruby Story with Noel Rappin. Noel talked about his contributions to the Ruby community and how they explore new technologies like Elixir. Listen to learn more about Noel! [00:01:40] – Introduction to Noel Rappin Noel is in episodes 30, which was about Software Craftsmanship. He was also on episode 185, which was about Rails 4 Test Prescriptions. And then, the latest one was 281, which was about Take My Money. [00:02:45] – How did you get into programming? Noel is a stereotypical nerdy kid so he started programming when he was young. He had afterschool classes in Applesoft BASIC at a place near their house. He had TRS-80 and Texas Instruments, and a couple of other things. [00:03:35] – Computer Science degree Noel has a Computer Science degree and a Ph.D. from the College of Computing at Georgia Tech, which was in the intersection of user interface design and Ed tech. He was designing interfaces for teaching, specifically for teaching engineers and developers. [00:04:15] – How did you get into Ruby? Noel came out of grad school immediately and went to a small web development company. He started hearing about Rails in about 2005. Having been one of the people who have done a lot of the Java-Struts web development that Rails was created in opposition to, Noel searched it up pretty quickly. But he started using it in 2005 or 2006 for some internal tools for his team. He built a test tracker and other things that his team is using internally. He built a couple of web apps for them to collaborate because they were working with some developers in Poland. And as he got comfortable with it, he contracted to do a Ruby on Rails book and got a full-time professional Ruby job. [00:06:30] – What is it about Ruby that got you excited? Noel has always like scripting languages and dynamic languages. He did a lot of work on Python for a while. It was extraordinary how quickly you do things in Rails compared to Java tools, even compared to Django, which was more or less contemporaneous. Ruby emphasized testing and Rails was very similar to some of the tools that he was building in Python. [00:08:50] – Books and contributions to the Ruby community Noel had a book which was out of date, 30 to 40 seconds after it was published. It’s normal in this industry. Sometime after that, he started publishing Rails Test Prescriptions and submitted it to the Pragmatic Bookshelf, and they purchased it. They published Rails Test Prescription 6 years. After that, he did a series of self-published JavaScript books called Master Space and Time with JavaScript. They are also out of date but they’re free now. He also did a self-published book about projects called Trust-Driven Development that you can still get. He did a book about purchasing, handling money and web purchases, and mostly this API called Take My Money, which came out last summer. Noel is currently working on a Rails 5 Test Prescriptions, which will include all the new Rails 5.1. It will come out this fall. [00:10:35] – Table XI Noel works at Table XI, which is a web consulting firm in Chicago with about 35 people. They do Rails development, websites, mobile development and a lot of React Native development. They build websites for companies that are not web software companies but companies that need web pages like non-profit or start-ups. They like to focus on solid business problems in software, rather than technology problems in software. [00:11:15] – What are you working on these days? Noel has his own podcast called Tech Done Right. The latest episode was with Michael Feathers. There is also an episode with somebody who is in charge of the Medicare Program under President Obama, who was actually the person who was called in to fix healthcare.gov and had some interesting stories about what that was like from a software manager perspective. From the development side, Noel has been doing a lot of Rails development, some JavaScript development, building purchase-sides for nonprofit, and doing a lot of upgrade work recently. [00:12:40] – Rails upgrades story This upgrade was for a Rails 2 application that was still in active development. The Rails community, at one point, was so bad at managing upgrades. And now, it does seem like the community has gotten better at managing new tools without breaking old ones. The security needs have pushed people towards the best practices. [00:14:15] – Ruby and Elixir Like a lot of Ruby companies, they’ve been exploring what the next tools are. They ran an Elixir project. It’s originally an internal prototype, which is a great way to get new technologies into the company. They wound up building a small project that was largely API focused. That’s the kind of thing that Rails is not super great at. They’re exploring what to do with front-end because there’s a sharp understanding of what Ruby on Rails is good for and what might be the purview of other tools. Elixir does a couple of things that Ruby doesn’t do very well. A lot of people who start with Ruby can learn a lot from going off to a functional language like Elixir or something that has a pattern-matching type of language like Elixir. Picks Noel Rappin R programming Podcast: Tech Done Right Author: Martha Wells The Murderbot Diaries by Martha Well Atom Editor Audio Hijack Bear Twitter @noelrap noelrappin.com Charles Max Wood Mighty Mug Phrase Express

Avoiding Legacy Code with Michael Feathers Follow us on Twitter! @techdoneright or leave us a review on iTunes and sign up for our newsletter (http://www.techdoneright.io/newsletter)! Guest Michael Feathers (https://twitter.com/mfeathers): Author of Working Effectively with Legacy Code (https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052); r7krecon.com (https://www.r7krecon.com/) Summary What makes a code base go bad and become "Legacy Code"? Can teams avoid writing bad code? Michael Feathers, author of Working Effectively With Legacy Code joins Tech Done Right to talk about technical debt, how communication can prevent bad coding practices, why coding problems are never just about code, and what it's like to go around the world seeing the worst code messes ever written. Notes 02:36 - The Definition of “Legacy Code” 04:25 - What makes code bases go bad? 07:26 - Working as a Team to Avoid Technical Debt and Other Problems 09:49 - Tools and Techniques That Have Changed Since the Book was Written scythe (https://github.com/michaelfeathers/scythe) 12:38 - Lack of Institutional Memory 15:24 - What creates technical debt? - Scrum (https://www.scrumalliance.org/why-scrum) - Extreme Programming (http://www.extremeprogramming.org) 22:50 - “Symbiotic Design” - Symbiotic Design Provocation (https://www.r7krecon.com/provocation) - Symbiotic Design Implications (https://www.r7krecon.com/implications) - Conway’s Law (https://en.wikipedia.org/wiki/Conway%27s_law) 25:38 - Test-Driven Development - Keynote - Writing Software (2014 TDD is dead from DHH) (http://confreaks.tv/videos/railsconf2014-keynote-writing-software) - RailsConf 2017: Opening Keynote by David Heinemeier Hansson (https://www.youtube.com/watch?v=Cx6aGMC6MjU) 31:44 - Fads in Codebases 36:58 - Error Handling in Applications (in Relation to Conway’s Law) Special Guest: Michael Feathers.

Conference Speaking and Diverse Perspectives with Carina C. Zona and Mark Yoon Summary Want to start speaking at conferences? We go over how to get your first conference acceptance, then how to become a better speaker over time. For conference organizers, we also discuss how to find the best speakers from a diverse set of backgrounds and experiences. Carina C. Zona (@cczona) and Mark Yoon (@wimyoon) join Noel Rappin (@noelrap) on this episode of Tech Done Right. Notes Follow us on Twitter! @techdoneright (http://www.twitter.com/tech_done_right) or leave us a review on iTunes! Carina C. Zona (https://twitter.com/cczona): Longtime developer and advocate in the tech community, certified sex educator, founder of @CallbackWomen (https://twitter.com/CallbackWomen) Mark Yoon (https://twitter.com/wimyoon): Developer and Director of Talent at Table XI (http://www.tablexi.com/) 01:12 - @CallbackWomen (https://twitter.com/CallbackWomen): What it is and How it Came to Be Website with More Information (http://www.callbackwomen.com/) DevChix (http://www.devchix.com/) 05:45 - Questions You Should Ask as a First-time Speaker and Speaker Outreach 10:06 - The Goal and Mission of @CallbackWomen On BritRuby (Avdi Grimm’s Blog Post Re: Diversity at Conferences) (http://www.virtuouscode.com/2012/11/19/on-britruby/) Carina’s Talk: Schemas for the Real World (http://confreaks.tv/videos/gogaruco2012-schemas-for-the-real-world) 15:24 - Advice for Conference Organizers to Make Conferences Accessible to Everyone; Internal and External Barriers for Potential Speakers 23:29 - Everyone Has Something Valuable to Contribute and Talk About: Approaching Talk Proposals - Nadia Odunayo: The Guest: A Guide To Code Hospitality (https://youtu.be/hHzWG1FltaE) 32:28 - Getting a Talk Accepted - Nickolas Means: How to Crash an Airplane @ RubyConf 2015 (https://www.youtube.com/watch?v=S2FUSr3WlPk) 38:38 - Benefits and Impacts of Speaking at a Conference Special Guests: Carina C. Zona and Mark Yoon.

Open-Source Community Management and Safety With Coraline Ada Ehmke and Yana Carstens Follow us on Twitter! @techdoneright or leave us a review on iTunes! Guests Coraline Ada Ehmke (https://twitter.com/CoralineAda): Open Source Advocate, Creator of The Contributor Covenant (http://contributor-covenant.org/), Founding Panelist of Greater Than Code (https://www.greaterthancode.com/), Senior Engineer on the Community and Safety Team at GitHub (https://github.com/) Yana Carstens (https://twitter.com/YanaCarstens): Senior User Experience Designer at Table XI (http://www.tablexi.com/) Summary How can you manage a social media site to maximize community and make all contributors feel safe? Coraline Ada Ehmke (@CoralineAda (https://twitter.com/CoralineAda)), from GitHub's Community and Safety Team, and Yana Carstens (@YanaCarstens (https://twitter.com/YanaCarstens)), a Senior UX designer with Table XI, join Noel on this episode of Tech Done Right. We discuss tools for allowing users more control over their social media environment and community, and how to use personas in design as a way to understand user's goals and guide them toward positive community actions. Notes 02:59 - GitHub’s Community Management and Anti-Harassment Tools Team and the Problems that They Are Trying to Solve 06:47 - Exposing Anti-Harassment Features and Making Them Prominent, Improving User Experience, and Identifying Harassers 15:10 - Throwing Friction to “Jerkfaces”; Block Functionality 19:13 - Sentiment Analysis (https://en.wikipedia.org/wiki/Sentiment_analysis) - Eudora (https://en.wikipedia.org/wiki/Eudora_(email_client)) 26:38 - Working Together with Other Social Platforms - Chatham House Rules (https://www.chathamhouse.org/about/chatham-house-rule) 30:38 - What does success look like? “Social Coding” 33:05 - Visibility and Flagging of Comments Resources: Coraline: GitHub Community Guidelines (https://help.github.com/articles/github-community-guidelines/) Yana: Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf (http://www.jeffgothelf.com/lean-ux-book/) UX Booth (http://www.uxbooth.com/) UX Mastery (http://uxmastery.com/) Usability.gov (https://www.usability.gov/) Special Guests: Coraline Ada Ehmke and Yana Carstens.

Episode 005: JavaScript: Islands, Sprinkles, and Frameworks Follow us on Twitter! @techdoneright (http://www.twitter.com/tech_done_right) or leave us a review on iTunes (https://itunes.apple.com/us/podcast/tech-done-right/id1195695341)! Summary Dave Copleand (@davetron5000 (http://www.twitter.com/davetron5000)) and Zach Briggs (@theotherzach (http://www.twitter.com/theotherzach)) join Noel Rappin (@noelrap (http://www.twitter.com/noelrap)) for a Tech Done Right discussion of JavaScript practices. When does it makes sense to build single page JavaScript app? How can your JavaScript and Rails interact? Is it an island of interactivity or a sprinkle of JavaScript? Which frameworks are handling community management well (hint: not Angular)? And how do you test any of this? Guests Dave Copeland (https://twitter.com/davetron5000): Author of Rails, Angular, Postgres, and Bootstrap (https://pragprog.com/book/dcbang/rails-angular-postgres-and-bootstrap) Zach Briggs (https://twitter.com/TheOtherZach): JavaScript Practice Lead at Table XI (http://www.tablexi.com/) Show Notes 02:15 - Reasons to Build a Single-Page App (https://en.wikipedia.org/wiki/Single-page_application) - Conway’s Law (https://en.wikipedia.org/wiki/Conway's_law) 09:37 - The Ease of Building Web Over Single-Page Apps 11:30 - Tooling; Navigating Good Choices vs Bad Choices 14:31 - Setup - Bower (https://bower.io/) - webpack (https://webpack.github.io/) - Browserify (http://browserify.org/) - Broccoli (http://broccolijs.com/) - Yarn (https://yarnpkg.com) - The Asset Pipeline (http://guides.rubyonrails.org/asset_pipeline.html) 16:30 - Combining a Rails App and a JavaScript App 18:34 - AngularJS; 1 vs 2 - Angular (https://angularjs.org) - React (https://facebook.github.io/react/) - Vue.js (https://vuejs.org/) 33:05 - Testing - jasmine-rails gem (https://github.com/searls/jasmine-rails) - Test Double (http://testdouble.com/) 35:35 - TypeScript (https://www.typescriptlang.org/) - Elm (http://elm-lang.org/) Tips & Resources: Dave: Check out Test Double (http://testdouble.com/). Zach: As a developer, don’t feel forced into choosing between a single-page app and a non-single-page app on the first day of development. There are infinite points in between when it comes to interactivity. Noel: Read about frameworkless JavaScript in Noel’s book Master Space and Time With JavaScript (http://www.noelrappin.com/mstwjs/). Special Guests: Dave Copeland and Zach Briggs.

Description Brandon Hays and Pete Brooks join the Tech Done Right podcast to discuss career development. We'll discuss some career development questions like: What makes somebody a senior developer? How do you acquire senior developer skills? What can you do to prepare yourself for a lifetime career and ensure that you are properly valued? Show Notes Pete Brooks: Software Developer at Table XI (http://www.tablexi.com/). Author of "How I landed my first programming job" (http://www.tablexi.com/developers/first-programming-job/) Brandon Hays (https://twitter.com/tehviking): “My friend” and line-level developer at OJO Labs (https://www.ojolabs.com/) 02:07 - Classifying Yourself as a Developer - The Conjoined Triangles of Senior-Level Development (12 Traits Blog Post) (http://frontside.io/blog/2016/07/07/the-conjoined-triangles-of-senior-level-development.html) 05:51 - Working Independently" “Throw a couple juniors at it!” 09:19 - What does it meant to progress? - Brandon Hays: The long strange trip as a software developer @ RubyConf 2016 (http://confreaks.tv/videos/rubyconf2016-the-long-strange-trip-of-a-senior-developer) - Brandon Hays: Hacking Spacetime for a Successful Career @ RubyConf 2015 (https://www.youtube.com/watch?v=TrLDU6u_-rY) - Occam’s Razor (https://en.wikipedia.org/wiki/Occam's_razor) 13:43 - Quantifying Value and Talking About Money 17:27 - The Cult of the New: The Approach to Technology and Breaking Into the Industry - Impostor Syndrome (https://en.wikipedia.org/wiki/Impostor_syndrome) 22:54 - Learning New Things and Becoming Professionally Proficient; Levelling - Software Engineer Career Ladder (http://www.myescareer.com/explore-career-ladders/engineering/software-engineer.aspx) 32:04 - When do I need to move on? Where do I see myself going? 34:20 - What should new developers be doing? Resources: Brandon: - John Allspaw: On Being A Senior Engineer (http://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/) - Find and befriend a software developer with 25+ years of experience. Pete: Keep following your interests. Special Guests: Brandon Hays and Pete Brooks .