Welcome to PyBytes Podcast

Julian 0:00

A lot of what you just talked about. While, yes, there's a technical theme there, that's all very much mindset. When those server engineers or systems engineers came to you and gave you that feedback of you need to fix this, this needs to be better, I don't like this. Whatever the human response is, to take that and say I don't want to feel this embarrassment or this frustration that you pushed through and you just kept talking to people. Hello and welcome to the PyBytes podcast where we talk about Python, career and mindset. We're your hosts. I'm Julian.

Bob 0:34

Sequeira, and I am Bob Beldebos. 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.

Julian 0:46

Welcome back to the Py Bytes podcast everyone. This is Julian, and I have a special guest with me today, nick Park. Nick, welcome to the Pi Bytes podcast. It's good to have you.

Nick 0:55

Hi, thank you for having me.

Julian 0:58

Now so formal. Man, You're so formal. I appreciate it. It's not like when I chat with Bob. It's very too relaxed. No, I'm joking.

Introducing Nick Park & Zylo Systems

Julian 1:07

So, everyone, I'm very, very excited to have Nick here today. Quick background from me on Nick before I hand to him for a wonderful introduction. Nick and I actually worked together at AWS at Amazon Web Services years ago. At AWS at Amazon Web Services years ago, we connected on my very first trip to South Korea and I absolutely love Sol, nick and Nick and a few of the other people took me out and treated me like family and looked after me and we've been friends since and it's been wonderful, nick, to watch your journey over the past few years and super excited to talk to you today about Zylo Systems, a company that you founded, that you're the CEO of, does cool stuff with Python. So I'm going to stop there and hand it over to you, but that's why you're here today and everyone. This is why I'm so excited to have Nick on the podcast. So, nick, over to you, please share, tell us the story. What's the introduction you'd like to give to everyone?

Nick 2:08

Hi, my name is Nick. I'm currently founder and CEO of Zylo Systems. The Zylo Systems is currently building the Zylodops for server engineers who struggle to write really good A API documentations for their API consumers. And then the reason why I started to this business is that when I was working as a server engineers in Fliption, which is my ex-company, and then I needed to write documentation at the same time creating new features. So my daytime I usually work for creating new features and then at the night I need to write a documentation. Actually, I really wanted to spend my time with my family, but I need to write a documentation. Actually, I really wanted to spend my time with my family, but I need to write documentations for our consumers. I really wanted to wipe out this time to writing things. So that's why I need to come up with some ideas to do that. And then that goes to the Xylopods years to do that, and then that goes to the Xylopops. That is the brief introduction of myself.

Julian 3:32

Nice man. I appreciate the focus there on family, right? We're big on balance, bob and I at PyBytes, and we know how much running your own company, but also, when you're stuck in the job and the extra parts of your job role that aren't part of the day-to-day drag you into working into the evening, right, and you wanted that time. Yeah, that's really cool. So, all right, well, look, what we'll do is the way I want to have this conversation today. I reckon we should have.

Julian 4:03

It is let's talk about Zylo Systems first, and then I want to go back to this AWS stuff you used to do there. You mentioned Fliption, which I want to talk about as well, and your journey from AWS to running your own company, right, yeah, yeah. So for everyone listening, yeah, so for everyone listening, nick, with Zylo Systems is building just a system that will automate your API documentation, but let's dive into it a little bit, nick. So how does it work? And for someone listening to this podcast or watching it on YouTube, they're going to be wondering well, this sounds great, but how do I actually use this? What is it all about? So tell us, like, how does this work? How does this automate your documentation?

Nick 4:53

uh, yeah. So basically the way, uh, that you can use these allodops is to download the library right into your web backend framework. So currently Xylodops system is supporting for FastAPI, which is really fast-growing API, not API the backend framework and then after you install it, you should write some boiler codes onto the script and you can, after you run your local server on your machine, then you can access to the page. So basically it is pretty much same as like CMS the headless things so it could be run on the local and then you can access by local host URL things and then all the things is really similar like Swagger. So for developers, they don't have any awkward things. All the things are really similar to Swagger. So for developers, they don't have any awkward things, so you can use it as same as Swagger.

Nick 6:15

