Yeah. Oh. I completely recommend publishing your code. No matter what stage you're at, good things will happen if other people look at it. They can make suggestions and improvements, and you can be part of something larger. So don't be afraid of publishing your code, even if you don't think of yourself as an experienced developer. Hello, and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome to the Py Bytes podcast. This is Bob. And with me today, I have Will McCoogan. Welcome, Will. How are you doing? Hi, Bob. Very well, thank you. Yeah. Recording okay? Yeah. I'm happy to have you on the show. Yeah, I think, I hope by now a lot of people will know your name because of all the exciting stuff you do in the open source space. And, yeah, everybody's doing rich in the terminal by now, hopefully. But maybe for the people that don't know yet, may, you want to introduce you to our audience quickly. Sure, yeah. So, I'm an open source developer that's the most popular in the python community. Know me from a library called Rich for generating nice, pretty content in the terminal. But I've been doing open source for many years, and right now I'm the CEO and founder of Textualize, which is a startup that's based on my open source work. Awesome. And do you have a win of the week? Always start with wins. I think software development is all about little wins. If you don't count them, then it can get a bit depressing. Yesterday, I optimized some code, which was nice. I realized I was doing an expensive operation twice, and this was for every widget in the textual app. And I reduced that to doing that expensive operation once, and it got faster, and it was quite nice because it was relatively little code, but had, like, a measurable speed up. So I'd call that a win. Yeah, that must be satisfying. Yeah. Especially if you hit those speed gains. Nice, nice. Honestly, I cannot think of a win of mine. So I'm going to skip on that for now and also to just dive in. So, first, I wanted to ask you, how did you first get into Python? Were you already a developer before? What is your story? Yeah, so I've been a developer for my entire career, 25 plus years. And I started out in video games, and video games at that time were written in C, but we often use a scripting language to add simple logic to the game. So you don't want to write all your logic in C, you can use a more kind of friendly language. And I was investigating scripting languages to add to a c game engine that I was working on. And I went to see them all. I went Ruby and then Python and Lua and some others, and I actually settled on Lua because it was better designed for integration with a game engine. That's kind of what it was built for. But that gave me exposure to Python, and I found myself returning to Python to write tools and things. And those tools gradually got larger and larger, and I started writing more python than C, and I got to a point where I just liked Python much better. I've been learning C for years. I was very good at it, but it was still a headache to write because it's a very low level language and it's so easy to, to break things. So, yeah, I just kind of determined to, like, move my career into Python. And eventually I did. My first pure python job was working for the Internet chess club, writing a chess interface. And ever since then, it's been predominantly python that I work on. Nice. And I think you alluded to what you like about Python, the easiness, cleanness. Yeah. You said c, things can go wrong. So what appealed initially? Yeah, the memory safety. Because of C, it's very easy to write things to memory that you're not supposed to, and things blow up. Python was memory safe and also just, it was expressive. It took less time for you to build what you wanted to build. It didn't run fast. It's still, it's not as fast as C, but I consider that a worthy sacrifice because I could build the thing I wanted in a fraction of the time. Yeah, it's often said, right, it's not the fastest language, but then the developer time you save, that's the real benefit, right? Yeah, absolutely. And most of the time, it doesn't matter how fast Python runs, because it runs fast enough. So, yeah, I love Python. I'd go into other languages if I needed that speed up sea or rust, but I honestly find very little reason to do that. It just seems to run fast enough. Maybe not initially, but after a few rounds of optimization, we found that Python is just pretty much fast enough. Cool. One trend you mentioned already, you did that big interface project. There's also the ignored terminal right on your site. So there's definitely a trend in your work with interfaces. Terminal. What inspired you to create rich and textual. What's the backstory? So rich was first. Many years ago, I wrote something which was kind of like the prototype for rich. It was called console, and it was part of another project, and it was just kind of like a repository for all the kind of terminal related stuff. But it worked really well. And the design that I came up with, I often thought, well, that'd be great if I could factor that out into another library. And I sat on it for years, just in the back of my head, I wanted to build this thing one day, and then I just a few years later, I started it. It came together quite well and it fit my needs. And then I posted it on GitHub and it just kind of took off. I think people wanted this for a long time, probably without knowing that they wanted it, but they wanted it. There was lots of libraries to do terminal stuff out there, but they didn't work together. So you couldn't put wrap text inside a table and then a progress bar, because there were different libraries and they didn't know about each other. So I built something where it was all composable. You could put these things together in any combination you liked. And I think that's what made it, made it popular and that you don't have to assemble a whole bunch of disparate libraries that don't work well together. You can just have one complete system. So, yeah, and just. I published it and it took off and that kind of led on to textual a little bit later. Rich is kind of for static content that you display in the terminal. You've got like a scroll back buffer, but it wasn't dynamic. It wasn't designed for keyboard and mouse and interactivity. But I saw some people doing that. They would take Rich and then use some other library for keyboard and mouse and build apps out of it. And I realized how much potential that had. The previous libraries to do list were based on libraries that came out of the nineties and they hadn't moved on a great deal. And if you want to build one of these apps inside the terminal, you had to be very, very motivated because you had to work around lots of archaic stuff to get anything working. So I built textual, which it kind of borrowed techniques from the web world because I was a web developer for 15 years, and I built that into a library for building these apps inside the terminal. And, yeah, the rest is history. Techshow is it's not finished. It's probably not going to be finished for a long time, but it's very stable, and I'm really happy that people are building things with it. Yeah, amazing. So could you say, especially that web background that you bring that web development experience and the way we build web apps into the terminals, making the terminal much richer? Yeah. People have been working on frameworks for the web for really hard, lots of different companies and open source projects for like two decades, and they made lots of advancements, but none of that was coming back to the terminal, that the terminal just kind of overlooked. But a lot of these advancements are equally applicable to terminal. So that's what I wanted to do. I wanted to cherry pick the things which I think were worked very well, and essentially port them to the terminal. And the first thing I did was CSS. I mean, people thought that was kind of perverse at the time, and it's like, why would you want CSS in the terminal? But it served the same purpose as CSS in the browser. It separates the logic from the presentation, and it was a much cut down version of CSS. So it's not like I'm supporting all the browsers can do. I would just build a CSS syntax and rules which would expose things you need in the terminal. So it's much cut down and built other things in as well. Reactivity. So if you want to update something in textual, we just modify essentially an attribute and the interface updates automatically. So that's what makes it easier to use than the previous generation of terminal libraries, like cursors now. Interesting. And yeah. Are there any other or specific features, capabilities of the tools that you're most proud or proud or excited about? Yeah, with textual, there's all sorts of cool things. I really like the live editing. So you can separate the python code from the CSS code, and you can make modifications to the CSS code and the interface updates accordingly, which makes it very fast to iterate. I mean, if you had to change your python code, exit the app, run it again, get to that same state, that'd be quite laborious process. But with CSS, you can update things very, very quickly and iterate very quickly. So that's one feature I'm very proud of. Nice. And I also have a more generic question. How do you approach complex problems when building those tools? Because some stuff we see in these terminal apps that you're doing, like, wow, how does he even do it right? So there's a lot of design and complexity involved. So how do you approach complex new features or bugs even, how do you go about that? Essentially, it's a divide and conquer strategy. Things are complex not because they're big, because they're built of like lots of smaller problems. And when you divide a big problem into smaller problems, they become more manageable. So essentially that when I was building the CSS, you separate that into a parser, something which generates an abstract model, and then you have something which takes the styles and then renders them. So when you break it down into lots of little pieces, it becomes more manageable, it's less magical and less scary. It's just a collection of much smaller problems. And that's applicable to just about any code that anyone writes. Also applicable to life, I think. If you have a big problem, break it into smaller problems and tackle those independently. Yeah, yeah. Analytical thinking, but also, yeah, there's the software. Best practices go a long way then. Right. Like, as you say, like I make it parser and I'm going to embed this new feature, intermingle it in some code, and I'm going to build and a reusable class, like as a simple example. Right. And if you apply already that structured thinking, then I guess it becomes easier. Yeah, exactly. Your mental model should match your code. And if you break it up into smaller pieces like that and just use best practices classes to do ideally one thing, and then it just kind of falls into place. And that mostly comes with experience, I guess. Right. Developing software for many years now. Right. It does. Experience doesn't make you smarter, but it just means you got a large repertoire of solutions that you can pick from that you didn't have to think through every time. So that's why experience is good. Talent is good, experience compounds the talent. And you can work around. I do. I work around a lack of talent by, you know, using my experience, basically having failed many times, and eventually come up with solutions which I can apply again to future problems. Yeah, that's interesting. You say that there's a lot of mindset involved there as well. Right here. Julian. Julian would normally come in, the other Pywyte's co founder. And that's all the mindset. Right. Like, if you fail more, then you progress faster. But a lot of people struggle with this. Like, oh, what will they think about my code? They even publish it as open source. That can be tricky. Right? Yeah. Oh, I completely recommend publishing your code. No matter what stage you're at, good things will happen. If other people look at it, they can make suggestions and improvements and you can be part of something larger. So don't be afraid of publishing your code, even if you don't think of yourself as an experienced developer. No one's going to, you know, be insulting about it. They'll probably be complimentary. It's like, you know, tackle something and see what you can build. Yeah. Thanks for the permission. And if anything, if you get some critique, then you will learn from it. Right. So it comes back again to, like, failing. Well, it's not even failing, but, like, you know, the faster you get feedback, the better, right? Yeah, absolutely. Yeah. I think of it as iterating, not failing per se. Yeah, yeah. Start your year with a python breakthrough at pybytes. Escape tutorial paralysis and jump into practical just in time. Learning our personalized coaching beats imposter syndrome and sharpens your python skills. Join our Pibytes community, a network where passionate developers grow together. Whether you're a beginner or leveling up, we tailor the journey to your pace. Visit pibytesdevelopermindset.com. Now, this year, transform into the confident, in demand python developer you're meant to be. Your Python mastery begins today with pibytes. Check out the link in the description below. Talking about iterating textual, you can say it went from hobby to business, right? You said it was a company now. So can you talk a bit about that transition, how that was? Yeah, sure. So I founded Textualize, which is a company behind textual. Two years ago now, almost two years ago, I decided to take a year off. I was going to live off of savings, and I would build textual, and then I would build this web service behind it, which I could commercialize, and then I would seek investment. That was plan A, but plan b was I talked to VC called Costanoa. They specialize in open core projects. Opencore companies are a company that has some open source code and they have some other service which connects to the open source code, which they can commercialize from. So it's kind of a compromise between open source and capitalism. So, yeah, I was able to hire three other developers. So now we're a team of four developers working, three of us here in Edinburgh and one in Portugal. And it's a very good team. It's coming together very nicely. Wow. Amazing. So now you not only write the code, but you also have to steer or guide the other developers, right? Yeah, which is not too bad. They're all experienced developers. They got their own skill sets. The type of person that gets nerd sniped, you give them a problem, they're going to solve it, whether they want to or not. It's just like a compulsion. Here's a problem. They'll have to solve it. It doesn't take that much work to manage a team. It is a small team at the moment, so I consider myself to be my main role as a developer, just like the other guys. Part of my time is taken up by organizing tasks and keeping things up to date. But other than that I'm just a developer or code monkey is my preferred title. Nice. Yeah, I recognize that tool. You have to solve it. Strength is also a weakness in the sense that you have to stop sometimes. Yeah. Talking about challenging things, what has been some of the most challenging things you had to do on one of these projects or in your software career overall, have you even felt like giving up coding altogether at some point? I feel like giving up coding every time I reach a bug that takes more than half an hour. It can be very frustrating. Software development in general, you know, I haven't really. I enjoy being a software developer ultimately, even though there's points of frustration, I enjoy it. I think my biggest challenge is when I became CEO, and it's in this site, the part of the role which is not software development, talking to lawyers and accountants and VC's, that kind of thing. That was not in my skillset previously. It's just me sitting in front of a laptop writing code generally. So those are the biggest challenges I think I faced. Just doing the kind of business side, managing money and legal things and employment law. You'd be amazed how much of that there is just with a small company of four people. There you go. Yeah, I know. We see that with Py bytes as well. There was one time where we were just sitting in our dungeons writing code, and that's still what we love to do. And now all of a sudden it's a business and there's so many more things and also things that make you a little bit uncomfortable and you have to learn and say, like, well, the coding was actually relatively simple. I was frustrating at that bug, but this is a whole new game, right? So, yeah. Thing about code is you have all the solutions and all the problems and you feel like even if you haven't got it now, you know, with enough effort, you can solve it using knowledge that you've got. But other the business side, you've got to go out and find that knowledge. And you don't often know where or who to ask, so you're left with this kind of feeling that you're not capable in yourself of solving it. You have to go and find that knowledge or find the right people to ask. And that's challenging. Yeah. With programming, there's a brute force aspect. Right. Like, yeah, you know, you will be able to solve it eventually with enough effort. Yeah, yeah. Well, this is more about you put in the effort, but am I even going in the right direction? Right. Where do I even find the answers? Exactly. Exactly. And sometimes it takes actually, just like in the early days when you're learning coding, sometimes you go down a path and you realize, oh, that's not working out. You go to backtrack and try again. So, yeah, we're back to iterating. It's the same thing, really. Yeah. Getting to a state where you ask the right questions. Yeah, exactly. Okay, so coder, developer, entrepreneur. That must be pretty tough on your schedule. So, any advice for a sound work life balance, which I hope you have. Yeah, I really struggled with this. One of the reasons I was wanting to take that year off was to de stress. I had a contracting job, and it wasn't probably the most stressful, but the stress just kind of build up. But then when I founded textualize and there was just extra stress, I found myself working every hour where I was conscious I was working. And then if I wasn't working, I was worried about, you know, whatever I was going to be working on the next day. I think to kind of like, work around that, you have to set boundaries. I said, no coding in the evening. I started doing that just a few months ago. That was beneficial because I would code in the evening and then I'd be, I wouldn't sleep well, and then I'd be tired the next day. And so it feels like it's a productivity hack working in the evening. There's two or 3 hours in the evening, but in actual fact, I think it was kind of, it was kind of a negative productivity because I'd be tired the next day. So I think that's what the work life balance is about. It's like setting boundaries. You can still work very hard and then still have some downtime to relax and enjoy a meal. I think that's important. Yeah, that's a great tip, because when you work on your business, right, it can, it's almost like water flowing wherever it can go. Right. You're constantly working on it, and if you don't set the boundaries, it's, it's just, there's always more work. Right. And yeah, there's an infinite amount of work ahead of you, so, you know you're not going to fix it by spending a couple of hours after dinner. And York is also not only the business, because these projects are so popular right now and there's so many, you know, there's so many issues and things happening on GitHub. So I guess is your team now there? Can you delegate that to the team, or is the open source community really also taking care of part of that maintenance work for you? They are, yeah. So obviously the team's full time, they can put in the most work. But we do have a number of people who just like what we do and they're contributing and they're helping each other out, which is terrific. We do our support through Discord, but sometimes there's not a textualized dev there to help. But some other developers who are just building stuff with textual will jump in and help others and they'll do the same thing with issues. So it is a big advantage, I think it's a big business advantage. You've kind of got a big pool of developers who are working for free, you know, I don't know of any other industry where people will just volunteer their time to essentially help a business. I mean, the textual is open source, so everyone can benefit from it and add to it and everyone benefits, which is fantastic. Yeah, it's amazing. Definitely something unique for this space. Yeah. So what's coming next? Are there any future python developments you're going to leverage in your work? There's now this trend with rust speeding things up and being built in to certain libraries like Balintec. There's AI. Any cool things you're planning on integrating? Yeah, I don't think we're going to be. We did think about doing speed ups and C and rust, but we got it working so fast in raw Python that we're thinking that there's probably not much benefit. I am going to try AI two years ago, it's amazing how fast tech moves. But two years ago I thought of having a no code, low code approach where you could write a YAml file and you give it the specifications, like the layout and then the widgets, and that would build interface without any code. But now that I think that's been replaced by AI, I think we can do something better with AI. So you could say Docker header to the top, add a panel to the left, bind that to the t key to hide it, that kind of thing. And then the AI would just generate the python and the CSS. I think that's the next thing we're going to tackle, and I'm quite excited about that. That sounds amazing. Cool. So you're also a humanist photographer runner, so maybe you want to share a bit about these passions, hobbies and how they. Well, I guess they balance. That's probably obvious, but maybe also how they inspire you with the work and the coding. Sure. So I wouldn't call myself a runner anymore. It's unfortunate, but I got a slip discovery my back so I can't run. That put an end to my running career, the photography. I love photography. I haven't had a chance to do it since tech because I've been so busy, but I'm definitely going to take that up again. I was very excited about wildlife photography. I did some trips around the world. I took pictures of bears in Finland and Komodo dragons in Indonesia. That's my passion really. If I get the chance to travel again, that's what I'm going to do. I'm going to take my big lens and take pictures of amazing animals. Yeah, so I'm a humanist. I just mean someone with a non religious worldview with a focus on human beings for ethics and morality. And that does kind of like influence my worldview and my politics, I guess. Interesting. Cool. Yeah. I hope you get some time back for the photography. Yeah, one day. We always end with reading and books. What are you reading at the moment? Or if you're not reading anything interesting at the moment, what book would you like to recommend to the audience? I started reading interview with a vampire. I always liked the movie, the really old one with Tom Cruise and Brad Pitt. And then there was a show based on interview with a vampire that I saw recently and. Yeah, so I thought I'll just, I'll pick it up on my Kindle and start reading it. And so far I'm quite enjoying it. Yeah, I don't read much tech books. I think I used to. I used to have a library of tech books, tons, tons of them. Huge volumes, like really thick, buy the pound. But nowadays I just try to read fiction to just relax online. Yeah, similar story here. They're really good books, but sometimes also you read a whole bunch of stuff about something you're not immediately implementing. And pie bytes, we always say like jet learning, just in time learning. So you're probably just going to look up the docs and now chat GPT. To really get you the resource, you need azure coding. So sometimes, although these books are great, you just overload yourself with a lot of information and you might not apply it and then forget it. I think that's right. I think books are great for getting a grounding, you know, a foundational base for your knowledge. But I think once you've got a bit of experience, you know where to go to get and information. So if you're working on a particular library or a particular technique, you can look it up on the web or buy a book then when you need it. So I still love books. I still love tech books, but, yeah, I like the idea of just in time learning. You learn a thing that you need when you need it. Yeah. I'm curious though, do you embrace AI tools? Do you use chat GPT a lot in your work? I have, and for some things it's terrific. Darren, one of the guys I work with, he's very good at chat GPT and it's helped us get things up and running, but I found that it generates very poor code for tasks which don't need the grunge work, the more specific tasks it will generate that doesn't run. I think it's getting better though, which concerns me as a developer, and I think I'll be using it more and more in the future, but I don't think it's there yet. I don't think it's the best. It's not a developer in itself, it's a tool which you can use to get up and running quickly. But I think there's still plenty of room for experienced developers, luckily. Yeah. But yeah, somebody was saying, like, yeah, it's true. It spits out wrong answers from time to time, but also less so, I think. But then it's also becoming smarter, like exponentially. And that's really not that I'm worried per se, but it is something we might not just see how far that can get in one, two, three years, five years. Right? Yeah, it is moving very fast and I think our jobs are going to change. I think we'll still have jobs. I think there'll still be plenty of jobs for engineers out there. But how we do our daily work is going to change dramatically when the AI gets so much better. And you're right to say that it will, the speed that is. I mean, it's like two years ago, I barely heard of AI's that wrote code for you. So I think in another two years it's going to be so much, so much better and we're going to be using that rather than writing code in an ide tiding times. But also we have to see what happens. Yeah, yeah. Cool. Yeah. Thanks for sharing. I much enjoyed our conversation. Is there any final call to action you would have for our audience? Mainly python developers, of course. And the best way to connect with you. Yeah, you check out our projects, go to www. Dot Techualize, dot IO. You'll find links there. You can join our Discord channel where you can talk to me and other developers on textual, or you can follow me on Twitter. And I do like engaging with other people in the community. So, yeah, I hope to see your listeners there. Awesome. So now fasted on, you're still on Twitter or I am on faustodon. Yeah, I mean, I want to move away, but there's just so many people still on Twitter. Yeah, if you google me, you'll find me on Frostedon, not fostodon social. Mastodon. I can't remember some mastodon instance. Yeah, yeah, if you google it, you'll probably find it awesome. Cool. Well, thanks so much, Will, again, really enjoyed it. And yeah, thanks for all you do. It's just impressive. And yeah, coming back to that humanist standpoint, you're helping a lot of people. So it's really inspiring. So thanks for all you do. Thank you. Thank you. It's been a pleasure. We hope you enjoyed this episode. To hear more from us, go to Pibyte friends. That is Pybit Es friends and receive a free gift just for being a friend of the show and to join our thriving community of Python programmers, go to Pibytes community. That's Pibit es forward slash community. We hope to see you there and catch you in the next episode.