The undercover generalist

Welcome to Changelog and Friends, a weekly talk show about AI rescue teams. Big thanks to our partners at Fly, the home of changelog.com. Launch your app as close to your users as possible for peak performance. Fly makes it easy. Learn how at fly.io. OK, let's talk. Yes, let's talk about our friends over at Firehydrant real quick. They have a brand new on call feature called Signals. And what you're about to hear are real reactions from PagerDuty users when seeing signals from Firehydrant for the first time. PagerDuty, I don't want to say they're evil, but they're an evil that we've had to maintain. I know all of our engineering teams, as well as myself, are interested in getting this moving the correct direction as right now, just managing and maintaining our user seats has become problematic. That's that's that's really good. Actually, this is this is a consistent problem for us and teams. Is that covering these sorts of ad hoc timeframes is is very difficult.

You know, putting in like overrides and specific days and different new shifts is quite onerous. Oh, and you did the most important piece, which is didn't tie them together, because that's half the problem with PagerDuty, right? Is I get all these alerts and then I get an incident per alert. And generally speaking, when shit goes sideways, you get lots of alerts because lots of things are broken. But you only have one incident. Yeah, I'm super impressed with that, because being able to assign to different teams is an issue for us, because like the one the one alert fires for one team, and then it seems like to have to bounce around and it never does, which then means that we have tons of communication issues because like people aren't updated. No, I mean, to be open and honest, when can we switch? So you're probably tired of learning tools that feel more like a headache than a solution, right? Well, signals from fire hydrant is the alerting and on call tool designed for humans, not systems. Signals puts teams at the center, giving you the ultimate control

over rules, policies and schedules. No need to configure your services or do wonky workarounds in just data seamlessly from any source using web hooks and watch as signals filters out the noise, alerting you only on what matters. Manage tasks like coverage requests and on call notifications effortlessly within Slack.

You can even acknowledge alerts right there. But here's the game changer. Signals natively integrates with fire hydrant's full incident management suite. So as soon as you're alerted, you can seamlessly kick off and manage your entire incident inside a single platform. Learn more or switch today at fire hydrant dot com slash signals. Again, fire hydrant dot com slash signals. Well, welcome to our third installment of It Depends. This is a series of episodes where I speak one on one with experienced devs about the gray areas in software. I know we all wish everything was black and white, one or zero, true or false. But unfortunately, the real world is messier than that. And all too often, It Depends is the only generalizable answer that there is today. I had with me Adolfo Ochegavia. Welcome to the show. Thank you. Thanks for having me. Happy to have you excited to talk about this particular subject.

You recently wrote a blog post called The Undercover Generalist. That's true. Which you did. I enjoyed I think I put it on changelog news. It very much spoke to me being a contractor for many years and being a generalist myself, the topic for today that we're going to It Depends. Oh, I should play our little jingle because I put a lot of work into this jingle. Not really very little work, but still let's play it.

It depends.

Now we can officially have an It Depends episode. We are It Dependsing today on the topic of generalizing or specializing or maybe both.

That will be what we discussed today. I really enjoyed this piece because you call yourself an undercover generalist.

I have long called myself a generalist and also advocated

for generalization. But many times have been told why that's not the best thing to advocate for.

And so sometimes I stop and say, well, it does depend though, because maybe it's not always the best advice. So let's pick into that. First of all, introduce yourself with regards to this post and the work you've

been doing, contractor, Rust, et cetera. Give us like the two minute Adolfo so that we can have a foundation for a discussion. I should have prepared that. Anyway, let's freestyle it. So I wrote this piece because it's kind of, it's been a topic in my mind for a long time I've been struggling with. And I felt like I had reached a point that I could finally write about it. And how I came there is that when I got into computers, I just loved to learn everything there was to learn.

But then when I, when I got in the industry, you kind of, people wanted to put me in a box and say like, Oh, so you are a backend developer or you are a full stack developer. And well, I guess you have to play the game if you want to work. Right. So I became a full stack developer at a company in the Netherlands. And there was something generalist to it in the sense that it was not only programming, so you also had lots of interaction with customers. And I even got to like, I don't know, do a philosophy course out of the company's pocket. So they really liked, broadly developed people in their workforce. And then when I became a contractor, self-employed, I kind of started realizing that it's difficult to sell your services if you can't put them into a very specific category.

But at the same time, there are people out there who would hire me no matter what, no matter what the work is, as long as it's technical. So that's like a paradox there where people who already trust me, they are willing to hire me to do whatever, like computer magic and people who know me less, they kind of need some assurance that I'm capable of doing the job. And well, my Rust identity in that sense helps on that front because I have done a bunch of things in the Rust ecosystem. This was longer than two minutes, by the way, but I hope you'll forgive me. No, I wasn't timing you. Okay. I think that's good. So my background is somewhat similar in a sense that I began one place and kind of moved another place, but always was trying to be a generalist. And as I went freelance or solo or contract, I had lots of situations where people would come to me and say, I have this problem. And the problem was usually some sort of technology. Like I have a PHP app and I need some PHP help, right? Or I have a Ruby on Rails app and I need some Ruby on Rails help. And do you know any Rails devs? I actually just got a LinkedIn message two days ago, just latent, you know, I still have like that, I'm in that latent space of people still think that maybe I'm available for this kind of work, even though I haven't taken a new contract since probably like 2017, 2018. And he says specifically like, Hey, I've got need for a react dev. Do you know any good react devs around? Because I got 30 to 60 hour project looking for some help, you know?

And these are people who he just happens to know that I'm, was in the business of, you know, contract for hire and he's looking for a pointer to somebody, but he doesn't know how to categorize that person. Like I'm looking for a good developer because I have a software problem. Like that's just not the way people think they think in what's my code base. I guess that's how they think, depending on who they are. And so, yeah, if you're not a reactive, basically you're disqualified from that. You don't have to go back to him and say like, Hey, I know the guy named Adolfo. He's really good at generalized things. And if he trusts me a lot, he might be like, sure, I'll give him a shot. But if he doesn't trust me so much, he's like, nah, does he know react? You know? And so there's your specialization. So what you have found, and I, what I think is generally applicable is when you're putting your signup, you kind of have to have some sort of specialized skillset because people are going to be looking for that skillset, whether or not that's in their best interest. That's just what they're going to do. Is that fair? You think? Yeah, I think it's fair. And the nice thing that happened is that someone reacted on my blog post saying like, well, marketing, isn't the only way, the only reason to specialize. Okay. So the literal sentence was specializing, isn't just a way to the market. It's part of becoming a generalist, which has to start with one or more specific areas of expertise. And yeah, that resonated with me too, because part of the article was sometimes I kind of doubt, maybe I'm a specialist after all, so which of both you pick