But the one thing that I really wanted to emphasize is that you can use AI service onto the page. So when I was a server engineer, in order to write really good documentations, I need to understand what the customers are currently, what kind of trouble the customer is currently having, and also let I should let them know how to solve their problems with the api that current that I'm currently building. So in that case I need to come up with some ideas to explain those kind of things. But uh, basically xylodocs helps that problem. So when you add context like what is this API is all about, and then how to use that, and then you can add that information into the Xylodocs.

Nick 7:20

And then, once you run the API and then it basically regenerates all the API specs based on the open API specs.

Nick 7:31

So once you run it you can get more detailed the name of the API endpoints, as well as description and summaries, and if some fields are missing, then Zalo AI also fill those information out, such as the example data or the description of the fields.

Nick 7:55

And then the one thing that our demo users really like is to create the test case for each API endpoints. So when we create these features, we used the raw open API which is extracted from the framework and then, based on that, we assumed some test cases which could be run on each API endpoints and then, by clicking and by testing the test case by the API consumers, which makes the audience understand how these APIs run as fast as they could, how these APIs runs as fast as they could. So that is the basically what we can say that this is the totally different things from the services out there. And then, once you satisfy the results, and then they also can share with their teammates or maybe partners in other organizations by sending the invitations through the email. So that is the whole, like our general process that ZyloDocs provides.

Julian 9:19

That is super cool. That is really, really cool. And so you obviously going back a second to the motivations here. You built this to save yourself time, right? Because if you were spending that many hours writing documentation and I hate writing documentation, I absolutely hate it even even just to read me on a github repo, I immediately think, oh so right now I'm I'm writing documentation for, or a knowledge base for, our platform, and it doesn't fill me with excitement, so this won't fix that. So, given how much time it takes to write documentation, especially for an API, you know API documentation is very specific and it's extremely time consuming to write. So how much have you noticed, have you been able to calculate how much time this saves?

Nick 10:17

So actually it is total, depending on how many APIs that you currently have and also who's your audience is. So depending on that, it varies a lot.

Julian 10:31

Right, that's a very ambiguous question in that how long is a piece of string? Everyone's use case is different. You're right, but from a typical, you know, just from a standard perspective. When you use it, do you notice it's saying like, instead of spending hours, you're now only spending minutes? Is it that kind of a difference?

Nick 10:54

You know. So for server engineers actually this is the problem. You don't care about how much it takes, especially for writing documentations, and even some people they don't know how important it is for the API audience. So actually this is not their high priority, so they usually write documentation as fast as they could. They think that this audience, they don't know. Actually this audience are currently having a hard time to understand the whole APIs that server engineers just created and then even the audience get to, audience read all these things they don't have any contact point to server engineers about. Oh, I don't understand this or I don't understand this. So measuring the exact saving time by using the silo docs is currently not recorded. But what I want to tell is that when you use these silo docs for your API audience, for your API audience, and then you can actually raise and then you can decrease the time your API consumer understands, and then that would be the point that I want to stress out.

Julian 12:41

Okay, no, that's cool. No, I appreciate that. That's really interesting. That's a really, really, really good point, especially for people who aren't writing documentation for apis, of course, but if you're not working with apis every day, um, where you're serving an api for people to consume, you don't often think about, well, what does the end user of this API expect to see? What do I need them to know to effectively use this API as efficiently as possible?

Julian 13:14

You know, you, as the creator of the API, you can get stuck in almost your tunnel vision of here's what I think they should know, but then someone who's reading it says, well, no, I need to know this, this, this, this, this. So you were talking about how you have LLMs wrapped into this right, or an LLM AI wrapped into this. Yeah, have you seen a huge difference in the quality of the API documentation now? So, for example, you said you've had some demo testers, right, did they immediately see an uptick in the quality of their API documentation now? So, for example, you said you've had some demo testers, right, did they immediately see an uptick in the quality of their API docs?

Nick 13:51

Yeah, sure. So in my case, before I started this business and then I understand the, I know the API, open API spec, but I didn't know there are a lot of features that I didn't know to. Our goal of Zadodops is to utilize the OpenAPI spec maximize. So by creating all the detailed information and by utilizing OpenAPI each specs completely, I think I'm definitely sure that we can make our API documentations fruitful. And then that is the main point of our siloed apps and then, which helps our API audience a lot, that's cool.

