12. Code Tests

11. Organizing A Tech Meetup

Meetup is one of the most popular platforms for bringing people in the tech industry together in real life for networking, sharing information and having fun times. All of us at the Rabbit Hole enjoy going to tech meetups, but many of our coworkers (and surely some of you) have wondered what it would take to start something new! Sarah Cassidy is a community specialist with Meetup.com. At Meetup, she is focused on community development, helping regular folks create the best possible meetups every day. Sarah coaches us through the process of creating a meetup, from the very first step of choosing the scope of your meetup, finding a venue and getting people to show up all the way to growing your meetup and avoiding the worst case scenarios. Whether you’re into Elixir or Ruby, are agoraphobic or under 5’7”, we hope you find something helpful in this episode to get out there and just start a new gathering of like minded techies today.

10. Books

In this episode of the Rabbit Hole podcast, we talk about software development books and literature. We talk about tow of our favorites in some detail, but also discuss the concepts of software development books more broadly (in the sense of what they can offer and why people might choose to read them). In general, these books (such as Practical Object-Oriented Design in Ruby: An Agile Primer by Sandi Metz) offer insight that encourages you to rethink your overall approach, technique, and mindset. Learning transferrable concepts, skills, and ideas is a strong motivator behind reading programming books, since there are other resources for simple references. One example of a book that offers this is The Phoenix Project, a novel that one of the panelists compares to being like Ayn Rand’s works in terms of being allegorical and a teaching tool.   In the episode, we also talk about hard skills versus soft skills. “Soft” doesn’t mean “weak” in this context,and soft skills have great value. This is summed up in a Portuguese expression, “água mole em pedra dura tanto bate até que fura.” We finish things up with a teach-and-learn moment about RSpec Bisect, and a toast to failure involving vcr. Tune in to learn more and to hear our thoughts on a couple of great books!

09. Vacations

Vacations help developers stay energized at work and avoid burn out, but sometimes it's hard to pull ourselves away from our computers for even a weekend away. On the Rabbit Hole this week, we touch on all kinds of aspects and kinds of vacation including unlimited vacation, mandatory time off, sabbaticals and the chaos vacation monkey. Learn how spending time away from work can help your team as much as yourself! Get in touch with us @radiofreerabbit on Twitter and leave a review on iTunes. Catch you guys next time!

08. Starting a New Project

07. Mentorship vs. Management

Managers and mentors are both crucial for guiding our career growth as developers. We discuss how management and mentorship works at Stride, dig into the similarities and differences between habits of good managers and good mentors and delve some deep metaphors to illustrate these traits. While a mentor relationship may be less formal and come with some level of confidentiality, both roles help set and achieve goals and are heavy on active listening and empathy for situations that the fellow developer is experiencing. We discuss how you can find a mentor and what different shapes that can take because having a manager is a near certainty and organization-based mentorship is less common, so. This may range from repeated online interactions to casual friendships with more experienced developers to more formal apprentice-like working arrangements. In this week’s Teach and Learn, we also chat about software archaeology and learning about the adjacent possibility of things like React and Angular from an older framework such as moustache.js. Get in touch with us @radiofreerabbit on Twitter and leave a review on iTunes. Catch you guys next time! Links and Resources Stride Consulting The Rabbit Hole on Twitter The Rabbit Hole on iTunes Moustache.js

06. Rolling Off a Project

In this episode of The Rabbit Hole, we consider the bittersweet experience of rolling off a project. Whether you are transitioning to a new role and responsibilities at a different company, or just taking on a fresh project within the same organization, it’s inevitable that time with all good projects must end. We explore how to end your time on a project in the most responsible way, while leaving a lasting legacy, saying goodbye the right way and maintaining personal connections with everyone on your old team. Leave that team better than you found it and keep that bus number high by listening with us on this episode! Get in touch with us @radiofreerabbit on Twitter and leave a review on iTunes. Catch you guys next time!   Links and Resources Bus number Stride Consulting The Rabbit Hole on Twitter The Rabbit Hole on iTunes

05. Retrospectives