when you're going to the outside world. And in fact, in the, since I wrote the article, I've been more and more convinced that I want to do the generalist stuff more as a hobby, kind of because I'm interested in computers in general, and I just don't want to lose touch with the general ecosystem, but I feel a lot like doubling down on Rust and systems programming at the moment. Yeah. So, yeah. So you might be specializing for a little while. Specializing in your day during the day and generalizing at night. That's interesting. I think that's true that you do have to kind of pick somewhere to start. And if you're going to become at least proficient, you know, to the point where you feel good about selling your work to somebody else and they feel good about hiring you, maybe you're not specialized in so far as it's all you know, but you need to be pretty stinking good at something to make your work hireable on the market. And so everybody starts somewhere. And if you're going to start with Rust, you're going to specialize in Rust until the point to that you're good enough at Rust, where you can now add another skillset to your, you know, tricks. For instance, accidentally I'm doing a lot in the software packaging space, especially around the Python ecosystem, because they are starting to realize that they can have huge wins in performance using Rust and it mixes

very well with Python. Like you can rub Rust code, Rust binaries in a Python layer in such a way that the consumer doesn't even know there's Rust under the hood, the same way you do that with C.

So more and more people are kind of investing in that. And so they'll become, I mean, these people have their own conferences, like the packaging conference. I didn't know about it. There's some specialization there, right? Yeah. Yeah. And also for instance, you get in touch with the container community, people who, I mean, KubeCon in Paris just finished, I think, it was last week. And it's also like, it's a very, like a specific corner of the industry. And yeah, like my current work is in the intersection between systems programming containers and software packaging.

So I'm learning a lot, not much about Rust, but a lot about these other things. Which is interesting for sure. I guess there's, there's more than one way to differentiate your work or to

stratify your work, to keep it interesting and not boring. My position has always been that my enjoyment has been to help people solve problems. And so I've always sold myself as a dedicated and thoughtful teammate to help you solve your problem. And I'll probably do that with software. And if you leave that to me, I will pick the tools that I think are best for the job. But I don't want to be attached to a singular tool because it's not always the right tool for a lot of different jobs. And I don't want to be pigeonholed because I've seen a lot of people get stuck where they are and never really move on. And my early young days, I used to say my, my greatest strength was fear of irrelevance. And so I was always up to date on what's going on. Cause I didn't want to become the guy who's irrelevant and doesn't know it. And I thought that that kept me sharp as a young developer and a lot of people

that just learn a thing, like maybe they learned Java in college and I'm not picking on Java for any particular reason. And that's just what they do. They just do Java and then, you know, 20, 40 years of Java and then they retire.

And for me, I was just like, I couldn't do that. I just never could. And so I've always been on the generalized side, but there are reasons to specialize. Like we've, we've addressed marketing. We've addressed specialization as a path towards generalization, I guess. And then the other reason is I think related to marketing, but pay. I mean, when you become very expert in a, in a particular vertical inside of software, and then that vertical becomes hot or useful or in demand, for instance, Rust programming skills are on the, you know, demands on the rise. If you were a data engineer, your AI engineer kind of person, like skills are demands on the rise and you become the person who knows that deep, right deep down inside, you can generally demand a higher wage as well. So I think there's another reason to specialize is to make more money. If that's your aim. Have you found your Rust gigs pay better than other general consulting that you do? I'm still figuring it out. So the problem here is that I've done some things in the European market, in the Dutch market, and also some things in the US market and that there's obviously a difference there, which is unrelated to whatever you're doing. The US pays better. I mean, I'm not sure if it's in general, but my contracts for US companies have always been for people like companies in Silicon Valley, which I guess have a money to burn from their investors.

So I'm not sure it's due to specialization or not, but within the Netherlands, if I compare, and Europe in general, the contracts I've done, like as a generalist and as a specialist, I've seen, yeah, big differences, but I mean, it's, it's still difficult to know because of the size of the company matters a lot too. Yeah. So for local companies, I've been able to charge significantly more doing specialist work compared to doing generalist work. So for instance, I remember doing a programming Elixir and like this company said, you know, you don't need to know Elixir beforehand, just come and strengthen our team. So they had a colleague who had been a colleague of mine in the past and he kind of vouched for me and said, this guy is good, just take him in. And I came to help and then later, I mean, I didn't feel like lots of money at the time and later other projects I did, I charged like 50% more or 25% more and

people were okay with that. So there's a noticeable difference. Well, friends, April is here and that means that Cloudflare's developer week is also here happening April 1st through April 5th virtually. They also have a meetup here in Austin that I'll be at on Wednesday, April 3rd in their ATX office. Check for a link in the show notes to register for that. Spots are limited, so secure your place right now. And I'm here with Matt Silverlock, senior director of product at Cloudflare. So Matt, what is this week for you? Launching for developers, a bunch of new tooling, a bunch of new things that gets

the next year or the next several months revived and a resurgence for new things happening. What do you, what's that, what does that to you? Internally we call them innovation weeks, which is kind of the way we think about it, which is how do we ship a bunch of stuff that is meaningful to the developers, both getting some things over the line, getting some early things out, sharing some ideas, some things that maybe aren't actually fully baked, but kind of getting that out there and talking about it so that we get earlier

feedback, but it kind of comes back to like, how do we think about innovating? And I think candidly, what's really, really helpful is kind of setting those deadlines, setting that week to kind of rally the team and get things out,

actually helps us get things done, right? There's always that tweaking for perfection, you know, another week here, another month there. It's nice when you set an immutable date, you get things out, gets it into the hands of the developers much faster. How do you then take that kind of, I suppose, approach and excitement to the bigger echelon that has become Cloudflare? Cause I know DDoS, CDN, like pretty common things that has been the building blocks of the, you know, behemoth that Cloudflare is today, but it's, it's gone beyond that. Can you expand on like the breadth and depth of Cloudflare today and, and the excitement happening? Yeah, I mean, obviously we do a tremendous amount and I think, as you said, most folks really know us for, you know, what we consider kind of the, you know, act one of Cloudflare, which is CDN, DDoS, you know, DNS web security. Since then, obviously we've done a lot in terms of zero trust and protecting companies and networks and obviously the developer platform as well. But you know, although a lot of what a set of our teams work on is developer platform, still a lot of the other things that the rest of Cloudflare works on, like a web application file or like CDN, those are still developer products, right? You still need those as a developer to go in front of your website, protect what you're actually building. Well, we're diehard R2 users. We had a, an insane S3 build that just sent us absolutely on fire. It kept growing and growing. And I was like, this can't happen anymore. Uh, we've had an affinity and a love for Cloudflare, you know, from a far in a

really, a lot of cases until we're like, you know what, R2 is pretty cool. We should use R2, you know? And so we did, and I think I tweeted about it about a year ago, and then over time, a relationship between us and Cloudflare has budded, which I'm excited about, but you know, why are developers, you know, we're opting for it, but for R2 in those cases, but why are developers opting for Cloudflare products over

