content_for :devs

#001 - The importance of Naming things | About the podcast, Q&A and random rumbling around our stories.

December 12, 2022 Seb Season 1 Episode 1
content_for :devs
#001 - The importance of Naming things | About the podcast, Q&A and random rumbling around our stories.
Show Notes Transcript Chapter Markers

We have the pleasure to announce the first episode of the podcast, whose core purpose is to inspire more developers to share their knowledge by publishing content to the world!

In this episode...

[00:00:00] Introducing the *content_for :devs* podcast
[00:00:30] Federico Iachetti Introduces himself and tells his story.
[00:02:55] - Sebastian Wilgosz talks about his background
[00:04:00] - Why we started *content_for :devs* and what are our goals
[00:13:00] - Format of the podcast. What can you expect?
[00:16:55] - Topic for today: The importance of choosing a name
[00:24:30] - Chat about the fun of writing for a niche and building trust.
[00:29:30] - A few interesting facts about Jeremy Evans!
[00:30:45] - Finding time for content publishing
[00:34:55] - Conclusion: Is naming important?
[00:37:30] - Q&A
[01:00:55] - How to find us?

Links

Socials to follow


How to support us?
content_for :devs is a joined effort of two people running their own initiatives. You can help us finance this project by a kind donation :). We appreciate any help to continue with this project!

[00:00:00] Introducing The podcast

Seb: Here we go. The work from in the new podcast for content creators oriented around or focused around publishing content for developers. This podcast has not a name yet. The draft name is, we have right now is beyond programming. But if you have any ideas how we can improve on that or.

Anything we could consider as the name for this podcast, feel free to reach out to us. We'll be happy to adjust. Welcome. I'm Seb and I'm fed. How are you? I'm doing fine. Thank you very much. We'll host this podcast few Weekly. I think this is the first episode, and I hope you'll find it useful.

Yes. So let's start. What, why you want to introduce yourself.

Fede: Yeah. I'm fed, I'm from Argentina. I live in Cordova. I've been a rugby developer since 2011. I've been working professionally since then. I always had [00:01:00] a, an inclination to teach. I really like teaching I and that person that finished my project in class and then help others do stuff because I really liked explaining things and for a long time I wanted to create my own streaming, not streaming screen casting service which I'm doing right now.

It's coming land. Haven't launched then yet, but yeah, I'm working on that. I've been working mostly in, in Rails projects, but I had a couple of just Ruby projects under my belt, and that's mostly me. I've written a book. Last time we record, because this is not our first recording , to be honest.

I forgot to to set up the actual recording, so last time we just streamed. But yeah, I, and you mentioned my book, which I always forget. I wrote a book about ro a while ago, which is now open source and has been maintained for a couple of years by the creator of rda [00:02:00] Jeremys, who I really appreciate doing because he really pumped it.

He really did a great job with the book. Yeah, that's me. How about you

Seb: Step? It's super fun that you are saying you forget about mentioning a book which for me is like a tremendous effort. It's like a just a lot of work. A lot of work book and I can't imagine how can you forget this

Fede: the way I wrote the book was the same way you write a course. It started as a course and then I took all the scripts and I made it a book, and I just wrote a couple of feelings to , mm-hmm. , to actually connect everything a bit more in a more cohesive way. So yeah, it was a big effort, but not more effort than you have done,

Seb: okay. Yeah. And my, from my side from my side I'm se I'm an out of H Mastery blog and the Screencasting platform for focus on h AMI framework, [00:03:00] Ruby Framework, and the Framework Agnostic Libraries. In written in Ruby and I have around 10 years of experience as a Ruby developer. Pure Ruby.

Really I never enjoy, enjoyed anything else as much. I enjoyed load Ruby. So for example, so once I found that bridge down is released is a thing I immediately started to considering as I just don't think I will write my side products with, because it's just pure Ruby and. I never considered like changing technologies or just reading something else.

But aside of that, I, similar to you, I always tried to share my knowledge and just share with people everything I know. And I master is my fourth blog. I wrote three blogs before and never with a great success. I cannot say that, but each one was considered to be way better than the previous one.

So I tried to learn from my mistakes and this is something I [00:04:00] just enjoyed doing. And, yeah. Now we are here. Now we are here starting a podcast for content creations, content creators. FEDA, do you think we are eligible to do you are muted.

Fede: Sorry. I was saying of course not, but we will do it anyway. .

Seb: Yeah. It seems like you are never ready to do things that that are important to you. So better start now. Yeah,

Fede: so the, my, my original intention for this now podcast was to have a weekly meeting with you to talk about content creation and our our journey through it.

So I think we are eligible because we are both creating content. We both have some experience. I don't think we are. I don't consider myself an expert, so please don't consider me an expert by any extent of the work, but yeah, it's a journey and putting out our experiences on the journey is makes us eligible, I think.

Seb: And we want to invite experts to this podcast to interview them. Yes. And show ask them how they drive their [00:05:00] businesses, how they manage their road to success and how they actually how this their lives look behind the stands. Because we've, what I found in terms of content creation is that at the end you just see, as a viewer, you just see the final result.

You don't see everything like 99% that is behind the staff behind distance. Yeah. What it takes to actually create and publish content regularly, but also no benefits are visible for most of the people. No. Also what I can find is just tips how to organize their lives. And this is like a lot of people is surprised how these guys can do so much publications while managing families and the jobs like regular jobs.