Finding the Right Audience in San Francisco

Julian 15:06

I like that. So you're bringing some actual quality, some standards, back to API documentation as well, which is pretty cool. Yeah, that's a really important point. These are things I don't think about right, and, as someone who doesn't work with production APIs all the time, but have seen APIs that are not perfect, you know so and quite often you don't know what you don't know. So sometimes, if you don't see it in the documentation, you assume that this API doesn't work, or that it doesn't serve the data that I'm looking for yeah, yeah. Or in a way that it doesn't serve the data that I'm looking for yeah, yeah. Or in a way that it should be presented Right, so, with rate limiting and things like that. So that's really. It's really cool, man. A quick break from the episode to talk about a product that we've had going for years now. This is the PyBytes platform. Bob, what's it all about?

Bob 16:00

Now with AI, I think there's a bit of a sentiment that we're eroding our skills because AI writes so much code for us. But actually I went back to the platform the other day, solved 10 bytes and I'm still secure of my skills because it's good to be limited in your resources. You really have to write the code. It really makes you think about the code. It's really helpful.

Julian 16:23

Definitely helpful, as long as you don't use AI to solve the problems. If you do, you're just cheating, but in reality, this is an amazing tool to help you keep fresh with Python, keep your skills strong, keep you sharp so that when you are on a live stream, like Bob over here, you can solve exercises live with however many people watching you code at the exact same time. So please check out pybytesplatformcom. It is the coding platform that beats all other coding platforms and will keep you sharper than you could ever have imagined. Check it out now, pybytesplatformcom. And back to the episode. I love this.

Julian 16:57

This is such a cool idea, especially that it came from your own need. I often hear that with people is that they build things to scratch their own itch, which is what we promote with PyBytes. Right, we talk about that a lot. Scratch your own itch, build your own stuff. And then here's an example of it forming a company and being something that people can use, they can pay to use and subscribe to, right? So, yeah, this is really cool. So you, you went to san francisco recently to talk about xylo, docs and and your company's system, right? So what was that about?

Nick 17:33

do you want to share how that went and what that whole conversation was like, where you went and all that stuff yeah, so uh, as you said, I recently visited to san San Francisco for two weeks, and then I met a lot of people.

Bob 18:01

And then I counted every people.

Nick 18:04

I especially talk with the engineers as well as technical drivers. So whenever I try to communicate with the server engineers in San Francisco and they told me, oh, this feature, this new feature, if you add this feature, then your product's going to be better. And then if you add this feature, this new feature, if you add this feature, then your product's going to be better, and then, if you add this feature, it's going to be better. And then actually their opinion is not that positive. So the first time I felt like, oh, I might this, because this will not, this might not help the server engineers to write documentations. They have their own way to solve that problem. But yeah, I felt this problem, who can understand my intention and things? And then at a very short time I was a little bit embarrassed. But one thing that I'm really happy about is that is to conversation with technical writers. So one of the technical writers asked me while I was demoing our service was that is there any roadmap for technical writers to use your service, or is there any way to use your service as a technical writer? So that question is really a big hit for me. So after I finished my demo I can communicate. I actually talked with him the technical content writers and he also gets some insights from my service, and that he introduced me to technical writers in New York. So we had a Zoom communication together.

Nick 20:12

And then there are two lessons while we were having the conversation. The one is that small and medium-sized company they usually don't have a resource to hire technical writers to increase their public documentation thing as well as internal things. And the second one is that technical writers take more care about documentation things rather than the server engineers. So that is the big lessons that I got from San Francisco. So when I came back to Korea, I changed my strategy to show and sell my service to the customers. I currently focus more on what exactly technical writers do for publishing the API documentations as well as internal things. And then what is the big difference between the technical writers and the server engineers for writing documentation? And then, yeah, I'm currently changing our API not API the Zylo AI not from the server engineers, but from the technical writers to make better API documentation. So that is the yeah, how I'm currently working.

Julian 21:54