Amazon web services or other providers out there? There's a lot of answers to this, but I think the one that I find kind of connects with a lot of folks is we're building a platform that makes it easy to deploy, you know, reliable distributed services without being a distributed systems engineer, because it turns out if I want to go and build something really reliable on sort of an existing cloud, I want to build it across regions.

When I've got to egress across regions, I've got to pay for that. I need to make sure I'm spinning up shadow resources, right? When you deploy to workers, for example, we just call that region earth, right? We take care of actually deploying all of those instances, keeping them

reliable, spinning them up where they need to be spun up if you've got users in Australia, and we spin one up there for you without asking you to think

about it, without charging you extra to kind of do that, that ends up being really, really powerful. You get your compute closer to users.

You don't have to think about that kind of coordination. In practice, it's just really, really hard to do that on existing providers. So we find a lot of teams coming to us so they can build applications at scale like that. There you go.

Celebrate live in Austin with us on Wednesday, April 3rd.

Again, check for a link in the show notes for registering to that spots are limited

and I'll be there otherwise enjoy Cloudflare Developer Week all week long from April 1st through April 5th. Go to cloudflare.com slash developer week again cloudflare.com slash developer week.

I think probably there's a lot of difference as well when we talk about contract work versus full-time wages, even when it comes to marketing yourself or getting hired, it seems like the kind of, the kind of the contracts that I got over the course of my contracting career, a lot of them were more the kind that you're talking about where it's, they know you already

or they've been, or you've been vouched for by somebody who's either hired you in the past or that they trust. And so in those cases, you kind of skip a lot of stuff and you go straight to like the first date is what I used to call it, like let's get to know each other and see if this is going to make sense, but a lot of people are out there like on the job hunt right now, which is probably thousands of our listeners as

many layoffs have happened and it's been tough right now to get rehired. It seems after you've been laid off because so many people are trying to

find work, that they have to lead with their specializations.

They absolutely have to, because like they won't even get considered, like their application will get filtered out by some entry-level HR person before they even get to the interviews because they didn't list the right jargon. And so that's gotta be frustrating, but also a reason to like sharpen your specific skills that are in demand today. Yeah. Well, and another topic you mentioned was seeing yourself as a generic problem solver versus seeing yourself as someone with a specific skillset. And there's a tension there for me too, for me as well, because I like, I mean, I want to work in such a way that I never lose out of sight the fact that I'm actually helping someone. So that's also why I couldn't work comfortably in a very abstract problem domain, like the financial system. Like, unless it's very clear, like, okay, who are you helping here? So for instance, if you make programmer tooling, well, you can make the life of Python developers less miserable and maybe contribute with the 99th package

manager to try to solve things.

All we need is one more and we'll be good to go.

So that dimension is very important to me.

But at the same time, I'm starting to realize there are some kind of problems

I'm just not interested in solving.

And that's interesting.

Yeah.

So that means you end up, like, I am starting to give priority to projects that require more thoughtful technical work and less to projects that require more, like just interfacing with business people, gluing APIs together, like managing a backlog and yeah, it's like a, I don't know.

Where this is going to end. But I think that like as time passes, problem solving is not

enough is mere problem solving. Everyone, everyone solves problems in the work. Some people cause problems, but yeah, everybody wants to solve problems. Yeah, I agree. But it's a very generic description. I mean, I really want to do stuff with computers.

So if you have a problem, which is a people problem, then I will honestly, I'd probably be able to maybe diagnose it to some extent and say,

Oh, I think you have a people problem. You should get someone else to solve it.

Yeah. Well, that makes you sincere Adolfo because, and I was the same way. One of the things that I stood on was I'm not going to try to help somebody who I can't help, even though I want to, because I want to help people, right. But being helpful sometimes is just being a pointer to somebody else, you

know, and sincerity and authenticity and honesty, and I guess integrity by, by proxy come out of the person who's willing to say, you know what?

I can see your problem. I'm thinking that the solution is over here and I'm not that guy or that gal. That's somebody else.

Like in your case, that's a people problem.

Here are some good people who can help you hopefully solve that problem, but it's not me.

And so you don't get that gig. You don't get that job.

You pass on it and that hurts because you want to make money or whatever, and you want to help people, right? Like there's always the tension of, well, I've got a family to feed. And so which jobs do I take? Which jobs do I pass? Can I afford to pass on this job? I mean, that's a hard one, right? Cause saying no is a privilege that not everybody has. Like sometimes you just got to have the work. How do you deal with those circumstances?

I guess I've been very lucky. So when I started out, I was in a mode of just do whatever, whatever comes up you take. But at the same time, I didn't want to devalue myself. So I set a pretty decent rate and it was challenging because I think I'm, I would be willing to take work that I'm not totally comfortable with for the right reasons.

But I'm not sure. Well, I mean, sometimes you just need to, but I kind of, things turned out in such a

way that I was never desperate enough to kind of do really like work with people who

don't value my work as I value it. So that's for me, like a, like a first basis of collaboration and only then comes, well, what kind of work are you going to do? So, and as I said, I've been very lucky. Like when I started out, I had planned things in such a way that I, I mean, I could afford having a little work and since then I've had work kind of nonstop, except

vacations, though it's still, I get very nervous when, well, I don't know what I'm going to do next week. And the funny thing is I shouldn't because purely from the numbers perspective, I mean, I've planned everything in such a way that I could, I could have months of no projects and everything would go well. The thing is when you don't have something, you start thinking like, oh, well, maybe

this is the end. Right. Maybe there's nothing else down the line. Maybe there's nothing coming after this. How did you get there? Did you just save up while you're working full time or? No. So I started very young. I have a very low cost of living. So that helps. That means that, I mean, if you can, let's say if you charge from a hundred euros, a hundred dollars per hour above, then just a couple of projects a year will, I mean, if you work two months for 40 hours per month, per week, then in a country like the

Netherlands, I should like kind of make the calculation, but, but you should, you should have enough money to survive if you are frugal. So not just two months of work. Yeah, the math works out in your favor because your low cost of living, high hourly

wage when you do have work equals, you don't need to be billing 40 hours a week in order for you to survive. Yeah. And additionally, there's like benefits and drawbacks to this, but the, the kind of welfare system in a country like the Netherlands means that if you have, I don't

know, a very serious illness, you won't be bankrupt by that. So you, everyone has mandatory insurance and like you would never, let's say under normal circumstances, you would probably never pay above a thousand euros for anything in your healthcare. Yeah. So your emergency fund doesn't need to be as big as people in other circumstances because you have a, you have a cap on your emergency spend.

Yeah, exactly. So, and after the first year, which was, I mean, it was tough, not from a financial perspective, but more in a, I don't know, psychological perspective. Like when you have had no work for a couple of months, you're like, does this

