Welcome to The Rabbit Hole, the definitive developers podcast. If you are a software developer or technology leader looking to stay on top of the latest news in the software development world, or just want to learn actionable tactics to improve your day-to-day job performance, this podcast is for you.
165. What's the Best Agile? with Diana Larsen
Today, we’re asking the question: What is the best Agile? To help us answer that question, we have invited Diana Larsen to join us for today’s episode. Diana is the co-founder of FutureWorks Consulting in Portland, Oregon, and she partners with leaders around the world to design work systems, improve team performance, and transition to Agile methods. She is also the author of a number of books about Agile and, in this episode, we start with the best ways to approach Agile depending on what it it you’re trying to accomplish. Diana takes us through the limits and constraints a team might encounter, how to avoid a backlog of work, and how Agile has focused our attention on necessary software, meeting budgets, and keeping deadlines. We also discuss the different zones needed for a successful product, from optimizing to strengthening, and Diana shares a bit about what the Agile Fluency Project does and the tools that they use. For all this and more, tune in today!
164. Remote Spaces with Esther Derby
As developers, we have likely had experiences with remote work before the pandemic, but now, the context of remote working has completely changed. The blurred lines between work and home life have brought an array of stressors that people have to face. Joining us today to talk about how to make this new kind of remote work the best it can be is a friend of the show, Esther Derby! As a programmer who was promoted to manager, Esther realized that management required an entirely different set of skills that are often taken for granted, and she now dedicates herself to making work more humane. In this episode, we talk about how not sharing physical space can affect collaboration. So many opportunistic conversations and interactions are possible when you are around your teammates. While this can happen remotely, it requires more intention and effort to get to know your team members outside of work. Esther and Dave share experiences of how they have done this on projects they have worked on. We also get into how managers should deal with this type of remote work. Esther believes that there needs to be a move away from micromanagement and a shift towards more flexible, trust-filled work experiences. She shares some of the ways managers can foster trust and collaboration, while still allowing great freedom. Along with this, we also touch on facilitation and ensuring everyone feels they have opportunities to contribute, why managers need to have one-on-one time with the individuals on their teams, and why remote work can be more productive than in-office work. Tune in today!
163. SOLID - Open-Closed Principle
As part two of our series that explores the SOLID software design principles, this episode dives straight into the topic of the open-closed principle — that’s the ‘O’ of SOLID for those who are counting. As a software principle created in 1988, back in the days of C++, the essence of this principle states that you should create code that’s “open for extension but closed for modification.” Using the example of needing to create a calculator that measures the areas of rectangles, we talk about how the open-closed principle makes it easier to create an extension to your area calculator if you suddenly need to calculate the area of a circle. While this principle makes it easier for developers to add features to your software, we discuss how needing to perform “shotgun surgery” on your code may be a sign that you haven’t adhered to the open-closed principle. For a real-world example, we share how we’ve implemented the open-closed principle into an intranet project that we’re developing. Near the end of the episode, we talk about how following the open-closed principle helps ensure that you’re following the other SOLID principles. Listen to this episode and learn how important the open-closed principle is to writing good code.
162. SOLID - Single Responsibility Principle
Do you know how you can feel overwhelmed when you have too much on your plate? Well, your code can feel the same way. This is why it’s important to follow the Single Responsibility Principle, SRP, which is what the ‘s’ in SOLID stands for. Today we do a deep dive into the SRP and how you can ensure that your class or object only does one thing at a time. We take a look at some of the benefits of following the SRP, such as ease of testing and greater flexibility with making changes. When there is more than one responsibility designated to a class, it can quickly become confusing when you need to alter a piece of code. We also look into why you should try to keep classes as small as you can, how to know if a class or object has more than one responsibility, and why you should always be ready to refactor.
161. Debugging Strategies
No-one likes bugs, and while we can’t entirely avoid them, there are some tried and tested techniques to squash those little pests. In today’s show, we dive into some of these strategies. While Mike’s initial reaction is denial and he runs the code repeatedly, there are other techniques as well, like writing tests, Googling, and reading the docs. These all have their merits and we delve into what they are. We also discuss how talking to a rubber duck or a toddler can help you work through a problem or even just how stepping away from the computer and hitting that mental refresh button can help you on your debugging quest. Along with this Mike and Dave, both share some of their debugging experiences and which tactic they are going to make greater use of. Be sure to tune in today!
160. Programming as a Story: How we tell three different stories when developing apps
A lot goes into writing an application that knocks it out of the park. One of the ways to look at the different components of success is to view programming as a story with three layers. In this episode, we dive into these separate, but very interlinked aspects that go into the storytelling of programming. We kick off the show with a look at the first layer, which is the story you, as a developer, tell the computer.
159. Bug Bash
Unless you’re William and write perfect code every time, as a developer, you’ll likely have encountered a bug or two in your time. One way to get rid of these pests, is through a bug bash, which we talk about in today’s show.
158. Positive Reinforcement and Agile
We know that we can learn a great deal from the animal kingdom, so today we’re exploring the relationship between positive reinforcement for dogs and Agile. We kick the show off with Dave sharing some of the lessons he learned from Don’t Shoot the Dog, a book he read after adopting his dog. While the title may suggest it’s strictly about dogs, he feels that the lessons can be more broadly applied. We then talk about providing positive reinforcement to the humans that you work with.
157. Vue - New Hotness or New Hype
We know with JavaScript, there’s a new framework basically every week, so it can be hard to separate the hotness from the hype. If you're ready to move on from jQuery, then Vue is a worthy candidate. Since its inception in 2013, Vue has steadily been gaining popularity, and today we dive in to see what all the fuss is about. We kick the episode off by learning more about the origins of Vue and how it took all the best parts of Angular but made it more lightweight.
156. Surviving Remote Work - Pandemic Edition
We have spoken about working remotely before, but working remotely during a crisis is a very different reality, so today, we share our thoughts on working from home during this pandemic. We kick off the show by finding out more about William’s quarantine in South Korea, why he’s there, and what the experience has been like for him.
155. "I don't know anything" -- It's OK to not know, It's what you do after you know you don't know
Admitting that you don’t know something can often be a bitter pill to swallow. Rather than beating yourself up about it, why not see it as an opportunity to learn something new? So rather than saying, “I don’t know,” choose to say, “I don’t know YET.” This way you can remain open to delving deeper into a subject, no matter how experienced you are.
154. Releasing software in Big Bang Fashion -- what to avoid...
When it comes to making changes and updates to software, there is one of two options: either you make incremental changes or you roll out a large update in a big bang fashion. But we’re not talking about life-or-death software like pacemakers or massive impact ones related to rocket launches—of course, those need to be treated with extra care and come with a host of regulations! We’re talking about your everyday applications like Slack, for example. Companies like Facebook have made the mistake of suddenly making big changes to their platforms, creating a sink or swim experience for users, which, as you well know, they raged at. It’s is in our human nature to resist change, so how does a software engineer go about implementing much-needed updates without offending the heck out of users? In this episode, we unpack the advantages and disadvantages of doing big bang rollouts versus smaller, systematic changes that people hardly notice, pointing out the considerations for each approach and giving you pointers for getting it right.
REMIX - Comparing Programming Languages with Sandi Metz
We are very excited to welcome the amazing and wonderful Sandi Metz as our guest on this episode of The Rabbit Hole! We are going to be talking to Sandi about her book 99 Bottles of OOP and the new edition that is currently in the works. This new edition will take the ideas that Sandi had written about for Ruby and expand them to other programming languages. Thus our conversation takes the form of comparing the differences, strengths and weaknesses of the languages in question.
153. Google Design Sprint and You - Part 2
It’s Tuesday morning at the Google Design Sprint. We all have our Crocs, our snacks, and our playlists... For part two of our series on the Google Design Sprint, we had Kirsten Nordine and Stephen Meriwether join us again to share all their experiences about day two, three and four! We discuss how all the participants were introduced to each other's ideas on Tuesday morning using Post-it Notes and a dot voting process. From there we get into the way the winning idea was chosen and then fleshed out using a storyboarding process.
152. Google Design Sprint and you - Part 1
If you’re like us, and just hearing the word ‘sprint’ is enough to break you out into a cold sweat, you’re not alone. Luckily today, we’re not talking about a physical sprint. Instead, we're unpacking the Google Design Sprint, which sounds about as energy-consuming as a running sprint, only more exciting and less painful.