The Changelog: Software Development, Open Source - The undercover generalist (Friends)

Episode Date: March 29, 2024

Which is smarter: specializing in a particular tech or becoming more of a generalist? It depends! Which is why Jerod invited "undercover generalist" Adolfo Ochagavía on our "It Depends" series to weigh the pros & cons of each path.

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. Okay, let's talk. Yes, let's talk about our friends over at Fire Hydrant 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 Fire Hydrant 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 really good, actually.

This is a consistent problem for us and teams, is that covering these sorts of ad hoc timeframes is very difficult. You know, putting in like overrides and specific days and different new ships is 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 pager duty right is i get all these alerts and then i get an incident per alert and generally speaking when you go 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 the one alert fires for one team and then it seems like they have to bounce around and it never does, which then means that we have tons of communication issues because people aren't updated. No, I mean, to be open and honest, when can we switch? So you're probably tired of alerting 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 firehydrant.com slash signals. Again, firehydrant.com slash signals. Again, firehydrant.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 have with me Adolfo Ochagavilla. 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, and I enjoyed it. 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 Depends-ing today on the topic of generalizing or specializing, or maybe both. That will be what we discuss 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 etc give us like the 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 that 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 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 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 latent, I'm 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 was in the business of contract for hire. And he's looking for a pointer to somebody, but he doesn't know how to categorize that person.

I'm looking for a good developer because I have a software problem. 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 React dev, basically you're disqualified from that. You know, I could 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?

And so there's your specialization. So what you have found, and what I think is generally applicable, is when you're putting your sign up, you kind of have to have some sort of specialized skill set because people are going to be looking for that skill set. 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.

But 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 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, 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 insofar 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 skill set to your tricks. For instance, accidentally I'm doing a lot in the software packaging space, especially around the Python ecosystem because they're starting to realize they can have huge wins in performance

using Rust. And it mixes very well with Python. 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 investing in that. And so that becomes, I mean, these people have their own conferences like the packaging conference i didn't know about it and there's some specialization there right yeah yeah and also for instance uh you get in touch with the content with like the container community uh people who i mean cube con in paris just, I think. It was last week. And it's also like, it's a very, it's 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 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. In my early young days, I used to say my greatest strength was fear of irrelevance. And so I was always up to date on what's going on because 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 there's a lot of people that just learn a thing. Like maybe they learn 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 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 addressed marketing 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. When you become very expert 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,

you're AI engineer kind of person, like skills are on, 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 u.s market and that there's obviously a difference there which is unrelated to whatever you're doing the u.s pays better i mean i'm not sure if it's in general but my contracts for for US companies have always been for companies in Silicon Valley, which I guess have 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 Europe in general, the contracts I've done as a generalist and as a specialist, I've seen big differences. But I mean, it's still difficult to know because of the size of the company matters a lot too. 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 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. I 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 was that what is

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 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 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? Because I know DDoS, CDN, pretty common things that has been the building blocks of the behemoth that Cloudflare is today, but it's gone beyond that. Can you expand on the breadth and depth of Cloudflare is today, but it's gone beyond that. Can you expand on like the breadth and depth of Cloudflare today 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 although a lot of what 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 firewall, like CDN, those are still developer products. You still need those as a developer to go in front of your website, protect what you're actually building. We're diehard R2 users. We had 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. We've had an affinity and a love for Cloudflare from afar in really a lot of cases

until we're like, you know what? R2 is pretty cool. We should use R2. 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 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, 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,

then 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 to 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. And 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's 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 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 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 the first date is what I used to call it. Let's get to know each other and see if this is going to make sense. But a lot of people are out there 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 their application will get filtered out by some entry level HR person before they 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 yeah and so that's got to 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 as well, because 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 there's it's very clear like okay who are you helping here 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. Yeah, 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'm 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, I don't know where this is going to end, but I think that like as time passes, problem solving is not enough. It's mere problem solving. Everyone solves problems in their work. Well, some people cause problems but yeah everybody wants to solve problems yeah i agree with 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.

You want to help people, right? 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? Because saying no is a privilege that not everybody has. 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 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 things turned out in such a way that I was never desperate enough to work with people who don't value my work as I value it. So that's for me 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 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 there 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 100 euros, $100 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 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 yeah 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 um 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 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 uh more like a roller coaster but about that time it came like the rust the breakthrough where there was uh 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 him 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's encrypt. 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 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 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 are smart the same goes when implemented 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 actors 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 time 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 this undercurrent of respect

there, even though you're not going to have necessarily starring Adolfo Oshkavilla on the playhead there. I did notice you have an awesome testimonial. You mentioned the Let's Encrypt from Josh O's on your website for instance like that is probably worth its weight in gold for people who know who josh owes is like to people who are in your little niche yeah like that's i i know 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 yeah 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. 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 these people from the Rust ecosystem and elsewhere are saying that it's worth working with him. So, yeah, I haven't yet kind of experienced that this really makes a 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. Because 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 it certainly can't hurt. We have a similar situation with podcast recommendations because we get a lot of nice emails and I love them

and we have dialogues in private with listeners who say 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 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, eh. 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, because, hey, I found you because of your writing.

Yeah. And now we're friends. And now I know, you know, if I come up with somebody 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 well, 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. So I made the switch. But the interest 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 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 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. 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 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. 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 to realize, 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 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, I don't't write a blog post i burr the blog post yeah 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 um it does feel like that like for me it's just like not drudgery but just painful work and then. And then I always, just like a child, you go through all of that, and it's the worst pain in human life 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 at 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 who they're emailing you telling you that you inspired them or you intrigue them