still make sense? And at the beginning you are, well, you know, it doesn't matter.

I can, I don't know, learn new stuff on the side, read all these books I wanted to read and whatever, but then where's the work? So in fact, I got kind of stuck after a few months and only thanks to a recruiting platform, I got the next, the next project. And it was kind of, yeah, it was a six month project. So that was nice. It meant I didn't have to look for anything else in that time. And after that project finished, I got another six month project, which was nice too. And after that, things got more, kind of had to serve the waves. Right. It got more, more like a roller coaster, but about that time it became like the Rust breakthrough where there was, well, I started writing more actively, like trying to actually started framing myself as a Rust expert. And I don't think this is a good strategy to get random people from the internet to work with you, but I think, well, it's mostly luck that someone thought, Hey, they saw like a couple of blog posts and they thought we should work with this guy. So they sent me an email and I worked for them for a couple of months. And then a Rust maintainer, I know of the couple of Rust networking libraries, he got offered to work on that, being sponsored to implement a few features, but he didn't have time. So I told them like, Hey, you should talk to Adolfo, he's good. And then I ended up doing that and that way things kind of escalated because I

ended up getting on the radar of the ISRG, the people behind that syncript.

And they asked me to work for about five months on a very nice project. So I got to do lots of open source work last year, which gave me also lots of things to write about. And I feel, I feel like having done this amount of work in the open and writing about it has helped me market myself, I guess, as a specialist, as I wrote in the blog post. Right. So you can remain an undercover, maybe generalist. But the thing is, I started right, I started doing this more out of a marketing necessity and kind of afterwards, like last one or two months, I started thinking like, Hey, I think this is not only marketing, I think I actually like this.

Maybe I should just stick with this. And of course, one of the things I love about this is not necessarily working with Rust, which I mean, is a nice language, but it also has its words. It's mostly that I get to learn a lot. So for instance, diving into the container specification, and recently I had to investigate lazy loading techniques to get your container startup faster. It's so interesting to kind of get in touch with the great ideas people have had about how software should be packaged. And you become smarter by studying the specification someone else wrote, because they're smart. The same goes when implementing the network protocol, like you get to read a bunch of RFCs and I mean, they're not perfect, but I don't know, for me, it feels like you become part of a community of very smart people who are driving the foundations of technology further. So that's, that's very attractive to me. It's like becoming a, well, I don't, I don't think I'll ever become like a famous internet person, but I kind of treading in the path of the people who build the internet, which is nice. Yeah. So you'll be the kind of person, it's kind of like the actor's actor, you know, this concept of like certain actors are not famous, like superstars famous, but they're so good at what they do, that they are respected by other actors more than they're respected by mainstream audiences. It's similar to like, if you go ask a major league baseball player who their favorite player is, a lot of times, they're not going to say the most famous baseball player. It's going to be somebody that is like, yeah, he's good. Like everybody knows that's a good player, but the players know that that player is good. And so there's like this undercurrent of respect there, even though you're not going to have necessarily, you know, starring Adolfo Ochocovilla on the play head there. I did notice you have a awesome testimonial. You mentioned Let's Encrypt from Josh Oze on your website, for instance. Like that is probably worth its way in gold for people who know who Josh Oze is,

like to people who are in your little niche. Yeah. Like that's, I know Josh, I've met Josh, we've had him on the show. I respect him quite a bit. I saw that. I'm like, dang, that's a nice testimonial. Like, I would love to have that about me. And he said that about your work. So that's indicative of that. Yeah, it's amazing. It's also like, I've very consciously tried to ask for recommendations after every successful project. It's not comfortable to do so. Yeah. But if people are happy, they will be happy to write something for you. And it can make a big difference, not necessarily making you more findable, but once people find you and they try to validate you, like, is this guy really worth this much money? And they see, Hey, all of these people from the Rust ecosystem and elsewhere are saying that it's worth working with him. So, yeah, I haven't, I haven't yet kind of experienced that this really makes

difference because I'm still getting most projects through network, like people who know me, who recommend me personally, not just on a website. So. Well, I can't hurt. It's certainly social proof to confirm perhaps a recommendation or a network, you know, cause they're going to check you out. Even if I got a recommendation, Hey, I'm looking for somebody who does Rust, whatever, whatever, somebody I trust says, yeah, check out Adolfo. He's pretty good. I'd go to your website. I would read it. I would see that testimonial of Josh O's and I'd be like, okay, there's two witnesses there that say he's good. So now I'm going to go ahead and have more confidence in hiring you that first time. So certainly can't hurt.

We have a similar situation with like podcast recommendations because we get a lot of nice emails and I love them. And we have dialogues in private with listeners who say like, you know, our shows are good, we've helped them in this way, et cetera, et cetera. And yet. In terms of like getting that into something that could be a recommendation that could be used publicly or something I have to then ask, you know, which is always kind of feels weird, but over the years I've finally just said, you know what, I'll just reply back, thank them so much. And then say, I even just did it just the other day and he was happy to go do it. I'm like, can you just copy paste that into an Apple podcast or a Spotify review? Because those are really helpful for us. And he's already written something nice. So copy paste, throw it in there. We really appreciate it. And people usually say yes, but it always feels a little bit tricky to ask because it's just like, yeah. Yeah. Yeah. But on the other hand, I mean, if you really think you have something to add to this world, you need to help people realize that you are there. Right. So, yeah. Is this the reason for your writing? I mean, you said been writing more, is this kind of in the marketing work? I mean, cause Hey, I found you because of your writing and now we're friends. And now I know, you know, if I come up with somebody who needs, who needs rust help, I might point them to your direction. So it's working, but was that the reason for the writing or do you just like to write? What are your, so there's a bunch of reasons.

I've always liked to write. I even, when I was in school, I thought about getting into philosophy after

finishing high school, but I lived in an environment where people were like, are you crazy? You will starve. You just go and become a lawyer instead, which is also kind of related to the humanities, you know? So I went and studied the first year of law, which was interesting. I think I got pretty much like a bunch of things out of it that I'm still using today. But then I decided I wouldn't write contracts for people who never follow them, but for computers who always do what I say now. So I made the switch, but like the, the interest for like for writing has always been there. And then actually similar to specialization, my main motivation, well, I don't know if it's really similar to specialization, but in any case, my main motivation to write at the beginning was as a way of, a way of marketing myself.

But at the same time, I felt like I should only write if I actually had something to say. So it's like, it's a combination because I just refuse to write filler articles. I don't even think that it would work because people are smarter than that.

