Screaming in the Cloud - Learning in Public with swyx

Episode Date: June 9, 2022

About swyxswyx has worked on React and serverless JavaScript at Two Sigma, Netlify and AWS, and now serves as Head of Developer Experience at Airbyte. He has started and run communities for hundreds of thousands of developers, like Svelte Society, /r/reactjs, and the React TypeScript Cheatsheet. His nontechnical writing was recently published in the Coding Career Handbook for Junior to Senior developers.Links Referenced:“Learning Gears” blog post: https://www.swyx.io/learning-gearsThe Coding Career Handbook: https://learninpublic.orgPersonal Website: https://swyx.ioTwitter: https://twitter.com/swyx

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with Postgresquil for 15 years.

And now, EnterpriseDB has you covered wherever you deploy Postgresquil. On-premises, private cloud, and they just announced a fully managed service on AWS and Azure called Big Animal. All one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money. They can even help you migrate legacy applications, including Oracle, to the cloud.

To learn more, try Big Animal for free. Go to biganimal.com slash snark and tell them Corey sent you. Let's face it, on-call firefighting at 2 a.m. is stressful. So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that Incident.io makes incidents less stressful and a lot more valuable. Incident.io is a Slack-native incident management platform. It allows you to automate incident processes, focus on fixing the issues,

and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io to recover faster and sleep more. Welcome to Screaming in the Cloud. I'm Corey Quinn. Some folks are really easy to introduce when I have them on the show because my name is insert name here. I built thing X and my job as Y at company Z. Then we have people like today's guest. Swix is currently and recently the head of developer experience at Airbyte, but he's also been so much more than that in so many different capacities that you're very difficult to describe. First off, thank you for joining me. And secondly, what's the deal with you? I'm a professional ADD just like you. Thanks for

having me, Corey. I'm a big fan, long-time listener, first-time caller. Love saying that. You have done a lot of stuff. You have a business and finance background, which, okay, guilty. It's probably why I feel some sense of affinity for a lot of your work. And then you went into some interesting directions. You were working on React and serverless JavaScript, which is of course how I insist on pronouncing it, at Two Sigma, Netlify, AWS, a subject near and dear to my heart, and most recently, Temporal.io. And now you're at Airbyte. So you've been focusing on a lot of, I won't say the same things, but your area of emphasis

has definitely consistently rhymed with itself. What is it that drives you? So I have been recently asking myself a lot of this question because I had to interview to get my new role. And when you have multiple offers, because the job market's very hot for DevRel managers, you have to really think about it. And so what I like to say is, number one, working with great people. Number two, working on great products.

Number three, making a lot of money. There's an entire school of thought that, oh, that's ghost. You shouldn't mention trying to make money. Like, why do you want to work here? Because I want to make money. It's always true. And for some reason, we're supposed to pretend otherwise. I have a lot of respect for people who I can cut to the chase on that. It's always been something that has driven me nuts about the advice that we give new folks to the industry and even students figuring out their career path of, oh, do something you love and the money will follow. Well, that's not necessarily true. There are ways to pivot

something you love into something lucrative, and there are ways to wind up more or less borderline starving to death. And again, I'm not saying money is everything, but for a number of us, it's hard to get to where we want to be without it. Yeah. Yeah. I think I've been cast with the kind of judgmental label of being very financially motivated. That's what people have called me for simply talking about it. And I'm like, no, you know, it's number three on my priority list. Like I will leave positions where I have a lot of money on the table because I don't enjoy the people or the product, but having it up there and talking openly about it somehow makes you, makes you sort of greedy or something. And I don't think that's right. And I try to set an example for the people

that I talk to who people who follow me. One of the things I've always appreciated about, I guess, your online presence, which has remained remarkably consistent as you've been working through a bunch of different, I guess, stages of life and your career, is you have always talked in significant depth about an area of tech that I am relatively, well, relatively crap at, let's be perfectly honest. And that is the wide world of most things front end. Every time I see a take about someone saying, oh, front end is junior or front end is somehow less than, I'd like to know what the hell it is they know. Because every time I try and work with it, I wind up more confused than I was when I started. And what I really appreciate is that you have always normalized the fact that this stuff is hard.