Man, that is such a cool story. That is really really cool. Look, this aligns so much with the stuff we talk about, right, where a lot of what you just talked about while, yes, there's a technical theme there, that's all very much mindset, you know. So, on one hand, when those server engineers or systems engineers came to you and gave you that feedback of you need to fix this needs, this needs to be better, I don't like this. Whatever your, your, the human response is to take that and say I hate, this is terrible, I'm gonna shut down my company, I'm gonna run away, I'm gonna hide. I don't want to feel this embarrassment or this frustration or feel like I've done all this hard work. I mean it's, it's human to feel that way, right? But you push through and you just kept talking to people, right? Not?

Julian 22:47

everyone is going to have the same passion for what you do and believe in what you're building as someone else. Everyone's going to be different, and so you found your audience right. And back to that earlier point is that networking if you just keep talking to people, you will find people who can lift you up, not just tear you down. And so now you've found this whole audience of technical writers um, engage with what you're building, which is really cool. Um, yeah, I love hearing that, and so do you see. So when you talked about changing the AI, you mean changing its kind of instructions to be more around what a technical writer would want to see. Is that what you mean?

Nick 23:33

Yeah, right, right. So technical writers really care about who the audience is for their documentations and then, since they started from with engineers, to understand the product which can make their documentations better. So that is basically what the technical writers usually do. And then, yeah, understanding how they work and what the important things for them is really interesting. It's really interesting, and then I'm happy to know that.

Julian 24:23

Yeah, yeah, yeah, and it's funny because you consider that wasn't your area of expertise over the years right, um, at amazon and yeah, so it's, it's cool, I'm, I'm with you, you know. Similarly with with pybytes, with the way we're going as a company, there's a lot of interest in what we do from corporate social responsibility, so the whole getting out into the community and helping people learn to code and having a company pay for that, that's something that people have engaged with from from my end. So I've had to change how I talk about these things with python, um and our coding platform to kind of suit what they need to hear and what they want to hear and what, what is important to them.

Julian 25:11

So, um and, and whether someone understands what a function does is not really important to those people, so I have had to change my kind of communication style to suit them. So this is really cool. I love that, but again, it came from just getting out there and you, I mean you flew to san francisco, man, you're in, you're in seoul, right? So, um, you flew halfway across the planet to go have these conversations. That's incredible. So I'm super impressed, man, amazing, thank you.

Nick 25:42

Thank you, yeah, but actually this is not my first time to visit San Francisco. This is basically fourth time to visit San Francisco.

Julian 25:52

Yeah, okay, so that was not bad. I remember you went to Fliption.

Nick 25:55

Yeah right, when I was in Fliption I also visited San Francisco twice, and then I spent like three months in New York last year too. Wow, that is the way that the Philipsion usually go abroad for their market discovery. So while I was in there, I think I'm accustomed to how they work, so that is not a big deal to visit in San Francisco.

Julian 26:34

It is for me, man, it is for me. That's really cool. I love it and I like that. You know this concept, right, you can build something. But you know, we've often mentioned this before with our coaching clients. You know there's this something that they some quote out there build it and they will come right. It's not true. You build it and no one knows about it, right? So you have to build it and then market the hell out of it, get out there and talk to people and attend these events, these hubs and things like that. So that's really, really cool. So look, so I love what you've done with Zylo Docs. At the end, we'll get to how people can learn more. I'm going to send you an invite into our Python community as well, because I'd love for people to come and chat with you about it and you can share it in there and all of that.

From AWS to Entrepreneurship

Julian 27:24

But one of the things just changing topics for a little bit, I wanted to go back to your time at AWS, when we met, so to give you a bit of background for everyone listening. We see a lot of people wanting to do what you've done. We see a lot of people wanting to do what you've done right. We see a lot of people who are in technical jobs or in whatever their corporate job happens to be and they want to build something for themselves. They want to take an idea and they want to build their own company, create their own open source software startup, whatever it happens to be. So when you were at aws, you were a technical trainer training people on all the technical stuff of aws, stack and cloud stuff. How did you get to xylo systems from aws? You went through a company called flipshin, which you can talk about in a second, but talk to me like this move from aws Fliption, if you can. How did that happen?

Nick 28:22

Yeah, so I was a work for technical writers. I worked as a technical writers for AWS almost like two and a half years.