I mean, at least the people I want to work with. So yeah, it started out as a marketing need. Like I needed to prove myself that I was a Rust expert. I mean, I was talking to a company and they were like, yeah, but like, who are you? So I thought I'd never want to have this conversation again. So I wrote a whole blog post explaining kind of, they did some historical digging. What was my exact contribution to the open source project? And I wrote down a big blog post, long blog post made the, I think it made the Hacker News front page to explain, well, this is what I did. And I'm not like one of those famous Rust contributors, but well, I did this and I did that. And I organized the Dutch meetup at the beginning a couple of times and yeah, that kind of worked. And after that, I started realizing, especially last year, I started realizing that people really get inspired by what I'm writing and that like I started receiving emails from people and seeing subscribers.

And I mean, it's not like I'm looking a lot into numbers because I'm not doing it

for the numbers, but I've had people write to me saying this article has really opened my eyes to X. And that's very special because I think if you have something to contribute to the world in any way, and you are capable of doing it within your means and without it going against more important stuff, well, why wouldn't you do it? So writing articles takes lots of time, especially if you want to write things that are worth reading. And pain too. Yeah. For me at least, maybe that's just me, but I feel like, and I always, I pick on my wife because I use this analogy and she hates it and she deserves to hate it because she's given birth to six children. And so I say, you know, you don't write, I don't write a blog post. I burr the blog post and I'm just trying to relate to the pain, but she's, you know, she won't have it.

And with good reason, I have no right to say that, but it does feel like that. Like for me, it's just like, not drudgery, but just painful work. And then I always appreciate, like, I always just like a child, like you go through all of that and it's the worst pain in human life, you know, that doesn't kill you or whatever. And yet afterwards it was all worth it because now you have this child. And a lot of times a blog post can be like that as well on a microcosm where it's like, this was a lot of work and anguish. And yet I always am glad I did it at the end. And that doesn't always motivate me to write the next one, but still it's worth it. Especially when you have people like you Adolfo with their email and you telling you that you inspired them or you intrigued them. I mean, it pays dividends, but it is, it is work. It's hard work. Yeah. Like recently I, I even ended up meeting people in person in Amsterdam because of one of my blog posts or having video calls with people from other countries. And I even got someone from Lebanon to go for lunch with one of my friends because I thought, Hey, I think you were the kind of person this guy would love meeting. So why don't you just meet? You two should have lunch. And that actually worked out and they did it and they enjoyed it a lot. They sent me a selfie and I was like, Hey, it's so nice that something small, such as a blog post, but actually it was this blog post that started also this conversation about the undercover generalist, that it triggered so many good things in so many people that, so as I, as I mentioned, I started writing from

a marketing perspective because I actually saw it as an investment.

I need to invest in my reputation.

And with time, I'm, I mean, I always thought it also contributed something to the internet discussion, but I'm starting to see, to think more and more that the contribution, even though it's not like life changing in an, in a bigger scale things, it is a real contribution that's worth doing. So even, I think even if I didn't have my business, I would end up writing anyway, maybe less frequently because it's just a lot of effort. But yeah, I just, I think that there's a bit of a lack of authenticity on the internet. So even if you write about very like daily programming stuff, like, Hey, I did this project and I had lots of fun and this is what it was about. People love it.

Or, Hey, I'm, I became a contractor a while ago and I've been struggling

with lots of things and I've figured out a bunch of things, but lots of other things I haven't, and I'm also a bit afraid. Here's my story. Yeah. Or the, the same about the, well, I mean, we're talking right now, like, it's so nice when you don't have to pretend you're some kind of expert. And I mean, when I opened LinkedIn or many, many places where you normally get articles from, people are pretending, they're pretending they're kind of

Einsteins that know everything. Right, gurus, there's gurus everywhere.

The five things you need to know to avoid starving in the next recession, you know? Right. So just writing about normal stuff from a real human perspective, and I'm filled

with curiosity about computers and I think I can pour that into my articles. And I also care about the people who are reading my articles. So I guess people in some way perceive that.

Yeah, no, I think that's true. And there is a lot of noise on the internet. This is one of the reasons for changelog news, which we've done for many years is just to be able to highlight people who are writing like you're writing to cut through a lot of the gurus and hopefully provide some signal to people who really

deserve it. I mean, our whole deal was like, shine a light where it should be shined.

And we hope that we do that on a weekly basis with that show and that newsletter. You know, any newsletter has probably between 12 and 20 links. And I think that like any working software developer who's curious in this space will find one of those like sincerely good and touching to them. But those are hard to find, you know, and like people like yourself are hard to find. And so not everybody has time to do that work. And so we try to do that work a little bit just with that, that little spotlight of ours that we can shine on people. So it's pretty cool. And I also think that your sincerity is absolutely spot on because insincere

writing, grandstanding, AI-generated trash, as a seasoned reader of the internet, I can spot that stuff a mile away. And I can also know when someone's writing from their heart and from their experience. And when I read that post, I was like, this guy knows exactly what he's talking about.

He's like, I just, there was no doubt that you were sharing that from your actual real experience. And so I would encourage you to keep writing. I want to also encourage our listeners who maybe aren't writing, but have things to share with the world is to go ahead and go through the pain, birth a blog post, send it my way, and we can get other people reading it as well. One of the people who inspired me a lot in this regard is Julia Evans. Like her writing, there's something special about it because... Yeah. Well, so much voice. Yeah. I mean, it's not the way I write. I mean, I like to polish my stuff much more. No, it's her voice. It's her voice, not yours. You have your voice.

She has hers.

It's like, she doesn't feel the need to appear as an expert about anything. Right. She's just like, Hey, I love computers. You should love them too. Yeah. And I'm actually trying to write from the same source with a different voice, but it's, I

think it's the same source and you end up writing stuff that it's not necessarily very generalizable in the sense like, I mean, you won't have advice for like the programmers of the world, but you can have a couple of stories, inspire someone with your curiosity, and maybe you'll document a bunch of things that someone will find useful about containers later when they Google something. Yeah, but at the same time, I think advice that is generalizable to the programmers of the world is very rare. I mean, that's the reason for the It Depends miniseries is because there's very little generalizable truth. I mean, maybe Fred Brooks hit on a few things. You know, there's no silver bullets. I think that's generally true. The mythical man month, generally true, but even our idioms and our cliches, don't repeat

yourself, right?

Our design patterns, they all have yeah buts like all of them do. That's why I specifically am trying to avoid that kind of stuff.

Like, Oh, you should always unit test your code, right? Come on.

Or all kinds of different generic rules.

You should. I did write one once, which was born out of my own experience. After many years of writing CRUD web apps, and that was titled, you might as well timestamp

it.

And the general premise there was, you think you need a Boolean, you probably just want a

timestamp, you're going to wish it was a timestamp at some point. Trust me, I've done it 100 times and been like, I'm going to switch this to a timestamp. You might as well just timestamp it. And still even that phrasing, which that one did go, I think like number one hacker news for a day or something, even that phrasing still has some wiggle for a minute. Like it's not, you have to, it's you might as well.