In this episode, we’ll talk about retrospectives. To be clear, we’re using the term in reference to retrospective meetings in the Scrum framework, not about art or other retrospectives (though we’ll touch on that in the episode!). In short, a retrospective is a regular, recurring time to air grievances and make suggestions for how to move forward and make the team better. Its focus is generally on how things went, not about how people behaved, so it doesn’t tend to devolve into a blame game. And it’s important to keep in mind that a good retrospective addresses positive things as well as constructive things. Generally, the people in the retro should be the people who were involved in the sprint it’s addressing (and who were in the planning meeting for that sprint). In some cases, though, it may be beneficial for an outsider to run the retro. A good retro should have three distinct phases. First, the ideation phase gives everyone a chance to put everything out there. This is the “yes, and” phase. The second phase is more constructive and involves grouping ideas. This is the “yes, but” phase. Finally, the third phase is where you focus in on key points and is based around action items. That should give you some sense for what a retrospective is and why it’s important. To learn much, much more, tune in to this episode! In This Episode: [00:22] - We start off with a teach-and-learn moment about Vim. [01:38] - Another of the panelists managed to teach someone sync settings on Atom, he explains. [02:53] - What is a retro? In short, a meeting that is one of the recommended ceremonies in the Scrum framework. Its purpose is to look back on what happened over the course of the last sprint. [03:55] - Somewhat surprisingly, retros don’t tend to devolve into blame games. [05:36] - We learn about the etymological root of the word “retrospective,” and what that means in terms of these meetings. [07:27] - The purpose of the retrospective is to do better during the next sprint. It allows you to make a plan for how to get better. [08:54] - Who should go to the retrospective? Should anyone who isn’t part of the team show up? [10:55] - The panelists discuss how long a retro generally takes. {12:28] - We hear about the good things that can come out of a retro. [16:09] - After the break, the panelists kick things off by talking about the phases of a retro. [18:20] - In the brainstorming phase, does everyone write down ideas? If not, how do the ideas come up without allowing certain people to dominate the conversation? In response, the panelists also discuss the pros and cons of anonymity. [22:11] - We move onto the part of the retro that involves identifying trends. [23:17] - William expands on what he meant about this being the “yes, but” phase. They then discuss the tendency to pile onto the popular topics. [25:58] - The third section of a retro involves action items. [28:37] - When do you check on the previous retro’s action items? [30:29] - One of the positives of the Scrum recommendations on which ceremonies to have is that they cover your bases. The panelists then discuss some reason why people may push back against Scrum. [32:55] - We hear some tips and tricks for having a successful retro that runs smoothly. [36:18] - The panelists share their closing thoughts on retros, including that every team should have one. [36:58] - We hear the picks that the panelists want to discuss for the upcoming week. Links and Resources: Stride Consulting Rabbit Hole on Twitter Practical Vim: Edit Text at the Speed of Thought Scrum

04. Pair Programming