Julian 28:34

Technical writer or technical trainer.

Nick 28:36

Oh, technical trainer, technical trainer. Sorry, okay, I was going to say, yeah, technical trainers for two and a half years, and then, while I was working as a technical trainer, I usually meet developers and then the IT operators who wanted to use AWS cloud technologies, and then my goal was to learn cloud technologies as fast as I could and then let them know how you can use these technologies to solve their problems. So that is the way that I work usually works. And then you know, this is the really interesting part is, but when you teach them or when you're consulting them, the most important thing is documentations. So let's say you wanted to use the CLI. So let's say you wanted to use the CLI or AWS consoleets that you have in your documentations, and then that makes your audience do something better actually.

Nick 30:15

And then when you have more latest captured image and then the right code snippet, and then that in that situation you are if you are a lecturer, and then you need to teach something to your, your, your, your students, and then they don't ask you about, oh, this is not working, this is not working things, and you can have your free time anyway. So that is the most important thing for me. So in that case, documentation is a really big deal. So, uh, the tech. As a technical trainers, you need to learn about the technology technologies. Uh, very well, but at the same time, you need to write really exact documentations for your students. So that is the most big part. That was the most big part for me when I was in AWS as a technical writer technical trainers- that's cool.

Julian 31:14

I think we have a lot of people in our audience who are trainers as well, so that's a really good point. If, if people are, if you explain a concept and people are just start working, that's a good sign that you explained it well and had the right documentation and paperwork for them. So that's really cool. And so how did you get to Fliption? So what was Fliption? We've mentioned it a few times and haven't explained it. So what was Fliption? And how did you get there from AWS?

Nick 31:44

Yeah. So when I was in AWS at the very first time like one and a half one years, the very first part first time, like one and a half one years that was really happy for working as a technical trainer. But the more I learned about the state of the art technologies created by AWS, I felt like, oh, I want to build something, I want to build something. And then, yeah, that is actually the motivation that I want to do some different challenges. And then one of my co-workers who also worked for AWS introduced me a founder of Flipsion, and then that was the start to go to Flipsion after I quit AWS. So for Flipsion, flipsion is Flixion provides the generative AI technologies to fashion and beauty industries who struggle to hire a real model to take a photoshoot of their product, their product.

Nick 33:17

They usually our consumers usually deal with some like t-shirts or sweaters or all the different kind of like outfit, and then they need to, yeah, clothing stuff and then they need to sell those things by taking a photo shoot with model.

Nick 33:40

And then if you want to sell those products to the global, then you need to consider different culture and races. So when you want to go to the United States market, you should think about the race, not only in asian, but also thinking about the white, black and caucasian and etc. And then so to sell them, uh, using the uh, the white and black, caucasian, asian all different types of models should be used for taking a photo shoot. So in that case they would use a lot of resources to create them, but by providing the generated AI tool that can create the virtual model that you can control all the rays, raise and height and then pose things, and then we let the users to use those kind of technologies without taking a real photo shoot, so that could decrease a lot of resource for distributing the only contents related to the products, and then that is the value that we could provide to the beauty and fashion industries. That is, that is the way the pollution currently doing.

Julian 35:13

Yeah yeah, I remember when you started working there and we spoke and I looked into what, what it is that flipsham doing. I thought it was just a really smart idea, because it's stuff that you don't consider, you know, and so, for example, if you're selling fashion or clothing in Korea versus, say, china and Japan, you want to make sure that the models wearing your clothes sign represent the country that it's being sold in. Oh, people want to buy stuff being worn by people that look like them. You know it's. It's human nature, right? You? You see yourself in that clothing. When you see someone if I, if I saw someone that doesn't look like me wearing clothes, I find it harder to see myself in those clothes. It's just a mental thing that we do. Yeah, it is.

Julian 36:01

It was super cool, and I remember seeing the quality of the pictures. I was like this is actually pretty scarily good. Like I thought I was going to look kind of, you know, dodgy, being AI, but I was like I'm struggling to tell the difference sometimes. This is pretty cool, so that's cool. So you're a systems engineer there, or what were you doing there at Fliption? And then, how did you, when did you make the flip, the Fliption? Sorry, that was a terrible joke. When did you make the choice to build your own company with Zylo Systems?