As of the time that we're recording this, a day or so ago, you had a fantastic tweet thread about a friend of yours spun up a Create React app and imported the library to fetch from an endpoint and immediately got stuck. And then you pasted this ridiculous error message. He's a senior staff engineer, ex-Google, ex-Twitter. He can solve complex distributed systems problems and unable to fetch from a REST endpoint without JavaScript specialist help. And I talk about this a lot in other contexts, where the reason I care so much about developer experience is that a bad developer experience does not lead people to the conclusion of, oh, this is a bad interface. It leads people to the conclusion of, oh, this is a bad interface. It leads people to the conclusion that, oh, I'm bad at this and I didn't realize it. No,

I still fall into that trap myself. I was under the impression that there was just this magic stuff that JS people know. And your tweet did so much to help normalize, from my perspective, the fact that, no, no, this is very challenging. I recently went on a Go exploration. Now I'm starting to get into JavaScript slash TypeScript, which I think are the same thing, but I'm not entirely certain on that. And like, oh, well, one of them is statically typed or strongly typed. It's like, well, I have a loud mechanical keyboard. Everything I do is typing strongly. So what's your point? And even then we're talking past each other in these things. I don't understand a lot of the ecosystem that you live your career in, but I have always

had a tremendous and abiding respect for your ability to make it accessible, understandable, and I guess for lack of a better term, to send the elevator back down. Oh, I definitely think about that strongly, especially that last bit. I think it's a form of personal growth. So I think a lot of people, when they talk about this, sending the elevator back down, they do it's a form of personal growth. So I think a lot of people, when they talk about this, sending the elevator back down, they do it as a form of charity, like I'm giving back to the community. But honestly, you actually learn a lot by trying to explain it to others, because that's the only way that you truly know if you've learned something. And if you ever get

anything wrong, people will never let you forget it because this is the internet and people will crawl over broken glass to remind you that you're wrong. And once you've got it wrong, you've been so embarrassed that you'll never forget it. So I think it's just a really good way to learn in public. And that's kind of the model that I'm kind of known for. Yeah, take the direction anywhere you want to go in JavaScript land. Happy to talk about it all day. Well, I want to start by something you just said, where you're doing the learning in public thing. And something I've noticed is that there are really two positions you can take in the general sense when you set out to make a bit of a reputation for yourself as something of an expert. And there are drawbacks and advantages to both. I think that if you don't look as wildly overrepresented as I do, both of them are more fraught in different ways, where it's, oh, you're learning in public. Ah,

look at the new person. She's dumb. Or if you're presenting yourself as an expert, you get nibbled to death by ducks on a lot of the deep technical nuances and well, actually to death. And my position has always been to, this is gonna be a radical concept for some folks, is I'm generally honest. I tend to learn in public about the things that I don't know, but the things that I am

something of a subject matter expert in, like, I don't know, cloud billing, I don't think that false modesty necessarily serves me particularly well. It's, yeah, I know exactly what I'm talking about here. Pretending otherwise is just being disingenuous. I try to think of it as having different gears of learning in public. So I've called this learning gears in a previous blog post of mine, where you try to fit your mode of learning to the terrain that you're on, your domain expertise, and you should never over-represent

the amount that you know. Because I think people are very rightly upset when there are a lot of people, let's say on Twitter or YouTube or Udemy even, who present themselves as experts who are actually, they just read the docs the previous night. So you should,

you should try not to over-represent your expertise, but at the same time, don't let your imposter syndrome stop you from sharing what you are currently learning and taking corrections when you're wrong. And I think that's the tricky balance to get, which is constantly trying to put yourself out there while accepting that you might be wrong and not getting offended or personally attacked when someone corrects you inevitably.

And sometimes people will, especially if you have a lot of followers, people will try to say, you know, someone of your following, you know, I kind of call this follower shaming. Like you should act invulnerable or run every tweet through a committee before you tweet after a certain

following size. So I try to not do that and try to balance responsibility with authenticity. I think that there's something incredibly important about that, where there's this idea that you either become invulnerable and get defensive and you yell at people and down that path lies disaster because people, believe it or not, we all get it wrong from time to time and doubling down and doubling down and doubling down again. Suddenly you're on an island all by yourself and no one respectable is going to be able to get there to help you. And the other side of it is going too far in the other direction where you implicitly take any form of criticism whatsoever as being de facto correct. And I think that both paths don't lead to super great places.

I think it's a matter of finding our own voices and doing a little bit of work as far as the validity of accepting a given piece of feedback it goes. But other than that, I'm a big fan of being able to just more or less be as authentic as possible. And I get that I live in a very privileged position where I have paths open to me that are not open to most folks. But in many respects, so do you. You are one of the easily first five people I would think of. Someone said, hey, if I had to learn JavaScript from someone, who should I talk to first? You're on that list.