And so every once in a while you'll hit on something, but even that has its yeah buts. New level timestamp, right? Yes. Where new is false and the timestamp is true. Exactly. And the existence of the timestamp is true. Sounds useful. It's just the same exact, it ends up, it's practically the same thing, but it has more information basically.

In practice, you get the same functionality, but you also have a time associated with it. Now there's other ways you can slice that too, which give you more information and you'll find those in the comments to my blog post, which is great too, because that's the other thing is when you write, you learn because there's lots of other smart, mostly genuine people. I mean, that's also one of the reasons to write, to see what other people have to say

about the topic.

Like I've been very curious about the topic of generalization and specialization and every

time it comes up, I kind of look at the comments, see what people have to say. And the fact that a whole bunch of people on Hacker News started commenting on my blog

post was amazing because I got to read lots of interesting stuff. And I see that like as a symbiosis between my article and the people commenting that becomes a new whole that people can consume is such a horrible word, but...

Consider. Yeah, consider.

It sounds much better. Oh, thank you. Absolutely. A lot of times the comments are the best parts. Sometimes the comments are just a dumpster fire. So it's hit or miss, but sometimes they're the best parts. Yeah. Hey friends, this episode is brought to you by our friends at Cinedia. Cinedia is helping teams take NAS to the next level via a global, multi-cloud, multi-GEO and extensible service fully managed by Cinedia. They take care of all the infrastructure, management, monitoring and maintenance for you so you can focus on building exceptional distributed applications. And I'm here with VP of product and engineering, Byron Ruth and David Gee,

director of product strategy.

So when you think about connectivity being the first thing to consider, someone pushed back on this and say, we'll think about it later. What competes with a mindshare of connectivity? Just like an HTTP developer, you actually just download and run the NAT server. Whereas an HTTP developer, if you're building an HTTP set of endpoints, you typically have to implement or, you know, use an HTTP library and then, you know, whether it's a go standard library, Python, whatever it is, and you're actually implementing endpoints that register into the HTTP server. And then now you have to go deploy this HTTP server and ensure that it's like performant. So it's a slightly different model, but like you download the NAT server. It's a standalone binary. It runs on, you know, the majority of platforms. And then you have a handful of client SDKs across all the major languages, you

download that. And we even have a higher level API that is akin to what HTTP

developers have of like defining a handler, for example, we just call it our services API. And you basically have a few boilerplate things that you register your handler in the NAT's context and out of the box, it actually supports sort of a general request reply setup. And then you get all of these other benefits out of the gate. But the experience and like the onboarding is arguably just as simple as any other HTTP onboarding, with the exception that you're technically deploying a client application that implements these NAT services in addition to the NAT server. But that's where the Cine Cloud, it's already a managed instance, you know, and we even have the demo server for you to just try it out.

It's a public endpoint that you can literally connect to.

So you can still build a simple client application, use the demo server as the endpoint, and then you can play with that and use that as sort of the server deployment. Well, if we talk about it just from, you know, the central view of applications for networking, all that kind of packet based stuff, you were calling them HTTP developers, which kind of stork instead of API devs. I mean, what do people do? They glue it together at a primitive level. So the primitive being HTTP, they move up the stack in their mind's eye and they go, oh, we're going to do some gRPC, which is kind of still point to point. So it's a lot of point to point stuff versus broker assisted connectivity, which is way simpler. You know, you connect to an endpoint, you get taught about other

endpoints. It's like connecting to a hive mind.

You know, what we're trying to do is move people away from coordinated point to point connectivity to easy connect to anything securely and connect to your other stuff securely instead of having to coordinate the whole rat's nest of where to connect to them. Then you've got to negotiate. Well, what do we do then? Now we're going to get the schema information and can we even connect to this thing and does it even work and what version is it and all this stuff? What we're trying to do is transform that and flip that to unify it to make it much simpler. So I think we're trying to go from a rat's nest of point to point connectivity in the application space to making everything on net.

And it's like connecting to a hive mind.

And what we're kind of asking people to do is think about applications the same way you would video conferencing. So if me and Barb are going to have a chat, we might do a huddle on Slack or jump on a Zoom or something. But if we want a colleague to join, we ask them to join the same course. We can have a point to point conversation by the same medium or we can have a party line by the same medium. So, you know, it's request, reply or pops up, but it's on the same platform. We don't care about what Zoom server we connect to. We join, we connect to the service and we coordinate our communications over the fabric. There you go. Yesterday's tech is not cutting it.

Nats powered by the global multi-cloud, multi-geo and extensible service fully managed by Cinedia is the way of the future. Learn more at Cinedia.com slash changelog. That's S Y N A D I A dot com slash changelog. Back to specialization. There's one danger in specialization, which I think I touched upon, but let's talk about it more directly. And that is when you specialize in a technology, you are making a choice to invest into a particular technology in lieu of the others. Like it's your exclusive of the others and Rust is working out very well for you, but you can also back the wrong horse. Yeah. As many people have and I even have a few times in my career, I've invested in technologies that no longer are in use. And I'm not talking about jQuery. That was a good backing in the day because it lasted for a long time in the marketplace. It's still in use. Yes, it is. But for instance, I got into Cappuccino for a while. Have you heard of Cappuccino? This was a JavaScript library that was built on top of another project called Objective J. This was from a startup called 280 North. Very talented guys. They built basically Objective C in JavaScript and Cappuccino was their app kit.

So they were basically like copying Apple's app kit framework into JavaScript and you could write it in Objective C-ish all. I think it was either transpiled or somehow done at runtime. I can't remember. And so they had this whole and they had a great web app called 280 Slides, which was an in-browser keynote clone-ish and it was very whiz-bang. And I wanted to learn Objective C anyways because I was getting into Mac OS development

and I was already writing a lot of JavaScript. And I thought, OK, I can learn some Objective C. I can keep doing JavaScript. I can bring it into the browser. And I spent about a year building Cappuccino things. It generated one client for me and that was it. And then it kind of went by the wayside. All three of the people who created Cappuccino moved on to other projects. I'm sure it still lives out there in some production code somewhere. This was about probably 2008, 2009 time period. And now you don't know what it is. Right. So that was like in terms of making a bet. That was not the best bet, but I didn't get deep into it. So I was able to read the tea leaves and move on. But you sure can back the wrong horse. And now you're really in trouble there. Can you speak to that? I mean. Yeah. So I also think about this because, I mean, you don't want to make bad choices in general. And I haven't met anyone who really got stuck in their career, probably because I'm very early in mine. I'm 31. But I've read plenty of comments on the Internet from people who got stuck. But I've always wondered, like, what is the real cause? Is this because they made the wrong bet or is this because these people have no proper network? They have, like, maybe they ossified their ability to learn new things. Like, there could be so many causes behind a random Internet comment saying, oh, yeah, I specialized and now I can't find a job. I've also seen other kinds of comments, people who wrote to me because of my article saying I'm a generalist and now I can't find a job. I should have specialized.