And this is also something that I was [00:06:00] and am super curious about. So I definitely will try to ask experts how they do this. Cause this is crazy sometimes. Yeah.

Fede: Yeah. Totally. And normally, at least for me, I see that. Almost for anything, podcasting, screen casting, and any other thing. You that gets published.

You normally see the you start seeing the creators once they reach some kind of success, some level of success, and not everything that they worked before. So yeah, it's a the idea is to show all that, that missing part, everything you don't see.

Seb: So what would be your goal to actually achieve by this podcast?

Podcast? You mentioned one thing that you wanted something like a mastermind with me and other people that will appear in the show. Yeah. What else?

Fede: That's my first intention was to yeah, as I said, have a meeting [00:07:00] weekly, a weekly meeting with you and talk about what we are doing, how we are doing it, and learn from each other.

And that for me, I don't know if that's exactly Mastermind but it's oriented in that towards that. But then I thought that might be useful for someone else except for, sorry for someone else other than the both of us. So having a podcast would be interesting for other people maybe, and useful and they can learn as well.

So yeah, initially my idea was just a mastermind, but I think. This might help someone else. And that's very encouraging, I think. So that's another very big goal to, to provide some yeah, some help of some tips or things that are useful for someone else. Awesome. What about you?

Seb: There are two key goals.

First of all, I started reading a lot about networking. Like there is not I found that [00:08:00] there is no way to grow if you will. Only Talk with the same people you are talking daily currently, because and if you really want to learn a lot, you just need to reach out to people that are way better than you to learn quicker.

And I completely agree with that. And this podcast is somewhat gait adores and to reach out to other people to have an excuse to talk with them. And maybe this is just one my personal thing. I also want this weekly call with you because I struggle personally, I struggle with consistency like in content public.

Consistency is the key. It's just the most important thing to just publish every week or every month or whatever, but just consistently so you build the audience and you meet their expectations. And when I do things alone, I just struggle with it. And this is why I started H Mastery with the [00:09:00] intention to not doing it alone.

And now we have a little team who help me building this content together. But with meetings with you I expect, I hope for some challenges and some like constructive feedback, some sparring and sometimes maybe punch in the face. Just when you say like Sep, you are just, you're just screwing up.

Why are you not working? , right? Yeah. Yeah just sit down and write something and this will, I, yeah. I hope it'll help in long term. And the final, and I think most important thing is that I would love to inspire others to start writing or maybe not writing, maybe podcasting or screen casting or writing books or just made some talks because I experienced so much benefits [00:10:00] from being a content publisher, even though I'm not super successful nor like very known person, it's still for my personal career.

As a developer, it helped me like crazy and,

Fede: So to interrupt that you have a bit of success

Seb: right now. A bit, yeah, of course. A bit. I would say definitely. But I'm already hitting like a few a few steps forward. But this is a trap with the, if you start comparing yourself, it's like, it's not healthy at all, right?

You can say I have a success. I can say I have not success yet. And things like that because you always will find someone who has a bigger audience, bigger blogs more content published, more earnings, more like everything, right? Yeah, so comparing [00:11:00] to other people is not too healthy in my, is very demotivating and, but I found myself I found very useful if I compare for me from the past, like I, I compare myself with the, with me from the past and that helps me a lot.

And if I will compare myself with the myself from the year ago yeah, there is a huge progress definitely in terms of content publication, it's a huge progress in terms of my developing like programming career also, this is a huge progress. So in this term, I can see a lot of success.

However, I did not meet any of my goals that I had listed for this year. It last I had a plan for my H Mastery content publication, and I didn't teach any of that, but other unexpected things happened that actually made me progressive and progressing in, in this field. Which is funny because after writing [00:12:00] for blog I thought I know something about the content publications and then it appears that I know nothing

Fede: Yeah.

Seb: So those are the goals I hope by doing this podcast and bringing other people and showing behind the stance of how they drive businesses, I hope it'll inspire, it'll lower the barrier. And explain some caveats for starting content publications. What could you do with it and what obstacles you can meet.

And maybe with this we will inspire other people to start writing and have their careers by that.

Fede: Yeah. I really adhere to that to that goal. It wasn't mine at first, but I might steal it as well. ,

Seb: yeah. We are doing things together so of course we will share some goals and over time, I guess when we will adjust to each other those goals will be more, more shared and blessed.

Separate, right? Yes, exactly. But we need to start somewhere. So what would be the next point of the episode?

Fede: [00:13:00] Okay. We are, the next point we have scheduled to talk is discuss topics relevant for content creation for devs. Yeah. One of the ideas for this podcast is to talk about anything that relates to content creation and probably some technical things as well, some technical topics.

Seb: I yeah. So we are jumping to the format of this podcast, right? What exactly so we want this podcast to be like, right? Yeah.

Fede: So yeah, talk about anything related to first of all what we do and anything related con creation, and as I said, a bit of technical knowledge as we encounter.

Seb: Yeah. What else? Also, we want to invite as I mentioned before, we want to inter invite an interview folks who publish the content already, who has blogs, who have screencasts, who build communities. For example, there is a great example recent example of Brandon [00:14:00] Weaver who started Ruby Learning Center.