And you've done a lot of things in this area, but you've never, but you alluded to it a few minutes ago, but I'm going to call it out a little more pointedly without naming names, let's be clear. And that you're not, you've never presented as a grifter, which is sort of the best way I can present, I can think of it of, well, I just learned this new technology stack yesterday. And now I'm writing a book that I'm going to sell to people on how to be an expert at this thing. And I want to be clear, this is very distinct from gatekeeping, because I think that, oh, well, you have to be at least this much of an expert.

No, but I think that holding yourself out as, I'm going to write a book on how to become a software engineer. Okay, you were a software engineer for six months, and more to the point, knowing how to do a thing and trap because I don't want to pretend to be an expert in things that I'm not. I barely think I'm an expert in things that I provably am. There are many ways to answer that. So I have been accused a couple of times of that, and it's never fun. But also if you defend yourself well, you can actually turn a critic into a fan, which I love doing. Oh, yes. What I fall back to, so I have a side interest in philosophy

based on one of my high school teachers giving us like a lecture in philosophy. I love him. He changed my life. Lionel Barnard. In case, in the off chance that he's listening. So there's a theory of knowledge of like, how do you know what you know, right? And if you can base your knowledge on facts and not opinions, then people are arguing

with the facts and not the opinions. And so getting as close to ground truth as possible and having certainty in your collection of facts, I think is the basis of not arguing based on identity of like, okay, I have 10 years experience. You have two years experience. I am more correct than you in every single opinion. That's also not like the best way to engage in the battlefield of ideas. It's more about, do you have the right amount of evidence to support the conclusions that you're trying to make? And oftentimes I think that is the basis. If you don't have that ability, another thing that I've also done is to collect

the opinions of others who have more, more expertise and present them and curate them in a, in a way that, uh, I think adds value without taking away from the individual original sources. So I think there's a very academic way you can kind of approach this, but that defends your intellectual integrity while helping you learn faster than the typical learning rate, which is kind of something I do think about a lot, which is, you know, why do we judge people by the number of years experience? It's because that's usually the only metric that we have available that is quantifiable. Everything else is kind of fuzzy. But I definitely think that, you know that better algorithms for learning let you progress much faster than the median rate.

And I think people who apply themselves can really get up there in terms of the speed of learning with that. So I spend a lot of time thinking about this stuff. It's a hard thing to solve for. There's no way around it. It's what is it that people should be focusing on? How should they be internalizing these things? I think a lot of it starts, too, with an awareness, even if not in public, just to yourself of, I would like advice on some random topic. Do you really?

Are you actually looking for advice or are you looking for validation? Because those are not the same thing and you are likely to respond very differently when you receive advice, depending on which side of that you're coming from. Yeah. And so one way to do that is to lay out both sides to actually demonstrate what you're split on and ask for feedback on specific tiebreakers that would help your decision swing one way or another.

Yeah, I mean, there are definitely people who ask questions that are just engagement bait or just looking for validation. And while you can't really fix that, I think it's futile to try to change others' behavior online. You just have to be the best version of yourself you can be. DoorDash had a problem.

As their cloud-native environment scaled and developers delivered new features, their monitoring system kept breaking down. In an organization where data is used to make better decisions about technology and about the business, losing observability means the entire company loses their competitive edge. With Chronosphere, DoorDash is no longer losing visibility into their application suite. The key? Chronosphere is an open-source compatible, scalable, and reliable observability solution that gives the observability lead at DoorDash business confidence and peace of mind.

Read the full success story at snark.cloud slash chronosphere. That's snark.cloud slash c-h-r-o-n-O-S-P-H-E-R-E. So you wrote a book that is available at learninpublic.org called The Coding Career Handbook. And to be clear, I have not read this myself because at this point, if I start reading a book like that and, you know, the employees that I have see me reading a book like that, they're going to have some serious questions about where this company's going to be going soon. But scrolling through the site, the social proof, the testimonials from various people who've read it, more or less read like a who's who of people that I respect who have been on this show themselves. Emma Bostian is fantastic at explaining a lot of these things for us. Brazil is consistently a source to me of professional envy. I wish I had half his musical