So for me, it feels like maybe you are looking the problem in the wrong place.

And what has paid off for me a lot is just genuinely caring about people and about your

work. With a bit of luck, the combination can be very powerful. Like, and I think also one of the things I like going back to the risks of investing in the wrong technology, I'm trying to invest in very fundamental technology. So Rust has pretty much won at this moment, like all the big companies are betting on it. The U.S.

has made a document saying we need to move off memory on safe languages like Rust is in the Linux kernel. When did you make the bet, though? When did you decide on Rust? I didn't very explicitly make it. I got into Rust because I was curious and I confess I was conscious that this might pay off and it might have motivated me a bit more than just fooling around. Yeah. But the way I bet with this kind of things is I make sure I bet on something that it's worth to me now. So even if I lose the bet, I don't regret it. So even if it doesn't pay off in the long term, at least it pays off in the short term, like, hey, I learned a bunch of very interesting things. I got to participate in an amazing open source project with a great community. Yeah. So when I started working, thanks to my involvement in the Rust community, I wasn't like the random junior guy who just got out of university because I knew how to properly use Git, how to properly make pull requests, test my stuff, like lots of things that are kind of basic once you get the hang of the craft, but which could take you maybe a couple of months or longer if you haven't had this exposure to, I mean, even your expectations, like if someone writes a bunch of untested code and you're right out of university, you say, oh, this looks like most of my code until this date. But after participating in the Rust community and like seeing a coworker write no testing code, it would be like instant red flag, like, wait a second, like, how do you know this

works at all? And I mean, without getting into like dogmatic test driven development kind of

stuff, but like full test coverage or whatever. But basically have a kind of developing, I don't know, some kind of second nature or taste for how a project, a software project should be managed. That was, how do we end up here actually? What are we talking about now? Well, we're talking about making bets on the wrong technology. Oh, yeah, right. So, yeah, exactly. So even if Rust hadn't panned out, I would have ended up a better programmer because of this bet. I think that's fair. I think, and looking back at that one particular bet that I made that didn't pay off, I don't really regret it anyways, because A, I had fun. B, I expanded myself as a programmer because I learned a lot about the JavaScript runtime inside the browser, things I didn't know when I came to Cappuccino. I learned a lot of Objective C isms, which for better or worse, I like some of that stuff to this day, and I still carry with me that experience. And I was also ready, willing and able to let go of it once I saw like this isn't actually going to go anywhere from here probably.

And that's the other thing is like, you can't be dug in when something starts to fail. Yeah, I think that's like a key idea, and that's also one of the reasons, even though I'm doing more and more systems programming stuff, I still keep an eye on other technologies who come and go, which are coming and going. Yeah, what's peaking your interest right now? Like if you were... So outside of the Rust bubble, I'm very interested in the way .NET and C Sharp is developing, like they are investing a lot in making it a proper like a language where you can write like high performance coding. In fact, related to the recent Redis license change, the alternative that Microsoft has made very timely, which is incredibly suspicious. Yeah, I know. It was actually I just talked about that the other day. It was like two days prior to the announcement of the Redis license. They announced this project. I think it was called Garnet or Garnet. Yeah, Garnet. Yeah, it sounds like I mean, they are probably offering a host to the Redis on Azure, right? So they must have received some communication from Redis. I'm sure they saw it coming. Saying like, hey, you should start paying in a few months. And oh, all right, goodbye. Redis client compatible.

Yeah, yeah. So anyway, that thing is written in C Sharp. Yes, I saw that. So and some I mean, if you knew C Sharp from 15 years ago, you would think this is madness. But C Sharp now is not C Sharp from 15 years ago. How so? It's evolved a lot. And the dotnet framework is now cross platform. It has lots of very interesting features. So to me, it feels very natural that this project is written in C Sharp. And in fact, when I write non systems programming code, I mean, when a client says to me, just use whatever language you want, I'll very often pick C Sharp. So I like I'm following it a little bit. Less actively than Rust.

And then, I guess just keeping an eye on Hacker News and seeing which things trigger my interest. There's not lots of time to invest into that. I mean, it can also be I guess most people have experience that it can get out of hand. Yes. Because well, we are curious, right? That's why we're into programming. Yeah, at least myself. So yeah, you need to take a bit of care. Yeah. But right now, like, I mean, I'm also trying to diversify my knowledge based on the work I'm doing. And I think that's also a good proxy. Like if someone is paying you to learn something, well, I guess it's worth learning. So I've been getting into, well, I don't think this will be reusable knowledge, but I was paid to do it. So I wrote a dependency solver for a package manager. Okay. And Python? Yes. So for the Conda ecosystem, it's being used, like for a new, like a replacement for Conda. And I don't think I'll ever get to do that again, unless there's some random person who randomly needs a dependency solver.

Yeah, yeah, yeah. But on the other hand, like it wasn't a bet, I was paid to do it. So I was, in fact, paid to learn this. However, sometimes I get paid to learn things that I know will be reusable. Yeah. For instance, I investigated how to produce container images very efficiently directly from Python packages without actually going through Docker. Just downloading the packages directly, messaging the data and generating a container image in parallel, every layer in its own process. Like it's amazingly fast. And a year later, a company that read that blog post said, hey, we actually need exactly this and come help us. That's the project I'm doing right now. So I had to figure out the container specification, a bunch of protocols and low level stuff, which does feel very reusable. And I also, well, we will see also, I mean, we still need to see what happens with AI, but I would expect that fundamental work, like someone, like some real human person needs to understand what's going on at the base of things. So that also, from that perspective, it sounds like a good idea to bet on the low level things. I'm kind of betting on them right now, but I'm being paid to do it. So it feels less like a bet. Well, that's a good reason to take a gig. I used to have like a decision rubric for a project where I would have three things. I'm trying to remember back because this was years ago. I would look at three different aspects of a project in terms of is it interesting to me or is it worth taking? Right. And the first one was money because I'm trying to make a living. And so if the money is there, that's a good reason to take a project. It's not the only reason, but it's a good one. The second one was intellectually interesting. So it's either something that I'm interested in the problem space or the technology, or like you're talking about, it's a technology I already wanted to learn anyways. Yeah. And now I'm able to learn it while being paid versus learning it while not being paid. Yeah. And then the other one was reputation or portfolio. Right. I mean, that's real. Like you have to build your reputation. You have to have examples of things that you build. And so like, is this good for that? Well, this sounds a lot like my own heuristic. Does it? Yeah. Those are the three things I would look at. And then you have other things too. Like, you know, is it something that I'm, I have a moral problem with? Like, I remember one, one time I went down the road with this gal about helping her build a website. I didn't go very far down, but it took me too long to realize it was a porn website. And then I was just like, I'm sorry, I'm not interested in, I just don't want to work on this kind of thing. That was a stopper for me.