This is great community that, that just appeared like mushrooms after the rain like immediately in, in one night. Like hundreds of people just immediately signed off and a lot of great folks. And I wa I was observing that and I could not believe, and I was like, how did he do it? Just please share.

It's so exciting to just see the effect and how much preparation to take or what actually impacted that, how he built this kind of network that people from the level of Yeah just the top, top. Ruby devs actually trusted him and just immediately jumped in to help junior developers within this discourse.

Discord channel that he built. Disor server. Yeah. That was exciting. And, but there are more. There are more, and yeah, definitely want to have a chance to talk with those people and ask about your [00:15:00] hacks. How they actually do it or how what we can learn from them.

Fede: Yeah. Sorry.

Anything we can from there, . Yeah. And publish it for everyone else.

Seb: Exactly.

Fede: Yeah. The other thing we formal wise we are gonna target biweekly episodes. Even though we will be recording for a while at least weekly, and we'll be streaming we will be releasing them biweekly. We have a we have some in store for when we go on vacation or if something comes along and maybe at some point we will start releasing them weekly if we can, but there's no promise there.

Seb: Yeah. Yeah. What's the last point? Then the quite of exciting one. We plan to do QA sessions for this podcast and included them here. So like in the, in. Time between episodes, we will collect some questions from people and we will try to answer them prepare and answer like any kind of like coding related or content creation related [00:16:00] or anything else.

We will try to answer them as according yeah, as much as we can. And hopefully this way we'll also be able to help promising junior developers promising writers or maybe screen cast makers. I don't know if this is even a job, but so this is our plan. And during this live streaming, if you will continue with this streaming, this is not the site that yet, but during this live streaming, you also can.

Comment on the chat and ask some questions so we can answer them and address them immediately. So that would be the format that we have right now. And what else? I don't know. There is anything else regarding format?

Fede: I think we are done. We have a topic for today that we want to discuss about choosing a name.

And that's very relevant because we haven't chosen a name yet. There is one in the making which I actually forgot. I'm sorry. . Oh. It's be beyond programming. And that's because we want to tackle topics that goes beyond programming, not [00:17:00] just the technical stuff, but going out there and.

Yeah, producing, helping, and what I said,

Seb: Also, yeah, just we want to also target people who don't only program only develop staff, but actually do something else. For example, there are a lot of people who who do open source after hours, right? Or treat their daily programming job as a part-time job.

But in the in the remaining time, they develop, for example, SL bots or or write books. There are multiple ways like Udemy courses. They are multi, multiple ways to actually. Fulfill this gap of not working full time as a developer by doing other amazing stuff. And there is a lot of potential to, to get inspiration from other people.

Yeah, this is why we are talk, the draft that we have is beyond programming to start [00:18:00] wondering what people do what the developers do despite accept programming, which is most obvious thing. And big question. Oh

Fede: Sorry. No. Please

Seb: continue. I dunno what I was go ahead.

I dunno what I wanted to say. I just wanted to go to the next point. So let's ask.

Fede: Okay. No I was gonna stay in, in. On the topic and ask you a very important question. Do you find it easy or hard to pick a name for something?

Seb: Definitely hard. Okay. And I can tell a story about multiple naming choices I got, I made for my publications.

If you think Yes please go ahead. There is, I'm Sebastian Vgo. This Vigo is my last name. So I had in the past a blog that was vigo.pl pl is from Poland, right? And I run this blog. I wrote this blog in Polish language, but it was oriented around Ruby because my company is just registered as my last name.[00:19:00]

And that was funny because I, myself, Did not read anything related to programming in Polish, but always in English. And it was very tough to actually write something in Polish if half of them words that I'm writing are in English, because this is just comes, this comes from English language and nobody searching Google and my articles.

And that was tough. But my first first name was just not related to the content that I was publishing. It was related to my name and my last name because it I wanted to promote my personal brand as a person. But it didn't work out. I thought okay maybe better would be to actually relate somehow like not relate what I'm doing with my.

Family name with my last name. Maybe it would be nice to step aside and just don't people do not allow people to [00:20:00] know that I'm the outer. And I wanted to, just at that point that the next step was to split my personal life, my personality, that just out of what I'm doing as a professional and hide myself, my family life.

Just do something else. And my next blog was complete random thing. , I just that's a great name. . Yeah. But it's hard to even like it's hard to even tell it. And when you need. Spell it for like thousands of people. How to spell your your email address. It's crazy.

Yeah. But anyway the second name was just random name. I, it meant nothing. It meant nothing. And it appears that the success of it was way greater. It was completely not related to the content I was publishing. So this was pretty funny because it's shown me that the name doesn't really matter.

So much. Yeah, it doesn't really matter so much. The content is the [00:21:00] thing that actually brings your audience and allow your pe, your people to come back. If people will like you, if people are think this is valuable, what you are writing about this is way more important. So my, my, my next blog was a way bigger success and it was connected to the Rice API course.

I've, I published on New Demi, and this blog was an extension that supplemented this this course content. It was targeted for my students and they were very much willing to share these articles with the other world. So it's shown me very much, very important thing that when I have a clear focus, who I target who I write for.

It actually clicked and it was it gave way better effects. Yeah. And for the last project I have, this is the Hani Mastery. That was a completely [00:22:00] different story. I just and the naming choice is pretty interesting because first of all, I want, I did nothing. I knew nothing about Hani when I started writing a blog about Hanmi.