talent, my God. And you're going down, it explains more or less the things that a lot of folks, people are all expected to know, but no one teaches them about every career stage, ranging from newcomer to the industry to senior. And there's a lot that, there's a lot of gatekeeping around this, and I don't even know that it's intentional, but it has to do with the idea that people assume that folks, quote unquote, just know the answer to some things.

Oh, people should just know how to handle a technical interview, despite the fact that the skillset is completely orthogonal to the day-to-day work you'll be doing. People should just know how to handle a technical interview, despite the fact that the skill set is completely orthogonal to the day-to-day work you'll be doing. People should just know how to handle a performance review, or should just know how to negotiate for a raise, or should just know how to figure out, is this technology that I'm working on no longer the direction the industry is going in? And eventually, I'm going to wind up more or less waiting for the phone to ring because there's only three companies in the world left to use it. Like, how do you, how do you

keep, how do you pay attention to what's going on around you? And it's the, it's the missing manual that I really wish that people would have pointed out to me back when I was getting started. Would have made life a lot easier. Oh, wow. That's, that's high praise. I actually didn't know we were going to be talking about the book that much. This is the problem with doing too much. You never know what people have found out about you and what they're going to say when they drag you onto a podcast. Gotcha. Gotcha. Okay. I know where this is going. Okay. So one thing that I really definitely believe is that, and this happened to me in my first job as well, which is most people get the mentors that they're assigned at work. And sometimes you have a bad roll of the dice.

And you're supposed to pick up all the stuff that they don't teach you in school at work or among your friend group. And sometimes you just don't have the right network at work or among your friend group to tell you the right things to help you progress your career. And I think a lot of this advice is written down in maybe some hacker news posts, some Reddit posts, some Twitter posts. And there's not really a place you can send people to point to that consolidates that advice, particularly focused at the junior to senior stage, which is the stage that I went through

before writing the book. And so I think that basically what I was going for is targeting the biggest gap that I saw, which is there are a lot of interview prep type books like Crack the Coding Career, which is kind of a crack coding interview, which is kind of the book title that I was going after. But once you got the job, no one really tells you what to do after you got that first job. And how do you level up to the senior that everyone wants to hire, right? Well, I've mastered cracking the coding interview. Now I'm really trying to grab my head around the problem of cracking the showing up at work on time in the morning, like the baseline stuff. And I had so many challenges with that early in my career. Not specifically punctuality, but just the baseline expectation that it's just assumed that by the time you're in the workplace earning a certain amount of money, it's just assumed that you have, because in any other field you would, you have several years of experience in the

workplace and know how these things should play out. No, the reason that I'm sometimes considered useful as far as giving great advice on career advancement and the rest is not because I'm some wizard from the future. It's because I screwed it all up myself and got censured and fired and rejected for all of it. And it's, yeah, I'm not smart enough to learn from other people's mistakes. I've got to make them myself. So there's something to be said for turning your own missteps into guidance so that the next person coming up has an easier time than you did. And that is a theme that, from what I have seen, runs through basically everything that you do. I try to do a lot of research, for sure.

And so one way to, you know, hopefully I try not to make mistakes that others have learned, have made. So I try to pick from, I think I include 1,500 quotes and sources and blog posts and tweets to build up that level of expertise all in one place. So hopefully it gives people something to bootstrap their experience off of. So you're obviously going

to make some mistakes on your own, but at least you have the ability to learn from others. And I think this is my, you know, I'm very proud of the work that I did. And I think people have really appreciated it because it's a very long book and nobody reads books these days. So what am I doing writing a book? I think it's only the people that really appreciated it because it's a very long book and nobody reads books these days. So what am I doing writing a book? I think it's only the people that really need this kind of advice that find themselves not having the right mentorship that reach out to me. And, you know, it's good we have weekly sessions going through every chapter. And I give feedback on what people are doing. Sometimes I've helped people negotiate their jobs and get that bump up to senior engineer. And I think more than doubled their salary,

which was a very personal proud moment for me. But yeah, I think more than doubled their salary, which was a very personal proud moment for me. But yeah, I think basically, it's kind of like a third place between the family and work that you could go to to talk about career stuff. And I feel like maybe people are not that open on Twitter, but maybe they can be open in a small community like ours. There's a lot to be said for a sense of professional safety and personal safety around having those communities. I mean, mine, when I was coming up, was the Freenode IRC network.

And that was great. It's pseudo-anonymous, but again, I was Corey and network staff at the time, which was odd. But it was great to be able to reach out and figure out, am I thinking about this the wrong way?