So there's other things that are like, nope, not going to do that. But for the most part, those three things. And if I could get two of the three on any given project, I'm super happy. Right? Like if it pays good money and I'm learning something new, super happy. If it's learning something new and getting a nice portfolio piece, but not paying very well, pretty happy. If I can hit all three, that's a home run. Very happy. Yes. Very happy. For me, it's the same. I mean, I don't put the moral stuff in the list because it's, it's not up to negotiation. Right.

So it is worth asking upfront sometimes because, because I, so many people have moral obligation or not obligations, moral objections to certain types of projects. The people who have those kinds of projects and are looking for that help, they'll kind of hide it and they'll save it till later down the, you know, at least that was my experience. Cause I was like, you should have led with that. Don't you think that should be right on the front page because now you're not wasting your time and my time. And it was almost like she was trying to sneak it in the side door and hoping that it wouldn't bother me. Well, if it wasn't going to bother me, it wouldn't bother me at the beginning either. So it's just a waste of time, but yeah. Okay. So specialization, generalization, technologies, decision-making. Have you ever thought about just going back and working for somebody full time to get a job again? I sometimes think about it when I, I'm afraid I'm not going to find enough projects on my own, but it always feels like, well, I would be doing it out of fear.

The fear that I won't be able to find projects, but, and I actually think that's not a good enough reason for me right now. Like yesterday I published another article about like a sequel of the one on the undercover generalist. Oh, really? I should have read that. It was, it is called from false tag development to systems programming. And at the end of the article, I mentioned that I actually dread at this moment, going back to an office job. Like this very call we're having now, it started for me during working hours and I don't care because no one is expecting me to be at an office.

So there's a level of independence that I really enjoy, but also there are many different aspects to it. Like even the reputation aspect, I feel like when you are working independently, you can, it's much clearer which impact you are making in the projects you are involved in. So that testimonial from Josh asks, you wouldn't, I'm not sure you would give that to a team, but you can give it to one person you have worked with. And you know, this guy made this and it's great. You should hire him. And so even from like my craftsmanship sense of like wanting to be recognized for my work, it feels like at most companies that just wouldn't be, wouldn't happen. So I kind of like, I'm still, well, I'm still searching.

I mean, it's, this is a long journey, but I, right now, I like the mental model I have career wise is I want to try to become like just a very good craftsman. And the people know to find me when they need a craftsman, because I, if they don't need a craftsman, well, I guess there's plenty of other people out there who can help you too. Like if you need to build something simple or, yeah, well, the robots will build those for people soon enough.

So the craftsmen will be the only ones left.

I hope, well, I hope at least that remains, otherwise I'll become a mere interface to the, to GPT. Exactly.

I mean, someone needs to translate business needs to GPT, right? That reminds me, I think now might be the best time in history. If you want to stake your claim as a, I don't know how to name this yet, so somebody needs to put a name on it. But the people who come in after the robots program you things and they fix everything, you know, similar to, there was Rails rescue projects. You know, I got, I did a bunch of rescue projects where it's like, we have a hot mess.

It's still serving value to our business, but nobody can touch it because the people that built it moved on or whatever. Please come in and save this project so that we can continue to do things. And there was like Rails rescue. There's like teams that all they did was, yeah, I rescue team. Yeah, exactly. And there was similar things for like, you know, you go to the wrong outsourcing, you know, a company, you end up with a hot mess. You're going to end up with some AI hot messes. And I just feel like if you want to get at the top of the search results right now, or not right now, in the future to be the rescuer of the AI, we got to get the domain. Name on it, right? Like this is when you stay here. Rescue.com AI rescue. Somebody can have that. Yeah. That's a free idea for anybody who wants to, it's obviously already registered. That's true. There's nothing new under the sun. Someone's all over that. All right, Adolfo.

This has been lots of fun.

The website, ochagavia.nl. There you'll find his writing. You can subscribe there. You can hire him anywhere else to send folks to connect with you online. No, I just use my website and email on GitHub. Well, you can find me on LinkedIn too, but that's like a horrible place to find people. Uh, I used to agree. I'm starting to disagree. And here's why. Everybody's there. And you used to be able to say that about Twitter. You can't say it about Macedon. You can't say it about threads. You can't say it about blue sky. You can't say it about X, but with LinkedIn, I mean, what a world, what a world we live in. To where it's like, you want to find people, everybody's on LinkedIn pretty much to a one.

So that's, that's a weird, but, uh, other than that, I would a hundred percent agree. Well, that's why I haven't left. Yeah, you can't leave now. That's where everybody is. Ah, Microsoft. All right. Well, thanks for hanging out.

A quick mention for those who want some more of this is that Adolfo and I actually had a, about a 45 minute pre-call recorded. Because as an authentic, sincere person that he is, he wasn't sure he was qualified for podcasting, I guess.

How, how would you frame it on awful?

You weren't sure that you could handle a conversation with me, which was, well, yeah, I just wasn't sure. I haven't ever been on a podcast before. So we talked about, it was a lot about rust. It was a lot about your history. I can't remember what all we talked about is about a month ago now, but we're going to put that in after this for our changelog plus plus members, because it really is a bonus. And so if you want some more to learn more about Adolfo and, you know, hear from me some more as well, stick around. If you're on changelog plus plus, if you're not, well, what's wrong with you? It's better.

Sign up for changelog plus plus, changelog.com slash plus plus, support our work directly. And then you'll also be able to stick around and get another 40 minutes of us to gabbing.

All right. That's enough of the sales pitch. That's all talk to y'all on the next one. Bye friends. Bye Adolfo. If you enjoyed this conversation style, we have a couple more in the back catalog.

Go listen to changelog and friends number 22 with Justin Searles on dependencies and to episode number 24 with Chris Brando about API design. And if you want more like this, let me know what topic and or guest you'd like me to, it depends with next. The best place to do that is at changelog.com slash request. Thanks once again, to our partners at fly.io to our beat freaking residents, break master cylinder and to our friends at sentry use code changelog. When you sign up and you will save a hundred bucks off the team plan. Plus that will help sentry know that we're making an impact on their business. Once again, use code changelog all one word for a hundred dollars off next week on the changelog news on Monday.

Zenno Rocha from Dracula and recent on Wednesday and Gerhard returns for Kaizen 14 on Friday. Have a great weekend. Please share our work with people who might dig it and let's talk again real soon.

So here we are. You were saying that you are from Chile, but you're currently in the Netherlands. That's true. What are you doing there? So I came here when I was 19 to study computer science. And, uh, I think it would take the full half an hour to explain, but, uh, it was, uh, one of the best decisions in my life.