So this was, I needed to choose a name and I wanted to be expert in Hanmi. Of course, I wanted to. But by doing this blog, I wanted to show my path, my road to become an expert. And I wanted to help people who read this to become an expert. And that was my initial thought.

But the other thing is that I was inspired by all this content publications and screen casting. I was inspired heavily by Ryan Bates from Rice Cast and also by the Greg Pollock, who was then outer of Code School. This code school is not not existing anymore, but

Fede: yeah, it's it's been sold to a broad site, [00:23:00] I think.

Seb: Yeah. Yeah. So completely different, I think. But I am observing this person and Great Pollock is engaged heavily into educating ujs. Community. And he has a YouTube channel named View Mastery. And I stole stole his his view mastery and connected with my like, idea of showing her the roadmap.

And I just replaced view with Hanami. And this ended up with Hanami Master. And this kind of was very kind clicky. A lot of people just immediately started remembering my blog name, and started very quickly, people started searching for Hani Master in Google and typing Kalani Master in Google.

And that was kind, surprising. But the downside was because I had so official name people started thinking I am a master of Hani immediately and started to ask me questions. I had [00:24:00] no. No idea how to answer, but also they assumed that my blog is official, like supported by the core team and everything.

But the core team didn't even knew about my existence at that point. So that was problems that I needed to clear out and announce that I am independent like Hanami enthusiast and just want to share what I know and help some people. And this is just, just

Fede: my own. Yeah. And I think Hani is right now is a really niche topic because it's just, it's not just starting, but it's starting to gain popularity just now.

So yeah, there are not many Hani oriented block blocks. Yeah, it makes it sound that you are official because there are not many. If you had a blog called Ruby Mastery, I don't think it will be connected in people's minds to the core team.

Seb: Yes. I think so. some people [00:25:00] consider Ruby being kaisha and if if I'm working for h I'm writing about H This is Anisha in Anisha.

And yes, that was a big risk for myself definitely to actually start writing a blog two years before the official version have been released, but it paid off. We'll see , I go,

Fede: But you had as I said before, you had a bit of success. And think You are more popular than you think and I'm not at, of course, I'm not at using it just to the name.

This is because if you have just a name and no content, that doesn't work.

Seb: This is a great, this is a great question and a great topic. I think we could discuss in the separate episode about that. Okay. Because you are absolutely correct. I have no idea how popular I am. I don't even know how to do, how to research that

But also I don't get too much feedback and I think a lot of creators [00:26:00] actually struggle with With collecting feedback. So for a long time I didn't know if what I'm doing is actually a good thing, if people need it. If people want it, or if I cause more problems than than it helps. Yeah. For example, when I publish,

Fede: sorry, do you have any feedback from the court team?

Seb: Yeah, but it's mixed feedback because they really enjoy that I started blogging about Hanami and appreciate that, but it also caused a lot of problems. For example, when I published a video about a feature that was in development, and it was changed two years after I published a video.

People just reach out to everyone in the core team saying that this is not working, but you have, but there are tutorial and you have tutorials about doing this way because this is hanmi mastery, this is official. Right? And things like that. And there was a lot of confusion in the community, especially because there was this committee is very small.

So at [00:27:00] this point I'm not super sure if I'm doing more good thing or more confusion. I bring more confusion to

Fede: when you thought about making it official, talking to the core team and maybe engaging with them on the content, at least on, on the topics to

Seb: talk about. Definitely I will try again.

Of course. But when you are just starting, nobody really can trust you. You need to build your trust, right? Yeah.

Fede: But not that you cause problems. They they should trust you.

Seb: I think what I proved is that I can publish content and I can publish it for a long time. But the focus for core team is actually the development.

They really want to push their limited time and release the complete version of the framework. And they recently, like few days ago, they released Hanami 2.0. A huge milestone. And the next focus would be to add a [00:28:00] persistence and view layer to it to make it a complete framework, a complete Ruby application framework.

And I think after that, definitely there will be more interest in marketing, content, publications and so on. Yeah.

Fede: They need to win more terrain against royal, I think. So maybe having a doing basically what Jeremy Evans did with me. I published the book and I send it to him. He reviewed it, he liked it and all of that.

I started selling it. Then I stopped selling it because it got out of date and he reached out to me and said, would you open source it? And he put it in the main page. So he now, okay. He's maintaining it. But in your case, you could maintain the content and they can curate it basically to allow you to have a lot of reach out to a lot of people.

Seb: .

So we, we'll see how the road goes and how the things [00:29:00] will evolve. Of course. I am open to any kind of contributions and I don't want to make, can mastery alone as I, I said. So whoever would like to contribute, I am open to to discussions. Yeah,

Fede: for sure. We should invite them to talk because

Seb: and the Jeremy also if you have any contact with Jeremy, I would actually

Fede: appreciate, I write, I'll write to him.

I

Seb: need to note this down because I wanted to talk with him since I saw his sequel read me. For the first time, it's yeah, I think it, it's son will cause problems on browsers while rendering. It's so extensive. There is so much content. I just wondering how does he do it? He's, yeah, there's so great developer, but he actually publishes content manage books, as you said.

He his documentation is so great and yeah.