In this great episode, we discuss the concepts and uses of pair programming, remote programming, and mob programming. Don’t worry if you’re unfamiliar with any of those terms; we’ll talk about them in more depth in the episode, and explore what is (and isn’t) cool about each one. Just to give you a short preview to help you decide whether to tune into this episode (hint: you should!), let’s take a moment to define what we’re talking about, at least for our main focus of the episode. Pair programming is when you have two programmers working on the same task, usually at the same workstation. This offers an incredible array of benefits compared to typical, solo work. For example, if you’re in a pair programming setup, there’s no way you’re going to be checking your email, phone, and social media while you’re working. That means you’ll be more focused; in fact, one of our panelists points out that pairing can lead to being tired (in a good way) because you’ve been so productive. Pair programming also offers great motivation to be your best, because you don’t want to let your team down by not giving 100%. Tune in to hear more about pair programming and its benefits and potential pitfalls, and to learn about remote programming and mob programming too!   In This Episode: [00:52] - We hear a basic definition of pair programming. [02:02] - What were the panelists’ first experiences with pair programming? [03:39] - Pair programming can be incredibly valuable in that it doesn’t allow you to get distracted or lose focus the way you might if you were working by yourself. [05:50] - We learn about the use of chess timers in pair programming. We then hear how pair programming can be valuable when you’re learning a new language. [08:12] - Have the panelists seen Livecoding.tv? [10:35] - The panelists move on to talking about remote programming, initially emphasizing the importance of a strong, fast internet connection. [12:32] - If you’re pairing with someone remotely, the person who is sharing is (almost) always the bottleneck. [13:26] - What kind of editors do the panelists usually use on their projects? They mention, for example, Screenhero, AtomPair and Floobits. [16:47] - The problem with all of these editor plugins is that they don’t tackle the shared browser bit. [18:46] - One of the panelists brings up an issue that happened to him in pair programming but not remote programming. [20:02] - The panelists discuss Dvorak in more detail, explaining what it is and why it’s a good choice for people with wrist injuries, for example. [20:55] - We hear the story of how one of the panelists inadvertently introduced a coworker to pair programming. They then talk about various modes of pair programming, particularly “evil mode.” [27:20] - We move on to mob programming, with the panelists sharing their experiences with it. The consensus is that it’s fun because it’s so collaborative. [30:45] - Mob programming can often be with some subset of the team instead of the entire team. Even if it’s with only three people, though, it can be helpful in breaking ties. [34:01] - Have any of the panelists had any particularly good pairing experiences? [39:00] - We switch to the other side of pair programming now: challenges and bad experiences working in a pair (including a story of overwhelming body odor). [43:05] - Another resource that people should check out is the RailsConf 2014 video “I’ve Pair Programmed for 27,000 Hours. Ask Me Anything!”   Links and Resources: Stride Consulting Rabbit Hole on Twitter Livecoding.tv Screenhero Real Programmers on XKCD AtomPair Floobits “I’ve Pair Programmed for 27,000 Hours. Ask Me Anything!”

03. Planning Meetings

In this episode, we’ll talk all about planning meetings. (And let’s be clear here: we mean planning-meetings as an entity; we aren’t talking about how to plan a meeting.) We discuss how having successful planning meetings will help you and your team move forward more efficiently. Ultimately, these meetings can help you and your team become even more awesome agile developers. When they’re done right, planning meetings can ensure that the team pushes out as many features as possible, which keeps the business happy. The way they achieve this is by getting the people who know the business value in the same room as the people who know how costly it is to implement. Unfortunately, there can be a lot of confusion surrounding planning meetings, especially when it comes to units of measurement that can be understood (and not misunderstood) by everyone in the meeting. There’s a great solution: using games as units of measurement! Listen in to hear more tips, advice, and thoughts on planning meetings!   In This Episode: [00:45] - We have a teach-and-learn moment about a talk by Martin Fowler and the importance of learning new languages. [02:29] - Today’s main topic is sprint planning. We hear a definition of what this is. [04:22] - We learn the main goal of a sprint planning meeting. It’s to have an intersection between the business knowledge of what’s important and the programming knowledge of how much work it will take to do that. [06:05] - We hear more about estimations and ways of doing them. We learn why many options are problematic, and why using games as units of measurement eliminate some of these problems. [09:27] - Does anyone on the panel have examples of things that have gone wrong in estimation or planning? [12:55] - Does the complexity change based on your personal expertise and what you bring to the table, or is the complexity measured more objectively? The panelists share their thoughts and recommendations, which include pairing with people who have different areas and levels of expertise. [17:37] - The panelists talk about prioritization. [20:58] - We hear more about grooming, and when it should happen. [22:11] - How long does a planning meeting normally last? The consensus is around an hour, because going longer can lead to reduced concentration or indicate inadequate grooming. [24:08] - The panelists talk about some other things that can help planning meetings go well. We hear about the “as/when/then” structure. [28:14] - A successful technique involves having a table in the middle of the room and having the team go through a silent exercise of moving the stories into different boxes based on difficulty. [31:04] - We move on to picks. We hear about pivotal/vim-config, and why one of the panelists recommends it. [32:32] - Another of the panelists will be looking into React Native over the next couple of weeks. [33:29] - A couple tools one of the panelists has been using over the past week include a tool from Django Extensions and a command line tool, the Silver Searcher. [35:04] - A couple more picks include git-pair and an app called Signal (available for Android and iOS).   Links and Resources: Stride Consulting Rabbit Hole on Twitter Martin Fowler pivotal/vim-config React Native Django Extensions Silver Searcher

02. TDD

