Welcome to the Rabbit Hole podcast!
Our panelists today: Aaron Streiter, Peter Lye, David Anderson, Michael Silvi, and William Jeffries.
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!
[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).
Michael: Hello, and welcome to the Rabbit Hole podcast. I'm your host, Michael Nunez. The panelists today are ...
Aaron: Aaron [Stroyder 00:00:11].
Peter: Peter Lye.
David: David Anderson.
Michael: Michael Sully.
William: William Jeffries.
Michael: Today we'll be talking about planning meetings and how having successful planning meetings will make you and your team move forward more efficiently, and be awesome developers, agile developers, just be great. Definitely will ensure that the team pushes out as many features as possible, and the business will be happy. I think that's the most important thing we could get out of a planning meeting.
We have any teach and learns today? I don't know if people want to go around and give a little teach and learn. I have one I can talk about.
Aaron: Yeah, why don't you start?
Michael: Awesome. [Martin 00:00:52] Fowler came by, the client, and spoke. One of the patron saints of programming, right, as we would call him, I guess. One of the things I learned from the talk in particular was about learning a new programming language every year is important as a developer. He mentioned one of the things about learning a new programming language is the ability to solve problems using these different languages helps you become a better developer because of the way you have to think when you solve problems in a different language. If you look at a sorting algorithm, for example, in Ruby, it'll probably be very different than the way you would do it in Elixir and how you would do it in JavaScript.
It's all the same thing. You're still sorting numbers or whatever you need to sort, but at the end of the day you get to think differently and to expand in those skills definitely helps you out as a developer. Pretty much full stack development is something that every developer should strive for and it's great because if there's any features that you need to do, you can do them, whether it's front end, use and react, back end, using Java, and just to get the work done. It's great. That talk was amazing. It was awesome.
Aaron: Did he have any suggestions on languages to learn?
Michael: I think his favorite language has been ... I think he mentioned his favorite language was Small Talk, but I don't know anything about Small Talk. He just mentioned to learn one language every year. Any of them is fine. Just make sure you put yourself in that position to do that, and it'll be great. You just become a better developer in the way you think.
Peter: What is the main topic again today?
Michael: Today we're talking about Sprint planning, and we could definitely discuss, does anyone want to jump in and tell me what is Sprint planning and how it's done on your current client? How that works.
Peter: What does Sprint planning mean to you?
David: Sprint planning to me is with a capital S and planning with a capital P. How do you plan according to agile techniques and methodology. There's a very particular way you go about planning how you're going to do work and how you show your client what you're going to do and how you show them what you accomplish every week. Yeah, you could learn it from reading a book, but actually in practice doing it every week is really how you learn.
Peter: To me, planning meetings are the first major ceremony in scrum. Scrum is an agile methodology that people use to help get work done in software development and to prioritize and make sure that the appropriate things are getting done in the appropriate order, and make it possible to change what you're doing relatively quickly without having to rewrite all of your specs and get sign off from a bunch of stakeholders, and the planning meeting is a really crucial part of it because that meeting sets the tone for the whole Sprint. It's where you actually decide what kind of work you're going to accomplish and it's where you do your story point estimation which eventually gets you to velocity, and I think velocity is a really powerful idea that makes it much easier for the business side of the organization to really embrace agile as a methodology.
Does anybody have a concise explanation of what the goal is of a planning meeting?
Aaron: I could jump in there. From my understanding the main goal of a Sprint planning meeting is to have the intersection between like the business knowledge of what's important, and the programming knowledge of how much work it's going to take to do that. Using that knowledge to get the most value out of the limited time that you've allotted for the Sprint planning session, or the Sprint itself.
David: Yeah, I think it's a balance of having the focus that comes with really planning out what you're going to do, but then also working in a small enough time period. For example, an iteration could be two weeks. Working in a small enough time period where at the end of the iteration if you decide the business has different priorities and you want to change directions, you're able to do that and switch directions while still maintaining the focus that comes with really sitting down and kind of writing out everything that you think you want to do, and how you could go about doing it.
William: Planning is a really great moment. When you get the people who know the costs of implementing a given feature in the same room as the people who understand the value of a given feature and they can talk about and discuss specifically which makes the most sense and implementation details.
Peter: Yeah, yeah. I really like what you said there about getting the people who know the business value in the same room as the people who know how costly it is to implement. I think that that really gets to one of the core pieces of what makes planning meetings successful. Does anybody else want to talk to estimations and different ways of doing them?
Michael: Sure, I mean I've seen quite a few. I know someone mentioned before Fibonacci's system of doing it. It's when you use numbers one, two, three, five, eight, and thirteen being an epic. If the story is of thirteen, then you have to break it down into smaller stories. My personal favorite one is T-shirts. Whether it's an extra small, a small, a medium, a large, or an extra large shows the magnitude of how big the stories are, depending on how small the T-shirt is. You want tiny T-shirts to ensure that the implementation and the feature can go through.
Does anybody else have any other interesting ways that they have seen at their clients?
David: I like the idea of thirteen being a number that you don't want for a story. It's like unlucky. You need to break it down if it's an epic, right?
Peter: Yeah, there was one that I thought was really cool. People like to come up with alternate systems rather than numbers in order to better convey that story points are not equivalent to days or hours or any kind of measurement of time. It's purely an estimate of complexity. I think one of the things that's tricky about that is that most of these alternate systems like dog breeds or T-shirt sizes is that they all relate to size still, which feels like a metaphor for how long something is going to take. One idea that I heard that I thought was really cool was to use games. A one point story would be pickup sticks, which is like a really simple game. There's not a lot of complexity to that game. Then a mid level, like a three point story, would be checkers. There's some complexity there, but it's not crazy. Then an eight point story would be Go. Go is a really complicated game. It was not until recently that computers were able to do it better than grand masters.
Michael: How do you reconcile having something that's not number-based in complexity? How do you tie that back to trying to figure out what a velocity would be for a team?
Michael: Interesting, yeah. Like, "Oh, how did you guys do this week?" "Oh, yeah, we did fourteen pickup sticks and a couple Go's." Yeah, no, I mean, I think at one point in time, I think the idea of the game is to keep it away from numbers. I've worked at clients where they use development pair days and that was an issue because when a user or when we estimate that something is going to take three days for a pair to do, but it ends up being four or five or even one, then it's like, "Oh, you got it wrong based on the days," but it was just an estimation. It's just an estimation at the end of the day. Just one other level of abstraction being the games help the business understand that, "Oh, this is going to be a difficult thing like a game of Go versus pickup sticks."
William: I guess in the end you're going to need to have a number on the back in order to do the velocity, but it's just for the estimating part where you just don't want to think about a number at all because the number is loaded and you have all kinds of different associations with it.
Michael: Yeah, exactly. Anyone have experienced things that has commonly gone wrong in planning or estimation?
Peter: It seems like you had a pretty good transition there with your story about people holding you to the number of pair days. I think that's a really common thing that goes wrong is people start thinking that they can convert story point estimations into duration.
Michael: That was pretty bad. Like, because we ended up being punished for that, whether it was over or under and stuff like that.
Michael: I think that estimations are more about the complexity of a particular task. Something, if there are no unknowns but it's a lot of work, it might take a long time to do, but it still might be a low estimation. Whereas something that might be very simple but you have no idea if some other factor will prevent you from finishing it might have a higher estimation. You don't know what might happen in the following week. You have to estimate for the higher value.
Michael: Right. That could be an issue because the business may not see it that way, but you're adding like a buffer for that particular story because of the complexity and the unknowns that may arrive as you're doing that story. I think that alone in itself, when there's a lot of unknowns in a story, can be very difficult to estimate. You've got to pull through. I think that the more you respond to the unknowns and whether you let the business or your project manager know, "Hey, this unknown actually changes the level of what we estimated because we now have a better estimation with all the data we now obtained through research and through delivering this story." It can help at the end of the day make the points that you agreed on at the beginning of the story, I mean of the planning meeting.
Peter: Yeah, I think [Scope 00:11:20] [Creep 00:11:20] is a danger that happens a lot. I guess that's more later on after the planning meeting has happened, after the [stripe 00:11:27] has been estimated, where stakeholders will ask you to add additional requirements to a particular story. I think another thing that commonly goes wrong in the planning meeting itself is poisoning the well. Someone, usually somebody more senior, will let slip that they think that a story is going to be really easy, and then everybody feels like they need to agree that it's really easy because nobody wants to look like they're ignorant, like they don't know whatever secret trick it is that's going to make this story so simple, when in reality it could be that the senior person is actually mistaken and there's really complexity hidden in there that they've overlooked.
Aaron: Who's had the experience of estimating ... Everybody estimates a two and you're the only one who estimates an eight and you feel embarrassed.
Peter: Oh, definitely been there for sure.
Aaron: That should be okay, right? Maybe you know something that the rest of the team doesn't know and you should be encouraged to speak up if you see an added layer of complexity that others don't see.
Peter: Absolutely.
David: Yeah, I feel like I definitely see a lot of people underestimating. Being like, "Oh, yeah, I got this. Don't worry, guys." Kind of trying to be like a superhero in a way and being like, "Oh, this is going to be fine. I got this." Then like, "I'm going to finish this in like an afternoon." Then they're maybe still working on it like a day or two later. Being overly optimistic. It's a human thing to do I guess.
Michael: I have a question. Let's say there's two devs. One of them has a particular expertise in JavaScript front end and the other person does not, is more of back end developer. Does the story require, would it be the same complexity for each person? Would it be a two no matter what? Or does the complexity change based on your personal expertise and what you bring to the table. If Dave is not here and he can't do the JavaScript front end, does that mean that the complexity is higher?
Michael: I know that if a story is estimated between two people with two different skillsets, it would probably be a combination of the two combined that gives it the higher number. If I use the example that was given before and the story is two pickup sticks, but the front end has to do some work or the back end has to do some work first, and then the front end follows up, that'll probably make it a game of checkers because there is some waiting on one piece of tech to get through, then the other one has to come in. The complexity does change when there's a specialist and then like everyone else isn't. That has to also give it a higher number but you should definitely look into ensuring that you spread the knowledge so that that doesn't happen, so that the complexity is always as minimal as possible by knowledge transfer.
William: I guess to your point before about learning more programming languages and being involved in the front end and in the back end, that really mitigates that challenge with estimating because if you have people who are only doing front end development and there are people only doing back end development, then really your velocity is kind of mixed up because like you might have, to your point, Aaron, like different people having different sets of estimates that are on a different scale because they really are not working together as much. Even though it's the same team there's really two arms of the same team or like two teams within the team instead of one team as a whole.
Aaron: I think one thing that's related to this, although not quite the same, is that one symptom that you can see of siloed information within the team or people working in silos is if you have a couple individuals who estimate a certain set of stories and then a different individual or a set of individuals who estimate other stories, that might be an indication that the team is not really propagating the knowledge of the whole system around.
Peter: I've always played that story points are objective and a story that could be done in a day by a senior developer could be a three point story and take three days for a junior developer. What I like about that is that it takes into consideration that you have an entire team there and every single person is going to be able to contribute in different ways. It could be that you have one react expert and they are going to be able to take that story and do it in half the time. That's an asset to the team, but that's really just another version of the classic situation where you have a senior developer who is going to deliver twice as many story points as a junior on the team. When you take things collectively, the law of averages is going to even out over the course of the three sprints that you're doing, your rolling average across.
Aaron: That's assuming that the react programmer will work in the back end, and the back end developer will also take on stories in the front end even if the people do tend to gravitate toward what they like and what their expert is at.
Peter: I would recommend that people pair on stories where one person has a lot of expertise and the other person wants to learn, so you'd have that react expert pair with the back end developer and level them up on react. That's what I would recommend. For a story point estimation, I would say that over time it's going to average out. A lot of the time the expert isn't going to be the one who picks up the story, and a lot of the time they are, but in the long run you'll start to see the velocity even out.
Aaron: Okay, I think you answered my question. If Mike goes on vacation and he's not here next week, he's not here to do the react story, it's the same complexity because it evens out over time. Got it. Thank you.
David: I'm curious if there's anything that we can say about the prioritization part of this. I know we're all developers and so obviously the thing that's closer to our heart is the estimation and the number of pickup sticks that we need to work through, but does anyone have any thoughts on the prioritization aspect, like working with the [product 00:17:37] manager or the customer?
Michael: I think we have to make it very clear that it is up to them to prioritize what they need to be done, and they should come into the meeting with things pre=prioritized. They don't estimate in the same way that we do. We're often hearing the stories for the first time during the meeting, but a lot of work should go into preparing for the planning meeting. Once they hear our estimations, it's up to them to decide what we work on for the week.
Michael: Yeah, because I imagine the project manager and the product owner would come in and they'll have a list of stories that they would like to see in those features be pushed to production. It's up to the developers who will be working on it who can estimate and say, "Hey, you know, this is going to be ... This is what we believe the effort that we can do with these stories." Then from there they can assess, "Okay, we can continue going on in this path," or then realize, "Hey, maybe we don't need X, Y, and Z stories for the MVP," and we can play those later. If they're really complex and doesn't have a lot of value, then they know to shuffle things around if necessary, but you are right, Aaron, there should be some planning beforehand in the project manager's perspective to ensure that we see the stories prioritized to what the business need and then we can estimate and then they can assess with that estimation as well.
Peter: One thing that I've seen that I think is really effective is when the product owner meets with the tech lead to groom before the planning meeting. The product owner brings the perspective of the actual business requirement and why it adds value and then the tech lead brings the perspective of how this story needs to be written in order for developers to be able to estimate it properly. The tech lead is there to say, "You know, you really need to specify if you want this to be sortable or filterable or if you just want it presented. The way that it's worded, it's unclear." Someone who can point out the kinds of little implementation details that need to be addressed by business in order for us to know. If we were to add an extra icon, do you want for the whole page to be slightly wider? Do you want for the icon to ... If there's more than one icon in that section if you want them to collapse or be displayed in some other way. Those kinds of questions I think are really good to have a product owner and a technical person hammer out before it comes time to estimate.
Then that way it goes really smooth because we've all been in these planning meetings where you pull up the story card and it's like, "Make it faster. Make the app faster." You're like, "Ah, ooh. That is ... All right."
Michael: Just do the thing, you know.
Peter: This is a little vague. We've all also been in planning meetings where you get the story card and it's really clear what it is that needs to be done, and maybe it actually is going to be really difficult, but at least everybody knows what it is that they're estimating. They understand. You don't need a lot of back and forth with a product owner to figure out exactly what it is that they really want. I think that the best way to do that is with good grooming beforehand.
William: Yeah, when does this grooming happen?
Peter: This is a great question. Great question. I think that the best way for it to happen is in private meetings. I think more often than planning one thing that I've noticed is that if there aren't good grooming meetings happening beforehand, you'll have a lot of back and forth during the planning meeting itself, and then you won't actually get to estimate all of the cards that business actually wants done. They're like, "I actually need to go and talk to one of these other stake holders and get some clarification about how exactly they're going to be using this feature. Then if you're only doing the planning meetings then you have to wait two weeks before you're going to have that conversation again, whereas if it's happening, assuming a two week sprint. Whereas if it's happening every week or every couple of days when things arise based on the schedule of the product owner, then the planning meetings go more smoothly.
William: Forgive me for pointing out that grooming by definition means it's something you have to do all the time. You can't just do it once. It's an ongoing chore and it has to be done before every meeting.
Michael: Oh, interesting. How long normally do you guys do planning meetings? For me, I've had experience where it's an hour and then I actually sit in a room for an hour and a half, up to two hours if it came to that, like just to knock them out, and then that way we would have stories on end and if we need to re plan them we can set up a schedule for that. Is that a good iteration for you guys? An hour? Have you guys seen more or less? I'm just curious.
Aaron: I love an hour. I think that if you go more than an hour, often people can't concentrate for that long. If the stories are well-groomed beforehand then an hour of time for a team should be enough stories for them to be able to complete in a week or two iteration. If it's going on longer that might be a symptom of this story is not being groomed or unlikely that the team is so efficient that they're just knocking out every single story. You probably need to do a little bit more grooming if it's going over an hour.
Michael: Yeah, that seems to have been the case. I believe the sprints were a bit longer than two weeks. We were trying to figure out what's the optimal sprint time at the time and I think it was even, they had like six week sprints, which ... Imagine the amount of stories you would have to groom in six weeks kind of like was the case, but then they started experimenting, cut it down to four and then maybe two and that's where the sweet spot was too so then it became one hour from there.
Aaron: That sounds good. I think six weeks, you may not get enough feedback in between iterations. Two weeks sounds great.
Michael: Yeah, I mean, I think it was they try to plan six weeks because that'll be two sprints in a quarter and that's how it worked, but then they just figured out cutting it down made it more faster to produce features. What are some other features you guys think that'll make planning go well?
Aaron: One thing I like is when stories are written from the perspective of delivering value to a user and not in a really technical way that may not be clearly providing value from a user perspective. This helps the engineers work on stories that are actually going to be providing real value to the product.
Michael Yeah, then you like the way that it's written also helps the developers build that feature as a user when I do X then I should see Y, and like when they're very clear and written as a user I think it's important. The developers get to see the value in that.
Peter: Yeah, I think following as when then is really effective. The user story starts out as a user or as an admin or as a whatever the role is. When I visit the home page or click on the sign in button, whatever the action is. Then I am taken to my account listing or whatever. You have these three building blocks. As whatever your role is, when whatever the trigger is, then whatever the action is. Another thing that I see that I really like is as a fourth item to have so, to sort of explain the business motivation. As an admin, when I log on, then I see a list of all of the accounts that I manage, so that I can better serve my customers or whatever. What's nice about that is that it gives the developer more information to use to make good decisions about how to implement things, and also to have a better sense of what they could go back to the product owner with in terms of suggestions or possible modifications if there are parts of the spec that are not possible to implement.
Michael: One method I've seen people do in their teams is actually bringing a deck of cards for planning poker. I don't know if anyone have done this, but they have the cards that are written out that will have the Fibonacci numbers one, two, three, five, eight we spoke about before. Project manager will read the story, and then right then and there each person has a deck and on a count of three they just show what they feel that story is. Depending on the discrepancies, that's when you have the floor to explain why you think it's X and not Y. That way you get a general sense of what the entire team is feeling for that story and everyone's aware of like some people's concerns or like the complexity. I think we spoke about that before, where other people may see something that's complex that others are overlooking. I think that's a perfect way of showing that without holding back or like holding information. That way everyone gets to shoot right there and then explain why they feel that number is. Depending on the conversation, you all come to an agreement on what the number is for that poker game.
Michael: The thing I like about that is that you could have some really quiet developers who don't feel comfortable contributing, or maybe who only contribute when it's very much related to them and they won't contribute for other things. I think that's a really easy way and a fun way, really. It sounds like a fun game to play to get everyone kind of warmed up and invested in the meeting and not falling asleep during the time boxed hour.
Michael: Yeah.
Aaron: I think another cool thing about that is that some people may have discrepancies. If somebody has a thirteen, another person has a one, it's very clear that there's a big discrepancy and you can have the lowest people talk and say why they think it's a one and the people who estimated a bigger story and they can talk about why they think it's more complex, and then the team can come to some consensus after determining why the different estimations were made.
In addition to planning poker, a slightly different technique that I've seen that's been pretty successful is that you've got basically a table in the middle of the room, you can draw a big square on it, and you throw all the stories on it and what the team can do then is basically go through a mute mapping exercise. One box represents a one, another box might represent a three, another box will represent let's say a nine, and then another box could represent an infinity, break this story down into smaller pieces. The team will go through this exercise of without talking just moving the stories into different boxes, and then if two different team members move one story into, let's say a one initially, and then another team member comes and they move it into a three, you'll take that story off and then you'll discuss it at the end. This is another technique that is similar to planning poker, but a little different flavor.
David: Would you have one card for each story in that case?
Aaron: Yeah.
David: Okay.
Aaron: The thing you need to do before that is the whole team needs to discuss all the stories beforehand so that they have a good understand of what's being estimated, so what I've found is effective is you just do an epic at a time so then that keeps it down to a pretty manageable amount of stories that the whole team can keep in their head.
David: Cool.
Peter: I've done that one and what I've found is that it's really great for getting more stories done faster because there are a whole bunch of stories in planning poker, I find that are really non-controversial and so those ones just don't get debated at all. The downside is that I think a lot of people are more hesitant to move something into a box that's radically different because there is a certain social pressure. It's a cool alternate technique, particularly for good teams that have a good working relationship and know, feel confident in differing in opinions.
Aaron: Right, and another difficulty would be if a manager, a more senior person, puts one of the stories in a given box first, there might be the temptation not to move that, because as you said, the social pressure.
William: Yeah, we talked about that a little bit before. I guess I'm curious with this method also, like you were saying that if the story is moved then you might set it aside. Who's responsible for maintaining that and keeping track of that status? It sounds like it could be a little bit chaotic with everyone getting around.
Aaron: I've seen one person in charge of kind of managing the board to kind of see when that happens, almost like a facilitator. That could be one of the product managers for instance.
Peter: Should we move on to picks?
Michael: Yeah, let's do it. Anyone got any picks they would like to talk about really quick?
David: I'll go.
Michael: Go ahead.
David: I recently was on a team where we all decided to use one vim configuration so that we could easily pair on each other's work station. It was called pivotal vim config. I believe it's the configuration that they use at Pivotal Labs and it's on Get Hub. We just all installed that on our workstations and we can all use the same vim and we can all learn the same key bindings and it's worked out really well and I recommend it.
Michael: Cool, was there any new features that you didn't think of using before that were available to you or was it kind of just a pretty standard set of tools?
David: Well, they do have all the standard vim key bindings but they also make choices about all the different plugins. They have all the plugins for [rails 00:32:03] and that includes [Nerd Tree 00:32:03] and there are several custom key bindings that use in addition to the regular vim key bindings. I'm sure all of you have had the experience of going to someone else vim machine and they all set up their own key bindings. That's great for that person, and maybe not all the pivotal vim config key bindings are perfect but they're good enough.
Michael: Yeah, yeah.
David: That if we learn them that we could all work on each other's machines.
Michael: Yeah, that definitely lessens the hurdle for pair programming and collaborating. That's awesome.
Michael: I think the following next couple of weeks I'll be looking into React Native, the client I'm in right now. We're doing a lot of react stuff and I figured why not just jump into the mobile scene with a framework that I'm already familiar with. I already got everything downloaded and did the the Facebook tutorial, which was great. Very, very easy tutorial to follow, and I think the fact that I have like some experience in react makes it even easier, so I'm really motivated into what comes out of this project that I'm trying to brew up. I'm looking forward to it though. It's great. It's awesome.
Michael: That does seem really exciting to me, like being able to not have to program Java for Android and not have to program Objective C or whatever for iOS.
Michael: Yeah, no, it's ... You've got to just run a command and it runs on the iOS simulator or you import it right onto your phone. It's dope. You just run one simple thing and boom, you've got yourself a little app. It's great.
Michael: Nice. For me, there are a couple of tools that I've been using over the past week that I've enjoyed. The first thing I started working on a new [Jango 00:33:46] app and I needed to get a quick understanding of the data model, so I found a tool within the Jango extensions toolbox where you can actually create a UML of the data model very quickly. Jango extensions has a bunch of nifty little things that you can use with Jango to make your life easier, but that was a pretty handy thing and it was nice when a fellow teammate of mine who was also ramping up, "Oh, if only I had this data model available, where would I get it? Who would make this data model? Who will spend the time?" Like, "Well, I have it right here. I just pressed this one command line thing and I got it." It was pretty cool.
Also related to that there's a command line tool that I've been using for searching code bases. It's called AG. It's like [Grup 00:34:39] but really easy. You don't need to remember options if you don't want to. It's a pretty sane default and really handy for quickly searching for code and any number of files. It's pretty awesome.
Peter: Yeah, I would piggyback on that. [Silvers 00:34:58] search AG that has a great integration for vim.
Aaron: That is included on the pivotal vim config.
William: Bringing it back.
Peter: Makes sense, makes sense. I have a couple of picks. One of them is Get Pair, which I think is actually also from Pivotal. It's really handy because it allows you to quickly switch who is on all of the Get Commit signatures, which is really nice if you're pairing on a thing and you want other people to know exactly who it was that actually contributed the code. That's great for people getting credit for their work and it's even better for making it easier for other people to know who to go to when they have questions about those commits. It makes it super easy. You type Get Pair and then the initials of the people who are pairing, and you can take the person off by putting in just your initials when you're [inaudible 00:35:48] and we just got it set up for everybody on my team and it's been really nice.
The other pick that I had is not necessarily related to development work. It's an app called Signal which is an instant messaging app for mobile. They have a desktop application as well. What I like about it is that it's super secure, it's end to end encrypted, the platform itself is open source and the cipher is public. It's just really rock solid in terms of security and it's also really user friendly. I got my mom set up on it. She signals me all the time.
David: Nice.
Peter: That's I think a really good sign for usability. Security is a thing that I've been ... Privacy is a thing that I've been getting more interested in of late and so I wanted to share that recommendation. Check it out. Signal and Get Pair.
Michael: All right, ladies and gentlemen. I'd like to thank the people who joined the podcast today. Thank you all for being a part of it, and thank you for listening to the Rabbit Hole, and we'll see you next time.
Stride Consulting
Rabbit Hole on Twitter
Martin Fowler
pivotal/vim-config
React Native
Django Extensions
Silver Searcher