Fede: He works for the US government and part of his work includes RDA and Sequel and all those open source libraries. So that's the reason, for [00:30:00] example, that I have a I have a link to my paper on the book, but he hasn't. He's not receiving any money because he don't actually want, because he says there's a conflict of interest there because he's actually getting paid to work on those projects.

So he uses work time for that. So I think that's part of why he can't produce so much both content and libraries because he's very active in development as well. At least for, I'm subscribed to the rather mailing list and. Every month for sure. He's releasing something. But every other week as well.

So

Seb: yeah, there's a lot of this is something I also got got inspired. I don't know who actually inspired me by doing this, but when I started H Mastery Block I was a RISE developer and I struggled with finding a time working on HANA related stuff because it was a conflict of interest with my company, and I decided to change my career to work on the company who works with Hani Projects, HA based [00:31:00] projects, and now producing content on Hana Mastery is in direct interest of the company I'm working on as a developer. Because I educate people, I educate developers. It's easier to onboard them. I'm working also on the guides or helping with the documentation a bit and this kind of stuff.

Is merged together. But I'm not yet in a way that I can just use work time for making articles. But the research is there. The research is definitely there. I'm learning a lot in the work time. And how do you organize your They are weak. Oh,

Fede: my, no, my days are a mess. . I don't organize that all time.

I suck at that, actually. Now I usually work during the mornings and then I spread it out on the afternoons a bit. I'm currently working freelance for a couple of small projects and then the content producing is very spread out. Yeah. I need to get a lot better of at.

[00:32:00] Organizing myself because it's always a struggle for

Seb: me. And do you feel like you've, you, over the week, you work more than 40 hours or less comparing, like including your contemp creations? All the projects?

Fede: No. Right now, definitely less. And that, that's because I'm, I've been experiencing some health issues, so I'm taking it very lightly.

. But it, it depends on the week, it depends on a lot of things. As I said, I'm working on freelance, on smaller projects, so sometimes I need to work much more and sometimes I have very say empty weeks. It's, it comes

Seb: And goes. Got it.

Fede: And what about you? I, you have a full-time job so you might have,

Seb: Very schedule.

I do. And when I started with H Master, things were just crazy. At that point things were just crazy. So I was Rise developer, a full-time rise developer, and I needed to and I worked after [00:33:00] hours to research, learn hanami and record videos, write articles, and do it all my own. And that was just hard.

But over time I simplified a lot of things. I changed my career and now I'm doing research within the company. I'm using company products to learn stuff related company. And this saves me tons of time. I started working on the guides and the documentation. Two has an excuse to learn more code and from the framework and has a direct access to the core team.

So I could ask them something where I was blocked and this saved me another tons of hours. Over time I was collecting some sponsorship payments. Some companies started to sponsor my work and good folks from the Ruby Committee also started supporting me on GitHub. [00:34:00] And this allowed me to hire some people to help me with the video production.

So now I have a lecture and have a video producer. And you also helped started helping me with the actual content creator, so the creation. So you are you came to the team and started writing a content and doing the research yourself to to, to reduce that some overload from me. And this is now the only way the only reason why I actually can handle full-time job with the content production because because I have people who help me in every week.

Over time, I definitely want to reduce my daily job to just work four days base, four days per week and have a full one full time, full day for content creation. But it'll take yeah, a while. Cool.

Fede: Yeah. So we ran from the actual topic, I think a bit. But we were talking about choosing names

Seb: What would be the conclusion before we, [00:35:00] we start the q and a?

Fede: It means hard. It's not as important as you might think but it's hard and you always want, as a creator to have a great name.

Seb: Definitely.

Fede: But yeah, it sometimes it's difficult to get a name I just thought of a name for this podcast.

And it might be, the name is not important, . The name doesn't matter.

Seb: One, one example. One example of this is hacker News. Do you know this platform? Yes. Hacker News is so popular, it collects so much traffic and the domain name is like, Why news combinator.com or something like that. Yeah. It's so unrelated.

Fede: Yeah. It's the content that exactly, that

Seb: pushes the content that people that matters. Of course it pays off if you have great name as addition to it, but you can always change the name. Abdi is great example, right? That,

Fede: yeah. He changed the name from Ruby Tapas to graceful Dev and he's having a lot of success as [00:36:00] well.

Seb: Yeah. So yeah, conclusion is naming is not too important and the most important thing is to just start producing something. Yeah.

Fede: My, my great trick for choosing a name, not for podcasts and things like that, because I don't use this trick, but for libraries and projects and applications that I'm thinking of writing and whatever, I just take a look around.

and see something, and I choose a name from that. For example, one of my latest projects, this guy, so this is scratched from the ice age. So I have this flashy thing the brushy to, and I chose SCR as the name because I liked it. And as you said, the name can change afterwards.

And then for my blog, the blog I've been writing for some time, which is Con Developer, which a little hat over the U, which is basically an internal joke for myself, . That's the way I choose names very randomly.

Seb: Yeah. I also [00:37:00] asked some existing podcasters, Ruby podcasters, to help us with choosing a name, but they were not too helpful.

They all just choose a name in a similar manner. They just choose a name by, by, which explains what they do. Yeah. Or a random name that they like, and there is no great philosophy behind it. Yeah.

Fede: I think we, we will need to do something like that.Q&A

Seb: Okay. So what do you think about jumping into the QA N Q N A session?