Nick 36:39

Yeah, so when I was in Flipstrand, I was a server engineer from the beginning, but after three months later, our founder asked me to be co-founder of their companies. And then, yeah, I accept that. So I was a co-founder and then also the server engineers in the company. And then, yeah, since I was a co-founder, I could make my role broad than the server engineers, could make my role broad than the server engineers. So I didn't just do the server engineers thing but also do the business side things as a product engineers. So that is the way that I usually work at Flipshine. And then actually it was almost like one and a half years later.

Nick 37:41

From the start, as an indie flip trend, I was a product engineer, so I could have a lot of opportunities to meet customers, especially in beauty and the fashion industries. So when they look at the images created by generative AI, they have really high quality bars. They have really high quality bars. You know we have the same eyes, but the quality that they could see on the image is way higher than me. So I cannot imagine how detailed they could see on the same image. So that makes me really shocked. And then I don't know. And then also, if you visited Korea. In Korea there is a Dongdaemun site, so Dongdaemun is really famous for fashion industries there. And then, in order to sell our service, I went there and then I printed, printed out all the you know, the files, uh, informations of our service, and then I uh basically gave to packing all the clothes and then they need to deliver it to their customers and then they need to write all the documentation things.

Discovering True Passion and Purpose

Nick 39:46

And then that makes me think about, oh, creating image with generative AI is not a big deal for them. So what is the most important thing for them? And then, can I really solve that? Do I have any passion to help them? So that is the question that I want to ask for myself.

Nick 40:17

And then my question was no, I would. I want to spend my time to audience, that I really want the audience that has a problem that I really want to solve. And then, what is that? What is that? That is the actually my question, when the almost end of the time in solution, and then the problems that I define is the documentation things for the engineers, and then that problem is the thing that I really want to solve, and then I can problem is the thing that I really want to solve and that I can yeah, so that is the point that I want to and that, yeah, that is so when I decided to do that, I started to talk with more server engineers who struggle with the documentation thing and then from that dialogue I started to design the problems.

Julian 41:34

Yeah, that's cool, and there's a couple of points that you've just raised there beautifully that I want to pick on a little bit, which is just it's okay to change careers, it's okay to lose interest in what you're doing, it's okay to realize that you don't have a passion for the work that you're doing and the problems that you're solving, and you don't have to be to tie yourself to it for the rest of your life. You know, some people would sit there and say, well, that's not the point. The point is that I have to work, I have to contribute to society, I have to do this job. This is what I studied for my entire career, so I'm going to stay. And they don't ask themselves that question of do I actually care about this anymore? Do I the? The problems have changed that people are having. They don't seem to. This isn't an issue I care to help with. I'm better suited to help people with these problems versus that problem, and so I think it's a really important question that you asked yourself, and it's pretty impressive that you I'm really impressed that you sat there and had that conscious thought and said no, really impressed that you sat there and had that conscious thought and said, nah, I'm done, because being pulled in, and especially being promoted into a position as co-founder there's a lot of pressure there and I think a lot of people would sit there and say I've just been brought into this or I've worked my way into this position, I don't want to give it up, or I shouldn't give it up, I should, you know whatever, but I think that's a really, really strong, important step there.

Julian 43:10

And then, obviously, as we've talked about, you scratched your own itch with writing documentation. So, man, this is such a cool story. This is a really impressive journey. I'm I'm so happy to see. I mean, what is it? It's been three years since three, four years since we met at AWS.

Julian 43:29

Yeah, it is it is and, um, yeah, I won't share the story of that first night that we hung out. I will. I will say everyone that that Nick's Everyone, that Nick's, I think, manager at the time told Nick do not let Julian go home, take him out for another dinner. So that was dinner number three that I had that night. So he took me out for my third dinner. Yeah, it was wonderful.

Nick 43:58

I think we had tokboki and stuff like that and I was just Ah, yeah, that was a really good place, that that was really good place, that was really good place. And then we almost drank, uh, at the midnight, at the midnight right, because we were back to my hotel and went to the bar. Yeah, right, right yeah yeah, I remember the day again if they.

Wrapping Up and Book Recommendations

