This week we have Robby Russell, the creator of Oh My ZSH, and CEO of Planet Argon. We talk about the history of Oh My ZSH, the history of Planet Argon, and the future of terminal environments. - https://ohmyz.sh/ - https://github.com/robbyrussell - https://x.com/robbyrussell - https://robbyonrails.com/ - https://www.planetargon.com/ Episode sponsored By Clerk (https://clerk.com) Become a paid subscriber our patreon, spotify, or apple podcasts for the full episode. - https://www.patreon.com/devtoolsfm - https://podcasters.spotify.com/pod/show/devtoolsfm/subscribe - https://podcasts.apple.com/us/podcast/devtools-fm/id1566647758 - https://www.youtube.com/@devtoolsfm/membership ## Sections - [00:00:21] Intro - [00:05:22] Starting Planet Argon - [00:10:58] Ad - [00:12:36] The Birth of Oh My ZSH - [00:21:12] Challenges and Growth - [00:38:19] Handling Open Source Contributions - [00:45:13] Creative Plugins and Customization - [00:48:29] Planet Argon and Client Services - [00:52:42] Keys to Maintainable Software - [00:58:38] Future of Terminal Environments - [01:04:34] Conclusion and Final Thoughts ## Transcript [00:00:00] I think we made it feel less intimidating for people because the UX of a terminal, most shell environments haven't changed in 30, 40 years. You install bash, Z shell, fresh install. It's like a dollar symbol. You're like, what the. Hell is that? #### [00:00:21] Intro Hello, welcome to the DevTools FM podcast. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co host Justin. Hey everyone, uh, we're really excited to have Robby Russell on the podcast today. So Robby is the CEO of Planet Argon. ~~Um,~~ and you also are the creator of OhMyZSH, which I'm really excited to talk about. Uh, but before we dive into that, would you like to tell our listeners a little bit more about yourself? I am a, so I run a CEO, I'm the CEO of Planet Argon and which is a web development software consultancy. We help companies, primarily for Ruby on Rails, help make their applications better and more maintainable. Um, I also am the host of the [00:01:00] maintainable software podcast, but yeah, I've been a software engineer for, I don't know, 21, 25 years or give or take now. And yeah, I'm happy to chat with you folks. Yeah, so I, I found it fun. I was looking into your background. Uh, I love to see when people are both, uh, like high school dropouts and then they got directly into coding. So can you, uh, tell us like how you got into coding and how you got into like the space you are today? Sure. It's a long convoluted story. The short version is as I, as a, as a kid, I was always, I always grew up with computers. Um, I'm from California, the Bay Area originally. And my dad worked in just recently retired in Silicon Valley and he worked in hardware and he always encouraged me to get into software. And I actually thought that that was sounded like the most boring thing I could possibly do as a career. So I rebelled and decided I'm never going to do that. I do not want to work in computers. That's how we used to talk about it back then. And this is the mid nineties. But I also wanted to sell stickers and I had a mail order sticker [00:02:00] business and I used to do this for like punk bands, things like that, and political stickers. And people literally send me a few dollar bills in the mail and I would then send them a couple of stickers back in the mail. Charge a dollar a sticker and I wanted to put that on the internet. So when I finally started getting into doing some coding to do something more dynamic, like more than just having, say, a web page, it was, how do I make a web page that could allow people to fill out a form, request some things. We didn't do like credit card processing or anything like that at the time, but at least it would save some data to a text file on the server. And then I would SSH or not SSH, but FTP into a computer server somewhere and check to see if anyone placed any orders. Usually not. Pulled down a, you know, a text file or a CSV file, but it would also do things like send an email saying, here's, here's Robby's information. Here's how to send them. Here's where to send your dollars in the mail. And then he'll send you some stickers. So I, that was like the first building blocks of like, I had a very specific thing that I wanted to do and I was like, how do I make that happen? So I just looked online, look for, and this is like online back then, but like [00:03:00] finding Perl scripts and also use some other things like Microsoft front page at one point and other tools that existed way back in the mid to late nineties. But that kind of, but I had all these different types of projects. Like I also had like an online zine for punk music and I wanted to put that on the internet because it was a paper zine. So I was always trying to figure out how do I replicate this stuff on the internet? How do I build community type things on the internet? And so I just kind of like picked up on these little skills over several years. This is maybe six, seven years before I ever got paid to actually work on someone else's software project on the web. But, and then at some point it was a lot of those projects were like finding other like You know, open source projects or example code that you can copy and paste, modify it. And that's how I learned to kind of do a lot of those basic, a lot of those fundamental programming skills that kind of built up in that sort of fashion. And then eventually I bought myself like a, how to do like how to build a MySQL database. So I bought like a MySQL database. Books. I taught myself SQL. I tried doing some stuff with access as well. And I also, cause I was always trying to [00:04:00] figure out how to do stuff with the Microsoft stuff and do stuff with open source technology in parallel. But those first several years was just kind of like building up all these little things. And then eventually I got a job working at a company doing like tech support. And then I started automating some stuff and put together a company intranet using an open source PHP framework. And then I started building some little PHP tools for the intranet. And then another department at the company that I worked at, this was back in 2000, they noticed that I was doing some web stuff. And they're like, Hey, we actually have a whole department that where we have programmers that do that. Why are you, that should be us doing that. Why are you doing it? And they're like, do you want to come work with us? And then you can do that stuff. As well. And so that's, so then I learned, I had some people that I got, um, that were basically, it was kind of, I guess I was a junior developer and they were like, come over here and work with like the web team. And then I started actually like learning more things from my coworkers. They were teaching me things and that was, they were a ASP Microsoft shop. And so I was. Being taught like, okay, here's how to do [00:05:00] stuff in ASP. Here's Microsoft SQL servers, store procedures, yada, yada, yada. And then I would go home and like, how do I translate what I learned at work today with PHP and MySQL, because I was really excited about open source stuff. And those building blocks just kept building up over several years. And eventually I was like, I think people might pay me to do this for their projects. And I don't need a Microsoft license because I can use this open source stuff. So let's see where that goes. #### [00:05:22] Starting Planet Argon And that's when I started playing Argon in 2002 as like a freelancing thing to do on the side. And it took me a couple of years before I was able to quit my job and do that full time and become an agency. So that's a, it's an awesome story. I feel like starting an agency early in your career, especially as like a, well, I mean, I guess it was a consultancy before it was an agency, but like starting that early in your career is a, is a big step, even if you're kind of like moonlighting doing it. How were the early years and then how have you been able to make it sustainable over time? The fun thing was that in, so in 2004 is when I quit my last [00:06:00] job. To do Planet Ark on full time and it was me and a designer and we were working together on a bunch of projects She had her own web design business and I did the development stuff. So we collaborated a lot and So I got my last job because I was thought that I go I'll just work for myself part time and then I'd focus on my focus on music which is actually the thing that I would have loved to have become like a You know, uh, professional musician one day. Um, sidebar for that for maybe another time, but I, I started to actually, so the funny thing is like, I, so I was doing freelance stuff and then in the late 2004, I applied for a job on Craigslist for a PHP job here in Portland, Oregon for a company called CD baby. I don't know if you've ever heard of CD baby, but they're. They were, they, you want to be shaking your head. Like, I have no idea. The other one's like, Oh, of course, a CD baby was the largest online records shop on the planet for independent musicians. And like you would literally send, they basically, if you were an independent band, you would [00:07:00] ship them a small box of CDs. They would manage inventory and they would ship it out to people. So they would manage all the fulfillment. And this is back in like the early two thousands. So the, uh, I was getting, potentially going to get hired to work on this, To be a PHP developer there. The owner of that company, his name's Derek Seavers, kind of well known person in the, uh, in the tech world to some degree, maybe less so these days. But, uh, he offered me a job verbally and then said, great, we'll sign you. So I thought I was actually going to get a job again. And I was going to work at this local music company and like meld my open source, love PHP stuff with working with, um, a music company here in town. And as I was also a musician, so I'm like, this is a great opportunity. He came back from a holiday, winter holiday break and said, Hey, I got stuck in a blizzard. And I started teaching myself Ruby. I had this Ruby programming book and I want to rewrite everything in this new thing called Ruby on Rails. And I was like, Oh, okay. So he's like, so I'm going to rescind that job offer, but if you can pick it up, I will hire you in a few months. I found this other guy that lives in San [00:08:00] Diego, and I'm gonna move into Portland and he's going to come help me start rewriting everything in Rails. I was like, Oh, okay. That was not exactly how I thought that was going to go, but I use that as a motivator, but like, I guess I should play around with this Ruby on Rails thing more. I had seen a video about a month before created by DHH, um, about how to build a blog in whatever, 10, 15 minutes or whatever. So I started learning Ruby on Rails, teaching myself it and became an early adopter of that. And I started a blog called Robby on Rails. And then all of a sudden my life changed. I went from, so when you come back to the original question of like, how did you go from an agency thing, it was like, I was doing work for myself and I tried to get another job, started doing Ruby on Rails, and then within a few months, people started reaching out to me like, hey, will you help me with this, because I started blogging very actively. This is the most, probably the most prolific blogger in the Ruby on Rails community that year, in terms of volume. And. The, I just, I had all these projects starting to come my way. So I was doing a bunch of like, I was like, Oh, this is interesting. So when Derek from CD Baby reached out to me like six months later, like, Hey, do you, I saw you're, you're learning [00:09:00] Rails. You want to come work for me? I was like, I have too much work now as a freelancer. I'm going to see where this goes. And I started getting calls from pretty large companies down in Silicon Valley. Like, Hey, will you come interview us? Uh, some of them are still really, really well big. Name companies. I never, I didn't really take them that seriously. I also didn't want to work on a cubicle in Silicon Valley. And that was like a thing that I was really trying to avoid as this DIY anarcho punk kid that lived in Portland. And so I found myself taking all these projects were coming and it was like, what do I do? Like, how do I, some of these projects started to get too big for me just to work on it by myself with my designer. And so, but I would go to the local Ruby meetups and I knew a bunch of people that love working with Ruby. And that was like their fun hobby project thing to work with, but nobody was hiring Ruby developers. And so I was like, what if I just hired these people? To come, Hey, want to come work with me? And we'll see where this goes. So that was basically the decision was I've got some, I got a really large project that popped up. It was a pretty for a new startup. And then another one popped up really [00:10:00] quickly for this other company called Nike that wanted to do something for this big project in 2006 and they wanted to use rails and I was like, well, what the hell, I guess I might as well give this a go, let's see what happens. Worst thing. I just go back to being an independent freelancer. If this doesn't, if this blows up. So. Kind of just took the chance and we said, okay, hired eight people to work on these projects, like almost overnight. And then that's just, we've been this company doing that ever since. So yeah, it was never, it was not what I had set out to do. It was very much opportunity driven, right place, right time. And being ignorant enough to say like, what's the worst that could possibly happen? You could lose a lot of sleep is like the moral of that story, running a company. Yeah, I've been able to keep doing that since, since then. I think another good takeaway from that is that learn in public is just so valuable in so many different ways. Like, if you hadn't been a prolific blogger, just like blogging your experiences about Ruby, it probably would have never, never, never led to those things. No, probably not. #### [00:10:58] Ad We'd like to thank our sponsor for the week [00:11:00] clerk. Clerk is an all-in-one user management platform that makes adding authentication to your app. A breeze. Whether it's as high level as adding some components to your app to support login. Or if you want to get in the nitty gritty of it, build it all out on your own using their SDKs, they got your back. With off, there's so many different ways you could log in. Literally new ways are introduced every year. This year, we got past keys. With clerk you don't have to worry about any of the details of those things. You just log into your account and activate the things that you want to use. Personally, I've used it at Google auth, Facebook, Spotify, so many different things, and it's all just so simple. But the best part about clerk is they're awesome free tier. With the free tier, you get 10,000 monthly active users and they also have this awesome program where if your app pops off and a bunch of use it, people use it for just one day and never log on. Again, you don't pay for those users because they're not really your users. I think that's really cool. It also just doesn't stop at login. You get a bunch of [00:12:00] things like user pages and other user management things. If you want to learn more about clerk@overdueclerk.com or if you want to get a better view of the product or the company. Go head over to that episode where we interviewed co-founder Braden. We talk about where the product's been, where they plan to take it. Like adding Stripe. Are you tired of hearing these ads become a member of one of the various channels that we offer it. There you'll get the episodes ad-free and a little bit earlier. If you want to find another way to support the podcast, however, to shop.dev tools.fm. There you can buy it. And help us keep going a little bit longer. And with that, let's get back to the episode. ~~Um,~~ #### [00:12:36] The Birth of Oh My ZSH so, uh, let's, let's switch gears a little bit and start talking about, oh, my ZSH. Uh, so for people who don't know what, oh, my ZSH is, let's set the stage a little bit. What is, oh, my, my ZSH? Okay. Well, I like to think of it as a playground. Yeah, it's a playground for your terminal, I suppose. The kind of a simple way I was like, [00:13:00] basically, if anyone's familiar, assuming most people listening are familiar with terminals, it's It's, you know, it's a framework for managing your ZShell configuration and it comes bundled with hundreds of plugins and themes, probably too many, but it does. And, and it's been, it created that nearly 15 years ago and first released it and has had contributions from, what is it like nearly 2, 400 developers have code contributed to the project. Again, it's, it's kind of a big playground and yeah, it's, it's awesome. It's kind of like what it is. Um, if you're curious about how it started, it was because my co workers were still, I had started using Z show about two years before I related, released Oh My Zsh or even thought to create the thing. But it was basically a combination of a bunch of little snippets and code sharing things that like peers had, we've been sharing on different, we used to have these websites, kind of like a GitHub gist, but called pasty back in the day and like other places. We used to share things over IRC channels. We'd be like, here's how to do this. And here's how to get some autocomplete functionality for this stuff. [00:14:00] And so for about two years, I was just like really enamored with, with a Z shell itself and give me a lot of cool autocomplete stuff. And then Git was this new thing at the time as well. And so it was. You know, able to make my prompt have like my local git branch, which in local branches were kind of a new concept at the time. And just like those types of things that also had like some auto completion stuff for over SSH and SCP, which was another kind of really useful thing. Cause I used to manage a lot of servers. Um, part of our business used to also be hosting servers and stuff like that, but the, um, So I kind of combined up, you know, built up all these things and I had built up a huge reliance on a lot of the aliases and shortcuts, like muscle memory. And so I would be pair programming with my coworkers and I'd be at their computer and I'd be like, Oh, what's the, how do you write? What's the thing? And I remember like in my brain, it's like three characters does this weird gig, you know, archaic get commit or get, uh, get command. And so we're constantly looking at like the manual and get manual and stuff like that. And I'm like, how, what, how do you do that? And I'm like playing with the [00:15:00] syntax and I'm like, which. I remember one day talking to one of my coworkers, same as Carlos. And I was like, Hey, would you, why don't you just use Z shell? And then I give you, here's my config file. And then like, it'd make my life easier when I'm helping you, uh, uh, selfishly. And then he was like, I don't know, like, I don't really understand what your config file is. configuration does. And I was like, and admittedly, I probably only understood about 40 percent of it too. Uh, because I had copied and pasted and shared things with a bunch of peers, you know, and IRC channels and stuff like that. And so I didn't think like me trying to walk them through the config file was going to be all that productive. So after battling this kind of problem, a couple of other, my coworkers did start using my Z shell configuration. Oh, my Z shell was not a thing, but it was just, so one weekend I decided to I was going to document my config file and I was like, I'm just going to add some notes, comments, explain what things do. And I'm going to kind of try to make sense of it. So I was like pulling up the Z shell configuration or the Z shell website for their documentation, trying to make sense of what I was actually working on. And like, I started [00:16:00] reorganizing things and I'm like, I should probably put this in a repository and do some version tracking in case I mess it up or people want to make changes to my coworkers. So I was like, I guess I'll put it in a repository and. I just named it on my Z shell. I'm took that real, I think there's really, really large file and broke it up into several smaller, slightly less messy files through the repository. I called it on my Z shell about a month before I had worked on a project with another coworker called Oh my science. I just kind of repurposed the name and through Z shell. Cause I'm like, it's my Z shell configuration put together. Read me like, here's how to install it. I shared that with the team on Monday and our, whatever I forget what tool we use campfire or whatever. Uh, chat tool we had at the time and everybody installed it, installed it, and I won victory. So that's how it makes you so for first started, I literally just wanted my coworkers to have all of my shortcuts because I had all this muscle memory. And then the next day, one of them asked, how do I change the colors? And it was like, why would you want to do [00:17:00] that? Uh, and they're like, well, I want to change the colors. And so I was like, well, okay. So I showed them, here's the file in the repository. You can change, like change this to your heart's content. And then other way, other in parallel, other coworkers wanted to start adding their own aliases for things like, oh, I do this and this is cool. And here's a little, some other little shortcuts you want to do. So they started contributing some ideas, but then that one coworker, Gary, who wanted to change colors had a problem because he couldn't do a get pull and get back. Push cleanly because he had made changes locally. And so he was like, how do I manage my changes? I'm like, well, this is kind of messy. How do we, what do we do? And so I sat there thinking, and I was like, Oh, this is kind of like a theme. Maybe. So I created a directory called themes. I took my file. My version called it Robby Russell. And then there was a Gary Blessington one, and I made it a configuration. The mine's the default. And if you want to use a different one, you can toss it in that directory and call it whatever you want. That's how themes were [00:18:00] created. So it wasn't something I thought of. Um, and then I shared this on my blog and other people started contributing. About a month and a half or so later, some developer reached out and said, Hey, I, um, I noticed a lot of, I really liking the tool, but I noticed that it assumes you're kind of, that you're a Ruby on rails developer, but I'm a Python developer, how do I get rid of all this Ruby stuff? And I want to add some Python stuff. And I was like, Oh, that's a good question. I guess I can just move all this stuff and to some plugins, we'll call these plugins and you're going to have like your Django, a Python one. And I'm going to move all the Ruby stuff into a Ruby one, and then we'll just kind of clean it up that way. So that's how plugins came about. So only Z shell, all the things people know about it, it comes with all these plugins and themes. We're not an idea that I had when I first created it. I literally just wanted a few of my coworkers to have my configuration file, all my shortcuts. And then it became this playground as people started to contribute and share their own ideas. And that's how it's evolved and continues to evolve to this very day. That's, [00:19:00] it's really funny how it started as, oh, I don't trust this configuration file, and then you added a little bit of abstraction on top, and they're like, oh, a tool I can install, I'll install that. Exactly. It's really, it's, this is such a classic story for a lot of like, unintentional large open source projects. It's like, I had this idea one day to throw together the script, people like that, and then they asked for this other thing and then like, you know, months later you have this, you know, huge sprawling thing. ~~Uh, uh, oh, my Z, uh, ~~oh, my Z at ZSH is actually really cool because for me, Discovering your tool was actually the start of my terminal, uh, like crafting journey, Me too. Yeah. So I was like, got into Z shell. And then the first thing I did was like, okay, I need to like install something. I think you need to like change things and then discover your tool. And it's really like taken off from there, but, uh, it's yeah. Phenomenal [00:20:00] work. And you know, it has a huge legacy now. I think of just engineers customizing their, their workspace. ~~Hmm.~~ trend setter and I didn't even realize it. I find it funny that all of these, like, first names are still in the themes file. Like, Gary's still there, still kicking after 15 years. Yeah. Um, I was recently having, I was giving a talk on this recently at a conference and I was doing some research on back on like some of those early things that I couldn't remember which coworker it was that asked for the color change. And then I was, I thought it was Carlos, but it actually was Gary. And I was able to look at the get history and find that out. And then I was asking him and I went and looked at his version. I'm like, it's not all that different. He's like, yeah, I can't stand your color. He's still to this very day. He's like, I hate your color choices. And I'm like, I'm like, you know, it's like one of the most common. prompts that most, a lot of developers use now. And it's little did you know, so I'm right. I think I I'm, I'm still right. So anyhow, it's, I think my, my prompt is beautiful, And you can now prove to him that yours is better [00:21:00] through usage statistics. but it was default So people didn't choose it. I mean, they did and they didn't. So how has the. the project grown and developed since then? #### [00:21:12] Challenges and Growth Was there any like point in the early life where it really, really took off? I mean, I know you talked about like writing the blog posts and getting people like seeing it and giving feedback, but was there like a moment in time where you're like, Oh crap, like this is big. Yeah, there's a, there's a couple of points I often reflect on. I mean, you know, I mentioned my blog earlier and I, you know, I was thinking like, what are some of the theories about why I think it's what's contributed or led to the growth of the project and how it's become one of the most air quoting for those not visually seeing this right now, how popular of a product it is, is one of the most starred projects on GitHub and has been since like the early days of GitHub. So. I think one, it was a good timing, you know, ohmyzsh, I released it kind of just caught the [00:22:00] wave as both Git and GitHub were just kind of the software community was kind of wrapping their head around it. And so GitHub showing like popular projects and us popping up, I think it just made people more curious, like, what is that thing? Um, and then it also kind of mentioned that it had like your local branches. That was like another, just kind of like weird thing. I think just like that. I didn't. It was useful in that sense. And it was really, so another thing was also, it was really easy to try, you know, like within the 30 seconds, anyone pretty much could like be using it because everybody's computer running on Mac or Linux probably already had Z shell installed, so you didn't have to. Do that people have, you know, I think people sometimes ask like, Oh, why aren't you using fish? I think fish was only around for a couple of years at the time. I don't think I even heard of fish for a couple of years after I first created Oh My Zsh. I've still only played with fish for maybe like 15 minutes. And I'm like, yeah, this is interesting, but I, it's, I, I'm not out of a loyalty thing to Oh My Zsh or anything. It's just more of like, I didn't, it does what I need to do. And I'm, I'd probably spend a lot less time in the terminal nowadays than I [00:23:00] did 15 years ago. But. As far as like there's inflection points. I remember when, I remember I was getting, it was on the change log podcast. Like I invited you on the change log podcast 2011. And at the time I remember thinking like, wow, like change like they want to have me on to talk about this. And I had been battling to keep the number of open pull requests under a hundred, which is a hundred open pull requests to keep updated on, you know, like it was just so many people contributing things and it was like, this is so much for myself. to navigate. No, it's funny. I think now it's hard for us to keep under like 300, uh, open pull requests on a regular basis. So that's, but that aside, but I think it was always like this interesting, there'd be these waves of like, all of a sudden a bunch of activity would pop up every few months. And I was like, what, what happened? I'm like, someone blog about it. Like who, who, what happened? Cause I wasn't like actively promoting it that much out of set of just being playful on social media and occasionally blogging about, you know, some new updates or something. But [00:24:00] I would often hear that, like, like the stories I would hear would be like, Oh, like, uh, a coding bootcamp, like all their, they basically asked all of their students to install it on day one. That would be like, just part of, like, the setup process or someone would be at a conference. And someone would be giving a talk and a demo of something and they were using Oh My Zsh, but then they didn't talk about it. They just were using it. And someone during the Q& A session would raise their hand and be like, Hey, what's that? How did you? What's that thing you're you were using? How did you make your terminal look like that? And they're like, Oh, I use Oh My Zsh. And then all of a sudden, like hundreds of people would be like, what's that? And you. So that, those stories kept popping up and it was people outside of the Ruby on Rails community, because that's the community that I was a part of and still largely a part of. So it was like, it kind of spread out into this like over and over and over. And it just, I don't, it's such a weird thing to be like, how did, how did you even hear about this thing? And, you know, it was like my little small little, you know, Ruby on Rails was like a pretty popular thing at that point in time. And like my blog was popular within that community. So it was [00:25:00] easy to get some usage in that community. And, and get broadcasted there, but to have it evolve in these other communities, I had nothing to do with whatsoever. It was something I didn't really know how to reverse engineer that outside of being like, this is the stuff that I heard about after the fact, like, Oh, I heard about it here. And, you know, just before we, you know, you were mentioning like how as a junior developer, you know, you're learning how to, you know, your first experience with the terminal. I hear this story over and over and over. And it's like, Oh, it was, you, I kind of attributed this. Like, I think we made it feel less intimidating for people because the UX, the UX of a terminal, most shell environments haven't changed in 30, 40 years. You install bash, Z shell, fresh install. It's like a dollar symbol. You're like, what the. Hell is that? You know, like, I don't, what do I do? Or how do I not break my computer? I can click around and like, it'll prompt me to do things. And it's like, are you sure you want to do this? And, but a terminal, you're like, someone just said, aren't like, what does that mean? [00:26:00] Remove like dash RF. Like, I don't know. I'm going to break everything. And which is also a challenge that, you know, it comes to running a project like this and we can dig into that, but. It just like the UX never really changed and still has it like it's like your first version like if you ever think back to if you use DOS back in the day, it's still like, what do I do? Like, it doesn't really like guide you. It doesn't give you much feedback necessarily, just if you, if it was a successful command or not. And so I think inadvertently, Omazeashell took all these kind of like nice little things and Baked it in and then people just felt like they have some sense of control over environment they might otherwise feel intimidated by and then immediately maybe feel like a little bit of like kind of a badass because now they Feel like I am look I'm it's like it's not it's not it's not like in the hackers movie exactly But look look at look how cool my environment looks like I finally I'm getting validated as a as a real programmer. The colors are really inviting. Like every time I get on with a junior [00:27:00] developer and I see their terminal and it is just that blank dollar sign, I'm like, how do you live like this? And I install it for them. But all of those little paper cuts, they really add up and they make the, they make the terminal such a more inviting place. When you have just this like visual feedback instead of like staring back into the past into what we're emulating instead of like making it a good thing. another thing that I You Believe helped the project, which was a contentious thing for some people, but it has an auto updater built into it and which might not seem like that novel of a thing, but I'm going to pat myself on my back a little bit. It was kind of new for terminal stuff. Back then when I first did it, I thought that people would install, you know, I'm air quoting install, which basically just taking this config file and director bunch of config files. They put it on their computer and then they would never update it because you'd have to remember to go run a manual update or something and you have to then you'd have to go pay attention to a project and if you're not spending all that much [00:28:00] time Tracking a change log on some open source project. You're not going to think to go update it and get all your new updates. So if you want performance updates, new plugins, improving things like adding new aliases, I actually thought that that would, because I was actually witnessing that with my coworkers, because I'd be like, Oh, like, Oh, I fixed that. And they're like, Oh, well, I didn't, I'm like, did you run the get pull yet? And they, they're like, no. And I was like, well, this, so even using them as like my little test bed, we'd like, like someone would be like, Hey, this thing's really weird or it's kind of broken in some situations I'd fix it. I'm like, Oh, you have to manually run this thing. And I was like, how can I simplify this? And so I built a wrapper because it's just uses get under the hood. That's basically all the updates are managed. If it doesn't get cloned and then it doesn't, you know, It's a git pull from the main branch every so often. So I built a wrapper that just prompts users at the time. Basically, every few weeks I ask users, Do you want to check for new updates? And it just does a git pull. And then we make the format of that information look kind of useful and pretty, um, as well. And, um, [00:29:00] That might not seem like that big of a deal, but what it also does it for people that are learning how to use Git already, it's like already kind of using the same sort of tooling. And it's the same sort of a user experience you have when you're working on collaborating with other people, like your coworkers or your classmates on a Git project, Git project. It's, it's the same sort of experience. We have added a couple of little. extra UX thing since then, but that part was there. And so you would see files change. You'd be like, so I think having that show up in your terminal and seeing that, Oh, there's new plugins. I can see that's a plugin. Cause it says it's X, Y, Z to a plugin. Like, what is that? And I think that would make people more curious to go check out new plugins or there's a new theme that they can try. Um, and then it would also have an opportunity to show my amazing ASCII art skills and then pitch that you can go buy stickers and t shirts from us. Uh, But I think that just kind of reinforced that there's this thing, there's this kind of like community that are constantly contributing things to that. And so when you got a couple [00:30:00] of thousand people contributing code, you know, that usually has updates every few weeks. And so you're like, Oh, there's this thing that's, things are happening. And I'm part of this. Community in a way. So I think that was another key thing to the success. Some people hate that we had to add the ability to disable that, but for the most part, I think I like it. And I think it's, I think it also contributes to just feeling like you're part of something a bit more than just by yourself, Yeah, that's, it's a fantastic feature. Uh, and. Now, all of the CLI tools that I really like really, really enjoy, like things that I feel like I can't live without, have that same sort of feature. ~~Uh,~~ so, uh, have you heard of Etuin? Uh, I think I'm saying that correct. It's a history plugin.~~ Uh,~~ Uh, so yeah, it just like gives you a good like history anyway, fantastic. Um, and it, yeah, it does like, let you know when there's an update available. Uh, but it does it very unobtrusively. So it's like you [00:31:00] continue to use the tool and let you know, uh, like Dino CLI, just, I don't know a lot of the tools that I use these days, like do a good job of just saying, Hey, like giving a nudge, not even like trying to like, really like force it um I want to, uh, sort of ask question related to kind of one of the things you said there at the end, uh, you know, The terminal is an interesting thing because like software developers tend to be very, very, very opinionated about the terminal environments, almost like more so than, you know, the other parts of their, you know, setup. Uh, at least it's been my experience. And, you know, People can be very loyal to their tools and stuff. So I'm curious if there were any other, like maybe unexpectedly challenging things that you had to solve for like the, Oh, people really hate this update thing, but why, you know, it's like, what were the other hard parts of like building something for the terminal? [00:32:00] couple of things that come to mind, you know, there was, there was a fork of Oh My Zsh at one point. And so, and it's called presto and there was a time when. We were trying to, we, there is concern that we were basically overloaded with too many plugins and themes. And I, I have varying contradictory thoughts in my head about whether that was a good idea or not to accept so many things into this playground. Um, and at the time. Someone had proposed an idea for coming up with a plugin management system that would rely on, if anyone's familiar with Git submodules, was going to be the tooling choice for that. And this was maybe 2000, uh, what year, a couple of years into the project. And so we were going down this path, testing things out, and we were going to basically move plugins to this sort of different, basically continue using Git. But if any, fast forwarding now, I don't know that many people that actually like using Git submodules. [00:33:00] Um, It was very, very complicated. And so that became a decisive point where I basically, after months of us testing and going and me being like, yeah, I'm, I'm into this idea. And eventually me going, you know, this is too complicated for me to wrap my head around. I'm not enjoying this. Like, and I just don't think my front end developers on my team, junior developers that we're bringing in are going to understand how to use this. And they're going to have to be like, what am I typing? And that was, that was a key point to be like, Oh, who's our core audience? Who's our core target user base? Like you're savvy enough to know how to use that. That's great. I'm barely savvy enough to understand this. So killed it. It's like, no, thank you. We're not going to do this. We're going to focus on making this optimized for you. Let's say junior developers are our core target user base, and people can graduate or upgrade out of Oh My Zsh at some point. You can use it for now and get you to where you need to go. And once you get more, if you want to get more advanced, there's lots of other tooling [00:34:00] out there. So that became our core focus. I find years later that people still love using Oh My Zsh, even though they've been using it forever. And they're like, Oh, I love the defaults. I have a couple of plugins I use. It does what I need. Problem solve. And these are really, really smart people that know how to do this and they could go do that stuff. They're like, no, I don't want to think about it. So there's that part of it. I think the, a lot of CLI tools can get really complicated really quickly. And so back to that kind of just like say developer ergonomics and how easy it is for people to kind of get on board. I don't want to assume everybody's always initial wants to become a power CLI user. They want to be proficient enough not to break things, get their job done and, and, and, and sleep at night. And. The challenging thing about the terminal, the shell environment is that because a lot of people don't aren't familiar with it when they start using it, and even those that are fairly well, like, have some experience of software engineers, CLI is not an environment that we tend to do a lot of version control over how things change in your [00:35:00] environment, you know, the tools that we use, yes, What we do to our own environment. When you open up a terminal and you start copying and pasting things or making changes, because it's kind of like you're interacting with this thing, you're copying and pasting things off of SAC overflow or your internal team documentation. And then you find out, you know, so we get, so a challenging thing of building a tool is that you've got different operating systems. You've got different terminals, uh, different terminal apps, and then everybody's environment is just a little unreliable and inconsistent. They open up a new tab. In their terminal app. And it works. What, what was the difference that there's not an easy way to track? Like what it's hard to go back and reverse engine or repeat those steps. So it's hard for us to replicate. Some bugs from people. Um, this is just, I think, a challenge when you're pair programming with your coworkers or helping debug things. If you're trying to set up your local, like a, your, your team's web app on a new person's computer and it works for everybody else, but they got a new Apple computer and it's got an M2 [00:36:00] chip. All of a sudden, like a third of the things don't seem to work right. And so you're copying and pasting commands that don't work. And so because of the chips are different architecture and the personal Linux as it works. So the people using things in Docker and you've got all these different Shell environments, that's complicated. And it's really difficult to explain that to people that don't have a lot of experience. Like how do you like, and then the other thing would be the security of people's environments is another thing. And so people will be very mindful about how, when people report bugs and they ask them to share some of their environmental information and that they're not copy pasting their AWS CLI, you know, environment variables because it's just, they type in ENVNs then. Somehow loaded that stuff up already. So a lot of messy stuff like that comes up in this environment. Um, so those are things that are challenging and we have to spend some time thinking about how we collect data reports. We have tooling that we've built so that people can submit bug reports to a separate service so we can scan out that kind of stuff and then [00:37:00] hopefully do a better job of protecting that. But it's, it's, it's a little messy. Yeah, terminal environments can be humbling. Like, I'm pretty well into my career, but sometimes somebody will approach me with like, oh, node's not working quite right, and I'm like, oh no. Like, just peeling back the layers of all the things that could go wrong is, is so hard to do. What version of node and which version does what app that you're working on require and you've got. Then you add in like having multiple versions of node on your computer or multiple versions of Ruby on your computer. And you're just like, how do you, it worked over here. It worked yesterday. So that, that stuff happens a lot. So that, that is a challenging thing to provide support for that sort of stuff. And just, it's not a very controllable environment, ~~um,~~ where the tools you're using, like change their paths one year and then all the documentation's outdated. And so things that work three years ago. Copy and paste them. It doesn't work anymore. And a lot of people don't even know what they copy and paste and remember that they copied and paste that, you know, like, what did you do? And they're like, they'll [00:38:00] remember a third of the steps, the things that they did, they don't know what they tried and like, how did you get there? Like, I have no idea. And you're like, well, it changed. Those are just, you know, fun pair programming challenges you have with. And I've seen that across all skill levels. It's not specifically just junior developers. It's anyone has these problems. I have these problems. ~~Um,~~ #### [00:38:19] Handling Open Source Contributions so you mentioned it a little bit and we've touched on it a lot here on the show, but, uh, you guys accept a lot of contributions and there is some peril in that. Like I have, I have managed my own open source projects. And at the start I was like, gung ho, everybody who makes a pull request, I'll work with you to get that pull request merged. But then I like kind of crested the mountain and I was like, Oh wow, that code is my code now. And I have to think about it. So how do you think about it with such a, as you said, a large project? It has so many contributors, so many plugins. How do you grapple with that? Well, I am not the first line of defense these days when it comes to reviewing [00:39:00] PRs. So there's a couple other people on the team that do a lot more of that. But once we made that decision to Let's take a step back for the first, for several years, I struggled to bring someone else onto the project to help manage the project from a, like, there's people that were like helping test things and stuff like that, but to actually give them permission, like grant them access to actually merge things into the, you know, into the primary branch of the project, why I, you know, One, maybe a little bit of a security fear. All these people install this thing and everybody's nervous about it. And if, if I, I just worried that one day I'm going to end up like, oh no, I merged something and it just wiped out like hundreds of thousands or I don't even know millions of people's computers. Because I overlooked something because everybody just runs the auto update So it could be like the thing that bites me in the ass one day So i'm like one day i'm gonna have to just run away from the internet and never come back Because I I messed up or I did it and because I was like i'm done. Goodbye [00:40:00] everybody I'm taking all your computers with me Um, it's gonna happen on april 17th, 2026. I warned you anyways, uh the um No, uh, but I wasn't, you know, as I created the project, I actually see myself, my role as more of a curator. And I think that distinct, you know, I created the initial thing, but even like that initial version was like curating a bunch of ideas from other peers. So it was kind of like, what resonated with me? What did I, what was I looking for? How did I want my experience to feel? So as people started contributing, yeah, I was taking things that I wasn't like, there's a lot of plugins I've never used outside of testing them or not even even to that extent, because I don't, I'm not going to install symphony. Whatever X number to test this one thing. I'm like, I trust that this person did their testing. Some other people voted it up and said, yeah, this is going to work. So I think it's a matter of like, does it feel, look and feel like it's something that belongs as part of the overall ecosystem for other like minded people. And so [00:41:00] learning to trust my sense of taste, I think became important. And then the other part of like me bringing other people into the project was like, how do I share the, not necessarily the permission from a security thing, but how, how do I share that curator role? How other people come in and make decisions that hopefully 80 90 percent of the time I also align with how I see the world. So that was, I feel like that was a really hard thing for me to do. And it was, So as, as people are, so many contributions are coming in, like I started, there was one person named Mark Cordella, who I was getting backlogged on keeping up with them. It was just too much, honestly. And I never felt like Oh My Zsh was this mission critical thing where like, unless there was like a huge security thing or a major bug, I always felt like it was already always kind of like done in the sense that because it was, It's open source. It was feature complete day one. Someone wanted to add a theme. Someone wanted to add some plugins. Anyone that was savvy enough to fork the [00:42:00] project and create a plugin. Already had that plugin. So I wasn't keeping them from it. It was just keeping other people from also using it unless they were savvy enough to figure out how to pull in that, you know, that PR into their own version. So if they were savvy enough to figure that out, then they could use it as well. Cause there were people that were testing out people's plugins and saying, yeah, this works for me as well. So I knew that people were using those things. And so I never felt like, well, just because. That PR has not been merged yet. I'm keeping everybody, you know, everybody's being held back. You know, it was more like, well, I'll get to it when I get to it. And anyone that really wants to use it, that's looking around can find it. The thing that I felt bad about was when people would start submitting. Plugin ideas that were very much similar to someone else's and they didn't see the other one. And I'm like, oh, they just spent time building the same thing, replicating something. And so that, that, when I, that, that's when I started to feel a little like, okay, [00:43:00] this is not ideal. And like, how do I navigate that? So, you know, I don't want to people waste their time.~~ So,~~ so that all that, all that to say is that once I was able to find Mark Cornell, I was the first, um, maintainer that I added to the project because he would start going through and like testing 30, um, like similar PRs and submitting another PR and saying, I tested all 30 of these. These are all working. I'm giving the thumbs up. If you merge this one PR, it'll merge all 30 of those PRs. And he would email me and like, Hey, Robby, just want to let you know of this thing I did. And he found all these workarounds to get my attention. So it made me, it made it easy for me to be like, Review, merge, thumbs up, done. And then I got, it was like a 30 X myself as a maintainer because Mark was doing all the work. Um, And so after he did that several times over maybe a year and a half, two years or so, I was like, hey, come on, I'm just going to give you access. Let's do this. Just make it easy for junior developers. Let's keep that the focus. And so we agreed on that. And so he's been able to continue doing a lot of that [00:44:00] since then as well. And so I can kind of dip in every once in a while. That way, I never feel like I'm getting burned out of the project. So I can go. Jump around and play in the project when I want to merge things, I usually will start off with like more recent things because they're easiest to merge. And so I feel like it can be helpful. And then I will also do other things like, um, jump in on PRs for first time contributors and like, thank them or send them an email, let them know that I appreciate it. Try to do a little bit of the other, you know, reach out when you have thousands of people doing this, like, Want to be highly attentive to people as best we can. But I, we had our main hater meeting. We do this once a month. There's also another developer named Carlo. That's on the project. We, we talked today and we've all maybe done a few PRs in the last month. Since we all last met together, we had to meet in person for the first time together last month at a conference. After been working, Mark and I have been working together for 10 years and it was the first time we ever met in person. And that was pretty exciting to meet. He lives in Barcelona. So does Carlo. We all met up in, um, uh, Berlin to speak because I was speaking at a conference and [00:45:00] so got us all there together and we got to host like an open source booth and like at the meet a bunch of people that use on me. She shot and that was super exciting. But, um, yeah, it's just like, uh, I don't know if I quite answer your question at the beginning there, but yeah, it's part of the open source thing. #### [00:45:13] Creative Plugins and Customization So of the plugins that you've reviewed and things that like people have submitted, what do you think is like one of the most creative plugins that you've seen? I think, you know, everybody likes to talk about and I've used it as well. Uh, there's one called the fuck. You can go look it up, but, uh, it's helpful. Um, ones I use the most are like dot ENV. Uh, Z is another one I use, which. Kind of builds up a memory of a knowledge base of like where I often navigate on the, you know, different directories and stuff like that, just to kind of like simplify things like that. There's some other things for like SSH agents that is helpful because I navigate through a lot of different SSH agent profiles and AWS environments for different clients because I work in client services. And so, Navigate a lot of stuff like [00:46:00] that. And there's some other custom ones that my team has built as well, that are more interesting for us. But that's another thing people ask, like, Oh, how can I contribute to the project? Um, or what are some ways to, to take advantage of Oh My Zsh? And what I often will encourage people to do is like, if you work on a development team with your coworkers, do you all have a lot of things that you end up like things in your documentation? Like here's a bunch of shortcuts for things like that. Create a custom plugin. Toss it, like collaborate on that custom plugin and you can load it in a normal Z show, and then you can have that be like a private repository or something, or make it open source, whatever, but that's like a really good way to kind of play around with the tooling as well and create your own theme and you can add other information like your AWS environments or other fun little details for, you know, distinguish your different projects and stuff like that. So it's like, just, you could just iterate on a custom theme together and just add some more little juice, fun details that are specific to your companies. Teams and work environments and stuff like that could be [00:47:00] helpful. So you've also seen a lot of themes. Do you have any like interesting things in your own theme? Like I've tried multiple times to create a Star Trek inspired shell that has like all of the different visualizations, but always just end up stopping because I don't want to create my own terminal font. My favorite thing to do is to turn on, as if you could, if you set your theme and your config file to random, every time you invite up a terminal, it's a different theme, it's a good way to, that's a good way to live in chaos for a while, but, um, and you can find out what theme it is and that could be one that you use. Uh, I still use mine because I'm lazy. Um, but there's been some fun ones that I've used over the years. I don't remember them off top of my head. Um, the names. I have to go double check a little bit. But I mean, I know that like was a power level 10 K or whatever is like a pretty common one. Uh, I'm really envious of what, from like, uh, just maybe from a monetary monetization perspective, the Dracula theme, um, I was like, why didn't I [00:48:00] think to like package this up into, into a thing I could just sell and have You know, themes for all these different color palettes. So I don't know, maybe there's going to be a Robby Russell theme one day that for your VS code, you'll pay money for it. But, um, he's, that developers made way more money than I have with Oh My ZSH, uh, outside of selling stickers and t shirts and coffee mugs and stuff like that. Yeah, we actually had him on a little while a fun story to hear. Awesome. We just got recently introduced over email. Um, I'm hoping to chat with them a little bit more in the near future as well. ~~A fitting introduction.~~ #### [00:48:29] Planet Argon and Client Services So let's, uh, transition over and talk a little bit about what you're doing with, uh, Planet Argon. Um, so you, you kind of talked about this transition of like turning it into a, an agency that, that primarily focused on Rails applications. Is that kind of the, the area that you still find yourself working or most of your, your customers doing Rails Predominantly, yeah. That's what we're kind of known for. We also work with a couple other technology stacks, like we're doing some stuff with [00:49:00] Laravel and React these days. But we used to do stuff with like some other PHP and Python stuff back in the day as well. But Ruby on Rails probably is good. 80 ish percent of our client base right now. The, um, and you know, we've been part of the Rails community, you know, as I mentioned, since very early in the Rails community. And at some point there became this pivot of like, rather than companies asking us, Hey, would you build this new app for us? It became, Hey, we built this app. Okay. So I had a conversation two or three years ago with this freelancer and they're no longer available. Can you take over the project? And one of the things I loved about Ruby on Rails was I made all these decisions on before, you know, all the kind of the defaults for a lot of things and just, it's opinionated. And so diving into existing Ruby on Rails applications was like, well, yeah, that's That's not like things are where they're supposed to be for the most part. And it's just like, how can I focus now less on where things are in the code necessarily, and more about like, how do I understand what their business domain is and like, what's important to this company. And also most importantly, [00:50:00] companies that have already built a thing and it's proven to be successful or. Provide some value to the company that tend to have budgets and startups that are, have an idea for a thing, tend to run out of budget. And then they tend to go out of business. So lazily it became easier to work on being pitched, kind of pitching ourselves as a company that likes to inherit existing applications and help move them forward. So for a lot of our clients, we are, we take over projects that are maybe were developed by another agency. And the agency is really good at spinning up an MVP. And keeping it on for a couple of years, but then their team is not excited about maintaining it three to four years later. And they're like, what do we do? We pick up projects like that, or they might've been a company that had two, three full time, you know, internal software engineers working on a project. And then at some point it went down to maybe one or two people. And then there was this one person on the project for a decade, and they're the only one maintaining it anymore. And then that person misses having other coworkers and they go, They get a new job and the company's like, [00:51:00] what do we do this? All this institution knowledge is going out the door. And we're like, Yeah, we can handle that. We can take over your project and, and keep that going because maybe they don't want to just hire a replacement for that one person, because kind of the advice that I give is if you can't afford to have budget, you don't have enough work for more than say two or three full time people just hire probably a couple of freelancers or outsource that because you don't, unless that person's like, uh, maybe a principal in the company, like a C level person or one of the founders, like just having an employee be like the one developer sitting in, you know, Maybe, maybe the corner is a little bit different now than it used to be a decade ago when it was literally just someone in the corner that nobody knew how to talk to you because that's the software engineer that kept his headphones on and didn't like to talk to people, but they made the, they kept the application running. So we took over a lot of those types of projects from companies. And so a lot of our clients, we're like the primary team working on those projects day to day, you know, make a small feature updates, um, bug fixes, performance improvements, things like that. And then we also do a lot of [00:52:00] coaching with helping companies that have their own engineering team on how to like navigate when they've gotten way behind on upgrades, or they've got a bunch of technical debt and, or they've had a lot of developer turnover. Maybe after layoffs or just people left, you know, four or five years ago and then new people come in and they just are afraid to break things. They're afraid they're going to break things maybe due to lack of testing or a lot of other things that happen in organizations. So come in and help teams kind of coach them through on how to like, you know, iterate and improve upon those situations to make their developers lives a little bit better. So that, that is quite a bit of what we do. And so, yeah, that's, that's what we do at Planet Oregon. Yeah. It makes sense that Ruby would be a great stack for that sort of work since there's so much convention by nature in the, in the framework. ~~Um, so~~ Yeah. #### [00:52:42] Keys to Maintainable Software so you have a podcast yourself, uh, it's called maintainable software and I want to ask you, what do you think are the keys to creating maintainable software? Don't write it unless you need to. Um, I think, you know, people, we talk about, you know, maybe your definition of done as a, you know, [00:53:00] as teams, hopefully your team, like when you, on anything you're working on for, A new feature or on your, on your own project. What is your, how does your team think about as we release this thing? What are all the, like, you might have your checklist, like, does it have testing? We can talk about all those different things, but if your team doesn't agree on what those things are, that's usually where things start to erode. Or when you start to be like, unless you have all these like exceptions, like, well, this is an urgent thing we need to push this out. So I think when that stuff starts to erode. Things. Your team's best practices maybe started to get pushed to the side a little bit. And so that can be a challenge, but I think, you know, when it comes to patterns that I've, I've seen in this, regardless of the technical stack, but, you know, just, I think a willingness to speak up and realize that part of our job is to make our, make our, the tooling that we're using and the And how we're exercising our skills as easy for [00:54:00] us as possible. And I think what I often see is a lot of developers fall in this habit of like, well, I have to ask for more time to do, to add automated testing. I have to, we have to ask for time from I'm air quoting the product people to address some technical debt or to do X, Y, or Z, or to get an upgrade done. And so it becomes now this like us versus them problem when it's actually more of a company, like. It's your, your, your team's slowing down. Sorry about that. Uh, your team's losing velocity or however you want to describe efficiency as a development team. And so we make up all these excuses and so you start pointing the fingers. Uh, some other entity, maybe you've asked, Hey, how can we spend, how can we get time to, I want, can I have permission to work on this stuff to address some of these issues that will make my life easier? It'll help speed us up in the future. And then they hear not right now, a few times, many times, and then they stop asking. And the other part of it, I think that's, that's sad. And so they think that if they just go to another company at some point, maybe the grass will be [00:55:00] greener and all these problems will go away. And that's sad. That's not reality. I think one of the problems we have as an industry is we talk about software development and we frame it around being, Hey, we're going to be creating things all the time. We're going to be building new stuff all the time. You know, you're going to, and I think, and then I think we've do ourselves a disservice as an industry. And we don't talk about a lot of software development is actually maintenance work is iterative improvements of things. It's not as glamorous, but it's important work. And it's like, I'm going to say it's janitorial work, but I've always thought we've treated ourselves like we're a white collar when we're really more of a blue collar industry, and I don't think we should be ashamed of that. And that's like the, we're doing this magic stuff, like, no, we're writing code to like business requirements change. And we're going to iterate on things and just keep moving the thing forward as best we can. And I think. We have a duty on our end as software engineers to make our lives easier, as I was saying, and we don't always have to ask for permission. Like, sometimes you just need to say this needs to happen in order for this thing to get done. But if you're always being like, if you're always offering the, [00:56:00] or we can get it done way faster if we just cut these corners. I think a lot of people don't talk about the corners that they're cutting either. And that's a challenge because they don't know it until they just end up overestimating or underestimating. And then kind of like making it up later and like, okay, we'll put that on the backlog and we'll deal with that someday does someday ever come as another thing. So I think two things, one company's teams need to agree on what definition and done is and what they accept as a team, what their, you know, like their principles are, but then also I think it's important to agree on what you consider technical debt. As well, um, I think it's an overused metaphor and as well, there's some stuff that just needs to happen. And I don't think it's necessarily debt to say like, Hey, we need to keep things updated. Otherwise we're not going to be able to ship this because, you know, and another that it's just like this really complicated thing. And, you know, I'm, I get that I host, I host this podcast people these questions and everybody has a different answer to this. And that's the reason why I have the podcast because I can have, you know, 200 people come on and say very different things. And that's. [00:57:00] Part of the, the problem, but also I think reassuring that like, Hey, every team is a little bit different and every, everybody's kind of thinking about this a little bit differently. And so maintainable software is whatever you think it is and agree on it as whoever the people that are working on that project. Is it maybe a short way to, to answer that question? Yeah, I resonate a lot with that. I, uh, argue that we should upgrade our dependencies a lot more. And I think it all just comes down to technical debt is just communication. Like you need to, it's communication between people and deciding upon what that is. ~~So.~~ I always think back to just as a quick small point, is that like, when you talk to people in other departments, if someone in accounting decides that they're going to redo some Excel spreadsheets and reformat them and change things to make their life, you think they're asking anyone for permission to do that? They might spend a day or two just taking care of that stuff. No one's at questioning their velocity. They're like, no, I needed to do this because the other tool, a spreadsheet was getting outdated and it was causing some issues and it was slowing us down or we were losing some information. So I created a new [00:58:00] spreadsheet or I revamped it. That person's applauded. Like, why don't we do that more as software engineers? Just like I did this thing. You don't even have to tell everybody. You just do things and be like, what did you do the last week? I'm like, it's making our tooling better. Like what the fuck, what's wrong with that? It's just, that's my job. You hired me to act in the best interest of the business and software. And if you think I'm not doing a good job of that, don't get me wrong. There's a lot of developers that will just go down and go down rabbit holes and just like go off on little solo missions for too long and not come back. Um, Very often report on their progress. And that's a problem. So just don't surprise people. I think is the important thing there. Take away from them. Yeah, it gets back to communication. #### [00:58:38] Future of Terminal Environments Um, so to wrap up our episodes, we usually ask a future facing question. Um, and I've, I've been thinking a little bit about what to ask in this episode. ~~Um,~~ so you've done a lot of work in the terminal, a lot of work on, you know, the environment around Z~~ Um,~~ And which I hope has given you a lot of really well formed opinions on this. There are [00:59:00] companies who think, Oh, the terminal is outdated. It needs to be reinvented. It needs to be modernized. We need to, you know, build it on different technologies or do something different with it. I'm really curious about what you think, uh, the future of terminal environments are, if it'll just. Continue as is if it'll change in some way, or maybe even things that you would like to see. It's a good question. You know, I think back, you know, again, earlier, I said that like the UX of a most shells haven't evolved much in 34 years. And I think, I think that says something, I think it would be great if shells could do a little bit more from the user experience. And the things that I get a little less excited about is when it's like asking me to log into a cloud service to use my terminal, because I, that's, but I could see that I might be thinking about it from an old. Person's perspective of like, Hey, the local shell is [01:00:00] my space. I don't want it. I don't need to be on the internet to interact with my computer. Um, or I don't want to be on an SSH connection and have to, I don't even like, that's even a whole nother thing when you're an SSH to a computer or something like that, set that aside. I think as far as like making the tools more interactive, better autocomplete functionality, um, like I think I've seen some, some interesting ideas around, you know, how. Maybe using some AI stuff like that, you know, things like that to like, there's even stuff in like the terminal I use, uh, I term to primarily on a Mac, but I'm using a couple of other new terminals. I'm testing it. One of the nice things about having a project, I go my Z shell as I get asked to check out people's terminal apps way before other people used to release them. So I got to use fig months before it was released. Um, there was another one. I forgot the name of it, but I'm using a tool called ghost ghosty right now. And, and that, I think. There's a lot of, uh, exciting effects that you, we're going to get more colors. Maybe you can use your mouse as another thing. Like [01:01:00] thinking about how you can use your mouse and a cursor, not always, but could we add some other functionality into that environment? I think that's kind of exciting to think about. Like, how could it's, I mean, it's funny. Cause it's like we were using mice. Games. So it's not like it's this wild, like brand new thing. It's just feels like in some ways where I think the point in, there's something about the interface to a prompt. And I think that's why maybe chat GPTs and tools like that are like resonating so much right now. It's like, you get feedback, you're typing into this thing. Yes. Chat GPT might feel like a very different thing, but it is. Kind of similar to interacting with your CLI and you're typing things in there's there's there's patterns for how you do that There's a syntax to doing it, right? And so I think you know, I think what might I think that that that feels like that world's getting will be blurry And I don't, I don't know what [01:02:00] that's going to look like. What I hope for is that we feel like we're able to type things in and feel pretty confident that we're not going to break our computers, that we're not going to destroy our local environment, or that if we do, it's recoverable. And so I think if there's something about shells and terminals and the tooling to better protect people that are using it and to make it more accessible to even people that are not developers, you know, I was mentioning that conference I went to recently, I spoke at in Berlin, and I was meeting to people that didn't classify themselves as developer, but maybe they worked in like their data analysts or something. And then you knew how to run a bunch of Python stuff and they were using Oh My ZSH. First up, and they're like, I was like, Oh, this is interesting. And it's like people outside of what I would, you know, I could cook. They're doing coding adjacent things, but they're not, they don't identify as coders. What might that look like in another 10 to 15 years where you've got someone in HR that's optimizing their workflow because they can run some really short things and like interact with like a CLI tool that could do some HR [01:03:00] related things or like spin up. So I just think like, if I don't know, maybe that's a crazy example there, but How do we make it more accessible? And, and then I also, the other hope thing is I just hope that things just still remain somewhat delightful and fine. And if people can not inject so much, like when companies are releasing tools, it's not as exciting to me as when it's like a community tool and there's a little bit more playfulness, a little bit more personality. And you don't see that as often when it comes from, say a corporate entity. And maybe that's just me with the DIY. Then coming back full circle to be like, let's not make it stuffy. Let's, let's have fun. Let's, let's be playful and a little whimsical, Yeah, I like how you related, uh, or chat GPTs interface to the terminal. They, they do feel very similar, even though they're like light years apart, but I could imagine a day where you like, it's just, the terminal is essentially a way to ask your computer to do things. If you could ask in a little bit more natural language and that makes it more accessible to more people, that'd be awesome. like build a script to [01:04:00] do this, this, and then it's just like spits it out right there. I'm like, you can do that now with some tools and which is kind of exciting. Um, I'm not doing that myself, but I'm not ready to have it run the commands myself yet, but I think that it's kind of, it's, it's interesting to see how that evolves. So I did not think Oh My Zsh would be this thing. 15 years later, I thought this would be a short lived project, maybe for a few years and some other cool things would come along and just wipe it off. Yeah, here we are. So in 15 years, I hope maybe Omaze is still a thing and it's still evolving. TBD. Well, it's had a good run so far and it's got a little momentum, so I'm sure it'll be around. ~~Um, yeah. you want to Uh, ~~w #### [01:04:34] Conclusion and Final Thoughts ell, that's, that's all we have for our questions. Thanks for coming on Robby. This was, uh, a really fun conversation. Like as Justin said, uh. This is one of the first tools I installed on my like journey to becoming a 10x developer, air quotes, where like, I really felt I had control over my tools. So thanks for creating the tool and just like making this community. Thank you, Justin. Thank you, Andrew, for having me. ~~to be~~ Yeah, thanks for, thanks Robby. It's, it's a pleasure to [01:05:00] have you on. Uh, this is, yeah, it's a great tool and, you know, the legacy continues, so we appreciate it.

Tag: shell script

Mapeamento e Identificação de Arquivos Duplicados em Discos Externos e SSD Secundário

Robby Russell - oh my zsh, Planet Argon