Yes, sounds good. We have collected five questions for this first episode, and the first one comes from the Abdu Ahi. The first two actually. He send us questions regarding getting jobs for juniors in Ruby and the Rails community since every job post requires many years of experience. Yeah.

Fede: We talked [00:38:00] about this on Monday but yeah, my, my first approach to this topic is to say that if you're a company and you need developers, consider hiring juniors. Don't ask for too much experience because there are a lot of great juniors coming out of cold camps and things like that. I actually studied a project a couple of years ago with my brother and we hired two juniors and.

They are very open to learning and very grateful for you correcting them and helping them progress. So if you want to actually make the Ruby community bigger and greater, higher juniors, if you are a junior looking for a job, don't be afraid of just posting yourself to a senior developer job.

Don't lie about it. Don't lie about your experience. Just tell I just came up from a boot camp and I know this is a, [00:39:00] you need experience, but this is what I know. That's my my 2 cents. You might get higher anyways. If they see your. Sorry. If you, if I see you are excited about getting this job they will and if the company's open minded, you will probably get the job.

And if you don't, it's a great experience as well.

Seb: I agree. Like I agree that it is important to know why you are aspiring to a certain company. And it doesn't need to be the company itself. For example, I will put an example if of how I got a job in Ascend where I'm working right now. This is a financial company and I had no experience with any kind of banking systems, any kind of loyalty calculations or anything like that.

And I, my motivations when when I'm looking for a job, my motivations are also always I want to do something important for the world, change the world [00:40:00] in some way, like live event in the world after my, my my time being there. And previously I work with the educational companies. I wanted to change or affect education also in the world, but also in the Poland itself because I think this, there is a lot of room to improve here.

But then I applied to Ascend, not because of this company itself. I applied there because of the technology they used. I was so excited about the technology they used. I wanted to be part of it. I wanted to learn that part. I was excited on this. And I also really like the people that talked with me, but I bet there are lot of great folks folks in other companies as well.

So there is nothing special in this particular part, right? And when they ask me why am I applying, I, I was I was just honest like I wanted to to work on the company, be that uses [00:41:00] Hana because I was excited with it. And I got the job. So this is really important to know that this single reason why you are applying to.

Yeah,

Fede: I agree completely. Honesty on a job interview is key for me,

Seb: I think. Yeah. But I agree. I agree also that there is a problem with companies not hiring juniors or not saying that they hire juniors in our company, for example. There are no open positions for junior developers. However, we are open to hire juniors if there will be any like spro promising talents applying here, right?

Yeah. So I would love if that could help. Yeah. I would love if that could change in the future. Yeah.

Fede: But listen, you saying that that's another reason for you as a junior to apply to a company, even though the job description says senior, they might be looking for juniors and just not putting out there

Seb: Yeah. And the, I would also not be too sad if [00:42:00] I get the rejection. I try to apply to multi, multiple companies all the time, every time I change the job, but occasionally I also apply to companies without the intention of change a job because I treated some kind of like a sport. Getting through the interview process is also a skill and from time to time refreshing the the knowledge, what companies expect, what kind of steps are needed.

To pass. This is very useful because it reduces a lot of stress to me. I'm a person that actually very easily gets stressed out during the interview process, even if I don't actually need a job because I'm hired. I don't want to change still when I'm doing the interview. This is a lot of stress to me.

And by going through them from time to time, it helps me getting used to it and reduce this kind of level of stress. Yeah,

Fede: I agree. That's a very good practice to have.

Seb: Should we go to the [00:43:00] next question? Yeah. What is the next one? Advanced

Fede: topics, sorry. Advanced ruby Topics for race developers, like modules, how gems work or how to build one or go through a gem code by highlighting the syntax or something like that.

Seb: And what's your standing on this?

Fede: My standing on this is that we can talk about technical stuff on the podcast, but it's very difficult for an audio podcast. Since this will be released as audio. Doing a cold review, a cold walkthrough would be very difficult and I don't think very helpful.

But we can definitely tackle some some technical topics on how we do things things like that. .

Seb: Yeah, I, there are several troubles in this in the answering of this question. So if you have any kind of concrete questions related to advanced technical knowledge, feel free to reach.

But most likely I will be able to cover them during my screencast episodes. And similar to feta I believe it'll be way [00:44:00] earlier, but producing content for like advanced, very advanced content for developers is tough because there are not many experts and advanced developers and those who are like in, in comparing to junior developers, there is way less senior developers.

And if there are advanced topics those people usually don't learn from videos. But I found that they are more effective just by reading documentation or the code itself to figure out some stuff. It's tricky because you need to always balance if you produce a content, you spend hours or days of your time, sometimes free time to do the research to to make sure that things you will show are correct.

And the more advanced content you produce, the more time it takes to actually produce that and research that. But the audience, people who [00:45:00] will be interested with it is smaller and smaller. So it's conflict of interest. I would say. We need to leave somehow, and this is why for senior people, the great channels are all often paid ones that you need to buy a book, you need to buy a course, you need to buy an access to the community, and then you have a time.

Of the experts on for your disposal. But this is usually paid. And I also want to produce more advanced content for the Hana Mastery Pro for my premium subscription channel in the future. Yeah I agree

Fede: with

Seb: all you said. The next one is from Ben. How do you organize code for concepts that are very similar but not exactly the same example, A work schedule and a work schedule template.

