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 if you're also learning a new technology on the job, and you don't have anyone else helping establish good foundations for what your workflow's gonna look like or your development patterns are gonna be, or making that elusive, another back to the whole theme of maintainable was one of my goals is to fight the big rewrite because oftentimes rewrites fail because people drastic and 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 failed upgrade projects out there. You just heard the voice of Robby 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 subject that Robby and his team at Planet Argonne are experts on go and check out what they are doing head over to planetargon.com. My name is Jonathan Cutrell, you're listening to developer TMI 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 Robby 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, 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 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 resume or your external worth to the company, grows in tandem, right? There can be certainly a dual win scenario, right? That's definitely right. Both slides are happier at the end. But it's important to recognize that it doesn't come by just allowing engineering to chase any direction. They want to chase, right? They being us. We have to be intentional about what we're choosing. It's very easy, like you said, to say, you know what, we want to do microservices because that's a new best practice. All three of us here at this company are excited to do 10 microservices together. And that just doesn't always make sense. 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, 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. I'm too agree with this. Very, very much so. It's a, you know, I was even just thinking recently, is talking to some interns about, you know, look over their resumes and their cover letters to get an idea of how their pitching themselves as they're looking for their, you know, their forever development home as, you know, as they 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 where even like proficiency percentages on specific technology stacks. I'm like, but tell me about how you, yeah, I think you're making a good point about like, talk about the impact 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 of 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, you know, our introductions, our resumes and our interviewing process. You know, I wanna know 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 clients and being able to articulate why you think and believe this approach might be more valuable but not do with an error of overconfidence that this is the only way to do it. This might be helpful but it's kind of like a showing, there's some give and take there and helping guide people towards like let's experiment with this type of approach or something and can be an effective way of doing that too but can you law of course there? But I think the, but I agree, the resumes focus too much on the text acts to some degree and not enough on like the impact you've been able to make. Yeah, I do agree with that and I think that that's, you know, that brings us into and you mentioned 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 not just, you know, 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 explain how you are conducting your technical internships today and why? Well, let's see. So 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 it for really being honest, the confidence and our ability to provide a meaningful internship experience to someone. So, you know, we've, I think since the almost since the beginning of the company and 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 and they reach out and we're like, I don't really know, like I'm busy doing client stuff. Do I have time to the capacity to really be helpful here? And so we kept putting it off and putting it off and like, I don't think this is something we can do until one day someone reached out and I was on a day where I was already thinking about the idea of being a mentor just in general and like how I was being an mentor to people in 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 buy the scenes and our leadership team are 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 ended up hiring them and they worked with for us for like about five years. 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 boot camp here in Portland, Oregon in the United States where part of their curriculum at the end of their, I think it's like 28, 30 weeks boot camp, they get, they place interns, well, 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 to seem like an easy enough type of thing to set up for, we're like, okay, we don't need to like put up an ad and like interview a bunch of people. We're gonna interview like six people and then they're gonna kind of randomly pick two of them that actually get assigned to us. But at least they're getting, six of those people are gonna 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 learned from that over the years and so early on, so let's fast forward to now what we're doing, kind of based off 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, it's a Wednesday that when we're recording on Friday, it's the end of one of our internship or Interhorns 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 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, maybe 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 for 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 end and for the interns in 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 clients in particular that we've been working with for a number of years where we felt like we had a decent and a level of trust there that we could go into and say, hey, we're going to be bringing interns in. We're going to have 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 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 the client. And we'll do that for free. So if you're willing to have a few geuricomic conversations and maybe a phone call or two and talk with them a little bit and give them some feedback at times that would be kind of, that's the trade. So we established that with a number of our clients now where 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 boot camps, it's most likely going to be a scenario where they're learning a lot of building blocks, building new things. And then all of a sudden, nobody starts their first job, these are very rarely and gets to work on a new application. 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 its industry and looking at a really large application. We were like, whoa, this application has how many hundreds of database 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, we'll sign them a few small features or bug fixes is also a good one where like that first week, they're getting up and running with the application and then they start looking at the area code base and they're if you can just see just how intimidated they are, but then you'll see three, four weeks later, they're how competent 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 gonna be like to have that first experience at their first job to help let them know like, okay, I can get through this and we're not, 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 plans scheduled pairing time with our interns so we have a tool kit 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 gonna do on a day-to-day basis but knowing that there's gonna 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 just to see how they're working and they're often surprised, you know, they'll, you know, something they'll talk about with things that they've learned and like, wow, I didn't realize that senior developers Googled so much and they need to look at stuff too 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 gonna 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 if you're someone out there that would judge someone on Googling for the documentation that maybe you think about your priorities there but I think trying to give them, expose them to what it's like to interact with as part of a team so they get, you know, they get the experience of working on pull requests and the cycle there, working on tests and squashing bugs and sending things over for approval, dealing with the feedback. We also try to plan out projects in their internship period that we don't have a high level of confidence that they're gonna be able to complete and we'll tell them, we'll explain that about, I mean, like we share our toolkit with them really 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 experiences is to be able to hand off work to other people and so we're always trying to think of, if you're not gonna, you know, there's a cut off when your internship's gonna end and I know you really wanna finish this feature or project but you're gonna 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 like a branch that sits there and then what ends up happening if there's nothing people can really pick it 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 like prepare work to pass it over to someone is another thing so the, and then, so you know, outside of just like, trying to make sure that they get exposed to real projects and not on like some weird internal pet projects and the other part of that is that helps them really think about how they can promote what they did when they're, you know, when they're applying for jobs and like, oh, I was able to work on this project, you know, like they can drop one of our, you know, 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 have heard of and I help improve the performance of their home page by 12% or what have you. And knowing that they had it, they were able to play a part of that, that's like a good little resume line item to include there. And 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 fill harsh, but on the other end, I feel like it's very kind to set 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, it's never ever going to hire an intern, but as a general rule, no, we, this is a fixed period of time and we're gonna 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 bring in. So we're trying to do this, we're trying to bring in at least eight to 12 interns every year, and we're having to ship that around a little bit with COVID, but as we just started doing it again, we just wrapped up three internships and over the last couple months now. And for me, it's also how 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 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. It's one of the things 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 you might be working with, they're nervous about rejection. And so they will put that off and maybe hope that maybe they'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 think, I want them focusing like, we're here to prep you for your next, your career 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 cheerleading them to a degree of like, helping them like feel confident as they go into interviews. And we've had people get hired before they finish 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 while ago before interviewing. 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 possible. I'm like, they're, that's great. That's, to me, 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 in long term, the payoff for us is they'll, they'll be at some company for a long time. And they'll have some leverages at some point to recommend a company like Planet ArgonneDB, a consultant for them. Yeah, yeah. Absolutely. And I think 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 gravefully, 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 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 valuable opportunity that if it was just that, if you had just the perspective shift, 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 other lens, one of the, at least a valuable part as the owner of my company is that I can, when I, you know, I'll do a quick check in early on within their internship and then towards the end. And 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, it's a try to take it with some screen of self. 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 culture and how the team works together. So in a lot of ways, I think the 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. 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 guests that was just kind of roaming around like you made me feel like I was part of this team. I'm sad to not 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 the, you know, for the team, the expectation for everybody that's, you know, 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 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 onboard 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 Plano-Rorgan 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 helped build them more inclusive and empathetic and thoughtful, mindful culture to the industry. And so I feel like that to me is something I feel like it's all legacy that I can be proud of if it's knowing that we made these decisions and this is a way that the company has been able to help the big picture type of thing financially, can I say? It's great. I mean, it can be, I think that my, 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 an interesting way of professional development that it is kind of helps people in more intrinsic level. Yeah, this is actually, so I'm going to give you 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, like 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 engineers to product 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 concisely convey that message in five minutes? And this is a hugely valuable exercise, even if you didn't have a demo, if you were just required to make a demo, right? Because what it forces, and not in a coercive way, but what it, I guess, is 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 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 dynamic that's set up, right? The full-time engineer and the intern are sitting next to each other, or they're working in the same PR, that intern is going to have a chance to ask questions. And the otherwise junior engineer, who may see themselves at the bottom of the proverbial totem pole, they get an opportunity to actually teach, 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, they're 10 or 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 kinds of what may feel like, if you're an engineer listening to this right now, and you think, why is management making us do this stuff? Right, I just want to go, 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 moves that you could grow in your career with, and those management tactics that you're hearing about, it's largely because of this, because it's going to enable something that, just coding on your own, is not necessarily going to enable. It's such a good point there. You're right. It would be interesting for me to actually go back and track a little bit, but I think 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, and in some ways, you know, 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. It's 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 long-term skillsets, and you said, moving in potentially in a management position or just being a good, 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, schemalist 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 kind of logged issues. This isn't what New Relic does. New Relic gives you better insights because it's higher order software. This isn't just 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 100GB a month to one full access user, head over to NewRelic.com to learn more. New Relic is observability made simple. Makes again a New Relic for sponsoring today's episode of Developer Tea. Because a lot of times teams tend to kind of homogenize. You have the senior engineers kind of work together. 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 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 negative consequences kind of uncomfortable. It's growth kind of uncomfortable. And so I do think that those kinds of situations produce growth for both sides. And it is an investment to your point. It's not a free thing. It's an investment. Robby, thank you so much for joining me on Developer Tea. 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 people would ask you about? I can tell you, I wish people didn't ask me what I did for a living. But because of the question. That was the first question I asked you. 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 it's easy enough for me to report on here as my priorities right now. But I think there's like a certain level of focus in my life right now. I've got a number of different projects outside of being an owner of a business to help lead a popular open source project to running, like having a band and play music. 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 what do you focus on? I think it's always an interesting thing. So it's a question I like to ask other people. That is a difficult question to answer, I think, for a lot of people, because they think categorically. What do you mean? What are my focus on at work? What are my focus on internally? Where is that focus at? So I'm interested. 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 in terms of your focus? And what are you focused on right now? There is overlap in especially, you know, in the time of COVID, where the barriers for like physical space, separation of, you know, I've 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're not all able to go practice together and feel safe doing that. But so focus is, you know, I think it's interesting the, so great question. So jokingly say that the I am focused on trying to find barriers, I suppose, to create more separation right now in this, this world where separation is hard to find. So like actively, I think the last several weeks it's been, my role has shifted recently. And 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 inside of nine to ten. So that's just like a context, like a switch that I'm navigating. So I'm trying to figure out my new focus looks like over the next, you know, quarter and trying to define those barriers. I'd 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, you know, show up and be present for that. And I don't let, I try to be very mindful in how 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 so she's been doing your whole adult life. So, yeah, I'm focused on trying to like navigate that to create some boundaries, not because I feel like it's bleeding over necessarily too much. It's just wanting to show up in each of those contexts and feel more focused within those contexts, rather than feeling like, okay, I show up in 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 too blurry, and that's creating maybe a difficult level of finding some focus within each of those confines. This is a problem that I have as well, and I'm interested 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, and I'm gonna stay at home. I have a bunch of these home projects and things like that. I feel perhaps more busy than ever, partially as a parent, as staying a home parent during a pandemic. But I'm wondering, you know, do you think that this separation, we know that we're not good at multitasking, for example, right? That's not gonna happen. I'm not gonna 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 this separation will give us a sense that we're able to get more done, right? So that's maybe one option, and I'm gonna 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 gonna go with the ladder 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 or for other people, but for myself, you know, I've got big to-do lists, and I can go through them 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 do is done today. It's more about that I think in this space right now as we're in the US, where there's a lot of things going on right now, and in the world as well. I think there's like a hard part for me right now is 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 things 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, you know, is my office going to open back up again? Do we get rid of our lease? Those are big business decisions that, you know, I'm kind of having an owing 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 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, it's less about, what can I cross off my list and more about, how can I 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 at Don each day, because I felt that way six, you know, more than six months ago, I was already felt that way about my to-do list. So, I think I'm just being honest with myself about that. So, the last thing you said right there, being honest with yourself, I think this is actually the problem 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 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 days are passing. And so, I have to choose sometimes, 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 almost a, it's like, procrast. It's almost a tension 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 tricky one where you're in that state and when you're kind of like having a humming over this or that or even, 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 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 our subscribers credit for it necessarily at the end of the day when we looked back at the checklists of all the things you did. Really, unless if you do that, that can be helpful. I'm like, okay, I always started off 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 am needing to carve out some more space for the unexpected things that may pop up work personal and whatever you that will pop up in the day of the unknowns, right? And so, we don't know, we don't know. And so, not everybody can just kind of close off to the whole world right now. And so, and something that I've been interested in, but I can't remember who said this, but I feel like I heard something or read something a couple years ago where some advice on how to prioritize things or how to make that decision. It's like, how would you, you know, it's always, I think maybe one way to like, illustrate this, like if you were, if 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 help them answer that question? And so, you could think about it in that way and then, you know, think of like, well, how would I 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 struggle with that sometimes is 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, 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 visual reaction to it, then I'll know that that wasn't the right answer. And I'll go the other way. So, I think it's like the whole flip of coin type of thing, but maybe just having to talk out loud as someone else can be 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, and listing these things out. Because like you said, there's these implicit things that end up landing on my to-do list. And it is funny. 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 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 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? How do we measure whether, and we come up with frameworks to even describe this, right? OKRs. 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 consider ourselves 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 is a way for us to, I don't know where that goes other than to say, it's hard, right? It's difficult to know how we are doing on these, on these different measures. There are things that I know that I want to do tactically. And it's, the reason I went down the track is because you are focused on this at a very granular level, right? This to-dos, there are things that I want to accomplish today. And there are reasons that I want to accomplish those things. 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. Yeah. 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. And they even important anymore. Can you remove it? It's like the, we treat to-dos almost more, in a way of like, if you open up a geartick, or 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 geartick at somewhere that's been sitting around for a while. Like, this isn't important anymore. It has it. There's been no chaos because we haven't taken care of this. But deleting that to do, if we reach a do list, feels like such a hard, we're such a big commitment. It is like not doing this. And does that mean, is anyone else, is anyone else going to be upset that we could 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 someone that doesn't follow through, on things that you said you would do at one point. And so, I don't have any 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, 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 had it for myself. Then it to do that I said I would do in a team meeting a couple of months ago, but I've since just, doesn't feel like it's even important, or 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 and 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 the better example, blah, blah, blah, blah, so that we don't have that problem again. I don't even remember why that came up on the to-do list. It's funny actually right after this call, I'm going to be talking with an engineer, and this engineer actually 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 stray from our own opinions. We have this idea of staying consistent with ourselves, even if we come cognitively or logically can come to the conclusion that we were wrong, it's difficult to reject our own word. 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 that's not a position or an idea that I had necessarily. We're going to go this other direction, and his point was, and he made it much more concisely, he said, that the good ideas will come back. That's true. This was his justification for not keeping an endless backlog, 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. That's a really interesting one, and then you can just thinking, what's the ramifications of that type of approach as well as then? Earlier, we were talking about maintainable software, and when the team identifies maybe some technical debt that needs to get addressed at some point, and so there might be different teams at different ways of documenting that or not. Sometimes there might be the argument that, well, a pain point in the application will get brought up continuously, and at some point we'll deal with it, but then at some point, 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? 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 prioritize it. 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, things to take care of as a team, and not doing it at all, because leaning on the idea that it will resurface, but what happens when a resurface is so much that you need to deal with that. It's always interesting as you go back to it also with when you bring in consultants or new hires, where do they go look for, like, hey, I'm curious about this weird area of the co-base, this seems like a messy thing. Oh, yeah, we've just, you know, we haven't committed to taking care of it, but it gets brought up. I don't know what kind of message that sends that person either. And I have the right answer there. It's just an interesting challenge for teams to kind of navigate like what that procedures are going to look like, and how they honor that to do is in 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're not able to focus, that's detrimental to everything that we try to do. Robby, 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? Let me second to think about this one. All right, so if I had 30 seconds to answer this question, and I'm 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 work day, 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 in no way 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 the end of day. So that way you can hopefully end the day not worrying about those last few little things that flow around in your mind later in the evening, so you can enjoy your personal time. Maybe have a good night's sleep. That is excellent advice, and certainly something that I would advocate for as well, 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, it's kind of a ram, right? And you've filled it up with everything that happened since the work day yesterday, 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. Robby, thank you so much for joining me on Developer Tea. Yeah, it's been such a delight, Jon. It did. Thanks for having me. Thank you for listening to today's episode of Developer Tea. Another huge thank you to Robby Russell for joining me on this show, head over to Planet Argonne to learn a little bit more about what he and his company do. Of course, if you aren't using Omizze 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 Robby 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 this show. This episode and every other episode of Developer Teacan 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 Cutrell. And I'll be helping Patroon until next time, enjoy your tea.