Julian 44:20

You know I'm not just going to indulge. If there there's a lesson in that it's always take the time to spend time with people, you know. So if there's a an opportunity, even if you don't drink alcohol, that's fine. But if there's an opportunity to go out for a drink with someone, take it Even if you're tired, even if you're jet lagged, like I was. Just go and do it. You know, you never know. And here we are for three, four years later having a chat about your company, right, which is amazing. So all right. So look, I know we're out of time. I just want to say, nick, firstly, where can people find you? And I'm going to make sure you join our community. I'll introduce you there so people can chat with you and share stuff about what you've built. But how do people, how can they get in touch with you if they're introduced sorry, not introduced if they're interested in learning about xylo systems and xylo docs?

Nick 45:10

yeah, so there are two links, uh that I'm currently uh provide to the audience. The first one is our landing page to uh introducing the xylo docs, and then the second one is the. It is currently uh distributed as a python package and then you can download it through the pit and then, so, uh, those are gonna be sent to the uh julian, and then you can enjoy that cool.

Julian 45:36

I'll put them in the show notes and um, we'll share it out in the email and everything as well. That's, that's very cool, and I I will also put your LinkedIn on there in case anyone wants to connect with you and follow your journey as well. Hey, everyone, a quick break from the episode to introduce you to our brand new coaching program, the PyBytes Developer Cohorts. Now, these are cohort programs typical of a bootcamp style interface, of working together with a group of other people, except it's got that unique PyBytes twist on it, where you are going to be building all day, every day. There is very little material that you will be consuming, so you won't be stuck in that tutorial paralysis.

Julian 46:16

The point here is that you will be building from day one and alongside other people also building the same app in their own repositories. You can all talk, you can all share, you can all grow together and, of course, you'll have a PyBytes coach supporting you the whole way. So if you are interested, just check it out, click the link below. It is pybytescoachingcom and we will see you in the next cohort, all right. So one thing I don't know if you're prepared for this, but we on the podcast, every time we end the episode, we talk about a book that we're reading. Did you happen to? Are you reading anything at the moment?

Nick 46:54

I'm recently starting to read Shudok, which is all about the Nike the Nike story yeah, that's cool. So that is the book that I'm currently reading.

Julian 47:10

Yeah, no, Bob actually gifted me that book a couple of years ago for my birthday. He sent me that book for my birthday. It's a good book. I liked it.

Nick 47:21

Yeah, okay.

Julian 47:22

Well, I only recorded a podcast with Bob a couple of nights ago, and so what I'm reading has not changed. So I'm not going to mention the books that I'm reading, although I did actually start reading the Three-Body Problem. Three-body Problem yeah, there's a Netflix show on it, but it's a sci-fi series, you know well, before it was a netflix show, um, but the netflix series built a lot more popularity on it. So I'm reading the book and, um, it's incredible. I the first few pages just hooked me straight away. So give it a look. Um, all right. Well, nick, is there anything you want to say to everyone before we go? Any parting words of wisdom? Anything at all?

Nick 48:09

Yeah, use all the dots and then give me some feedbacks and then I'm really open to that. And then, yeah, any opportunity, collaboration, why not Contact me?

Julian 48:22

I love it, man. Thank you All right. Well, look, thank you, nick. Nick, so much for joining me today. It's just pleasure catching up, as always, and chatting, and um, hopefully I can make it out there to see you um, one of these days. Fly out to korea, it would be nice to go back. Um, yeah, thanks for jumping on the podcast thank you, thank you, thanks.

Julian 48:42

Thanks everyone for listening. We'll be back on the next episode next week. See you all. Cheers. Hey, everyone, thanks for tuning into the PyBytes podcast. I really hope you enjoyed it. A quick message from me and Bob before you go To get the most out of your experience with PyBytes including learning more Python, engaging with other developers, learning about our guests, discussing these podcast episodes and much, much more please join our community at pybytescircleso. The link is on the screen if you're watching this on YouTube and it's in the show notes for everyone else. When you join, make sure you introduce yourself, engage with myself and Bob and the many other developers in the community. It's one of the greatest things you can do to expand your knowledge and reach and network as a Python developer. We'll see you in the next episode and we will see you in the community.