Share many attributes, but one attached to employee and has mother more [00:46:00] behavioral.

Fede: Okay. My, my first answer to this is, it depends a lot on the project itself, the technology you're using and the approach you're taking. That's my developer answer. Regarding what I would do out of my from top of my head.

I usually tend to split things in objects because I am very object oriented person. So I tend to group things that are the same in objects. And then you can also think of this in a, in the folder structure, where to put things I tend to group things into soap folders and things like that, but I don't think that's the focus on the question.

So yeah, my, my answer would be I try to organize things in. In object in, yeah. In classes and objects. Sometimes I will use a module, but more regularly I go to classes. What about you?

Seb: I also in Ruby, I also avoid modules including modules. Occasionally I do especially if [00:47:00] there is already a gem that is based on that and they just follow what is there.

But I have no clear answer for that. My, my first and most important stuff is I try to split the business logic, a part of the application logic. So in web applications you have the part of the application that serves the request, it processes the request that coming from them. Client to the server and delivers the responses.

The response, this is very API specific, but this under the hood you launch the business logic. That is, that also affects like suchs data, processes data on your databases do some calculations. And those, that code can be also invoked from re tasks or or even RS or HNA console. And this is not re the, so the input there should not be related to the or [00:48:00] to the api, to the controller, to the to the, this application part of the.

And this is my first step when I'm trying to distinguish things and organize those differently in rice applications. I wrote I actually recorded a screencast how I did the, this split for for rice applications. And this was episode seven, I believe. And I really I really like that that approach when you have just business logic independent and you can organize it freely however you want.

But I also tend to use classes and I am more into functional programming now and in Ruby, however it sounds I, in our applications we use interactor pattern. or, so you can also name it service objects or whatever, but it's more or less the same thing when you have a one service that does one thing and you can call it only in the one way.

It has just one a public [00:49:00] method or something like that. Yeah. Yeah. So that's my take on this.

Fede: Yeah. Something to say is that I normally use modules just as name spaces. I, it's very rare that I include a module unless it's it comes from a library or from or whatever. Real thing.

I normally use them as name spaces.

Seb: There is, there, there is at least one use case when I find it useful to include module. For example, when you have a psychic worker, And you want to and this sidekick implements perform method, but sometimes you might want to extend this this method itself.

So you prepare your module with extending the functionality to add some tracking or add some successful notification or error notification wrapper around the perform method. And this can be done via the module inclusion, and I find it very useful.

Fede: [00:50:00] Yeah, I agree with that. Okay. For the next question from Ken, how is Ruby ease of use and learning curve compared to other languages specifically for the web backend?

And what is the future of Ruby? What's your

Seb: take? When Ruby came out it was not popular at all. And when the Rios came out, it was a mindblowing change in the world of developing web applications. The ease of use and the time of delivery from the client requirements to delivering mvp was just mind blowing, super fast, was producing web applications in rise comparing to Java, php or whatever else that was accessible at that point of time.

But over time, over years and the competition catch up, caught up. And currently there are a lot of different frameworks where you can achieve similar things and produce. Content, produce a [00:51:00] code in more or less similar efficiency. So there is not such a clear border between Ruby and other languages like Python who has J or even Alex here that has things right,

But so nowadays it's just a matter of preference and matter of what kind of applications will you work on. If you have a very deep data processing calculations or real time systems, maybe Ruby will not be the best approach. But as a lot of big Ruby projects proved be before you will hit issues related to Ruby being not performant enough, you will actually be completely huge enough to afford rewriting everything or splitting into microservices or whatever.

Yeah. I would say there is not a big difference, but I personally just love Ruby. [00:52:00] I love Ruby syntax. I prefer it way more over the Python, for example. And if I would need to change my tech stack, I would more likely learn a Elixir. But I cannot say too much about the ease of use of that.

Yeah.

Fede: Yeah. My, my take on this is regarding learning curve. I'm torn. There are two, two views. I subscribe to. I think Ruby is a very terra language. You can very easily write a a program with Ruby. Since it's a, since it's a script language it's very easy to get into it. But on the other hand, it's a very complete language in terms of say syntax.

So for a beginner, sometimes, unless you are well taught it can be confusing. And my example for this is The eternal fight between Ruby and Python approaches. In Python, if you have to do something, there is one way to do it and only one way to do it. [00:53:00] So if you search on Google how to do X, you get 100 responses and they all say the same or mostly the same.

In Ruby that's not the case. Ruby tends to allow us, or not allow us, because Python also allows it. But it's oriented to having multiple answers for the same question. And this, I think one, one great example of this is how you use blocks. Do you use curly braces? Do you use due? And there is a discussion about that.

The first approach is multiple statements. I use due end. Single line statements use braces. But then there's the other way of thinking it, that if you have a return value, use braces. And if just, if it's just a functional block used to end and there's a fight even there, even with something so small.

And I'm not talking about implementing a feature, I'm talking about writing a block , right? Yeah. So it can be daunting for a firstcomer. My experience was [00:54:00] not hard. I picked up the Pax book and I really loved it, and I caught up on all those things. I came from university learning Java and C and all those kind of kinds of languages.

And then I learned Python, which I really loved until I didn't like it anymore because of the syntax of the. Indentation thing, which is crazy for me. , and then I learned Ruby and I really liked it and all of that regarding the future of Ruby. If you're interested enough knowing, first of all, if Ruby is dead, there is the page.