After starting off the episode with a teach-and-learn moment about leaky abstraction, we move onto the core focus of the episode: TDD. TDD, or test-driven development for the uninitiated, is “an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring” (definition from Agile Data). If you don’t completely understand the concept of TDD from that description, or if you have lots of questions now, don’t worry! That’s what this whole episode is about. We’ll talk about TDD in great detail, addressing the ways in which it’s counterintuitive and can be tricky at first. More importantly, we discuss how TDD can offer incredible value and make things ultimately easier and simpler, even though it may not feel that way at first. It can ease the demand on your brainpower, and even reveal your own assumptions. Finally, we discuss why TDD may not be relevant in certain environments. Listen in to hear more about TDD and what it can do for you! In This Episode: [00:22] - We have a teach-and-learn moment about leaky abstraction. [02:28] - Working with someone who has never done any front-end work can be a great experience. [03:35] - We learn what the definition of TDD is, and why it’s counterintuitive. [07:33] - How do you decide to use TDD? Or is it something that you use all the time? The consensus is to use it all the time, or close to it. [11:01] - Part of starting with TDD is understanding the first step. This may mean you need to spend some time “mucking around” before you even know what to test. [14:16] - One of the times when it’s hardest to do TDD is when you don’t know how to test something. [15:25] - We hear about the potential value of creating a stash as a reminder, and the possibility of making a spike branch. The guys then joke about whether stashing behavior translates to desk organization. [18:32] - After a short break, we hear more about an early experience with TDD. [21:09] - Pairing with someone junior to you offers value that’s easy to underestimate. It makes you stricter on yourself and encourages you to be more concerned with best practices. [22:07] - We hear about the experience of getting into TDD on your own. We also learn that TDD can reveal your own assumptions. [24:03] - Developers need to hold a lot of information in their heads while trying to solve a problem. TDD is a great way of preventing things from accumulating in RAM, so to speak. [26:38] - The guys talk about the pros and cons of remembering the moment you discovered TDD. [29:41] - We hear which programming languages the panelists prefer to do TDD in. [32:40] - There’s a bunch of front-end stuff that isn’t testable. [33:57] - Have the panelists seen the Martin Fowler talk “Is TDD Dead?”? [36:45] - The small applications that college students tend to write for their courses aren’t a realistic representation of what happens when you do this for a living (in terms of the necessity of using TDD). [39:22] - Google recently released an API called Actions on Google.   Links and Resources: Stride Consulting Rabbit Hole on Twitter Introduction to Test Driven Development The Art of Agile by James Shore Sandi Metz Is TDD Dead? TDD Is Dead. Long Live Testing Actions on Google

01. Introduction to The Rabbit Hole

Welcome to the introductory episode of the Rabbit Hole! While this is the first episode available to the public, it certainly isn’t the first we’ve recorded. We’ve been working on this project, and recording, for the past six months to create a backlog of episodes. Each podcast is a dynamic conversation full of great information by developers for developers! A little about us: we’re Michael (host), Dave (co-host), and William (producer). We all work for Stride, an Agile software development consultancy. Stride embeds with your tech team to help you make software development a competitive advantage. We're a bunch of engineers obsessed with the idea that software development should be agile, collaborative, and leave teams stronger at the finish than they were at the beginning. Combined, we have over 20 years of software development consulting experience, and we want to share our knowledge with the world. Our mission with this podcast is to help developers become better at what they do. By sharing our knowledge, we hope to change the world! (Or at least change one developer’s life.) Listen in to hear more in this brief intro, and be sure to subscribe to receive our upcoming full episodes! In This Episode: [00:11] - Your hosts and producer introduce themselves. [00:22] - Michael, Dave, and William talk about this being technically the first episode, even though they’ve recorded quite a few others. [00:44] - We hear the mission of the podcast, and then learn about how the podcast will accomplish its mission. [02:13] - We learn more about how much consulting experience our podcast hosts have. [02:42] - What are some of the episodes that will be coming up? [03:42] - Our hosts work for Stride, an Agile software development consultancy in New York. [04:47] - Michael, Dave, and William (and this podcast) are on Twitter: @radiofreerabbit. Links and Resources: Stride Rabbit Hole on Twitter