Just getting guidance. And sure, there are some channels that basically thrived on insulting people. I admittedly was really into that back in the early 2000 nothings. And it was always fun to go to the Debian channel. It's like, yeah, can you explain to me how to do this? Or should I just go screw myself in advance? Yeah, it's always the second one. Community is a hard thing to get right. And it took me a while to realize this isn't the energy I want in the world. I like being able to help people come up and learn different things. I'm curious, given your focus on learning in public and effectively teaching folks, as well as becoming a better engineer yourself along the way, you've been focusing for a while now on management. Tell me more about that.

I wouldn't say it's been actually a while. Started dabbling in it with a temporal job and then now fully in it with Airbyte. You have to realize we're in pandemic time. It has stood still. Anything is a while, given these are the interminable. This is the decade of Zoom meetings. I'll say I have about a year and a half of it. And I'm interested in it partially because I've really been enjoying the mentoring side with the coding career community. And also, I think some of the more effective parts of what I do have to be achieved in the planning stages with getting the right resources rather than doing the individual contributor work. And so I'm interested in that. I'm very wary of the fact that I don't love meetings myself.

Meetings are a means to an end for me and meetings are most of the job in management time. So I think for what's important to me there, it is that we get stuff done and we do whatever it takes to own the outcomes that we want to achieve and try to manage people's, try to not screw up people's careers along the way. Better put, I want people to be proud of what they get done with me by the time they're done with me. So you've talked to me about this very briefly, but I don't know that as of the time of this recording, you've made any significant public statements about it. You are now over at Airbyte, which I confess is a company I have not heard of before.

What do you all do over there? What is it we do here? So Airbyte is... Consultants want to know. Airbyte is a data integration company, which means different things based on your background. So a lot of the data engineering patterns

in the modern data stack is extracting from multiple sources and loading everything into a data warehouse like a Snowflake or Redshift. And then performing analysis with tools like DBT or business intelligence tools out there. We like to use Metabase. There's a whole bunch of these stacks and they're all sort of advancing at different rates of progress. And what Airbyte would really like to own is the data integration part, the part where you load a bunch of sources, every data source in the world. What really drew me to this was two things.

One, I really liked the mission of data freedom, which is when you run a company, like a typical company, I think at Temporo we had like a hundred different small little SaaS vendors, all designed to be the sources of truth for their thing or a system of record for their thing. Like Salesforce wants to be a source of truth for customers and Google Analytics wants to be a source of truth for website traffic and so on and so forth. And it's really hard to do analysis across all of them unless you dump all of them in one place.

So the mission of data freedom really resonates with me. Like your data should be put somewhere where you can actually make something out of it. And step one is getting it into a format and in a place that is amenable for analysis. And the data warehouse pattern has really taken hold of the data engineering discipline. And I think that's a multi-decade trend that I can really get behind.

That's the first thing. I will say that historically, I'm bad at data. All jokes about using DNS as a database aside. One of the reasons behind that is when you work on stateless things like web servers, and you blow chunks in one of them. Oops! We all laugh. We take an outage, so maybe we're not laughing that hard. But we can reprovision the web servers and things blow chunks in one of them. Oops. We all laugh. We take an outage. So maybe

we're not laughing that hard, but we can reprovision the web servers and things are mostly fine. With data and that going away, there are serious problems that could theoretically pose existential risk to the business. Now, I was a sysadmin and a at least mediocre one, which means that after the first time I lost data, I was diligent about doing backups. Even now, the data work that we do of deep analysis on our customers' AWS bills, which doesn't sound like a big data problem, but I assure you it is, has become something where, okay, step one, we don't operate on it in place. We copy it into our own security environment, and then we begin the manipulations. We also have backups installed on these things so that in the event that I accidentally leave the data, it doesn't

wind up causing horrifying problems for our customers. And lastly, I wind up also, this is going to surprise people, I wind up securing the access to that data by not permitting writes. Turns out it's really hard, though apparently not impossible, to delete data with read-only calls. It tends to be something of just building guardrails against myself. But the data structures, the understanding, the analysis of certain things, I would have gotten into Go way sooner than I did if the introduction to Go tutorial and how to use it wasn't just a bunch of math problems talking about, this is how you do it, great. But here in the gear of our Lord 2022, I mostly want a programming language to smack a couple

