#58 Robby Russell succeeds being selfless
Transcript
⚠ The following transcript was automatically generated.
❤ Help us out, Submit
a pull-request to correct potential mistakes
Tim Bourguignon 0:06
Hello and welcome to developer's journey, the podcast shining a light on Developers Live from all over the world. My name is Julien and today I received Robbie Roussel. Robbie co founded planet, Oregon in 2002, which is a software consultancy based out of Portland, Oregon in the US. Senate Arden helps companies with existing Ruby on Rails applications make them better and more maintainable. Robbie was an early adopter of the Rails framework and was known for his blog, Robbie on rails. In 2009. He created all my z shell, which is a productivity tool for software developers, and it accidentally became a success in the open source community. Nowadays, Robbie spends his time helping lead his company's development team and is the host of the maintainable software podcast. Robbie, welcome to dev journey.
Robby Russell 1:03
Thank you so much for having me.
Tim Bourguignon 1:04
Tim, I was asked how do one accidentally create a successful tool derivative for me?
Robby Russell 1:10
I don't think I it's like a replicatable approach, I suppose. But yeah, back in 2009. I don't know how familiar I with like things like bash and z shell and other terminal tools. But I had been using a shell called z shell for quite a while that, you know, is a replacement for bash in my terminal when I'm working as a developer and doing things in my, my local computer in my development environment. And I was working with my with my team. And it was really difficult for them to kind of understand, like, I would just say, Hey, I have I use the shell, here's my configuration file for that. Because when I would sit down and bear with me all my useful shortcuts and little cool features that I had kind of baked into my z shell configuration weren't on their machines. And I thought that was I was trying to always convince them that it was just copying my z shell configuration file to your computer, and then switch it over as your default terminal. And then when I'm working with you, you'll be able to kind of take advantage of the stuff I put together. But add a few employees that were really didn't, you know, there's there's also there's people that want to understand how things work. And there's people that just like the end product of something that works. And so there are some people on my team who wouldn't just take my z shell configuration file and add it to their local file directory and just switch over the shell because they didn't understand what all they all the configuration did. And so they wanted to understand, like the reasons behind some of those, or if they want to make changes to it, that didn't, they didn't really understand it. So I decided one day that I after kind of kind of nudging them to consider using z shell for quite a while, like maybe over the course of like six months, and I've been using it for several years. One day, I thought, well, maybe if I just clean up my z shell configuration, add some documentation to it, so that they know what it is because honestly, I kind of forgotten what some of it was myself. So I was like, I'll do this. And then I thought, oh, I'll document it, I'll clean up the file. And then during that process, I kind of realized, Oh, I should split this up into a couple different configuration files. You know, I'm like, oh, maybe I'll stick it up on an on our GitHub account. So that way people on my team could use it. And then if I provided some instant air quoting installation documentation, then maybe it would seem more formal, and they would consider using it. So I did that one day, and shared it with my coworkers. And everybody installed it and started using it. And I thought, Oh, this is cool. Great. I work my my little theory that if I made it look, official, they would maybe use it in granted the I didn't have a lot of understanding how the shot worked underneath the hood. Anyways, I was just taking some examples of different configurations from different friends that are in the community. And so so I did that. And then like two days later, someone asked, okay, how do I change my terminal prompt, I want to change the color pattern that I had set up. And I was like, why would you want to do anything different than the way I do it? Because I'm obviously whatever I do is probably the best way to do it.
Being a little sarcastic there. But the so they wanted they wanted to make some of their own changes to it. I'm like, Okay, well, you can, you can kind of create your own Fork of the project, and make changes to it. And so I showed him how to do that. But then there were some more of that. And I realized they were adding some stuff that I didn't have. And I'm like, well, that's cool. Why don't we put it all in my project. And we'll just kind of compile stuff. And we saw we started extracting this one big long configuration file into a set of smaller files in organizing. And then we were sort of making some internal pull requests off that and making changes to it. And so I and so what's on my z shell is is a it's a basically a framework that includes plugins and themes for making your terminal prompt, more, in my opinion, more delightful to work with, especially if you don't have a lot of experience with it. So providing some more quicker feedback, some good color coding in certain environments, and plugins for a lot of them. really popular, at least at the time, tools like software development tools, like I'm, I'm from the Ruby on Rails community. So there were some specific stuff to Ruby and Ruby on Rails in there. And then I also knew that there is some stuff for some other database programs. And then I had some friends that were working with PHP. And so we did something for them. And eventually, this thing, kind of, I bet, I did share this on my blog at the time as well. And within a couple of weeks, some people started submitting their own requests and to make things better. And so they were kind of using my configuration tool. And so that was back in 2009. It was mainly to encourage my co workers to use z shell, which, actually, this year, as you might have noticed or not, but Apple announced that they're going to be making on the next version of os 10, is that it will be running in Catalina, it will be running z shell by default, if you open up your terminal prompt versus bash. So you know, fast forward 10 years later, that's now going to be the default. So if you're, if you're looking to explore my z shell, this would be a good time to start doing that, because just to kind of preemptively get ready for the Catalina switch. But you can always always, you can always, obviously, always switch back to bash as well. So anyways, I created this project, I shared it on my blog. And people started submitting Knuth like some basically came up this concept of themes, which was so that me and my co workers could ever own version of how the prompt look, but then other people in the community sort of sharing their ideas. And Fast Forward 10 years, we now have 140 themes built into the product. And we've had maybe over 200 plugins that do help you do things like if you're using PHP or Python Capistrano comm brew, if you're working on a Windows machine, or a Linux machine, or a Mac machine, there's specific stuff, there's a bunch of tools for making shortcuts in useful tools for us interacting with git, and Docker and is, like I said, is like 140 ish, or over 200 plugins, actually, at this point. And so that project over the next couple years, started to quickly gain a little bit more traction, people started using it, and and then those people, what ended up happening was some people that might have found out about it for me, who were also the type of people at least some of them would be giving, like a talk at a conference and doing like a live demo of some coding. And then after the their their talks, people would ask them, Hey, when you were doing that, you jumped into your terminal, how did you get it to look like that, like, oh, oh, my z shell. And then that became like a way of spread. Like I started spreading the word about it from what I think a lot of conference speakers were, that's how least one way that it spread, because I wasn't doing any, like major marketing or anything for the project, I thought it was just like a fun little goofy project. So again, it's been 10 years, almost, it'll be 10 years old in August, I believe. And we've had, we've already accepted code contributions from over 1300 different software developers from around the country around the planet, that have code that they've contributed to that's baked into the project itself now. And so it's, it's kind of been this funny journey, where it's, it was kind of like a, oh, I did this for my coworkers. And then I decided to share it with the world. And a lot of people started to use it, and people keep talking about it. And it's always fascinating to hop on Twitter, and on that Twitter account and see people talking about it in different languages. I'm always like, using the Translate tweet, option, so I can see what people are saying if they're complaining about it, or they actually really love it more often than not, it's positive. But it's it's kind of fascinating that a ton of way outgrew, like anything that I ever thought was going to be happening. What's going to happen when I first built the project, so
Tim Bourguignon 8:41
amazing, amazing, I love how it's always the same, it's when you scratch your own itch and, and do something, really for yourself first, and just put it out there because it might have someone who's on a project that really take off and really become something kind of by accident. Like you said he didn't want to schedule it to make it a central successful project. But because you were so passionate about it, and because you were doing it for yourself and for your coworkers, it became something I love. Sorry.
Robby Russell 9:16
Thank you. Yeah, it's it's been a it's been a fun adventure. It's like one thing I've always also I mean, I also struggle with the project in some ways, because it's never been like a high priority project for me. Because I've got other things I run a business. And I do I have other interest in other types of projects that aren't specifically Oh, my z shell. And so there's always like this little bit of a tug on my in some ways of being like, well, how much attention Can I give the project. And I've always been very upfront with the community me like, hey, there's a lot of things you want to see improved about it and you're allowed to make contributions, but I have very limited bandwidth and how much time I'm going to spend working on the project. So as long as I can keep making it like when I have a little summit Some spare gaps in my schedule to work on it, I'll do it. But I've been able to recruit some other people to help with some of the maintenance, maintaining it as an open source project. That's been great. And one of the things that's I always find really fascinating about this project was, I can go back, you know, talk about how I got into software development. But at one point, I started when I was learning to write software I wanted was because I was trying to sell stickers on the internet for like, like punk bands and things like that in the 90s. And that's why I learned how to program and now I've built software, that I sell stickers almost daily to people around the world for the software projects. So it's kind of become this like, twofold or like, completely flipped around thing where I didn't expect that I would finally get to realize my dream of selling stickers on the internet, because I created a piece of software, when I needed to learn how to write software in the first place to sell stickers.
Tim Bourguignon 10:53
Let's go there. Thank you start learning how to code.
Robby Russell 11:01
Yeah, I guess that first part of like, when I've started to actually take, like, maybe a stronger interest in software development, probably was in my late teens, back in the late 1990s. And like, probably around 9796 or so. But backing up a little further, I first got introduced to software development, and probably was in 1985 1986, I was about six years old. And my dad works in computers and technology, he works more on the hardware side. But he was really, we had a computer in our house when I was a kid, I always had one since I was like maybe five. And then I think for my sixth birthday got my my own computer because my dad got a new computer for the house. And so I got to basically keep the the older one. And that would allow me to do some had some video games on there that can play, I really knew how to like work around with DOS and things like that. But my dad would buy me, he bought me a couple books on teaching kids how to program and this is in the mid 90s or mid 80s. And I remember sitting down in front of like an editor, like a software editing tool, I remember having a blue background with some white text on it. And I was reading software code in this book, and my dad was trying to explain if you write all this into this, if you retype all this into the computer, and you run it, you'll get to play this game that you just built. And then you can start making changes to it. And as I sat there, I think I spent maybe a half hour look like copying what was written in the book. And I thought this is the most boring thing I've ever had to do in my life, because someone already did this. Why do I need to write this? I already have some games I want to play? Or can I go outside and play with my friends? Because that seems more interesting right now then, like basically what I felt like was basically just copying. And like, there might have been a level of like learning how to become a better typer through that experience. But I just thought the actual idea of like writing software just like I don't, why would I do that someone else's, already knows how to do that. I'm going to go play outside, I'm six years old. So my dad, like there's a theme through my childhood. And my father was always trying to encourage me to get into software development. But it always had this kind of like, I don't, why would I want to do that it doesn't seem interesting to me.
type of thing. And so.
And then I think I as it became a teenager, I started to associate being a software developer with meaning, I would be working in Silicon Valley, in a cubicle in an office not next to any windows. And that wasn't the sort of life that I thought I would be interested in having. So I was like, I don't want to work in computers, software development seems boring, why not not interested, I'm gonna do something creative. I want to make music or do something else with my life. I don't know what it was. But working in the computer industry did not seem like an ideal fit for me at the time. So, so fast for a couple more years, I dropped out of high school. And so I didn't finish that and became a paint I painted houses for three years. So I work in construction. And, and when I was in during that period, I was also really into like a local punk music scene in the San Francisco, Berkeley area in California in the US. And so I got really excited about like making paper scenes, you know, like little scenes where I would write reviews of bands that I had seen or CDs that I had purchased recently interviews with some of the bands. And then I wanted to publish that stuff on the internet. So I figured out how to make webpages that so I could do that. So I could share that online, not just have a paper version of my Xen. And then I wanted to get into selling stickers on the internet. So I was like, oh, like know how to make a webpage. So because I did that other project, maybe I'll make a webpage for my sticker business that I was trying to start. And so I figured out how to make a web page how I would allow people to place an order online, and back then it wasn't like I was taking people's money online. Like that. Wasn't That was way outside of my skill set. But I was able to make things like a forum that people could fill out on. Like, they could make a request that they want to order these few things. And it would send them an email saying, great, here's your confirmation, please send $5 in the mail to this address, and I will then send you your stickers in the mail. So it was kind of like a online mail order form type thing. So that's how I started learning how to write some basic coding to do things like collecting data on a webpage form and saving it say to a text file or a CSV file that I could FTP into a server to see that I have new orders in the CSV file, and then then I get to work on fulfilling them in the near future. But so that's kind of how I started to dabble in programming. And then, in 2000, I moved from the Bay Area, except Cisco Bay Area, to Portland, Oregon thinking, I'm going to go live in a different city, I didn't know what was gonna do with my life, I just quit my job, painting houses. And I thought, Okay, well, I had to find a new job, what can I do, and I ended up applying a couple different places. And then I got a job during customer support at a company that had an internal software development team. And then over the next year or two, I had started building some internal tools for that company, to help them to basically make my job easier as a tech support person. And because we had like 200 employees, so I was helping people with their desk computers when they had issues. And so I decided to create like an internal intranet where people in the company could,
or I could publish, like how to documents for how to like, set your out of office reply without causing an infinite infinite loop with another person that's on vacation. Because back then, as a totally side note, we used to have software where, you know, when we would go on vacation for a week, or over the weekend or something, we'd say, you know, we'd set your auto reply if your email, and there is a silly bug or problem in the software that we use for our email servers, where if two people had gone on vacation at the same time, and they somehow got one of them sent the other person an email, or right around then, and then left for the weekend, we would come in on Monday with the email server being crashed, because those two email inboxes were just emailing each other back and forth constantly over and over and over until I ran out of disk space. And so, which was kind of silly. But so I started writing documentation and putting screenshots for our employees, so that they could, so I can basically tell them how to do that safely without it causing that sort of problem. And I did that for a bunch of things like that. And then I started building some little tools to help some of the departments do manage some of the there like they had, like, we had file sharing problems. And so I created a tool that would allow them like a department to share some files in a website, on an internal server. And that became really, like, helpful for different departments in the company. And, and then eventually, the we had a software development team on the company in the company that I was not part of, but they saw that I was doing all this coding on it for these some of these little projects inside the company. They're like, hey, do you want to come join us in over in this department, because you're actually writing code down doing some web development. I was like, oh, maybe. And then. So I, I did that. And I took up the job offer to switch to a different department. And I got to start learning how to properly write web applications. And now back then that was with Microsoft, ASP, and dotnet. And I had been doing a little bit of stuff on the side like outside of normal business hours with like things like Perl, and some other scripting stuff. But so I had some understanding of like, some basic shell, shell scripts, shell scripting, and some like putting like Perl scripts to process like, like CGI forums, things like that, back in the day. And so I started working with ASP, and dotnet projects is when that during that era of working with that company, and then at the same time at home, I was constantly working on some other projects, like related to political activism, websites, and things like that, where we had like news sites for people that can go on and publish articles. And so I kind of taken this PHP tool and kind of morphed it to be something that I could use with other people like a platform where lots of people can contribute like articles and stuff, too. And so through learning how to customize that in PHP, I realized that what I was learning during the day with my Microsoft ASP work, and at night with my PHP work that there is a lot of commonality between the languages in some ways. I'm like, Oh, I'm just translating this, like how do I, if I did learn something at night or during the day and one of those language I would go home or go to work the next day and try to figure out how to do the same thing in the other language. And so I kind of kept doing that for a little while before I realized I really wanted to work with open source technology. And so I in 2002, I decided to start my own start freelancing and decided to do that under 100 company name, which became planet Argonne back in 2002. So that way I could on the weekends, like maybe take some projects for that, where I would get to work with the technology that was more excited about which at the time is like working with Perl and PHP. And this is probably back in like 2002. And so that's how the company kind of started initially was me doing some side work. And then me after that, I ended up quitting the company that I was working at, to work at a really small software consultancy that only work with open source technology based in Portland, and I thought, This is perfect. And now I can now start getting introduced to working with Python as well, and still using PHP and some Perl and some projects, and got introduced to Postgres SQL as a database, because my boss at that company had written like an array, the O'Reilly book about Postgres, so I got to learn a lot of things under the hood about how that worked. And, and so through this process, I was like, Oh, I'm picking up to these different technologies. And people gave me some opportunity to work on projects. And I was at that company for maybe a little over a year, before I realized that I thought that I could probably do this just as good of a job as my previous boss was doing in terms of client management. And I was like, oh, maybe I should go do this by myself. And I can just do freelance work full time now. And then I can also focus more of my time on like, writing and playing music and my my bands that I was in. So that's how I kind of learned how to get into programming as well, just getting my foot in the door was, was kind of almost accidental, in that I had been at a job. And I was started dabbling with some stuff to help people with some of their problems. And so I would figure out and kind of, you know,
duct tape together some ideas on how in software to figure out how to help give them a solution to that problem. And I just kept, that was the part that I really started to enjoy it not so much wasn't the I didn't love the program. And in some ways, I still found it boring. And I think today, I still haven't read an entire programming book, remotely front to cover because I don't think it really suits the way that I learned how to do things. But I suppose having gone through that process of learning to program kind of, you know, over a period of like, I think if I think about that timeline, from 1996, when I first started doing maybe some basic shell scripting and like web form stuff to 2002, that's a good, you know, like, five, six years of time that I was learning a few little pieces here and there along the way whereby, you know, 2002 2003, I was working kind of on my own, with for clients and helping them with their projects It was so it was always about it wasn't because I wanted to become a programmer is because I kind of really got excited about building things for people to help them with like a business problem. Because most of my clients were like small businesses and stuff. And I thought that was really interesting. That part was the thing that I got excited about, oh, I can help you with that problem. Here's a tool to make that happen. But I'm really interested in talking about your business problem, and helping solve that. And so that became like a trend. And so that's how I started doing the first few years. And so I was doing, planning Oregon full time, and starting in 2003 2004. And then towards the end of 2004. I had been growing my my freelance work. And I'm still working by myself. I had it I also had a designer that I work with on a bunch of projects. And we kind of we partnered up on a lot of that. And she later became a business partner. But the initial thing was that we were working on at different things with PHP, and playing music. And then towards the end of 2004, I there was a job ad that popped up on Craigslist here us in Portland, for a PHP developer at a company called CD Baby. That was at the time, the largest online retail, like online store for selling independent music third, so as a general concept, if you were in a band back then, and this is like 2004, I think when this all happened, but around that I was in music, I played music and that like I knew who CD Baby was not everybody does. But anyways, they were they're pretty well known company and the music's seen. And they're located here in Portland. And they were looking for a PHP developer to come in and take over writing a lot of the code because the owner of CD Baby, his name is Derek seavers, who may or may not be pretty well known for some of your audience, but he had done most of almost all of the software development up to that point for the company. And he was realizing that he needed to, like get someone else in to help with some bigger projects. And so I applied for that job thinking, Oh, I'm going to stop doing Planet Earth and I'm gonna go work at CD Baby. And, and I'm just like, because that seemed like a dream job because I get to work with all these different like musicians and just get to play in our world and I get to use my toolset that I picked up and get to work in it. For I thought would be a really cool company. So I had a couple of interviews, and that will all sound really sounded really promising. And he gave me a verbal offer on the for the position. And this was like late 2004. And he said, and I remember, he was he interviewed me like in my living room one day, and we're chatting about this stuff. And he was not, he's not like a normal business person. He's on a completely different wavelength. Think like more like Richard Branson, but also kind of like, I think he was like a weird clown or something at one point, too. He's anyways, Derek seavers was an interesting was an important character in my developer journey, because he offered me a job before the before the Christmas holiday break, and said, well reconnect after, after the holidays after the new year, and we'll start talking about next steps and a great cool, though. And behind in my mind, I was thinking, Okay, great. I'm gonna wrap up a couple projects. And then in January in February, I'll start working at CD Baby.
Well, that didn't end up happening. He came back from his trip. And he said, Hey, I got some, I guess different news for you. I, I got stuck in a blizzard during Christmas week. And I was like, because he was on vacation. And I got stuck in a blizzard. And I had this book about programming with Ruby, and as a different programming language that which I hadn't really used at all yet. And he says, so I know. He said, I want to rebuild everything that we've done at CD Baby with Ruby on Rails. And I was like, Wait, isn't that that new thing I heard about like a month ago. I don't know that. I don't know anything about it yet. Outside of like watching like a video that the creator of Ruby on Rails had released, I think maybe November. So I probably saw that in December. So January, I'm having this conversation where he says, so I'm going to rebuild everything in Ruby on Rails, this new framework, because it sounds seems really exciting. And I know you don't know that know it yet. But I ended up finding a developer in San Diego, who knows how to work with this has been working with it for a couple months. So I'm gonna, I'm hiring him, and I'm gonna relocate him here to Portland to work on the project. If you can, Robbie, if you can pick up Ruby on Rails, Ruby on Rails in the next few months. I'll hire you then. And so if you're interested in like learning this and still interested in a job, and I said, Okay, great. That wasn't exactly the how I thought everything was gonna pan out. But I was like, Okay, I guess I'll take a look at this because I need to find work again, or something. Because all my I finished my freelance projects that I had on my cube. So I started diving into learning how to use Ruby on Rails. And this was probably a year before Ruby on Rails, one even came out. This is pretty early on. This is like 2004, early 2005. And as I started playing with it, I'm like, Oh, this is really enjoyable. And I decided there wasn't much there wasn't really anyone really too many people blogging about it or anything. And so I ended up started blogging about it, because I, I enjoyed writing some technical posts and stuff. So every time I had, I had a problem with something that I didn't really understand. And I figured out the solution, whether looking through the source code, or looking through the documentation, I would talk about it on my blog, I can't hit this problem with Ruby on Rails, here's my solution, let me know if you have some a better way to do it. Because we didn't get outside of like an IRC channel, we didn't really have a lot of online forums and groups to talk to you because there wasn't a lot of other developers yet using it. And so that quickly kind of evolved a little bit. So I started I ended up calling the blog, Robbie on rails, because I thought it seemed pretty clever at the time that it sounds like Ruby on Rails, but it's Ruby on Rails, me talking specifically about rails. And so I was doing that I was doing too much of writing for the first few months about Ruby on Rails. And I guess it's one of those scenarios where you're kind of in the right place at the right time. After that, Ruby on Rails started getting rather quickly some popularity. And within I think four months, I got approached by a book publisher to write a book on how to develop with Ruby on Rails, because it was this new hot thing. And I was like, what, like me? I don't, I don't, I've only been using this for like three months, but you talking about? So but, but that was like, at the time most about there was only like one or two people that have been using it for more than like six months. So it was still brand new. And so I was like, Okay, this is interesting. And so then when I got that book offer before I signed my contract for it, I thought it was a very different point. It was from a publishing company, I won't name them. But then I had this moment of thinking, Wait, they're interested in me doing it like, but they're not the publisher that I buy most of my programming books for from and that would be O'Reilly at the time. And so I was like, I wonder if O'Reilly would be interested in this. And so Mike, it doesn't hurt to ask before I signed this other contract. So I reached out to O'Reilly and pitched the idea for the book. And they gave me a better offer. And I was like, Oh, that was that's cool. So all of a sudden, like maybe four or five months after I started using Ruby on Rails, I had a book deal to write a book called programming rails, and which is a big, long, complicated story. But so I started writing a book. And so at this point, it's just me and a designer and working on this book project. Doing some stuff I was I was actually starting to get some client work with that was using Ruby on Rails at that same time. And I also part of what I also was offering was web hosting for company or for developers, because Ruby on Rails is pretty new. And there wasn't really anyone that was offering, like affordable Ruby on Rails, web hosting, so I decided I would offer that. And so I started getting a lot of people signing up for our hosting service. And again, behind the scenes, it was basically me and a designer, making that all work, but we had a couple of hundred hosting customers pretty like within the first year, I think, but the so that, I don't know, just kind of set off this weird chain reaction where I started getting more jobbing queries from people that wanted to hire me to work on their projects with Ruby on Rails. So that when I went back, and I talked with Derek from CD Baby about getting my getting a job there that we had talked about, he was like, Okay, great. So are you interested in coming to work for me now? And I said, I don't know. Because a year ago, I was like, scrounging to find like to compete for some freelance PHP projects, and all of a sudden, it sounds switched to people were asking me to come take full time jobs of their companies, and, you know, down in Silicon Valley, which again, I didn't want to work at, in, but there was this weird
period where I was kinda like, oh, there's a lot of opportunity coming my way that I, that I didn't anticipate, so why wouldn't I try to see where this would go. And so, so I start taking on more and more projects to work on. And then we got approached by some larger projects later. And I think, I think it was like maybe September of 2005, that were way too big for me to take on by myself for the designer and said, Well, maybe I can hire one of these developers that I've met at some of the local meetups that like go to like a Ruby brigade meetup that are that there, they had it, like there weren't really that many jobs in Ruby on Rails or Ruby yet where you could be a Ruby developer. And so like, oh, how about to be the person that starts to hire these people, and give them an opportunity to get the program with Ruby on Rails now. And so that's what I started doing. In October of 2005, we, we basically went from two people to think there was eight or nine of us working out of my, my house, his attic at the time, we had this one big room up there. And so there's all these tables who put together we had all these developer, like misfits of developers all working up there, on these client projects, and I had no idea how to run a business, by any means outside of we should probably spend less than we make. So it became like, that's how the company kind of started to evolve in to becoming an agency. So it was, wasn't something I originally planned on. When I started playing around as a company. It was like, Oh, I'm gonna do freelance work, under the name planet, Oregon. And, you know, a couple years later, it's like, oh, now I'm hiring people to work in Oregon, which was never the game plan. It just was an opportunity that presented itself and like, well, worst case, if this doesn't work out, I just go back to doing what I was doing before. So let's see where that goes. And so that was in 2005, where, you know, end of 2005, and now it's 2018. And they've had, you know, typically around 10 to 15 employees at a time since then, working at our company.
Robby Russell 33:06
Wow,
Tim Bourguignon 33:07
what a story. That is really, I love how it started and scratching, you're scratching your own itch again, I'm doing this consultancy, going to building your tools because you have problems and trying to help people and knowing again, into something, something that others can benefit from. Amazing.
Robby Russell 33:29
It's one of those things where I didn't, you know, I, it's I've never, I've never been a long term planner really, is something like my, my romantic partner she gives me a lot of hell about is that she likes she's a planner, and I'm not. And so it's kind of like this weird thing where I never I don't I didn't really have this vision for a man to create a company, I never thought I want to do be in a position where people would report to me in some way. Like, I was always really skeptical of management or any sort of authority in organizations as an employee. And so I was like, I don't want to ever become that person. And you know, of course, now 1516 years, 17 years later, whatever I am, I am kind of that person. And that's been an interesting transition. So, but, you know, I think there's always that, as you said, like scratching my own itch. But I there's, I think a certain level of being ignorant and naive play, it was probably really important to when I'm going to air quote, as my success. I didn't know what I was getting myself into. Because now it's always interesting when people come to me and ask for some business advice, whether they're thinking about starting a new company, or maybe switching career careers or something like that. You know, hiring people. I feel like I know too much now that I'm like, why would you want to do that? That's like a whole crazy path. You know, I had to kind of learn, you know, as I went, and it's not something I could tell people like well just follow this specific path and it'll work out well for you like, I think my I think in some ways, I've benefited from some level of privilege, and to some degree, but also, I think it was just too stupid to, to not to say no to things. And so I would just be like, yeah, I think I can figure that out. And I was. So it's always been like, yeah, I can probably figure out how to solve that problem for this business. And most of the projects, we worked on it, I've realized that over the years, like, maybe that's like your, I always worried that I maybe had a little bit of imposter syndrome. But the other part of it is like, oh, what I'm really good at is like, I can go in and have a conversation with, with, with some business people about a problem that they're facing. And I don't necessarily know how we're going to solve it right now. But I know that I can help figure out a way to make it happen. And so because I, I can do that I'm good at helping come up with a solution and do research and figure things out. But I'm not, I'm not necessarily the person that can. And I don't really know, I'm going with this question. So I'm gonna stop there. But
Tim Bourguignon 36:00
it's very interesting, I want to say ignorance, but
Robby Russell 36:07
I'm very aware that sometimes ignoring things and just going for it.
Tim Bourguignon 36:13
So possibly, design books is a is shrinking. by the minute, I wouldn't want you to finish without talking about the podcast, how your podcast maintainable software fits into this picture how he came to be.
Robby Russell 36:28
Yeah, so it's been this project, I've been kind of ruminating for a while. And if, you know, outside of being interviewed on some various podcasts over the years, we're talking about open source projects, one of the things that my company has really transitioned to focusing on over the last, you know, 15 years or so, is going from we used to work with a lot of startups to most of the companies that we work with, like that our our clients today and have been for the past five to 10 years have been companies that had software developed before they knew us so by other agencies, or freelancers, or internal employees that were software developers. So they come to us with a usually existing software code base, built with Ruby on Rails. And we usually come in to help improve the state of the codebase. And whether that be long term support and development of that project, you know, replacing a previous agency or replacing a couple of freelancers that used to work on the project, to becoming this regular client that we're now the ones responsible for it. And so, over from that transition of going from, like startups to existing software and making it better, we realized that that was actually an area that we felt much more passionate about working on, because those companies had already made a large investment, and they've proven themselves as a business that they can, you know, they can succeed enough to a know that they have budgets, I think, just from as a consultant, it's nice to work with companies that you know, are gonna have some money, you know, a year or two from now versus the, when you work with startups, and you're, they're bootstrapping, and you don't know if they're going to be around in six months or a year. And so you have to constantly keep defining new work. So we found it, we really enjoyed working with these businesses that had different sorts of problems. And the startup does, which thinks they're solving a problem, they don't know yet if they have product market fit, whereas these other businesses tend to have already sorted that out. So I think over the last several years, we've been talking a lot more and about maintainable software and best practices when it comes to refactoring and improving this quality and velocity of your development team. And that kind of like, went off it, I found myself kind of like, Oh, I'm really interested in talking about this topic a lot more, rather than I feel like a lot of developers and podcasts and literature talks about how to build things. Typically, like a lot of people going through a coding school, or if you're CS degrees, you know, they're usually working on new stuff, right? You're building something new with the technology, you're learning how to do that. But they're not always really well equipped to, like, start that first job where they are, you know, they come into an environment where there's already, you know, 10 years worth of software code existing and a code base from like, you know, several developers, and like, okay, you need to build a jump in and figure out how this all works. And I think we've seen in our industry, a lot of conversations kind of go from that to Oh, we need to rewrite this again. And I've always been a big advocate of not big rewrites, but rather focusing on kind of incremental improvements and refactoring things. And there is a way to salvage a messy codebase if you, you know, if you can prioritize it properly. And so what I really wanted to do is I felt like, there's a lot of developers that don't know how to talk to the business owners or the stakeholders on projects or project managers or product owners about the technical debt that their software that they work on, has, how much of it has accumulated or maybe they've asked like, hey, this, we know that this is outdated, or there's some problems in this area code. And they've asked, Hey, can we prioritize something in the near future to work on this and then maybe their stakeholders upset know if you do too many times, and so they, they just kind of give up asking and think like, well, they don't care, they're not gonna invest in it. And yet, they're still responsible for maintaining this piece of software. But they don't feel like they have any support from the other parts of the business to, you know, help them prioritize that work. And so what I really wanted to do with this podcast was speak with people that have figured out how to work through those problems with business within businesses so that maybe some of those developers feel stuck right now and their job where they don't feel like they can clean up things or improve that like work on an upgrade of some stuff or just some of those a maintenance tasks that you really need to focus on to make the to make a make the make make it easier for you to continue working on the software, and to speed up your development process. But I think just I just want to, I'm hoping those with these conversations with people that I'm having that though, they might get some like little nuggets of ideas about rephrasing things, or how to how to sell these ideas to people. So you know, within the organization, how to join companies where there's existing software, and how to make an impact effectively, and not just be someone that complains about the software, but rather the sub be someone that's actually can like, highlight how, if they address some of these issues, it's going to be better for the business. And I think software developers aren't often good salespeople for their own best interest. And so that's kind of the underlying goal of main, the maintainable software podcast is to speak with these different people in the industry to hear how they've solved that problem. Or at least give some ideas on how, what they would recommend to people listening on how they can solve those problems themselves.
Tim Bourguignon 41:39
Yeah, definitely a skill or necessary skills you have
Robby Russell 41:45
to sell and talk to business.
Tim Bourguignon 41:49
Speaking of skills, you've hired many people in the past few you say, in the past years, your your company was always something like 10 to 20 persons. vague, is there one skill that is very important to you, when you when you hire someone?
Robby Russell 42:06
I think, you know, I do think there's a it's this is a kind of a mixed one. There's obviously like, can you retain some information in your head about how the software frameworks were working with, you know, how they interact with each other. But I really think that I can under stated importance, at least with my type of work because we work in a consumer consultancies. So for our team members are constantly either on phone calls or,
or over our ticket management systems with our clients communicating back and forth on a regular basis about understanding requirements, and clarifying questions and, and giving updates on how it were their progress or where they're getting stuck or talking about how they need to work on something like cleaning up some technical debt, things like that. So I think writing skills has become something very obvious is an important thing. It's not so much that you need to be a great writer, but more that you can kind of articulate what's in your head a little bit and communicate that effectively to the right audience. And I think that's an important thing that if you're working with other peers and client and especially, I think with Client Services, being an effective writer, I think just helps demonstrate your ability to explain your, your, how your brain thinks about the problem. And I think if I often find that some of the people that I think struggled as software developers tend to not be as effective at communicating what's in their head. And that becomes a challenge. It's not, it's less sometimes, I know that I can put myself in front of a coding editor and solve write some code. But sometimes they don't know if they're working on the right thing, or they misunderstood the requirements, or they didn't, they weren't good at keeping stakeholders updated, because they didn't know how to effectively communicate that. And I think that's, that's an important thing. So it's like always communication, and probably certain amount of humility. So that I think that makes you probably a better team member, as a software developer, whether that be you know, amongst your team, or you're being empathetic of your end users or your peers or being empathetic to the people that used to work on the software projects you're now working on, because it's always easy to scapegoat, a previous person that's no longer there to explain why they did something the way they did it. So I think maybe, and so those are a couple things on the, you know, we call them sometimes soft skills in the community. And I think someone I recently interviewed on my podcast kind of explained that as like soft skills are actually really hard skills, and you have to work on them. And so if you think you've learned enough about communication you're at when you're applying for a job or you're at a university or something like that should be something you probably keep working on, is being just a good member of a team and be a good member of society. You know, being able to communicate your ideas effectively. Because if you're not good at that you get frustrated with people Don't understand you and that can be detrimental. And so on a technical side, maybe on the skill set, I think you know that I do appreciate people that are, you know, constantly looking at new technology. But I get worried that sometimes people are too focused on making sure they check off enough boxes for the resume. So I think I've heard the phrasing resume Driven Development recently has been a thing where they constantly want to work with new technology, because they want to make sure that you get that on the resume at the end of the day. And they get to make them seem more valuable. But I worry that sometimes people are getting to spread too thin across too many different types of technologies, like I check off all these boxes. But how deep can they get into any one of those checkboxes is another question. So I think sometimes, as a job as someone that's higher in a position to hire people, is, I wish it happened all less often. But there's always times where I'm talking with prospective candidates about the technology that we're working with. And they can't really talk about it that deeply. Yet, they, they're there, they're happy to list off that they feel like they've they're well versed in it but you know, today, they're not because they kind of like scratched the surface a little bit a bunch of things. So I think I would really recommend people to go deeper into a more of a focused kind of niche of, like a specific programming language or framework, like get really deep into it, versus trying to spread yourself across a lot of them. Because I think that just makes it a little bit more difficult. And it's never going to be the right answer on Is this the one to do that with is this the specific programming language or the framework to do like that, I should do that. Like, I can't, I can't read those tea leaves. But I do think it's something that I, there's a reason why I keep focusing on the technologies that we do, because I think we can get really deep into it. And we can be really, we really understand it. But I'm always curious about other technology. But I know that I'm just gonna keep I want to keep getting deeper into this, you know, to the similar model that I've kind of worked on for the last 1015 years or something. Thank you very much. Two very, very important advices. I agree to both of them. Thank you very much for that. Um, Robbie, Where can the listeners who can want to continue this conversation? Where would be the right place to? Yeah, so you can find me on Twitter, and on the internet under Robbie with a Y Russell. And then also, you can find my podcast, which is at underscore maintainable. Is our Twitter handle for the podcast and hope you consider giving a few episodes a listen.
Tim Bourguignon 47:34
I sure. I'm sure the listeners will do. I definitely advise them to try it out. Thank you very much. Do you have anything coming up? You're thinking?
Robby Russell 47:46
Not so much. I think you know, we're, you know, Paragon if you're listening and you're in the Western Hemisphere, or in West Coast of the United States looking for a job where we are hiring in over the summer, so I think that's one thing. I don't have any upcoming talks just yet scheduled, but helping to later in the year.
Tim Bourguignon 48:05
Okay. I'll link to your blog. You're probably gonna find advertisements. on there, right. Yeah. listeners, if you want to know where you can meet up in real life. Just log in. I'm Robbie, thank you very much. There was fantastic, very interesting story, a lot of things that triggered my endometriosis. I could talk for hours, but what he meant to timebox as usual, thank you very much. Thanks for having me. That was my pleasure. And this has been television will feature.
If you haven't subscribed yet, you can find this podcast in iTunes, Google music, Stitcher, Spotify, and much more. Head over to WWE WWF journey dot info. To read the show notes, find all the links mentioned during the episode. And of course, links to the podcast on all these platforms. Don't miss the next developer's journey story by subscribing to the podcast with the app of your choice right now. And if you like what we do, please rate the podcast, write a comment on those platforms, and promote the podcast and social media. This really helps fellow developers discover the podcast and those fantastic journeys. Thank you