In today’s episode, we complete the ultimate showdown between product and developer! In this round, it will be the developers who are on the defensive as Dave and Michael account for their faux pas as developers. Rob O'Brien returns to the show with plenty of ammunition. Our conversation starts with a friendly exploration of the type of faux pas a developer might generally commit, as we repeatedly return to the importance of a team-based mindset and why developers need to be invested in user outcomes. We explore how a developer’s role goes beyond completing their delegated tasks and some handy tips for working with designers. The crew also outlines the many benefits of building rapport with your co-worker including having more resilience when things get stressful and having a more cohesive team working environment. Tuning in you’ll hear a thrilling, action-packed discussion on the merits and flaws of developers and how to make your team a badass trifecta of efficiency!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 265. Product vs. Developers with Rob O’Brien - Part 2 - Product Strikes Back
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Living large in New York. I’m your host, Michael Nuñez. Our co-host today.
[0:00:09.3] DA: Dave Anderson.
[0:00:09.7] MN: Today is part two baby, product versus tech. This is the fight of the millennium, 2021 is going down.
[0:00:17.6] DA: Yeah, we’re locked in mortal combat.
[0:00:18.9] MN: Yeah, that’s the code, it has to go down, it’s Godzilla versus King Kong, you said Diddy Kong is in the mix too, my apologies. We have again a special guest, Rob O’Brian, how’s it going, Rob?
[0:00:32.8] RO: Good, man, how are you guys doing?
[0:00:34.3] MN: I’m doing all right man, I’m trying to recover from last time but I think I’m ready to punch myself in the face.
[0:00:40.5] RO: We didn’t hear no bell, right? We’re still going, we’re still going.
[0:00:42.9] DA: I got a piece of steak on my eye.
[0:00:46.5] MN: To cool it down, yeah, and some Vaseline, I got Vaseline going on. I think we dived into a lot of the faux pas that we would see in a product manager and some solutions. I think, Dave, I’m sorry man, it’s the ball is now on Godzilla’s court, we’re going to have to talk about some dev faux pas.
[0:01:03.6] RO: Are you ready to defend? That’s the question I have
[0:01:06.4] DA: It’s fine, just hit me, I’m in the square stance, I’m fully rooted, I’m ready to take a punch.
[0:01:13.2] MN: Yeah. I think Rob, well definitely, he has some, a ton of experience working with devs and might have seen a thing or two and I would love Rob for you to be brutally honest, it will only make us better s developers.
First and foremost, I would say, I think I’m going to tap into the faux pas from last time and it had to do with – you may have gotten a story from the product manager and the idea that the acceptance criterias aren’t clear. I think that’s something that normally happens to a dev, especially I think, I’m looking back in my career, I think this may happen when a dev doesn’t want to ask question because they don’t want to feel like they don’t know what they need to build.
I think that that can be definitely a problem because when you finish the story and then you go and you ask for it, it’s like, “Hey, no, I meant like these things” It can be a combination of it being unclear or the developer didn’t understand but didn’t bother to ask.
Do you have any experience with that, Rob? Have you seen that in the wild or any thoughts as – any other reasoning as to why that would happen?
[0:02:18.9] RO: Yeah, I think in certain organizations, it’s kind of incentivized to stay in your lane and it’s your developer, you do development and challenging what you hear or challenging the status quo is not accepted. I think that is a faux pas of devs on a true product team, working together as a team where it’s like, I build this after we build it, we look at it and a product person’s like, “Wait, this doesn’t really make any sense” and the dev goes, “I felt the same thing while I was building it, this is a dumb story” I’m like, “What? You felt that the whole time, why didn’t you tell me?” “Well, this would have been a much better answer, I’m like, “Well what the heck, I thought we were on the same team?” He’s like, “No, I just build it, you write it.” It’s like, “Come on”.
[0:02:54.6] DA: I heard that. I may have actually built them story as well.
[0:03:00.5] MN: Yeah, I’m guilty of it too, it’s like, “Yeah, I thought you meant this bro, what do you mean?” It’s like, “No, you’re wrong developer, it’s not cool” and I’m like, “Man, okay, let’s go to the chopping block, let’s figure this out.”
[0:03:11.5] RO: It goes back to what we talked about before, it’s like, do you have a relationship with your customers and stakeholders to truly understand and care about what they want and do you want to make them happy and build the best products? Some developers don’t and I think that’s a big problem, they said no, “I’m just here to code, I clock in, I clock out, I’m out. I don’t care, if it’s built, it’s good.” No, focus on the outcomes.
[0:03:31.8] DA: They’re not ready to fight for a better outcome for the user or the stakeholders or whatever. Okay, this is what I was asked to do and my scope of my impact will be this one little block in my geo swim lane and I will drag it over to the other one. Yeah, that’s especially painful, also if it is generally correct but you’re just making assumptions and I really do think there’s a lot of value in having a kickoff to a story. Even if you talk about it in grooming, you’ve talked about it in planning maybe.
You’re kicking off the sprint and kind of agreeing to the work but sometimes it’s kind of nice to huddle up with the people who are involved in that. Okay, I’m actually starting it and I’m just going to read the story and we’re going to make sure that we’re starting on the right place and not kind of going off into the lens of waste like those lean software development ways where you're just going to have all these wasted work or you’ve gone down a path that doesn’t make any sense.
[0:04:43.1] MN: I think we mentioned it before many times. I always like the concept of a desk check just like “Hey, project manager, you got a second? I want you to see this thing, you let me know if it makes sense.” To kind of make sure, rather than – I feel like when you are doing the desk check, I feel like you're less exposed or you feel less vulnerable than asking questions because you don’t understand. It’s like, “Okay, I built this thing and it looks like this, what do you think? Does this make sense to you?” and kind of get that out, versus, you finishing a story and you think that you’re done with the story or the next steps of done is happening, when in reality, you’re not. I think that that’s desk check kind of buffers that, that breaks that apart.
[0:05:22.2] DA: That also breaks them like they’re not, that’s not my job mentality where it’s like okay, we’re all in this together, product, designer, you do a desk check and you’re like, “Hey, is this the right thing? Are we on the right path?” Is it working as you expect it to work? To head off any derailment that you might have further on down your con bon swim lanes in its like cousin that’s not my job problem with the tester or something like that or getting it deployed to production, those are also kind of – your job, it’s the team’s job. Pulling more people in and just being more collaborative.
[0:06:06.8] RO: Some of my favorite developers I’ve worked with and the most strongest developers I’ve worked with are not because I think they were necessarily the best technically or anything. It’s because they were really focused again on outcomes of the user where I brought a story or a feature to the table and have explained to them why we’re building it and what value it will drive, we’re intending to drive for the customers or the users and they will challenge me that they have a better idea, a simpler idea that will meet that need, or that want by the customers, in a better way.
I can’t tell you how many times I’ve been like, that is a much better idea than what I had, we are both anchoring on the same outcome, we want to make sure the users can log in faster. Wow, your answer is much better than my answer, thank you for that, right? You can just sit back and say, “That’s stupid” You said, “Nope, that’s what we’re trying to do? I know these people, I’ve met with them, I have a better solution” that’s like the greatest thing a product manager can hear is developers coming to the table with better solutions.
[0:07:03.7] DA: Is there ever time like if you give me a stupid story I should just develop it?
[0:07:10.5] RO: Yes, maybe because there might be without getting in trouble, because my wife is a lawyer, there are some legal things and compliance things that you have to build that no one loves but you have to do to make people happy.
[0:07:24.0] DA: I got to do those footnotes, yeah, right.
[0:07:25.6] RO: Yeah, you got to do those footnotes, you got to add those massive techs of agreement and really break up this easy user experience flow so yes, I think there are certain situations but it doesn’t mean you shouldn’t push back. It means you should be very clear on, “So if we don’t build this, we’ll get sued?” Okay, then we’ll do it, I agree it sucks but we’ll do it.
[0:07:45.7] DA: Yeah. I guess sometimes also, you might build this stupid thing on a path to building the right thing as well. I could accept that as long as we’re not just leaving it and if we agree that it’s stupid then I’ll be like, “Okay, fine, let’s see where this goes.”
[0:08:02.4] MN: I have a question, Rob. I think like we mentioned multiple times, I’ve heard the phrase, “That’s not my job” right? All I want to do is punch keys and make sure this feature works. In your experience, have you seen engineers who behave that way, do you have any thoughts or anything you want to say to them? Because I feel like sometimes and this is probably like a philosophical question, it’s like, what if this person is an engineer but isn’t really excited about the product that they’re building or they just want to code because that’s just what they know how to do?
Do you have any tips and tricks or things that you may want to – for anyone who may be listening and think that they just want to punch keys that’s bigger than that? Do you have any thoughts?
[0:08:44.0] RO: Yeah, I definitely do. I think the big thing is defining done as a team, your definition of done and having the team rally around getting to done. Often times, if you're – you got a jerry board, you got a Trello board, wherever it is, you’ll have your different swim lanes and you’ll have your in progress, your code review, your QA, your sign-off, hopefully it’s not that complicated, and then done.
For a developer to think, my job is to get it from in progress to code review and then it sits in QA and then I’m good, I moved it to QA, I’m out. Wrong. You should not feel good unless things are getting to done, right? We got to be pulling to the right. Yes, what does that mean? It means, sometimes you're going to be hunting people down, you're going to be setting up meetings, you’re going to be calling people, you're going to be saying, “Design, can I get you on the phone, I need you to desk check this.”
“Hey, who is the legal person?” The success is only done. If you can’t define your success individually saying I got 50 tickets into QA. Well, that’s great and none of those got out and added any value to a customer. Really anchoring on what is the true impact and really thinking about that done column as success gets people away from saying, “I threw it into QA, no one looked at it, that’s their fault.”
No, that’s kind of your fault, it’s all of our fault, you got to go hunt those people down, you got to go do the non-dev work because if we got nothing done at the end of a sprint, we all failed, right?
[0:10:04.3] MN: Yeah, the user doesn’t get any value that’s of concern at the end of the day. Dave, look at us, we did an episode on definition of done, go us, yes.
[0:10:13.5] DA: Boom.
[0:10:14.2] MN: We know a thing.
[0:10:16.7] DA: We did, yeah.
[0:10:18.5] MN: Yes, I think the idea of knowing, when you do establish as mentioned before, the definition of done, that bit brings the team all together to rally and ensure that the story gets from that swim lane all the way to that done column. However long that is as you mentioned, don’t’ make it too long because that’s not fun.
This is possibly having to do with the definition of done as well but one thing that I’ve seen and this might be a faux pas on a dev aspect it has to do with the design of something. I’ve worked in different places, I’ve worked with different people within the same organization, I can work with one designer and say, “Hey, you have this design this way. Can we change it up a little bit, it will make it a lot faster” we just change it up a little bit and that’s fine.
Then there are other parts where it’s like, “No, you have to do it this way” and then this is how it’s done, you go take that and do your work.
[0:11:15.2] DA: Yeah, what is the level of fidelity you expect those input into creating the actual software. Is the designer building a pixel perfect world that’s like just a mock-up of a whole software? Is that how you're operating or are you okay with some kind of imperfections that you can then have a conversation with? You know? the whole promise for a conversation coming back again and closing the loop on, “Do you really mean that this is going to be a six-pixel margin? Everywhere else, it’s 10. Why did you do that?” “I just sneezed when I put that button down.”
[0:12:03.2] MN: Happens all the time.
[0:12:04.5] DA: Yeah, right?
[0:12:05.2] MN: Rob, do you have any thoughts on, this sounds more like, I don’t know, as mentioned before, I don’t know whether this is a dev faux pas or an organization faux pas or the designer faux pas, do you have any thoughts on how the developer treats a design and what to do?
[0:12:19.5] RO: I think it comes out on both sides. I think when designers are designing, their faux pas is they don’t bring dev in early enough. They try to get the answer and then get feedback from devs, rather than co-creating an answer with development. They waste a lot of time building out something that they really like just for a developer to be like, “You just added three months of work, I have a different solution that will take two days that will go with the same outcome” and they’re like, “Crap, I just wasted two weeks designing this.” Exactly.
Bring developers in much earlier, use them as team members and on the flip side, developers need to bring designers in as they’re building things because designers, you might have agreed with the designer, “Great, we’re going to do this padding, we’re going to do this.”
Then you say, “The mobile view, this actually looks pretty wonky” you can go, “Whatever, I’ll push it out.” If the designer, that’s how they designed it, whatever. No, you bring them in and you say hey, I’m in the middle of building this, come check out local, I didn’t put, this is not anywhere, look at local, is something wrong here? Can I recommend this, right?
Save time, don’t throw it over the fence to designers. Bring them into your development process just like we want them to bring you into their design process. It’s the same concept we keep going back to, this is a team and a team blurs the line of responsibility because we’re all focused on the end result, which is the outcome, the impact we want for our customers, not, “I do the coding, I don’t touch anything else, I did designing, I don’t touch anything else, I write the stories and make the priority, I don’t touch anything else” That’s not a team, that’s a bunch of individuals, right?
[0:13:47.9] DA: Yeah, I’ve done a lot of React development work and there’s this one page in the React docs called Thinking in React and the first section of that doc, I loved sharing with designers and just being like, “Hey, look at this, you don’t have to look at the second section, you can look if you want to, it may be more than you want to know about how React works after that point but it could be kind of cool for you to know if you read past that point” but just the idea of thinking about how I as a developer am going to use react to carve up this page into little pieces that hopefully I can reuse in the future.
Although, maybe not but I think in order to make that kind of reusable mentality stick, you really do have to have a strong partnership and like an alliance with the designer. If you're not pulling them in to those conversations and evolving it together and saying no to things that fall outside of what’s already there and kind of like easy and attainable then you’re just going to end up with every single page having its own beautiful and bespoke experience that takes you twice as long as you’d want to take.
[0:15:07.0] MN: Yeah, so I mean if you’re a developer hearing this and this sounds like a full pod you’ve been tripping up on, don’t. Talk to your designer, I think it is important for collaboration to happen on that regard.
[0:15:19.9] RO: Buy them a beer, become friends with them. They’re important.
[0:15:23.2] MN: I’ll ask you Rob, yeah you mentioned, is beer the go-to like not drink of choice but like building rapport of choice do you find beer better than coffee? Should I come over with snacks when I talk to a designer like, “Hey, I brought some snacks, you want to chat?” like what are your thoughts?
[0:15:41.2] DA: I don’t know, Rob strikes me more as a wine kind of guy. I don’t know why.
[0:15:44.4] RO: Tonight I am but I am a beer and a scotch person and then red wine but no, yeah. I think whatever it is, it’s just getting to know people outside of work. It doesn’t matter how, it doesn’t matter if you have a beer or have a coffee. It’s just being like one big thing I would like to do with new teams who don’t know each other is to literally be like, “Hey, we’re going to block off. Tell stakeholders, tell executives, we’re going to block off like an hour and a half for us to grab lunch and just chill.”
I don’t want to talk about work. I want to talk about where you’re from, what’s your favorite food, what you do on the weekends. I want us to get to know each other as people because those are the best teams. You want to work with people that you know because the real important part of that too is when things start going bad, you feel like you know each other. You’re less likely to point a finger at a friend than you are to just random person who happens to build and write my code or happens to do my designs.
[0:16:32.4] DA: That’s kind of like really been emphasized for me or some of that take it for granted. Building a team in a pre-pandemic world where we all can be collocated and like rub elbows and breathe on each other freely.
[0:16:49.3] RO: It’s the good old days, right Dave? Where you could do the thing.
[0:16:52.9] DA: Yeah, just breathing on each other. That’s what I used to do but now like this Apache guy told me I can’t do that so I don’t do it but like there were those intangible bonds that were formed and like you’re saying, when there’s stress or when you have to push back and you have to say no, then it doesn’t feel like it’s the end of the world because it’s like, “Yeah, okay whatever I know that you really like quesadillas and I like quesadillas too and it’s fine. We’ll just go out for lunch.”
[0:17:25.9] MN: Yeah, I mean I think building rapport is important for those who like to keep their heads down and punch keys, always trying to build some kind of relationship with your peers. I think it’s very important for you to have that kind of context with the individuals on your team. I think the next one I want to bring up has to do with someone who still likes to look down. Maybe they built rapport with people but at the end of the day, they feel like what they do best is coding, so much so that they avoid the meetings themselves.
It’s like, “I’ve got work to do, I don’t got time to be sitting in the meeting room with you all when I got things I need to handle.” Do you have any thoughts about that faux pas that devs often like exert when they’re in the workplace?
[0:18:11.7] RO: Talking to me or Dave?
[0:18:14.0] MN: Anyone, who have any thoughts. Dave, are you that person? Rob, do you hate that person?
[0:18:19.0] RO: I clearly have thoughts on this one. These are the faux pas’ about you guys so I’ll let you defend yourself. Go ahead Dave.
[0:18:24.0] DA: Okay, so I think I’m just going to lean into Rob’s punch here. He can give it to me. Sometimes, I think that there are certain meetings that everyone should be at but I think if you have a really strong bond with like the trifecta like the team lead, the tech lead, the design and the product who can come together and you can trust to make decisions and like liaise with the broader world, that can be very helpful so I don’t have to go on the call with the vendor that is providing us tech support or what have you but if you just – I don’t know.
Are you talking about a guy who is just like, “I don’t want to go to any meetings at all?” like not going to retro, not going to – a little mean person.
[0:19:21.0] MN: I have seen that in the past but I am curious to hear, Rob, have you seen that kind of individual who’s like, “I don’t want to go into iteration plan, just tell me the stories I’ll do them.”
[0:19:28.0] RO: It’s a little more nuance I think the topic, so the one that I think is the most impactful, I totally agree with you Dave, there is a certain amount of trust of sending a representative, right? We don’t need the whole team to come to every meeting but as a product person because I do really value my team, any meeting that I go to, I try to have a tech representative, a design representative. It doesn’t need to be the same person and it doesn’t need to be the whole team but where I think this topic really is important to me is when we do these initial kind of kick-off brainstorming ideation team forming meetings, where they are saying, “We’re going to iterate on this new feature. All we have is an idea.”
Sometimes we’re like, “Well, tell me when the designs are done” and like, “Well, no. We don’t have designs yet. I want to bring you to the table and I want your ideas.” Now like, “Well no, I build off of designs. I am not a designer. Tell me when they’re done” and I’m like, “Well, you’re kind of missing the point. We need you in these ideation sessions. We need you in this product visioning session. We need you in this metric definition session.”
Well that, someone always told me that. My product owner, product manager will tell me the metrics and tell me the vision. My designer will give me the designs, tell me when they’re done. Like no, right? We want you, we want to collectively come to solutions and ideas as a team. We don’t want to be told what our vision is or told what the design is. We want to co-create those. Now yes, the responsibility does primarily fall on the product person for certain things and designer but it doesn’t mean you shouldn’t get involved and that’s where I really get upset with people who don’t want to be in these workshops or don’t want to be in these kind of upfront meetings or ideation sessions.
[0:20:52.7] DA: Yeah, that’s fair. That’s fair, that is kind of a bummer and I think we talked about this in our definition of that episode that just dropped but like nothing is really truly done as well. The vision isn’t done and the metrics aren’t done and the design isn’t really done until you like delete the site, when you take the software down and you stop using it then it’s kind of done but like you know, nothing should be set in stone and so you should have that context too to help evolve it.
[0:21:23.7] MN: I think that I’m going to try and I’m going to probably – it will be a failed attempt that a parry of this punch and I think that the idea that there may be places that engineers may work where they feel that way and they feel that that is where their energy should be most spent in is when you have the designs or you have the acceptance criterias aren’t placed, this is where I shine and I think Rob, what you are alluding to is the idea of like having a diverse group of people is more important and building out the designs or the ask or the user features than actually punching the keys themselves and getting it done.
You know, oftentimes, myself included, I don’t feel to be a creative a lot of the times. I think I am one to feel more useful when it comes to delivering a feature versus in that planning phase if you will but I also believe that not a lot of developers get that opportunity. I think that if you are a developer who feels this way about particular features that are being built, definitely try and find out how you can contribute to that because it is important. The more people who are involved in that kind of process, the more eyes are on the idea that this is being built for the user.
[0:22:49.8] DA: Yeah. You know, what I really love about product people, I love it when they write all my tickets.
[0:22:59.1] RO: All of them?
[0:22:59.7] MN: You don’t like writing any?
[0:23:01.3] DA: Every last one, yeah. When Rob’s on vacation then there’s just RNA tickets. I just wait until he comes back.
[0:23:08.2] RO: Nice relaxing way for me to come right back into work, you know?
[0:23:11.9] DA: Yeah, exactly.
[0:23:12.6] RO: Nothing has moved.
[0:23:13.9] DA: Inbox just piling up.
[0:23:17.0] MN: Oh man, I have one more and this is definitely going to be a punch in the face. I’m going to punch myself Dave so you don’t have to worry about blocking this one.
[0:23:25.3] RO: You guys can’t see this but Dave just ducked. He just completely ducked the punch.
[0:23:29.9] MN: Yes.
[0:23:30.0] DA: I am light on my feet.
[0:23:31.9] MN: The one that I’ve seen and the one that I often get like caught up in the dev faux pas if you will, you know, a story comes in, you know I’ll tee up you guys, the story comes in. The acceptance criteria are clear, the designs are great, they make sense. I pick up the story, you know there is that cool new tech that just came out, I don’t know some kind of asparagus JS that I could use to make new graphs for this thing that’s being asked.
I am going to go ahead and spend all my energy introducing this very complicated piece of technology to do something that we could do very, very simply. Dave, have you ever experienced that? At some point, you were like, “Oh I want to use this thing because it’s cool and I want to learn more about it but you know, I could just do the very simple thing and keep it moving.”
[0:24:22.9] DA: Yeah, I mean like I love doing that. That’s my favorite thing like let me learn some new technology. Let’s use asparagus base graphic query languages.
[0:24:33.7] MN: Rob, do you have any thoughts on like how to talk a developer down from having to do something very, very complicated before in time?
[0:24:41.4] RO: Yeah, unfortunately before you really get beat up by this product person, generally you don’t feel that because you don’t really know what’s going on until you’re like, “Hey, this story has been carried over for the last three sprints, what’s going on?” “Well, we had to fit up a new server and AWS because this technology doesn’t exists on Prem and relationships don’t exist and no one has ever written in this but it’s really cool and it is going to optimize our speed and shave off a hundredth of a millisecond from this performance thing.”
I’m like, “It’s a submit button, I told you it is going to come back to the user in three days.” “What?” “What did you just do?” It’s like, “Well, I just think this is so cool. I went to one conference about this” I’m like, “Okay” you know, you start to find those patterns and sometimes you have to question when you hear, you know, going back to estimates it’s like, “Hey, I think I didn’t explain this well.” We’re not looking for the most performative or the most this but luckily, you usually have a good group of – you know, you’ll have those couple developers who will challenge that and say, “We don’t need that now” right?
We can add that complexity later, let’s just meet the acceptance criteria, let’s not meet what we think is the coolest and best thing to do.
[0:25:44.4] DA: Yeah and I guess that is also a good thing of like having a whole team in the room for talking about estimates and talking about alternatives like if it does seem like it’s going to be a lot of work for this really cool thing, then what is the really not cool thing that one could do and replace of it?
[0:26:06.4] MN: I have to look at my XP explain book.
[0:26:09.5] DA: Oh, is that the first edition?
[0:26:11.2] MN: This is the first edition, yeah. I had to go and grab it really quick.
[0:26:13.9] RO: That’s the one I read.
[0:26:14.7] MN: The idea that people or engineers often forget is you know, if you are following the values of XP, one of them is simplicity, right? It’s the idea of like, how do we get the most simplest thing out the door for our users? You can find out whether this feature is actually useful rather than diving into all of these different piece of tech and then you know, potentially finding out that it’s not going to make things any faster, as you mentioned, it’s a form that comes back in three days or what have you.
Building the most simplest thing so that you can get it out to your user is one of the four values of XP and it is important for us to remember that all the time.
[0:26:53.5] DA: Yeah, do the simple thing, get out there, get the feedback, build another simple thing.
[0:26:58.9] MN: It’s like KISS, keep it simple stupid. There you go, that’s one of the acronyms that we have. Yeah, I think that was a lot of dev faux pas. Rob, you shanked me with your Godzilla claws I guess.
[0:27:10.8] RO: I got some bruises on my face. Don’t worry, as product people we got our work cut out for us.
[0:27:14.4] MN: I think hopefully the people who enjoyed it are the viewers or the listeners who have listened to this episode or watch the movie, I don’t know if you watched Godzilla versus King Kong. I think it was good.
[0:27:25.2] RO: It’s terrible.
[0:27:26.6] DA: Are we getting paid? I guess we are not getting paid now.
[0:27:29.4] RO: Sponsored by.
[0:27:30.7] MN: Yeah, oh man. Yeah, I think that if we understand the faux pas of different aspects of the teams that we work in, we can find out how to better ourselves. I think there was a lot of self-reflection on this dev episode today. Dave, what do you think?
[0:27:46.2] DA: Yeah, I did punch myself a couple of times so I learned a lot through that.
[0:27:50.3] MN: Thank you Rob, that was therapeutic, just punching myself and breaking my glasses in the meantime as I was doing it and punching Dave too, sorry bro I didn’t mean to.
[0:27:59.7] DA: It’s okay.
[0:28:00.8] MN: Hopefully the next episode that you all listen to will be less violent but it was great to have you Rob. Thanks for coming on down.
[0:28:08.0] RO: Yeah, thank you guys for having me. This was a lot of fun. I’ll have to come on again and talk about something else. Maybe something a little less violent, you know?
[0:28:14.3] MN: Yeah, hopefully that’s key.
[0:28:15.1] RO: We’ll find harmony the next time I come on.
[0:28:16.7] DA: Yeah, right.
[0:28:17.5] MN: Sounds good.
[END OF INTERVIEW]
[0:28:18.4] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