of JSON objects together and ideally come out with something resembling an answer. I'm not doing a whole lot of calculating prime numbers in the course of my week. And that is something that took a while for me to realize that, no, no, it's just another example of not being a great way of explaining something that otherwise could be incredibly accessible to folks who have real problems like this. I think the entire field right now of machine learning and the big data side of the universe struggles with this. It's, oh yeah, if you have all your data, that's going to absolutely change the world for you. Cool, can you explain how?

No, not effectively anyway. It's like, well, thanks for wasting everyone's time. It's appreciated. Yeah, every startup's sitting on a mountain of data that they don't use. And I think everyone kind of feels guilty about it because everyone who is like a speaker, they're always talking about like,

oh, we used our data to run and form this presidential campaign and look at how amazing we are. And then you listen to the, the podcasts where the data scientists, you know, talk amongst themselves and they're like, yeah, it's bullshit. Like we're making us to go along just like everyone else. But, you know, I definitely think that some of the better engineering practices are rising on this. And I, it's professionalizing just like-end professionalized maybe 10 years ago, DevOps professionalized also roughly in that timeframe. I think data is emerging as a field that is just a standalone discipline with its own

tooling and potentially a lot of money running through it, especially if you look at the Snowflake ecosystem. So that's why I'm interested in it. I will say there is also, I talked to you about these sort of API replication use case, but also there's database replication, which is kind of like the big use case, which, for example,

if you have a transactional sort of SQL database and you want to replicate that to an analytical database for queries, that's a very, very common one. So I think basically data mobility from place to place, reshaping it and transferring it in as flexible a manner as possible, I think is the mission. And I think there's a lot of tooling that starts from there and builds up with it. So it integrates, everybody integrates pretty well with Airflow, Daxter, and all the other orchestration tools. And then you can use dbt and everything else in that data stack to run with it. So I just really

like that composition of tools because basically when I was a hedge fund analyst, we were doing the ETL job without knowing the name for it or having any tooling for it. I just ran a Python script manually on a cron job. And whenever it failed, I would have to get up in the middle of the night to go kick it again. It was that bad in 2014, 15. So I really feel the pain and the more data that we have to play around with, the more analysis we can do. I'm looking forward to seeing what becomes of this field as folks like you get further and further into it. And by, well, what do you mean folks like me? Well, I'm glad you asked, or were about to, as I put words in your mouth, I will tell you people who have a demonstrated ability, not just to understand the technology, which is hard, but then have this almost unicorn gift of being able to articulate and explain it to folks who do not have that level of technical

depth in a way that is both accessible and inviting. And that is no small thing. If you were to ask me to draw a big circle around all the stuff that you've done in your career and define it, that's how I would do it. You are a storyteller who is an act who is conversant with the relevant elements of the story in a first-person perspective, which is probably a really unwordy way to put it. We should get a storyteller to workshop that, but you see the point. I try to call it like accessibly smart. So it's a balance that you want to make where you don't want to talk down to your audience, because I think there are a lot of educators out there who very much stay at the basics and never leave that. You want to be slightly aspirational and slightly push people to the bounds of their knowledge,

but then not to go too far and be inaccessible. And that's my sort of polite way of saying that I dumb things down as a service. I like that approach. The term dumbing it down is never a phrase to use as it turns out when you're explaining it to someone. It's like, let me dumb that down for you. It's like, yeah, I always find the best way to teach someone is to first reach them and get their attention. I use humor, but instead we're going to insult them. That'll get their attention. All right. No. Yeah. But it does. It does affect some people who insist on precision and jargon. And I'm quite against that. But it's a constant fight because obviously there is a place and time for jargon. Can you explain it to me using completely different words? If the answer is no,

the question then is, do you actually understand it? Or are you just repeating it by rote? There's people learn in different ways and reaching them is important. Exactly, exactly. Yeah. I really want to thank you for being so generous with your time.

If people want to learn more about all the various things you're up to, where's the best place to find you? Sure. They can find me at my website, swix.io, or I'm mostly on Twitter at Swix. And we will include links to both of those in the show notes. Thank you so much for your time. I really appreciate it.

Thanks so much for having me, Corey. It's a blast. Swix, head of developer experience at Airbyte and oh, so much more. I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, or if it's on the YouTubes, thumbs up and subscribe. Whereas if you've hated this podcast, same thing, five-star review wherever you want, hit the buttons on the YouTubes, but also leave an insulting comment that is hawking your book.

Why this episode was terrible that you're now selling as a legitimate subject matter expert in this space. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production stay humble