If ruby dead.com, which is great, you should go and check it out. Do you think RU is gonna die anytime soon and doesn't matter

Seb: at all? Definitely not. Like even a few weeks ago, there was a rise foundation put together with over $1 million funding and start with a promise of hundred, 400 per [00:55:00] 400 K dollars per year of the participants to support content creators open source projects and.

Other like community things about rice only and rice is not actual ruby ecosystem. So yeah, we've so big projects in, on the web that are built in Ruby and yeah, all like new projects coming out every year, every month, or every week even in, in, in the world. I don't think Ruby will die anytime soon and I don't think it matters too much.

Ruby is fourth most paid language at the moment in the world, which is attractive. But even if it would fade away in like next 10 years, in 10 years, if you will start to learning Ruby now in 10 years, you will be a senior, like a very senior. And at that [00:56:00] level, switching technologies to something different, something similar or or whatever is not a big problem.

Companies even support that. Even sponsor that by employing senior developers and providing funds for courses and like a few months training sessions just for changing technologies to what they do. So if you are a senior, it doesn't matter what you used too much in my opinion. So if you want to start, you can just start whatever it works for you and whatever you like.

And I definitely like Ruby if I would , yeah, I don't even consider changing that anytime soon. Yeah. Same here.

Fede: On the other hand, if, first of all, what would it mean. For a language to be that. I think even if the project itself just stopped, which is an open source project, someone else would pick it up, I think.

But say it actually stops and no one ever, no one else cares. First of [00:57:00] all, there are a lot of applications to be maintained. I just talked about this with a person the other day who had a project written in Rails two. It's an old project with a NU technology and it's still been maintained.

And even if you are not maintaining projects anymore, you have to port them to something else and to port them, you need to know the language as well. So yeah, I, I don't think. I, first of all a language can die. Cos is still around. If that's not a good metric, I think nothing is. And on the other hand, even if it could die they will still be work to be done

Seb: using the technology.

Let's take an example, php, right? It was old when I was learning development at the university. At that time nobody had actually wanted to work with php. No. At that time it was the only alternative. But a few years later, nobody wanted to touch a PHP at all. And now we have a LA framework which actually [00:58:00] brought a lot of interest and a lot of new fresh blood to the to the PHP language.

And a lot of people are again, interested in working with php, which for me personally is crazy, but this is how things work. It's just history just makes circles ? Yeah, of course. So this is my take on this part. Yeah. Sounds great. And . The last is from Ioni, but it's very much related to what we discussed already.

This is, why should I learn, Ruby? I heard it's a dying language. And

Yeah.

Fede: Go to that site. I said it's ruby dead.com.

Seb: I don't think it is a dying language and it maybe depends on who actually talks about it. But if you think about cryptocurrencies, right? Cryptocurrencies are being dead every four years, every just a cycle.

Every cycle you will see messages and news about cryptos. Is that [00:59:00] about Ruby? Every time there is also a page that tracks how many articles are related to the Ruby being that and personally I don't care because I just do what I like and I like Ruby, and this is why I'm coding in Ruby.

And as I mentioned before I am a Hanami developer at the moment. And this is a niche. In an niche. If Ruby. Five or 10% of all the websites in the world, probably less because WordPress is everything . But but if Ruby has 5% of websites made in the world and Hani has 0.5% of Ruby projects still I'm getting success with Almi.

So it doesn't matter really. If you are good, if you are doing what you like you will be able to get, gain a lot of success with whatever you do. Yeah, totally. Yes. And that brings us to the end. Yeah.

Fede: Should we wrap up? How [01:00:00] are you, how are we wrapping up this?

Seb: Thank you very much for that and for the intention, right?

Yes, exactly. Thank you very much. We need to actually learn how to close episodes. I need to listen some other podcasts to the end, because usually I end up a few minutes before the end of the episode. And now I understand that , it's not,

Fede: I listen to mine on, on my car, so I don't, I never can skip episodes.

And they usually point people to the show notes and things like that and to the site, but we don't have yet that

Seb: yet. But when this will be released on on podcasting platforms, definitely we will have. The show notes Yes. With links included that were mentioned in this episode. And I also plan to write the text version of the episode by using some kind of fancy scripting.

But this is not a promise at all. Feather, how can you people reach out to you,

Fede: On [01:01:00] Twitter? F y which is very difficult to write is F I A C H E t I yeah, that's the main way right now until I release my screen casting. What about you?

Seb: I'm everywhere, but but Twitter is the main thing for sure.

Right now. I have noticed a lot of Ruby Community had started their shift to Macon Ruby Social. I also have an there, so if you will write to me on Macon, I will also notice that as I said you said a lot of success. I got I have not enough success to, to miss private messages. So definitely a long way in front of me.

So feel free to reach out if you have any questions. We will post on our Twitter's channels the next form for the next episode, and see you in the next one. Okay.

Fede: See you next week, Seb, and see everybody else two weeks from now.

Seb: Bye bye.

Why we started *content_for :devs* and what are our goals
Format of the podcast. What can you expect?
Topic for today: The importance of choosing a name
Fun of writing for a niche and building trust
Finding time for content publishing
Conclusion: Is naming important?
How to find us?