Code and the Coding Coders who Code it

Episode 5 - Sebastian Wilgosz

Drew Bragg Season 1 Episode 5

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 30:50

On this Episode I'm joined by Sebastian Wilgosz of Hanami Mastery. In addition to all things Hanami, we discuss the challenges of writing good documentation, helping to build a community, and the value of giving back to Open Source.

Links:

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show

Hello, everyone. And welcome to another episode of code and the coding coders who code it today. I'm joined with Sebastian from Hanami mastery. CEP. Why don't you introduce your. Hi, it's nice to meet you again and being a part of the show. So yeah, I'm, I'm a Ruby developer. I'm set. Recently I started the Jaime mastery initiative and have a lot of super fun with it. But I've a lot of learning as well. Yeah. And then I'm super happy to be here. Yeah, we're pumped to have you. so for those of you who don't know the way this is going to work is I'm going to ask sub three questions. The first one's going to be, what are you working on? And this could be work-related or it could even be your personal projects. Then we're going to talk about blockers. Do you have any, or if you recently had one that you were able to solve, how would you solve it? And then we're going to wrap the show up with you having an opportunity to share anything. Fun. Cool, interesting. That you've recently learned or discovered it doesn't even have to be coding related. So with that being said, Sev, what are you working? I have two ongoing projects right now at first of all, it's the Jaime master initiative, which is 50 or, and like blog blog related, like joined mixed thing. So. I'm not sure if you are very aware of Hanami project, but I discovered it last like three years ago and I fell in love with, with it. I am not this, that there were some troubles there related to this project when I was first of all, waiting if we can use it in our company and the, decided to address some of them by starting the video tutorials on YouTube. The second project I worked in con right now is the official enemy the condition guides, which I'm trying to contribute as much as I can aside of my full-time job. That is awesome. Documentation is never easy, especially if it's not your full-time job, do you have a. Certain approach or a workflow that you have for finding the parts that you want to document and then explaining them in a way that works well for beginners and experienced developers. Well, this is a good question. it, I think depends on how, Different projects are structured, but what I noticed in HANA me and a whole related family, gen families as that, those projects are extremely well documented themselves by using the inline documentation and the test coverage and it applies to the roam, a dryer B German families, and also the whole dynamic components. Let me, cause all of those libraries are maintained by the same people. And I was extremely surprised. So the first part of the guides was the rotor part. I choose the simplest and the less complicated component to document. And I just went through the test coverage and it just documented three. So there are some parts of this the computation phase, which are just effortless because of the quality of the components, the light diversity itself, and also the the inline, the compassion. And that is just a common practice here. And there, there. Easy part is the fact that anime is still in alpha. So when I'm trying to document things, I need to sometimes really wait for features to be completed or or I'm aware of that API can change very soon. So I pushed back some work that on, on it, and this is the harder part to figure out. But fortunately the team can very easily support and point the priorities of what can be diplomatic. The first one is more stable. What can be worldwide? We can start from. Very cool, now you had said that you kind of discovered, Hanami when you were at work, evaluating it for a project. Can you talk about that? A little. Yeah, we work. We were working on the job platform, leading job platform in Switzerland, and we used rise for it. For 10 years. I mean, I didn't work in this company for 10 years, but when I joined, it was like almost 10, 10 years. All right. This project and the team faced some troubles with scalability and. Maintaining the growing complication. So we tried to figure out solutions around those, those problems. And we started to reorganizing the fires to not follow the L the rise of. Of things and extend our architecture. Not only rely on models, fuels and counselors, but trying to find another abstractions to figure out where to put some parts of the code. And we tested several approaches. And we tested that trailblazer, for example, to, to extract the business domain out of the system. And we also try dry libraries to, to just do it. And we worked on this internal architecture for around three years and. After a while we started at the thing that maybe other people can also have similar problems. And this is where we discovered, or I discovered that Hannah me, thanks to that tool. One of my teammates, I was extremely surprised that. When I just got to look into the project, is that a lot of philosophy, a lot of approaches and concepts were shared with us. Even though this team were completely independent and that was a mind blowing because completely as in her nose, not team figure it out. Way better solutions to the same problems we had. And that was, that was amazing. We tried to patch rise because it sounds. Easier, but Hanami team actually decided to do the complete framework from scratch and that was tremendous, tremendous work put in, but definitely something that will be. You asked how, how I discovered it and I just observed and I progress. And when I thought. We can try it. I was able to convince the client to evaluate the project because the the system worked with microservice based approach. So we were allowed to experiment a little bit with some smart services and I just started to write a microservice. Within Hanami it was pretty alpha version was very early development phase, but I was surprised how stable it was actually. So I was managed to create a complete solution. However after devolution I decided not to go with this because it was too early. It was just a two yearly. There was no community behind it and no learning resources. And that was. That was, that were the mind obstacles I faced, right. Community is such an important component when you're dealing with these, any kind of open source, anything having a strong community behind it is going to be paramount. But so you opted not to go with it in this particular case, but you are using it professionally. Oh, yes, yes, yes, definitely. So yeah, I, I figured out that there were some troubles with documentation, with learning resources available on the web and the community. And so. I instructed my client not to go with the enemy just yet, but I also fell in love with Hanami because it was just a great project. And I was, I was just surprised. So what I did is I started the anime master blog to actually solve or address some of these. Problems. I figured out I really wanted this project to succeed and I'm only one person, but tries to just do my best to help with it. So I started publishing the learning content with the idea that at least every 10% of all the income I get generated will be Gave away to the HMI team or yeah, they had an army development team and that started very small, like from, from a dollar dollar per month. But it was really cool because in the single project I actually started addressing. All the issues I found like the two small little team, like small team was because not enough support, not enough coming community by bringing the content to the web, I can engage more people and make more people interested in Hanami. So, you know, like self fixing machine. Yeah, and that word starts. So, but after a while, I figured out that there is a lot of overhead when I'm doing the research around Hanami project. And when I'm trying to write after the work and record videos and edit them and publish them and try consulting with the Hanami team, how to do things better. But on my daily job, I worked with fries and that was just too much for me. So I grew up to the decision to change the company, to work full time with Hannah me on my daily basis, which reduced a lot of overhead and saved a ton of time about around the restaurant. Yeah, I can imagine getting to both learn and write and work with one framework is going to be substantially easier than trying to do it in two, especially because from my admittedly limited understanding. The philosophies of rails and Hanami are very different. Like they both use Ruby, but their philosophies on how to build out. And, and how their architecture set up is, is pretty different. Yeah, the, there are a lot of different things and unifying, this is, it's very important. Think in my head, I like it really simplifies things I'm doing and it's also called because all I'm doing is whenever I'm doing something. I'm trying to find like win-win situations or two or more sites are benefiting from the same work. And this is exactly the case. Like just by changing the job, I was able to start publishing the content where the company I'm working on actually benefits a lot because they really want their developers to be more educated. Right. And. Yeah on board that easier. So, and when I'm doing the work, I was doing the research at the same time. So yeah, that, that, that, that is one of the, one of the benefits and the, the. Other other great part was that from all this work, the HANA project benefits at all as well, and the team and development, like everything just, just wins in this situation. That's what that was. That is something that I'm proud of, I think. Right? Yeah. No, that is awesome. Especially the way that you're able to do this work, not just for. Your personal project and then your company that you work for, but how it trickles back to improving the whole framework itself. And you actually said something that kind of piqued my interest. When you were talking about you're writing these blog posts or you're writing content around how to use the framework. And you talked about it being a lot easier to onboard developers when they have that. And you would also talk about it, your last position, where you guys tried to essentially patch rails and build your own architecture to solve your problem. What, what kind of benefit do you see between using something that's very open source and using something that you build internally? Like how much easier is it when a developer can find their own resources versus have to figure out who to talk to in turn. To figure out why does this thing work this way? Well, if you develop anything internally, you have very much easier time in maintaining that because you don't think. You don't need to care about other people. You don't need to care about other projects using it. You don't need to about care about vegetables. All you need to care is about. It's just your team, your consensus what you agreed on and your style, right? You don't need to be super strict about test coverage. If the company please. It's not right. You're not going to care too much about code styling if there is no pine for it, but all those things start to matter when you release project to the public because you can, you need to be very, very, very strict about security patches, the security bags, and. this introduces a lot of overhead the company. From my personal point of view, when I started working on open source projects or releasing my knowledge to the public, I benefited like crazy from the feedback I got from the community from other ideas people have often the word, like much smarter people than I was so. Whenever I'm trying to work publicly on something I deliver at the end much greater equality. So this is a trade-off for the company. Definitely. Definitely. It's easier to just, just work on, on something internally. The price you pay for it is that you learn and your team learn much less. Yeah. And I mean also if something, even if it's not an internal project, like you're trying to onboard a new developer and you have to bring them in and you have this custom rails architecture. And you have to try and get them up to speed on that. You can only use your internal documentation really on, Hey, this is why we made this decision, or this is how we do this. But with using something like NAMI, you end up with what is an up and coming community to kind of help almost offset some of the onboarding struggles, because if someone's looking at something, they have, you know, that things, documentation or stack overflow questions. And how much do you think that is? A, is a huge win for using the right open source tool versus just trying to force an architecture where it may not belong. The documentation really matters. What I learned is that the condition is very, very important part and a lot of open source products struggling. And if you have great documentation and a lot of problems just do not exist. I found that less experience the. Often learn from tutorials and like, like cries casts, screencasts maybe just blog posts or whatever, or your dummy courses. But when people get very like, like senior ish, They were, they start to be more effective just by reading the documentation and the code or, or even tests. And did they learn by doing, by trying things, but by just applying the libraries for or when, when there is a bag, they usually. Trace it back and, and patch it, or even coming to the open source product. So this is like completely different mindset from, from certain level of seniority. You don't really get a lot from from maybe from blog posts. But more from, from the great reputation, I think. However that may not be true for, for ideas. Like, like, like applying some patterns, some programming patterns, some architectural styles and so on, but yeah, just, this is my fault. Sure. It's kind of like learning when you're cooking and it's knowing how to cook is sometimes a little different than just being able to cook off of a recipe. Like I, I enjoy cooking a lot and as long as there's a recipe in front of me, I make stuff that's edible, but my sister's boyfriend is a real chef and he cooks a completely different way. So I do understand that. When you're slightly less experienced at all different levels. Like there's recipes, they can teach you a lot about mixing things together and why certain flavors go well. But then you hit a certain point where you're able, almost able to just kind of understand what. Trying to create when you're cooking and you no longer need that recipe, you just kind of are reaching for the right things. So yeah, I can understand how, as you move up in seniority, those tutorials or those very basic blog posts become less helpful because they're, they're not actually showing you anything that you would use in your skillset to do your type of problem solving, but from a blogger and screen castor perspective. This is really unfair, like reality. I mean really unfairly Realty because it's way easier to create a blog post or a video for less experienced people for basics, for how to do a. But there's a more advanced content. You try to prepare, you need more research, you need more preparation and you have less audience. There is like way less ex, senior developers out there. And most of them don't watch screencasts anymore. So this is a really, really, really tough situation. When you want to, for example, prepare content for senior people, and this, this is tough from a. Profit profitability point of view. And this is why I think this is why like a lot of content for seniors is just paid like very like, like expensive courses, expensive subscriptions, subscription subscriptions or something because there is no other way around. Right, right. Yeah. Now that actually brings us, that's a perfect segue into kind of my next question for you is talking about your blockers or blockers that you've had and kind of how you've solved them or current blockers. And it sort of sounds like constructing good content for seniors is one of your blockers right now. What. One of the, the blocker and Tufts situation I have right now is just, I got, I just got the third child and this turned my whole life upside down again. But this is not something I want to really solve. I want to just wait until it will be solved on its own. Might take a few years congratulations though, on a third child. A very brave man. And I definitely see how that is a, a bit of a blocker, but you seem to be doing all right. They look well rested for, for someone with a newborn. Anyway, like one of the toughest things I have currently I'm facing currently is the ideas generation for example, and this is where whoever listens to me, they really can't have, like, because Tanami master is the fully open source project. People can contribute the content. People can contribute. Project code. This is just, just everything public and is the hospital and GitHub. So if anybody has an idea, what I could cover, like if there are any great Ruby gems, for example, that can be applicable for rice and for Hanami and for Rhoda, they are just framework agnostic, which is what I think every gym should be. Then just send me the suggestion and I will gladly gladly cover it up because the idea generation is kind of a toughest part. I have system and I system for ideas at the moment, but there's often just, just a lack of the next. To write about or, or record video about, so, yeah, this is one of the, one of the toughest, toughest parts I have at the moment. But I solved it partially, or I helped myself. Bringing the ideas to the project by by finding collections. For example, Halloween is a nice project because it consists of multiple components. Like there's actual gem, Hanami validation, CHAM Hanami router Alami, API, and so on. And so on. I just opened my obsidian a note taking system and at least all the components. And I said, okay, I will just cover all of them at some point then, because Collection of three Gemma families. Like they, they, they merged together three gen families which is the wrong or be dry or B and Jaime components. I did the same for Rome and dry as well. And I ended up with like almost like hundreds hundred ideas for episodes to have. So so this is definitely a fault. I have and a nice idea for anyone, I think who consider starting blogging and, and really don't think about the ideas, how to get ideas how to get to know what to write about. Yeah, no, that's, that's a good that seems like a really good workflow. I am with you on the dumping stuff in obsidian. Andrew Mason has turned me on to that and I am a full convert. I listened to the episode about obsidian and I use it for over a year already and I drive home and I master in shattered around purely inside of the oxygen. And I symlinked, for example, because I, I work also on the Harami guides, but HMI guides are just marked on fires. And the same for, for example, dry or be documentation. So I SIM linked those projects to my oxygen for volt and I have all linked together. So whenever I want to, for example, a right, the new episode, and you are book articles, I have all my network of the commutation linked together, and this really helps really helps. And I. This is a free idea. That is that's awesome. That's actually a really good idea. I don't know why I didn't think of that before. And I'm, I'm mad that Andrew Mason hasn't thought of it and told me about it, but we will be stealing that idea rest assured so we're gonna do a quick wrap-up or not even that quick you can take as long as you want really, but the last question, you know, something cool or interesting that you want to share with us, obviously. There's probably a ton of developers out there that don't know Honami yet they do. Now they'll probably look into that, but is there anything else that you wanted to share and it doesn't have to be code related to if you're just like, Hey, I don't know. A few people know about this thing. There's, sky's the limit. You can talk about whatever you want. Well there is something I figured out recently I discovered the Jordan harbinger show, and then one of the first episodes I wa I listened because this is a podcast I listened. There was the Adam Grant, the interview, which is the outer of book. Are you a giver or taker? And that was a really mindblowing interview, which I totally recommend for everyone. He, he talked about how to figure out if you are a giver and why you should be like, when you do anything. At any time, just always focused on providing a value to other people. And that was, that was really astonishing. A discovery for me. And this is something I tried to do, but also sometimes I just was kind of go is thick. And I really didn't didn't have those things. I didn't thought too much about those things and this really, really, really improved my life. And they also talked a lot about building a successful networking system sets of contacts and how to do it well. How to bring people together, how to give them value and keep them. I staying with you for, for a long, long time. And that was also something I had no experience at all, no learning support. And I think this kind of staff, if I could learn that, like 10 years ago, I would be completely different person right now. Sure. Yeah. I mean, that's basically. One of the biggest things about getting into the industry as a second career dev or self-taught is like developing that network of, of folks. So it definitely could see how learning to network effectively, especially early on and make a huge difference, but learning it at any it's going to be helpful. But that is a good, I like that one. I will add that to the show notes, but Sev other than Hanami masters, What are other good ways for people to find and connect with you on the internet? Whoa. I'm also I almost everywhere because the Halloween community is quite, quite kind of small. I have like, like 12 chat applications at the moment. Stop. Oh, that's an ADA. That's an ADHD nightmare right there. Or is it a good thing? I don't know. Yeah. W I just worked, I think, yeah. But the best, the best thing to connect with me is at there at Twitter. I think that Twitter so just reach out to me as, as we go or our It's so political. I think, I don't remember. Sorry, but you can find me. It'll be in the show notes stories. We'll have a link or the official mastery account. I currently, I drive both of them. I started about soon I will start delegating some work. Awesome. That's awesome. I will put that in the show notes. And before we sign off here, is there anything else that you wanted to add that we didn't get to talk. Thank you. Thank you for inviting me to the show. And also thanks everyone for listening and thanks for watching and reading whatever we content creators publish. This is really awesome stuff that, that you are, you are here and just stay here forever. Yeah, man. Thank you so much for coming on the show. It was a blast and. Shared some awesome resources with us that I can't wait to build the show notes for this. It's going to be a giant list of links and you've given me a lot of stuff to work on on my own time to play around with. I think we've got a start some kind of opposite and funds Guild or something. Yeah. It can be a subset of the Andrew maths and fan club.'cause I think you might be one of the biggest talker of it, thank you again for coming on and talking with me and spending time with me, especially with the time zone difference. Cause you are not in the same time zone as me, it is currently four 40 my time. And it's what your time. Almost 11:00 PM, but this is the only time it's quiet here. So I get that. That is, that is past my bedtime though. So thank you so much for making time to come on the show. It was a blast to have you, and we'll definitely have you on again. Okay, thanks. See you then.

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

Remote Ruby Artwork

Remote Ruby

Chris Oliver, Andrew Mason, David Hill
Ruby for All Artwork

Ruby for All

Andrew Mason & Julie J
IndieRails Artwork

IndieRails

Jess Brown & Jeremy Smith
The Bike Shed Artwork

The Bike Shed

thoughtbot
Code with Jason Artwork

Code with Jason

Jason Swett
The Code Gardener Artwork

The Code Gardener

Alan Ridlehoover & Fito von Zastrow