Robby is the co-founder and CEO of Planet Argon and the original creator of OH-MY-ZSH.
Robby is the co-founder and CEO of Planet Argon and the original creator of OH-MY-ZSH.
In this part 2 of the two part interview with Robby, we focus on goals of a team and how to identify areas that need some maintainability focus.
Thank you to New Relic for sponsoring today's episode!
Make managing and analysis of complex digital architectures work for you. Check them out at NewRelic.com to become a full access user with 100GB per month totally free.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
which might be a way to recruit new people for new technology. But then, you know, if you're also learning a new technology on the job and you don't have anyone else helping establish good, good foundations for what your workflow is going to look like, your development patterns are going to be, or making that the elusive another back to the whole theme of maintainable is one of my goals is to fight the big rewrite because oftentimes rewrites fail because there are people who drastic underestimate what it really takes to go through to not only build out a new application, but to keep the existing one going in parallel and then dealing with that migration at some point. And so a lot of, you know, a lot of failed upgrade projects out there. You just heard the voice of Robbie Russell, today's guest. If you missed the first part of the interview, I encourage you to go back and listen to that part. Before you listen to this one in this episode, we continue discussing issues of maintainability, which is a subcategory, a subject that Robbie and his team at Planet Argon are experts on. Go and check out what they're doing. Head over to planetargon.com. My name is Jonathan Cottrell. You're listening to Developer Tea. And my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. This is the second part of my interview with Robbie Russell. Let's jump straight in to the interview. Yeah. A lot of this comes back to good software design. But I love this point that you make about resume-driven development, because I do think that there is, you know, it is totally reasonable to think about the economics for the individual, right? Yes, totally. It's very unlikely that each developer on a team is willing to say, I'm staying here for the rest of my life. That's almost certainly not going to happen. And so it's necessary also, for engineering leaders, right? Managers or engineering kind of team leads, whatever that position is in your organization, to stay aware of this, right? And say, hey, you know what? There's an opportunity that will advance your career despite your position here or elsewhere. Like this is a good opportunity for you to work in this direction rather than letting that become a, you know, kind of the primary goal. Let it become a side effect. And this, or I guess design it to be a side effect, right? The hope would be that you're solving problems. And naturally, as you solve problems, your kind of your resume or your external worth to the company grows in tandem, right? There can be certainly a dual win scenario, right? Both sides are happy. At the end, And so making good decisions, right? This is perhaps the most important takeaway, I think, from this, I guess, a little diversion here. Making good decisions is a more important thing for your resume in the long term than any technology you can put on that list. If you can explain in a well-reasoned way why you made a particular decision, even when it was a hard one, when it was not in vogue, right? We went with the monolith on purpose. Here's why, right? Those kinds of discussions are, for good employers at least, are much more valuable than any buzzword because there are a thousand employees or potential employees who have those buzzwords on their resume too. Microservices are not a unique thing. So that's not what's going to differentiate you. If you want differentiation, if you're a new engineer and you want differentiation, you're going to have to make a decision. If you want differentiation, explain your decision-making. Make decisions that are well-reasoned and well-thought-out. As it turns out, that is more rare than it seems. Would you agree with this? Very, very much so. I was even just thinking recently, I was talking to some interns about, look over their resumes and their cover letters to get an idea of how they're pitching themselves as they're looking for their forever development home. As an intern, I'm like, oh, I'm going to do this. I'm going to enter this career. But there's this interesting thing with resumes where it's just like, here's a big list of all the things or even like proficiency percentages on specific technology stacks. I'm like, but tell me about how you, yeah, I think you make a good point about like, talk about the impact that you've made and the decisions you've helped make and how you've influenced things and the things you might even consider, you know, in retrospect, I feel like I would probably definitely redo this in a different way now. And I think being. Able to speak to that, I think is being, I think if anything we know as developers, it's always like the, it depends is like the start of every one of our questions or answers to a question. And I think we should be able to show nuance a bit more and in our introductions and resumes and our interviewing process. You know, I want to know how you, how you're thinking about these problems. And because I'm looking to hire someone that can just spit out code. That's like an artifact of the work that you're doing, but you're here to solve problems for. Our clients and being able to articulate why you think and believe this approach might. Be more valuable, but not do with an air of overconfidence that this is the only way to do it. Um, this, this might be helpful, but there's kind of like a showing there's some give and take there and, and, and helping guide people towards like, let's experiment with this type of approach or something. And it can be an effective way of doing that too, but getting a law of course there, but I think that, but I agree the. Right. The resume is focused too much on the tech stacks, um, to some degree and not enough on like the impact you've been able to make. Um, Yeah, I do agree with that. I, and I think that that's, you know, that brings us into, and you mentioned, uh, internships, actually, this is another topic that we discussed beforehand that you've been interested in recently. Because I think there's a lot of overlap here about understanding. Uh, not just, you know, what are. What are the good decisions and how do you align those with growing your resume? But how do you kind of create that as a habit early on in your career? So I'd love for you to kind of, um, explain how you are conducting your technical internships today and why. Well, let's see. So we, we started doing for a long time. I mean, like we, like, I think a lot of people that I talked to. Didn't think we had the time. And I think if we're really being honest, the, uh, the confidence in our ability to. Provide a meaningful internship experience to someone. So, you know, we've, I think since almost since the beginning of the company, we've had people contact us that were like just about to graduate, or maybe they're a year away from graduation and they have a summer off and they want to find somewhere to intern for a couple of months. They reach out and we're like, I don't. I don't really know. I come busy doing client stuff. Do I? I have time to in the capacity to really be helpful here. And so we kept putting it off and putting it off. I'm like, I don't think this is something we can do until one day someone reached out and I was, it was on a day where I was already thinking about, um, the idea of being a mentor just in general and like how I was being an intern mentor to people on the team. And so someone reached out and said that they were looking for an internship and I was like, you know what? I'll at least have a conversation with this person and kind of get a sense of where they're at. We ended up bringing them in and. Taking a gamble. We're like, okay, we'll do our best. And behind the scenes on our leadership team, we're like, let's try to screw this up. Let's just make sure that they have a meaningful internship experience. And we kind of winged it and it worked out. Okay. That person, we ended up hiring them and they worked for us for like about five years. And. And so that was then, and then I think about, it must be about six, seven years ago, we started, we paired up with a local bootcamp here in Portland, Oregon, in the United States where, um, part of. Their curriculum at the end of their, I think it's like 28, 30 weeks, um, bootcamp, they get, they place. Um, interns, well, they're, they're students on site at a company for another five weeks and then to get some more real world experience. And so. For us, it seemed like an easy enough type of thing to, um, set up for it. We're like, okay, we don't need to like put up an ad and like interview a bunch of people. We're going to interview like six people. And then they're going to kind of randomly pick two of them that. Actually get assigned to us, but at least they're getting six of those people are going to get experience of getting, going through some interviews and then we'll have those people come in for five weeks. And then there's a very clear time window for that. And so we kind of took that and learn from that over the years. And so early on. So let's fast forward to now what we're doing kind of based off of, um, in the spirit of time here, the, there is, so when people come in and there's kind of like this pre and during COVID scenario as well, which like cool. It's a. It's a. Wednesday that we're recording on Friday. It's the end of one of our internship or interns last days on Friday. And so this was the first time we've ever done fully remote internships. And we were really nervous about doing that because we had never done it before. And we've, we've, we've always really appreciated doing that in person because our, you know, our company culture, we've always been in house together in the same office space. And now with COVID that's all out the window and I don't know if we'll ever be a fully. On-site company again. and that's a topic for another day. But so with our internship program, people come in and we've now set it up where historically we would put them on pet projects, might be some internal things, some small internal apps we wanted to work on, or even some like kind of projects that they would kind of get to experiment with. And we had a set of features we were looking to them to build and we provide feedback on them. And then those projects may or may not see the day of light at the end of it. And we learned that that felt really ineffective for everyone involved in from the people on our on our end and for the interns and that they didn't really feel like it mattered if they finished the project because they didn't know if it was ever going to get used anyways. And that didn't feel I don't think that felt good. So I think about three or four years ago, we started to work with some of our clients. We had a couple of clients in particular that we've been working with for a long time. And we've been working with for a number of years where we felt like we had a decent level of trust there that we could go in and say, hey, we're going to be bringing interns in, we're going to get two interns for the next five, six weeks. And we want them to work on your application. And it's a large, scary application. But we want to we want to introduce them to the idea of working on an existing older code base and work on something that will make some valuable contribution to your code base and also have the experience of getting to interact with a client. And we'll do that for free. So if you're willing to, you know, have a few G or a comic conversations and maybe a phone call or two, and talk with them a little bit and give them some feedback at times that would, you know, that would be kind of that's, that's the trade. So we've established that with, with a number of our clients now where they'll come, our interns will show up. And we are on onboarding experiences to bring them into an older code base, which, if you think about a lot of bootcamps, it's likely going to be a scenario where they're learning a lot of building blocks, building new things. And then all of a sudden, you get this, you know, nobody starts their first job, these rare, rarely and gets to work on a new application, you know, it's like we were talking about earlier, you're joining a company that has been established, there's likely an established application code bases that have been around for a while, team documentation. And it's intimidating and scary to be an intern and a junior developer coming in this industry, and looking at a really large application, we're like, Whoa, this is going to be a scenario where they're going to be learning a lot of building blocks, buildingension, bringing together all these players, bringing together all these players, bringing players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these players, bringing together all these tables, I've created a couple dozen in my career so far. So and so we'll work, we'll see that transition where they'll, you know, we'll send them a few small features or bug fixes is also a good one, where like that first week, they're getting, getting up and running with the application. And then they start looking at this, you know, the area code base, and there, you can just see just how intimidated they are. But then you'll see three or four weeks later, they're how confident they feel about working within an existing application. So that, to me, is I think one of the most valuable things that I think we can do in an internship program is to really expose them to like what it's going to be like to have that first experience at their first job to help let them know like, okay, I can get through this. And, you know, we're not, you know, we're here to help guide them. And then the other part, the other things that we're also doing is, you know, we have a lot of planned scheduled pairing time with our interns. So we have a whole, we have a toolkit that you can download on our website, too, for this whole kind of maps out our whole program, but for other people that are trying to set this up themselves, but a big thing for us is to pre plan, not so much what they're going to do on a day to day basis, but knowing that there's going to be scheduled time to either shadow or pair with other developers during their internship period. And one of the things that we always find to be really valuable, outside of, you know, just getting to work on existing code bases, but when they're pairing or even shadowing a developer that's working on some other area of the application, is the just to see how they're working. And they're often surprised, you know, they'll, you know, something is they'll, they'll talk about things that they learned, like, wow, I didn't realize that senior developers googled so much. And they need to look this up, too. And, and they're like, Oh, I don't have to remember all this stuff at the top of my head, or, you know, they'll go look up the documentation on how to split this array properly, you know, they don't just remember all these things. And so like, that helps to boost their confidence, like, okay, like, I'm not going to get fired at my first job, if someone looks over my shoulder and sees that I'm looking up some documentation on something that I should know already. And because that is a lot of, you know, there's a lot of things to remember, we don't all remember everything. And, and if you're someone out there that would judge someone on googling for the documentation, that maybe you think about your priorities there. But they may have taken theijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij our toolkit with them early on. So if they read ahead, they can see that we do that, try to be transparent about it. But I think an important part of the team experience is to be able to hand off work to other people. And so we're always trying to think of, there's a cut off when your internship's going to end. And I know you really want to finish this feature or project, but you're going to have to wrap it up and organize it so that someone else can pick it up and continue working on it. And so what does that process look like? And so that way you don't just leave a branch that sits there and then what ends up happening, if there's nothing people can really pick up, that branch just gets tossed. And then when someone decides to clean it up at some point. So I think that's another thing to think about is giving people that experience of trying to prepare work to pass it over to someone is another thing. So outside of just trying to make sure that they get... Exposed to real projects and not on some weird internal pet projects. And the other part of that is that that helps them really think about how they can promote what they did when they're applying for jobs. And like, oh, I was able to work on this project. They can drop some of our client names are pretty high profile and they can be like, I work with so-and-so company that those people might've heard of. And I helped improve the performance of their homepage by 12% or what have you. And knowing that they had a... Yeah. They had a... They were able to play a part of that. That's like a good little resume line item to include there. Another thing that we're strongly opinionated about, which some people can be surprised by, is that we intentionally do not see this as a recruitment pipeline tool for us. And so very upfront, we are not going to hire you. And that might feel harsh, but on the other end, I feel like it's very kind to say, I'm not going to hire you. I'm not going to hire you. I'm not going to hire you. I'm not going to hire you. I'm not going to hire you. I'm not going to hire you. At that parameter, because the thing about... Because we've hired interns in the past and don't get me wrong, I'm not saying I'm like, I'm never, ever going to hire an intern, but as a general rule, no, this is a fixed period of time. And in order for us to continue offering this to other people, we need to enforce our own boundaries here. Because if we bring in the higher the people, we might not feel like we have the ability to continue operating this program to the next round of interns that we want to bringing in. to bring in. So we're trying to do this, you know, we're trying to bring in at least eight to 12 interns every year. We're having to shift that around a little bit with COVID, but as we just started doing it again, we just, we just wrapped up three internships and over this last couple of months now. And for me, it's also how that's, that's an important thing to bake into my team's culture is that they're going to be regularly expected to help onboard new people onto the team for a period of time and provide mentorship, guide to them, and then help consult them on how to think about their career, the type of direction they might explore. And I think we touched on the whole being consultant versus a product company. And it's one of the things I, I, we tried to bring up early on in those conversations about like, Hey, how's your job hunt going? Because those junior developers and interns that are, you know, you might be working with, they're nervous about rejection. And so they will put that off and maybe hope that maybe there'll be like, they'll get to stick around for a while. So I don't want to squash that hope necessarily, but I want them to thinking, I want them focused on like, we're here to prep you for your next, for your job. And so, so we're like, let's look at your resumes. Let's look at your cover letters that you're sending out and, you know, and cheerleading them to, to a degree of like, you know, helping, helping them like feel confident as they go into interviews. And we've had people hired before they finished their internships here. We have someone finishing on Friday and I sent over some feedback to her yesterday on her cover letters. And she said, Hey, she replied to me a little, a little while ago before our interview. And she's like, just an FYI, I got a job interview tomorrow at this really big company. And if that doesn't work out, this other company offered me a paid internship just as a fallback. And I'm like, that's awesome. Like they're, that's great. That's to me, that's, that's the most successful thing is seeing that they're able to take that next step. And we're getting to be maybe a stepping, stone part of their career. And who knows, maybe long-term the path for us is they'll, you know, they'll be at some company for a long time and they'll have some leverage at some point to recommend a company like Planet Argonne to be a consultant for them. Yeah. Yeah, absolutely. And I think it's, it's amazing because my career was so much impacted by my internship. And I don't think that the company, I actually interned also at a consultancy. I don't think that they saw the internship as a pipeline for hiring necessarily, although they had hired interns before. But what I saw it as was an opportunity to be around a bunch of people who frankly knew way more than I did about what I was doing, far more. And I made many mistakes in that internship. And I look back on that very gratefully. Both for the experience and the people that I was able to meet as a part of the experience. And I think that the company was in ways providing that to people as a service, right? Internships are not an easy thing to figure out, but they also are doing it because it makes them better at a lot of different things. Companies are improved by internships, in my opinion, not just because, uh, it is a hiring pipeline or in your case, it's not right. But because it allows you an opportunity to investigate things through a different lens, investigate your own work and your own processes and your own culture through a different lens, especially. Yes. And I think that is such a critically, um, valuable opportunity that if it, if it was just that, if you had just the perspective, the internships would be worth it just for that. But I'm interested in what you believe is the most important lesson or thing that you've learned for your company as a result of doing these internships. Something you just mentioned where you get this, this other lens, um, this one of the, at least a valuable part as the, the owner of my company is that I can, when I, when I'll, I'll do a quick check-in early on within their internship. And then towards the end, and I'll, I'll ask them to describe our company culture as a new person. Right. And then maybe then I'll ask them a very similar question towards the end and see how much that changes over that period of time. And sometimes it could be maybe even some level, you know, they're always going to be happy and excited to be there. And so you take it, you know, try to take it with some grain of salt, but I should also accept like the positive feedback and the praise that they might have for the organization that I've helped build over the years and the team more. Yeah. Yeah. Yeah. Yeah. At the same time, they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and plunge and they may have taken the plunge and they may have taken the plunge and they may have taken the plunge and they may have taken most valuable thing that I feel like I personally get is some validation that we have a very thoughtful, mindful team that cares a lot about the well-being of their peers. Because I think that always comes through with interns in particular, where they just feel like, I felt like I belonged here. I feel like I was part of the team. I wasn't like the other guest that was just kind of roaming around. You made me feel like I was part of this team. I'm sad to now leave it. And so that, in a way, feels good and something that I'm glad that we can kind of facilitate. But ultimately, it's for the team, the expectation for everybody that's all of my full-time employees, that they're all getting that experience of providing mentorship and getting past the, I don't have time, or to answer questions from someone that may have less experience than me, or even just maybe help remove some of that ego, because there's things that they know that they can't answer. And so I think it helps combat that in a way where everybody on the team is expected to participate with interns in some level. We bring in interns for other roles as well in the organization. So it's not just developers. So everybody has those experiences. So it's just baked into our team DNA that we're constantly having to learn how to, on board and mentor people. Because then we can do that with the people we bring on full-time and be really successful there. Because as a consultant, when we got brought into these other companies where they have a team that's been around, and they're bringing in, I mentioned that story earlier with the old guard and the new guard type of situation, where the old guard didn't have any mentoring skills whatsoever. And maybe in some ways it was too late to help train them or help them overcome that. And, I don't worry about the people that work here at Planet Oregon going on at least for the remainder of their time here, but also as they go on in the rest of the industry and their future jobs, that they're going to carry those skill sets and be able to bring that value and keep just being, help build a more inclusive and empathetic and thoughtful, mindful culture to the industry. And so I feel like that to me is something I feel like is a legacy that I can be proud of. It's knowing that like, oh, we made these decisions. Yeah. Yeah. Yeah. Yeah. Yeah. And this is a way that the company has been able to help kind of like the big, the big picture type of thing financially. Can I say it's great? I mean, it's, it can be, I think that it's hard to kind of weigh that up. It's a cost to us, but I think it's a, but I feel like it's, it's, it's an interesting way of professional development that is kind of helps, helps people more on an intrinsic level. Yeah, this is actually, so I'm going to give you a kind of a parallel practice that I've been kind of playing around with as a manager for a long time. The idea of doing high level demos within an organization and doing so not just for the engineering team or department, but also inviting other people. Okay. Stakeholders, et cetera, and allowing the individual contributors to do those demos. Now what this provides is some forcing functions. And I think internships also provide some forcing functions that are similar, which is why I bring it up. The first thing that it allows is it allows everybody to see the more specific details of the work that's being done. So there's some translation work that's happening, right? From engineering, engineers to folks, et cetera. But there's also the opportunity and perhaps the imperative for engineers to consider their work through the lens of someone who isn't an engineer. What does that work mean to the stakeholder? What does it mean to, let's say other teams, other engineers on other teams that don't necessarily know about the specific problems that you're facing? And how can you, how can you concisely convey that message in five minutes? And this is, this is a hugely valuable exercise. Even if you didn't have a demo, if you were just required to make a demo, right? Um, because what it, what it forces and not in a coercive way, but what it, I guess it's more of an invitation. What it invites individual contributors to do is to understand things at a high level and to be able to translate all of the work that they're doing. Like you said, in those PRS, right in those individual commit messages, translate all of that and summarize it into something that is consumable by almost anybody on the team. In a similar way, if you have interns that are, uh, on your various teams, right? Let's say you had a team of five engineers and there's an intern that makes up number six. Those five engineers now have the open opportunity, no matter what level they are at, they have the open opportunity to act as a mentor to that younger intern engineer. And even if that is not explicitly identified, that is kind of the, the dynamic that's set up, right? The, the kind of, uh, full-time engineer and the intern are sitting next to each other or they're, you know, working in the same PR. That, that intern is going to have a, a chance to ask questions. And the otherwise junior engineer who may see themselves at the bottom of the, you know, proverbial totem pole, they get an opportunity to actually teach, to, to, to lead somebody, to start flexing or exercising those muscles that they're going to need for the longevity of their career and doing so early rather than waiting until, you know, their 10 or, their 15 years down the road and they've forgotten what it means to be a beginner. Right? So I think these are really important ways. These are these kinds of, uh, what may feel like if you're an engineer listening to this right now and you think, oh, why is management making us do this stuff? Right? I just want to code. I just want to get my work done and go home and be happy. And for some people, that's a completely reasonable way to go through your career. But for engineers who are going to grow, into leadership positions for engineers who are going to eventually, for example, potentially jump tracks to being a manager and all of these kinds of, uh, moves that you could grow in your career with, um, those management tactics that you're hearing about is largely because of this, because it's going to enable something that just coding on your own is not necessarily going to enable you to do. you know, it's, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, it's a, you're right. The, uh, it'd be interesting for me to actually go back and track a little bit, but I, I think we, we bring on junior developers and, you know, it is often one of the cited reasons why our internship thing is so helpful is that it helps improve those people's confidence so quickly that they're like, oh, I'm actually able to help someone else kind of. And in some ways, you know, like they might feel like, oh, they're up here. They're only like six, 12 months behind me. But, you know, we're kind of like, you know, it's like you get up that next ladder step and you're like, oh, let me help the next person up behind me. Um, that's such a good, such a good, I think, good thing to feel for, for those people to go through an experience for sure. And they build up those longterm, you know, skill sets. And you said bringing, moving in potentially into management positions or just being a good, uh, good teammate, I think is important. Today's episode is sponsored by new relic. New relic is observability made simple. Monitoring a complex digital architecture takes dozens of different tools and troubleshooting ends up meaning jumping between tons of dashboards and data. And new relic wants to change this problem. They've designed everything you need in three products. First is a, telemetry data platform, which creates a fully manageable schemaless time series database of all your data from any source. The second is a full stack observability for analyzing, visualizing, and troubleshooting your whole stack. And finally applied intelligence that seamlessly automates anomaly detection and incident intelligence correlation using AI and ML. That sounds like a mouthful, but really what it comes down to is being the one place that you go to understand what's going on with your application. Not just reading logs, by the way, not just looking through a bunch of, uh, kind of logged issues. Uh, this isn't what new relic does. New relic gives you better insights because it's higher order software. This isn't just, you know, sticking in between your logger and logging that out to new relic and allowing you to search that information. It's much more than that. And of course, the best part is that you get all of that for free. There's no host based pricing and no constant upsell for more functionality. You get a hundred gigabytes a month to one full access user head over to new relic.com to learn more. New relic is observability made simple makes again a new relic for sponsoring today's episode of developer T. Um, because a lot of times teams tend to kind of homogenize, you have the senior engineers kind of work together, right? And then you put the junior engineers on their own projects, because they kind of speak the same language. But when you put them together, something kind of unique forms out of that. And it's difficult. That's the D that's the hard part is that you're kind of creating a difficult scenario. There's demos are difficult. Internships are difficult. They are because it's uncomfortable. It's uncomfortable to be, you know, as a junior engineer to be asked questions, right? It's exciting. It's not a bad kind of, um, uh, negative consequences, kind of uncomfortable. It's, it's growth kind of uncomfortable. Um, and so I do think that those, those kinds of situations produce growth, uh, for both sides. And it is an investment to your point. It's not a free thing. It's an investment. Robbie, thank you so much for joining me on developer T. I want to ask you questions that I like to ask every guest who comes on the show. If you have just a few more minutes here. Yeah, definitely Jonathan. So the first question I want to ask you is what do you wish more, more people would ask you about? I can tell you, I wish people didn't ask me what I did for a living. Um, but cause I think that was the first question I asked you. I know. Um, but I wish people would ask me, what are you focused on right now? And I think that in a way, just because if anything, to help me focus as an owner of a business, sometimes where there's a lot of things going on and, um, you know, it's easy enough for me to report on, here's my priorities right now. But I think there's like a certain level, there's like a certain level of focus in my life right now. Like there's, I've got a number of different projects outside of, you know, being an owner of a business to, um, you know, helping lead a, a popular open source project to, you know, running, like having a band and playing music, other things in my life right now. So I'm a project oriented person. So I wish people asked me more about what new projects are you working on? Or like, what are you focused on? I think it's always an interesting thing. And so it's a question I like to ask other people. That is a, it's a difficult question to answer. I think for a lot of people, because they think categorically, right? What am I, what do you, what do you mean? What am I focused? Am I focused on at work? Uh, what am I focused on internally? What, where is that focused at? So I'm interested. Do you, do you see that? I know a lot of entrepreneurs don't really draw really hard lines between those things. Do you see that overlap kind of, blurring or do you see them distinctly, uh, in terms of your focus and what are you focused on right now? There is overlap in, especially, you know, in the, in the time of COVID where the barriers for like physical space, separation of, you know, I'm been working primarily at my kitchen table for the past six months. And so I don't know where the barriers are anymore and I don't get to play music with my band right now because we were not all able to go to the gym. So I'm not able to go to the gym. I'm not able to go to the gym. I'm not able to go to the gym. I'm not able to go to the gym. I'm not able to go to the gym. I'm not able to go to the gym. I'm not able to go to the gym. I'm not able to go to the gym. because we were not all able to go practice together and feel safe doing that. But so focus is, you know, I think it's, it's interesting. The, uh, so great question. So, uh, jokingly say that the, uh, I am focused on trying to find barriers, I suppose, to, to create more separation right now in this, this world where separation is hard to find. So like, like actively, I think the last several weeks, it's been, my role, has shifted recently. At my company, we were able to, for the last three, four years, I've been directly managing the software developers on our team. And we recently just hired a new engineering manager. They've been here for 30 days now. And so my role has been able to switch quite a bit where I used to have, you know, a number of one-on-ones and now I have two direct reports instead of nine to 10. So that's like a context, a switch that I'm navigating. So I'm trying to figure out what my new focus looks like over the next quarter and trying to define those barriers and be like, okay, I want to make sure I have enough of me to, when I'm home with my fiance to talk about the projects in our world that I can show up and be present for that. And I don't let, I try to be very mindful of not allowing my, something I think I'm always constantly working on is not drawing the success of my business as to be the same thing as the success of me as a human being on the planet. That's a tricky thing to kind of walk the line as a business owner at times, but especially you've been doing it your whole adult life. So, so yeah, I'm focused on trying to like navigate that to, to, to create some boundaries, not because I feel like it's bleeding over necessarily too much. It's just wanting to show up. And each of those contexts and feel more focused within those contexts rather than feeling like, okay, I show up and I'm, I'm in my, my dining room area and I'm like, okay, I got to work on these projects for work. And then I also got to get back to the band about these things. I got to work on, you know, get back to the nonprofit. And it's like, I feel like in some ways it's my to-do list is maybe too widespread. And so it's, it's too blurry. And that's, that's creating maybe a difficult level of finding some focus within each of those confined, you know, areas of the organization that are, that are, that are, that are, that are, that are not, that are, that are not, that are not, that are not, that are not, that are not, that are not the right places to be. This is a problem that I have as well. And I'm interested in, in what you think about this, because I think, you know, I have a lot going on. And it seems like even though I'm not going anywhere, like you said, I'm kind of staying at home. I have a bunch of these home projects and things like that. I feel perhaps more busy than ever partially as, as a parent, a stay-at-home parent during a pandemic. But I'm wondering, you know, do you think that you're going to be able to, you know, be able to, you know, be able to, you know, be able to, you know, be able to work with your kids? Do you think that the separation, you know, we know that we're not good at multitasking, for example, right? That's not going to happen. I'm not going to be able to spend quality time with my children and also work at the same time. I have to separate those things out. Do you think the separation will give us a sense that we're able to get more done? All right. So that's maybe one option. I'm going to give you one other option. And of course, the floor is open for you to add a third. But do you think it will give us a sense that we're getting more done? Or do you think that separation will help us understand that we don't need to do as much? I'm going to go with the latter there. I think it's more, I feel like it's easy in some ways to feel busy right now. Because there's a lot of things going on. There's a lot of things to tend to, a lot of things to do. And so I can't speak for you. I'm not going to go into too much detail for you or for other people. But for myself, I've got big to-do lists. And I can go through and like, okay, I'm checking off all these things. And I'm getting a lot done. And I think in some ways for me to think of me improving my focus is not necessarily so I can go, okay, cool, I can get more to-dos done today. It's more about that I think in this space right now, as we're in the US, there's a lot of things going on right now and in the world as well. And I think the hard part for me right now is that I'm not going to be able to do as much as I want to do. And I think that's the, I think there's a lack of permanence. And I think there's always like, I think in some ways, for many years, I was always trying to be very careful about not getting attached and make too long term about decisions. And I think in a weird way now, I kind of miss that. It's hard to make long term decisions about anything because we don't really know what three, six months looks like anymore. Can we, is my office going to open back up again? Do we get rid of our lease? Those are big like business decisions that, you know, I've kind of hemming and hawing over for quite a while about, but it's like, if those things feel permanent to make these like, kind of like, how will this impact the company if I make that sort of decision? And like, how can I really come up with the annual plan right now when it feels like we're kind of in this weird reactive world and how can I feel proactive again? And so if anything focuses me thinking, okay, I need to focus on just these few things that I feel like are going to have the most impact on the company or on the band. Or on my personal life or what have you. And so that I can be like, I'm narrowing in and that I can feel like the conversations I'm having with the people that I'm collaborating on those projects with, because every one of my projects is a collaborative effort. I don't do a lot of solo projects. And that just is like a little side note there. And so I want the conversations that I'm having to be more focused and with the other people that are involved. And so, so it's less like a one-on-one conversation, but it's more like a one-on-one conversation. And so I want to have more consistent focus conversations with the people, the collaborators that I'm involved with so that I can feel like we're making more meaningful impact and not just checking off a bunch of to-do lists or feeling this guilt about not getting enough of my to-do list done each day. Because I felt that way six, you know, more than six months ago, I was already, I already felt that way about my to-do list. So I think I'm just being honest with myself about that. Yeah. That, so the last thing you said right there, being honest with yourself, I think this is actually the problem that we, that we tend to have. Okay. So I have 50 things on my to-do list. My wife always kind of makes fun of me for this. She says, I'm way too optimistic about what I can get done in a given day. And I think part of this is, you know, me believing that I can fit more than I can and not prioritizing that list because I don't want to come to terms with the fact that I'm not going to be able to do it. And so I think that's a big part of that. That I have to cut things off of it, right? That that list actually needs to be shorter, which means I have to sacrifice something. And that's painful. It's painful to come to terms with the fact that, Hey, you know what? You know, the, the, the days are passing. And so I have to choose sometimes between two really good things. And sometimes that's a very personal choice. I have to choose between doing the work that I know I need to do and spending time with my three-year-old, right? And both of those things are really important. So how do you choose? Well, if you'd never make the choice, then you don't have to confront that pain, but then you're stuck in this middle ground where your attention is split and you don't really do either one, right? It's, it's almost a, it's like procrastinate. It's almost attention procrastination. Yeah. You're trying to do both, but you're not really doing either one of them. You know what I mean? That's a, it's a tricky one where you're in that state and we were kind of like hemming and hawing over this or that. Or, or what you end up doing is distracting yourself with something else, right? And so you add, you know, there's probably a number of things, if we're being honest with ourselves that we, we silently add to our to-do list that we didn't sign up for at the beginning of the day or whatever we organize our to-do list that we ended up doing, but we didn't give ourselves credit for it necessarily at the end of the day. When you look back at the checklist of all the things you did, uh, really, unless if you do that, that, that, that can be helpful. I'm like, okay, I started off. I had to get, I had to get these 10 things done today, but I actually did seven of those. And I did five other things that I didn't expect to do. And so trying to, then you can use that as maybe a way to like plan ahead, like, okay, I'm needing to carve out some more space for the unexpected things that, that may pop up work, personal, what have you, that will pop up in the day of the unknowns. Right. And so we don't know what we don't know. And so not everybody can just kind of close off to the whole world right now. And so, and so I think that's a good one. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Interesting. But some, I can't remember who said this, but I feel like I heard something or read something a couple of years ago where some advice on how to prioritize things or how to make, make that decision. It's like, how would you, you know, it's, I think maybe one way to like illustrate this, like if you were, if it was someone that you, someone came to you and said, Hey, I'm kind of like weighing up the options of this or that to focus on how I focus some of my time over here and which one I prioritize, which one should I do? And like, how would you, how would you, how would you, how would you, how would you, how would you help them answer that question? And so you could think about it in that way and, you know, think of like, well, how would I, you know, advise someone else to do that? But then another way to do it is maybe to think of, you know, that you could also just ask someone else for advice on which one is you think is for the good of that project or what have you. It feels like a more pressing thing because you're just not sure at the moment and then maybe they'll kind of point you in the right direction. And so I think regardless of which, I think it's interesting because I've struggled with that sometimes as like the CEO of my company where I'm just like, I don't have a boss telling me focus on this right now. And so there's oftentimes I have to do that myself. And so that can be a little bit of a challenge, but sometimes I'll be like, okay, I'll talk to my fiance. I'm like, Hey, just a quick little side thing. I'm kind of weighing these two things up. What do you think? And she might just help nudge me in one direction. I'm like, okay, I'll just go with that. And if I have a strong visceral reaction to it, then I'll know that that wasn't the right thing. And then I'll be like, okay, I'll just go with that. And if I have the right answer and I'll go the other route. So I think it's like the whole flip a coin type of thing, but maybe just having to talk out loud to someone else can be maybe a helpful way to help navigate that. So in addition to that, sometimes it's as simple as getting a piece of paper out for me, right. And listing these things out, because like you said, there's this implicit things that end up landing on my to-do list or, you know, and it is funny. Um, when I talk to people about this, it's easy to talk broadly and to talk about principles, or to, you know, back way out, zoom way out and say, well, I want to be, you know, kind of identity, uh, words, right. I want to be a good engineer. I want to be a good leader, a good manager, a good father, a good husband. Very rarely do we talk about, okay, what decisions did I make today? Or what decisions will I make tomorrow that will advance that specific thing that I want to be? Right. How, how, do I, you know, we do this with our business all the time, right? How do we measure whether or not this was a good decision? Um, how do we measure whether, and we come up with frameworks to even describe this, right? Okay. Ours, uh, what are the key results of making good decisions for our code? We don't do that so often with our identities or with our legacies or whatever the word is that you want to kind of fill in our purpose, right? How do we measure whether or not we can make a good decision? And I think that's a really important part of the process. Consider ourselves, um, successful in those endeavors. And I think part of that is because it's not about our own definitions. It's about the perception from others, right? So how do I measure if I'm a good father? It's not going to be something that I can say. It's going to be measured by, for example, my child and their future. And I don't know how I'm going to measure that. And so I wonder, you know, if there's a way, for us to, I don't know where that goes other than to say it's, it's hard, right? It's difficult to know how we are doing on these, on these different measures. Um, there are things that I know that I want to do tactically. And it's the reason I went down this track is because you are focused on this at a very, uh, granular level, right? This to do's, there's things that I want to accomplish today. And there are reasons that I want to accomplish those things. And I think that's a really important part of the process. And I think that's a really important part of the process. And I think that's a really important part of the process. And that sometimes those to-dos and the reasons were important previously, and they may or may not still feel as important or as impactful today. Um, I think that to be a challenging thing too, is just being honest with ourselves, that just sometimes things will feel important. You know, think about meetings, you might have a meeting with your team and some to-dos come out of that list. And then maybe those couple of those to-dos are still lingering three months later are they even important anymore can you remove it it's like the uh we treat to-dos almost more in a way of like if you open up like a jira ticket for like oh we should probably take care of this at some point it's we were notorious in our industry for putting off putting off things that eventually be like okay we're just not going to do this because it's a say a jira ticket somewhere that's been sitting around for a while like this isn't important anymore it's it hasn't there's there's been no chaos because we haven't taken care of this but deleting that to do from your to-do list feels like a such a hard weird such a big commitment like not doing this and does that mean is anyone else is anyone else going to be upset that we decided not to do this do we need to communicate to everybody that we decided not to do this and why and then so then you think about what all the other ramifications of not doing does that make you look like you're not doing it and then you think about what all the other ramifications of not doing is you're someone that doesn't follow through on things that you said you would do at one point and so yeah i don't have an answer to that outside of it's just it's an interesting little series of thoughts to kind of navigate it's i think you're right though it goes back to the uh for me it's more but i think it might be easy enough for me to remove my own personal to-do item that i added for myself than a to-do that i said i would do in a team meeting a couple months ago but have since just doesn't feel like it's even important or i'm not even 100 sure what the purpose of it was anymore to go and say yeah i'm not going to do that because i don't want to probably admit to the team that i forgot or don't understand or just also be maybe set an example that we don't follow through on things even though i can probably list out hundreds of things that i said i would do that i've done but that one little annoying to-do thing about updating the documentation about this with a better example blah blah blah so that we don't have that problem again doesn't i don't even remember why that came up on the to-do list so you it's funny actually uh uh right after this uh call i'm going to be talking with an engineer and um this engineer actually uh pointed out to me the idea that sometimes our ongoing tracking of ideas or ongoing tracking of discussions can become a little bit of a prison because we're reminding ourselves of what we once believed was true and it's very difficult for us to change the way we think about things and we're reminding ourselves of what we once believed was and we're reminding ourselves of what we once believed was true and it's very difficult for us to stray from our own opinions we have this idea of um you know staying consistent with ourselves uh even if we even if we uh kind of cognitively or logically can come to the conclusion that we were wrong it's difficult to reject our own uh uh word and so if we don't have a record of it it's much easier for us to say well i never believed that or i never said that or You know, I don't, that's not a position or an idea that I had necessarily. We're going to go this other direction, right? And his point was, and he made it much more concisely. He said that the good ideas will come back. It's true. And this was his kind of justification for not keeping a endless backlog, right? That the good ideas are going to resurface and we don't necessarily have to hold on to them. That if it's a good enough idea, it's going to revisit us whether we want it to or not. And that's a really interesting one. Because then you can, you know, just thinking what's the ramifications of that type of approach as well as then, you know, like I think about, you know, earlier we're talking about maintainable software and like when the team identifies maybe some technical debt that needs to get addressed at some point. And so there might be, you know, different teams at different ways of like documenting that or not. And so sometimes there might be the argument like, well, a pain point in the application will get brought up continuously. And then at some point we'll deal with it. But then at some point you're like, when do we decide, okay, now we're going to document it or we're going to put it on the to-do list or what have you and take care of it. And because you can also set this weird cultural thing where people will complain about things, but then never write it down and say, we're going to like prioritize it. So I think if you figure out where that balance in there is between not putting everything on a list where you have this growing backlog or this huge list of technical debt or things to take care of as a team or. And, and not doing it at all because leaning on the idea that it'll resurface, but like what happens when it resurfaces so much that you need to deal with that. Cause it's always interesting as you go back to also with when you bring in consultants or new hires, where do they go look for like, Hey, this, I'm curious about this weird area of the code base. This seems like a messy thing. And like, oh yeah, we've just, we've, you know, we haven't committed to taking care of it, but it gets brought up. Like, I don't know what. What kind of message that sends to that person either. I don't have the right answer there. It's just, it's an interesting, I think, challenge for teams to kind of navigate, like what the procedures are going to look like and how, how they honor the to-dos and commitments that they're making as a team. Yeah. Yeah. It is a balance and I think everybody has to find their own, but I think one thing is certainly true that if we hide from what we know to be true, then we're bound to face frustration and difficulty. And if we're avoiding things like focus, right? If we're trying to do too much in one day and we are not able to focus, that's detrimental to everything that we try to do. Robbie, thank you so much for taking the time with me again today. I have one last question that we can wrap up with here. If you had only 30 seconds to provide advice to engineers of all backgrounds and of all experience levels, what would you tell them? Give me a second. I'm trying to think about this one. All right. So if I had 30 seconds to answer this question and I've already used five seconds, I would probably advise them to work on a good habit of ending their day with some sort of ritual that involves capturing where they're at, but kind of giving them some indicators on how they should start their next workday so that they can show up with their cup of coffee or tea. Or water in the morning. And they've kind of left themselves a note and nowhere to kind of get up and get going again. So I think that helped reduce your reboot time in the morning by coming up with an end of day. So that way you can hopefully end the day not worrying about those last few little things that float around in your mind later in the evening so you can enjoy your personal time and maybe have a good night's sleep. That is excellent advice. And it's certainly something that I would advocate for as well. Yeah. Giving yourself kind of the, it's like a cheat sheet. It's difficult to reload in your brain. All the, if you think about your brain is kind of a Ram, right? And you've, you've filled it up with everything that happened since the workday yesterday. And you're trying to figure out where, where in the world, where are you at? And you can spend the first two or three hours just getting back to where you were, where you were yesterday. That's great advice. Robbie, thank you so much for, for joining me on developer tea. Yeah. It's been such a delight, Jonathan. Thanks for having me. Thank you for listening to today's episode of developer tea. Another huge thank you to Robbie Russell for joining me on this show, head over to planet Argon to learn a little bit more about what he and his company do. Of course, if you aren't using all my Z shell yet, go and check it out. It's pretty cool. I use it every day. I've used it for years now, and I really appreciate the work that Robbie put into that. Thank you so much for listening to this episode. Thank you to new relic for sponsoring today's episode of developer tea. New relic is observability made simple. New relic.com. And of course it's free to get started. Thank you so much for listening to the show. This episode and every other episode of developer tea can be found at spec.fm and a huge thank you to you for sharing this show for sharing this episode with someone that you believe would be positively impacted by it. That's the thing that keeps this show going. Today's episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.