i mean it pays dividends but it is it is work it's hard work like recently i i even end 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 are 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 journalist that it triggered so many good things in so many people. right so 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 starting to see, to think more and more that the contribution, even though it's not like life-changing 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 it's just a lot of effort. But yeah, I think that there's a bit of a lack of authenticity on the internet. So even if you write about very 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 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 open LinkedIn or many, many places where you normally get articles from, people are pretending they're the 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, 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. That's 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.

Any newsletter has probably between 12 and 20 links. And I think that any working software developer who's curious in this space will find one of those sincerely good and touching to them. But those are hard to find. People like yourself are hard to find. Not everybody has time to do that work, and so we try to do that work a little bit

just with that little spotlight of ours that we can shine on people. 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. Like, you do 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 uh we can get other people reading it as well one of the people who inspire me a lot in this regard is julia evans yeah like her writing there's something special about it because yeah well so much voice yeah i mean i it's not the way i write i mean i like to polish my stuff much no it's her voice 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. And I'm actually trying to write from the same source with a different voice, but I think it's the same source. 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. 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. Come on 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 time stamp it and the general premise there was you think you need a boolean you probably just want a time stamp you're going to wish it was a time stamp at some point trust me i've done it a hundred times i've been like

i'm going to switch this to a time stamp you might as well just time stamp 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 room in it like it's not you have to it's you might as well yeah and so every once in a while you'll hit on something but even that has its yeah buts still has some wiggle room in it. 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 bots. Nullable timestamp, right? Yes.

Where null 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 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.

Consider. Yeah, consider. It's so 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 Sanadia. Sanadia is helping teams take NAS to the next level via a global multi-cloud, multi-geo, and extensible service fully managed by Sanadia. 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 use an HTTP library. And then 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 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

NATS 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 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 Sanity Cloud, it's already a managed instance. 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, forget networking, all that kind of packet-based stuff, you were calling them HTTP developers, which kind of stalk instead of API devs. I mean, what do people do? They either 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 connect to an endpoint, you get told about other endpoints. It's like connecting to a hive 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 you know rat's nest of where to connect to them then you've got to negotiate well what do we do then now we've got to get the schema information and can we even connect to this thing and does it even work and? And what version is it? And all this stuff. And what we're trying to do is transform that and flip that to Unify 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 Barham 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 it's request, reply, or pubs up, but it's on the same platform. We don't care about what Zoom server we connect to. We connect to the service and we coordinate our communications over the fabric. There you go. Yesterday's tech is not cutting it. NAT's powered by the global multi-cloud, multi-geo, and extensible service, fully managed by Synedia, is the way of the future. Learn more at synedia.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. It's your exclusive of the others. And Rust is working out very well for you. But you can also back the wrong horse, 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 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. Cappuccino was their app kit.

They were basically copying Apple's app kit framework into JavaScript. You could write it in Objective-C-ish. 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, okay, 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 I built 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 yeah and i haven't met anyone who really got stuck in their career but 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 wrote to me because of my article saying, I'm a journalist 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 at 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. And I think also one of the things,

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 US 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? Well, 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 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 seeing a coworker write no testing code, it would be like instant red flag, like, wait a second, how do you know this works at all?

And I mean, without getting into dogmatic test-driven development kind of stuff, but like full test coverage or whatever. But basically, kind of developing uh i don't know some kind of second nature or taste for how a project a software project should be managed that was uh 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. 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. 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 a,

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 piquing your interest right now like if you were so outside of the rust bubble i'm very interested in the way dot net and c sharp is developing okay like they are investing a lot in making it a proper like a language where you can you write like high performance coding in fact related to the recent redis license oh yeah 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 re-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.NET 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, 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 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 dependency solver. 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. So I was, in fact, paid to learn this. However, sometimes I get paid to learn things that I know will be reusable. 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. Yeah, 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 it. Is it interesting to me or is it worth taking? 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. And now I'm able to learn it while being paid versus learning it while not being paid. And then the other one was reputation or portfolio. I mean, that's real. You have to build your reputation. You have to have examples of things that you've built.

And so 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. Is it something that I have a moral problem with I remember 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 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, no, not going to do that. But for the most part, those three things.

And if I can 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. me it's 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 but it's worth asking up front 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. At least that was my experience. Because 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. 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? Just 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 um of the one on the undercover generalist oh really i should have read that

it was 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 like 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, this is a long journey. But right now, like the mental model I have career-wise is i want to try to become like just a very good craftsman and that people know to find me when they need a craftsman because i if they don't need a craftsman well i i guess there's plenty of other people out there who can help you too.

Like if you need to build something simple. Sure. Yeah. Well, the robots will build those for people soon enough. So the craftsmen will be the only ones left. Well, I hope at least that remains. Otherwise, I'll become a mere interface 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.

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 Rails rescue, there like teams that all they did was-

The AI rescue team. Yeah, exactly. And there was similar things for like, you go to the wrong outsourcing 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, you're going to put the name on it, right? Like this is when you

stake your claim. AIrescue.com. AIrescue. Somebody can have that. 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. 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 is on LinkedIn pretty much 201. So that's, that's a weird, but 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 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 would you frame it, Adolfo? 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. It was about a month ago now. But we're going to put that in after this for our Changelog++ members

because it really is a bonus. And so if you want some more to learn more about Adolfo and hear from me some more as well, stick around. If you're on Changelog++, if you're not, well, what's wrong with you? It's better. Sign up for Changelog++, 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 two gabbing.

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

Go listen to Change Login 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 Beatfreakin' residents, Breakmaster Cylinder, and to our friends at Sentry. Use code CHANGELOG when you sign up and you will save 100 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 $100 off. Next week on The Change Log, news on Monday,

Zeno Rocha from Dracula and Resend on Wednesday, and Gearheart 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 I think it would take the full half an hour to explain. But it was one of the best decisions in my life it's better