The two ways I would talk about are one I'll call "just in
case," and the other one I'll call "just in time," and most
of the learning and teaching is "just in case" learning.
"I'll tell this information to you just in case you ever need
it in the future," and I think that is a pretty unsatisfying
way to learn because you don't get, like, the immediate rush
or satisfaction of, like, having learned something useful.
I think learning is, like, one of the great joys in life.
And I think the times I learned best are
when I've really struggled against something.
You know, I've really banged my head against something.
I'm like, "Oh, I wish I understood how this works," and at that point, if
someone teaches me how it works, that's what I call "just in time" teaching.
You give me the information right when I need it.
That's when I'm primed to learn the material.
Welcome to Screaming in the Cloud.
I'm Corey Quinn.
My guest today is Adiyta Bhargava, staff software engineer at
Etsy and creator of a, I guess the best way to frame this is
a series of articles featuring wonderful illustrations that
explain one of the saddest things in the world, AWS networking.
Adiyta, thank you for joining me.
Thank you.
I'm excited to be here.
This episode is sponsored in part by my day job, the Duckbill Group.
Do you have a horrifying AWS bill?
That can mean a lot of things.
Predicting what it's going to be.
Determining what it should be.
Negotiating your next long-term contract with AWS.
Or just figuring out why it increasingly resembles a
phone number, but nobody seems to quite know why that is.
To learn more, visit duckbillgroup.com.
Remember, you can't duck the Duckbill bill.
And my CEO informs me that is absolutely not our slogan.
So, you have done a number of different things, and the first
thing that attracted me to what you have written, and I've
included my newsletter a couple of times now, has been not just
the subject matter of, "Ooh, AWS networking." Yeah, stop me.
You've heard this one before.
"Stop." Instead, the way they're illustrated.
There are ducks with personalities popping up in these things.
There are, it's a very human approach to it.
Even the writing is extraordinarily familiar in style.
It's not written like most things in this space.
Where did you come from that this is how you communicate?
Because I love it.
I want to see
more of it.
Sure.
I mean, I have been writing this way for years.
I used to do blog posts about functional programming years ago,
and I did one about monads, which everyone finds like a really
scary topic to talk about, but I did it in the same style.
And it really took off, and it's how I like to learn, and it made me
think, "Oh, this is something other people resonate also." So, I've done
the blog, I wrote a book about algorithms that also became quite popular,
and I have a whole bunch of other ideas, but one of the things is, I
wish there was a better resource for AWS networking, and there isn't.
So that's what I'm trying to make here.
You've noticed, I don't know what it is about the insanity of AWS
networking, but for those who are unaware with my nonsense, I know
we're recording this on YouTube nowadays, because that's where the
kids like to consume content and all, but everything I have done
has been involved in the written, or occasionally spoken, word.
I am not a visual arts person.
It is not what I'm good at, and yet, one of the exception pieces
of this is a ridiculous diagram of data transfer costs in AWS Land.
I think that there is something about the way that this networking
stuff interplays, that it becomes impossible to talk about
descriptively instead of speaking wildly with one's hands.
Like you, you need to, at some point, "Okay, we need to draw this
out," and suddenly my disused whiteboard gets a lot more use.
Yes, I totally agree.
I think, you know, I hear from people sometimes saying
they're not a visual learner, but I think everyone is because
it's such a joy to go into a post and think, "Oh my gosh, I'm going to have
to read all this text. I know what this is like, wall of text coming at me,"
and instead, it's like three lines of text, image, three lines of text, image.
It just makes it so much more fun, I think.
They say that a picture is worth a thousand
words, but I guess that's for people who can draw.
The problem that I find is that, okay, I need to wind up
throwing a bunch of really crappy pictures, I chicken scratch
stuff out, and then I send things off to designers or people
with, I guess, a sense of competence in what it is that they do.
I kind of write code the same way, where like the first
stab at these things is, I don't know what the corporate
polite term for a bloodbath is, but that's what it is.
And they look at this like, "Oh honey, step right over here
and never, ever, ever touch this again." And you do something
badly enough, competent people take it away from you.
It's kind of amazing.
You are one of those competent people.
It seems like there's no one to take it away from you.
So you're stuck doing it.
Yeah, I mean, and I love doing it.
I have a background in art, so, you know,
I really enjoy the drawing portion of it.
Yeah, I mean, it also helps my mind shift a bit, right?
And like, Think about the problem in a different way and
think about how I could explain that better to people.
Yeah, it's networking is one of those strange areas where I, when
I fix AWS bills, I focus primarily on data transfer as my first go
to, and people like to go with what they're comfortable with, and
that's not what's happening here because no one's comfortable with
understanding networking in an AWS context, but because I find that
that sort of unlocks the data flows of, what what is talking to what.
In what volumes?
Help me understand what's going on in this environment.
And I always found a network-first approach to be
incredibly illuminative when it comes to that sort of thing.
You have taken it in a different direction.
You're not, as best I can tell, trying to explain this in a
context of here's how to save money, or even here's how to
understand architecture, but you're approaching it from a first
principles explanatory basis of here's how this stuff works.
You have a gift for this.
It's you make it engaging, you make it fun to read, and I don't mean to cast
shade, but I think there's no way to say this without casting shade, you upstage
the AWS documentation folks around networking by several orders of magnitude.
It's this stuff is incredibly complicated, and that's not
made any better by the crap state of the existing explainers.
Thank you.
The way I teach, I kind of break it down into two philosophies
of teaching and learning, and I think most people do it the
wrong way, which is kind of a hot take for this podcast.
Oh, this is the place for hot takes.
Please dive in.
The two ways I would talk about are one I'll call "just in
case," and the other one I'll call "just in time," and most
of the learning and teaching is "just in case" learning.
"I'll tell this information to you just in case you ever need
it in the future," and I think that is a pretty unsatisfying
way to learn because you don't get, like, the immediate rush
or satisfaction of, like, having learned something useful.
I think learning is, like, one of the great joys in life, and I think
the times I learn best are when I've really struggled against something.
You know, I've really banged my head against something.
I'm like, "Oh, I wish I understood how this works," and at that point, if
someone teaches me how it works, that's what I call "just in time" teaching.
You give me the information right when I need it.
That's when I'm primed to learn the material.
You've just put your finger on something that I've been
dancing around the periphery of for most of my life.
For me, the best way to learn something
is I need a project that focuses on this.
By the time that this episode airs, it will have been out,
that's how I built mylastskeetinaws.com Bluesky threading client.
I had some AI stuff and some brute force and enthusiasm as far as programming
goes, and I didn't know TypeScript, but I kind of know how computers work.
I know a lot more about it now.
I now know how their horrifying OAuth implementation
works and how to do it statelessly in a lambda function.
These are things that no one wants to have done, and yet
somehow I did because I had a problem I needed to solve.
If you had instead given me all the documentation for these things,
which I have at my fingertips, it's called the internet, I wouldn't
have picked up a damn bit of it because I didn't have a need for it.
The idea of learning something when you need it is incredibly valuable.
It's similar almost to the idea of what I've been saying for years about S3.
Whereas S3 has infinite storage, and from a purist perspective, that's not true.
There is, it's a big number, but there's a limit to capacity of what they
can have, but no, they can increase that storage faster than you can fill it.
I know this because with a runaway script, I tried once.
Got it.
Yeah, I mean, I think that's a great example.
And in this series, what I'm trying to go for is, what is the minimum amount
of networking you need to know to put up and start an EC2 instance and have
it, you know, run a server and have someone be able to connect to your server?
And I think that's such a great motivator.
You know, that's a very clear problem statement, and so people
have messaged me and said, you know, "Oh, it's so great.
You talked about VPCs, you know, could you also
cover this information or your subnets article?
Could you cover this?" And my answer has always been like,
"Well, that's not necessary to get this EC2 instance running."
You know, I think that becomes "just in case" information then.
And what I'm looking for is "just in time" information.
I have also heard the same thing about my book, because if you look at my book,
which is an algorithms book, and you look at all the other algorithms books,
my book is about 300 pages, and all the other ones are like a thousand pages.
And people are always like, "Well, you haven't covered all the
sorting algorithms." And I'm always like, "Well, if you ever need
to write a sorting algorithm from scratch, you can read one of
the other algorithms books." What I'm telling you is all the stuff
you need to know to actually be good at your engineering job.
And guess what?
You can learn that information in 300 pages.
And that saves you time and like, it's just a
much more interesting, fun and useful experience.
Is this more to do with understanding the groundwork of the area?
Is it a learning how to learn type of situation?
I mean, in my consulting engagements, by far the most common answer I
give to clients has been, "I don't know," but because I'm a professional,
we finish the sentence with, "but I will find out momentarily."
And that's the way it has to work, because I'm paid to never be wrong.
The first time I bluff, and I'm wrong, and I'm spreading
misinformation in that context, everyone's going to look very
hard at what, what exactly are we bringing this guy in to do?
We thought he was good at this, and instead it seems he's a lying clown.
You have to be able to learn and absorb things quickly, and
understanding where to look for these things is often some of the
most important, I guess, technical skills I've ever picked up.
Because, spoiler, whatever technology we're working on today is not
going to resemble bit for bit what we're doing five years from now.
Things will be inherently different.
That has always been the case.
You have to keep going back to the well.
You have to keep relearning things in most areas.
I do not know if that holds true in algorithms.
I do not have a formal academic background in computers.
Like, well, I don't know, we're not getting
another Newton anytime soon, we don't think.
Okay, great.
There are exceptions to this.
There are fundamental natural science laws of these things.
But in practice, the day to day, at least for me, is a lot
more vocational and the things change incredibly rapidly.
Yeah, I mean, I think that's exactly right.
And one of my other hot takes, that people really
struggle with as you don't need to finish books.
Like people will start books and they'll say, you know, I'm a finisher.
I will finish this book.
I do this myself sometimes.
Like I want to learn more about machine learning.
I have this book.
Once I finish it, I will know more about it.
Yeah.
that's not actually a useful way to learn.
I am a reader.
I have that same flaw where it's, I feel the need to
finish it and I, what sort of got me out of that model
for better or worse has been the absolute, horrifyingly,
just pedantic nature of so many business books where this is a 300 page
business book that says something that fits comfortably within 15 pages.
The problem is, if you're trying to sell a business book and you show
up with a pamphlet, people don't think they can charge as much for that.
Which is a problem.
I wish that they would.
I would pay more for the thin book that covers the same information than
the thick one, because I don't need you to act like an old time persistence
hunter where you circle the topic to death until it dies of exhaustion.
Tell me what I need to know and get on with my life.
Because there's more important things that I have to pick up next.
Yeah, sometimes, yeah, I've seen a couple of reviews of my book where people say
like, "Oh my gosh, $40 for a 300 page book. That doesn't make sense." When the,
Do they think you're paying by the word?
Yeah.
I mean, people generally do buy books based on page count, but I totally agree.
I would pay more.
I just picked up this great book actually called.
I think it's called the 100 Page Book on Machine Learning, and
it was one of those, like, set your own price, and I was happy
to pay a good price for it, because to me, it was like, well,
if you can cover this in 100 pages, that's worth a lot to me.
I want to be very clear that everything I have just said about brevity being
soul of wit and all, this, I'm thinking of this in the context of nonfiction.
What up, my library science friends?
When it comes to fiction, I like the long, slow rise
and fall and multi-book series to keep me engaged.
I get a little sad when I buy something from my latest author and
it turns out, wow, that was distressingly inexpensive on the Kindle.
Oh no, it's only 80 pages.
It's a novella, not an actual novel.
I was hoping for something meatier.
That is not the same thing.
Doing things for pleasure versus doing them because you need to
learn them to pick up information is a radically different approach.
And I'm not sure that that's well understood by folks who do
not spend their lives growing up with books instead of friends.
I agree with that.
I'll even add to that.
I think books are different from like podcasts or videos on YouTube or something
where like, often I will watch these like watercolor videos on YouTube, and
I'm happy to just put on like a long video and just have it in the background
while I'm doing something else because it's so soothing to have that around.
And I don't, you know, I would rather have an hour
long video of that than like a five minute video.
That makes perfect sense.
I'm not a video person at all.
I read very quickly.
I find that the pace of videos, even when you speed them up, is relatively slow
and plodding, so I find it infuriating when the only way to pick up something
the way to do something particular, Photoshop, I'm looking at you, is a bunch
of YouTube videos, where then people are trying to bow to the YouTube algorithm.
Where they do the teaser at the front, and then they drag it
out to make sure it hits ten minutes, and it's, buddy, I wish
there were better ways to do it, but some of my favorite YouTube
videos are when I'm looking for a specific model of a sink.
How do I replace the drain plug in it?
And there's a video that's 10 years old and some guy
does it and the video is 53 seconds long, and it's okay.
He is not going to say around making all this in and
out and the rest unless the video is, that's the trick.
You don't end to end tape roll credits.
No, it's they get straight to the point and they go with it.
It's wonderful.
Yes.
I one of my favorite YouTube videos because I do watch a lot of videos.
Also.
I have this water heater at home because I live in Minnesota and
you need hot water all the time in the winter, but it's really
hard to figure out how all the buttons work, and I found this video
where this guy in 30 seconds tells you how all the buttons work.
And I just was like, you could have made this
a 10 minute video, but this is so much better.
Like I can just move on with my life.
This episode is sponsored by my own company, The Duckbill Group.
Having trouble with your AWS bill?
Perhaps it's time to renegotiate a contract with them.
Maybe you're just wondering how to predict
what's going on in the wide world of AWS.
Well, that's where The Duckbill Group comes in to help.
Remember, you can't duck the Duckbill bill, which I am reliably
informed by my business partner, is absolutely not our motto.
I want to change gears a bit, because
you've written a book that I find confusing.
You have two editions of it out, which
doesn't help the direction I'm taking this in.
The book is called Grokking Algorithms, and the problem I
have with this is that you've written a book that has the word
"algorithms" in the subject line, but as best I could tell when
you're at home, people don't tend to refer to you as professor.
What's the deal with that?
Yeah, that's a good question.
My role in the book, I always think of as like, I'm not the
subject matter expert, but I am great at teaching stuff.
So I have taught a lot of things in the past, one of them as algorithms.
It's grounded really well because we got
this awesome technical editor for the book.
Great guy.
Both of his parents are computer science professors at Yale.
He has a PhD in computer science.
I think his thesis was on trees, and he really went
through the book and, you know, nailed everything down.
But my job is just, how do I get away from all the stuff you don't
need, such as proving that a sorting algorithm works, which like no
one needs to do in their job and talk high level about the ideas.
And what I have found is some of them are so intuitive, just
to give you an example, the first algorithm I cover is binary
search, and you don't even need to know anything about computers.
I mean, I gave this example to my mom, and I said, you know,
"I'm thinking of a number between 1 and 100. Guess what it is."
And she said "50," and I said, "Well, it's higher than 50." So she said,
"75," and as humans, we naturally break the problem space down into two.
We cut it in half every time, just intuitively.
Yeah, almost a binary search on some level, mentally speaking.
Although there are elements to the actual binary search algorithm that
I found unintuitive until someone explained it to me, and then suddenly
it made perfect sense, and I started going in that direction a lot.
To be fair, I think that was middle school that someone pointed that out.
I haven't somehow gotten to like my 40s and then never
realized, "Oh wait, you mean if you cut things in half it goes
better?" Yeah.
Exactly.
We all know this.
Just, you know, intuitively we know it or we learned it at some
point when we were younger, and we don't even think about it.
But like if you read the binary search chapter in the MIT
book, it's pretty complex because they go through all of the,
you know, all of the proof and like, where is this going?
Whereas I'm more interested in what is the big idea you can
take away from this, that he can actually apply to your job.
Cause he can use binary search everywhere.
You just need to know the concept behind it.
I want to get in a slightly different direction
as well, because I don't feel that I have.
made enough of a big deal about this.
The book that you have written, Grokking Algorithms,
from a technical publisher, Manning, is illustrated.
Yeah.
It is not something that is just sitting
there doing, just flapping in the breeze here.
It's engaging.
The pictures you have drawn as part of your substack
series on AWS networking, it makes it more approachable.
It's not, I want to be clear, when I say that there's an animated
duck that you draw, it's in service of the larger message.
It's not there just as a distraction of, "Well, been
ten minutes, need to throw another joke in," style.
I say this as someone who periodically has that urge himself.
The whole thing weaves into a style of
storytelling I just haven't seen very often.
Thank you.
I feel like that is the part I brought to the book when I started it.
I started working on it in 2013, and it came out in 2016.
So it was a long time in the making.
I kind of knew how to use the pictures right away, but
since you mentioned Manning, which, which is my publisher
for this book, they paired me with this incredible editor.
He's like, you know, the head editor at Manning, and I got lucky.
They wanted to start this new grokking series, and so they said, "You know,
your book is going to be like the first one. That's going to be the flagship. We
want to make this a real success, and then we'll build on this grokking series."
Which they have, but this editor Bert really taught me how to teach and writing.
I had a lot of the ideas, but he's the one, you know, "just in time" versus
"just in case," which we were talking about earlier, initially came from him in
the context of writing this book, because initially it had a lot more content.
And he's the one who told me, "You know, this feels
like just 'in case information.' what does the reader
need to know right now?" They just did a great job.
I mean, you know, you don't, I feel like people don't really get
that side of the writing very often is like understanding where
the publisher fits in, but Manning really helped make this book.
And,
and now you, lately you've been deviating a bit from that direction.
Now, let me be clear, 2016 you wrote this and last year in February you
released the second edition, which again, usually a trick we see from professors
who want to sell new versions and kill the used market for the textbook
they use in their own class, but you went back to that particular well.
But where I've encountered you this year
has been in relatively rapid succession.
Your Substack, DuckTyped, people who are interested, it's ducktyped.org.
You can, you've gone through this series now explaining concepts of
AWS networking, and the first time I saw it, like, this is great.
It's awesome.
I, and then I added to the queue, put it in
the newsletter, and honestly, I move quickly.
I didn't think much about it again.
Then a couple of weeks ago, the second one in the series, came across
my desk through the same methods, and okay, now this is, this is, once
is, once anyone can write something great almost by accident once, it
seems, but doing it consistently, now there's something going on here.
And that's why I wanted to talk to you about this, it's an area
that is significantly divergent from the algorithms world that
you came from, but you're no less effective at explaining this.
How did you get into the, the fun world of AWS networking yourself?
That's a good question.
Yeah.
I mean, again, I am just lucky I happen to know a bunch of people who are
experts on different parts of AWS, and I really wanted to understand AWS better.
That's where a lot of this writing comes from, is like me feeling
like, okay, I've learned this thing, but I'm not going to be confident
that I know it until I can explain it very clearly to someone else.
And so that's where I started writing these AWS posts,
and I've had people review them, and it's been such
great feedback, and there's so much more to cover.
You know, for example, IAM is such a mess.
Like such a hard, there's so much to understand there, and someone
at my last job, Rula, is, you know, an expert at IAM, and I talked
to her about, like, you know, "Would you be willing to review this
post," or like, "Do you have a resource for learning IAM?" And
she's a staff security engineer at Rula, and she just said, "I don't
know a single resource that will cover everything that's needed.
I have just learned it over a decade of being in this job."
That's the kind of thing I think people would be really interested in.
I think that would be really valuable information, and it's
just a matter of like, I need to figure out how to teach it.
I need to figure out what the story is.
You know, what is the "just in time" story I can tell here?
And then I want her to review that series of posts and see if that works.
It's funny you mentioned IAM because along with networking, that feels a
lot like the thing most commonly hand waved over of, okay, when I, when I
copy and paste the magic spell from the tome of wisdom that was formerly
Stack Overflow and is now ChatGIPPITY, great, it does what I expect it
to do, but no one really understands what's going on under the hood.
Last year I was invited, to my great honor, to give the
keynote at NANOG 91, and my talk, like, "What do you want us,
what do you want me to talk about?" "Just be funny." Great.
Awesome.
Terrific.
So, when left to my own devices, and I had no idea what else to talk
about, I talked about myself, most people do, and specifically my
journey through how I learned networking, which is digging deeper
where I needed to, and I noticed that increasingly in our cloud world,
people don't work with networking because the cloud providers have
gotten so good that they you don't need to know a lot about networking
to get started to, to use your example, to spin up an EC2 instance.
You don't need to know how the network works until suddenly one day you hit a
wall where you absolutely need to understand how the network works, and that
is usually a gnarly enough scenario where "just in time" might not be enough.
So where is the ebbing tide of networking folks in the cloud era?
Oh,
that's that's such a great question.
So I would say "just in case" definitely has its place, right?
And like, as a staff engineer, I do "just in
case" learning all the time for that reason.
Like, it's not enough to just like, no,
the short version of how something works.
I really need to understand it at a deep level because when something breaks,
I'll be the one who's called in to fix the issue, and I can't at that point
be like, well, I know that, you know, our site is down, but I need to go
and like, do this deep dive into the docs to figure out what's going on.
That's where I think great books come in so useful.
And this is where I would really encourage people like, you know,
you don't have to finish a book if you do want to finish a book, read
a few books and figure out which book it is that you want to finish
because I think a great book, one of the things it does for you is it
lays out all of the content that the author thinks you need to know
in order to become, you know, let's say intermediate at this topic.
So I think a great book on AWS networking for me would be.
Okay, here is all the information you need to know so that
if something breaks in your system, you know how to fix it.
I think it's less useful to have books that are like,
here is everything that you could possibly know.
And at the same time, it's also not as useful to say,
to your point, you know, this is a "just in time" book.
So we're just going to give you the short version,
and then if you need more, you're sort of out of luck.
There's a time and a place for it.
For example, like, well, you don't necessarily want your
surgeon to wind up doing the "just in time" learning thing
of right before you go under, but you also kind of do.
You don't want your surgeon to have to figure out what, like,
"how do I perform surgery?" Pumping that into ChatGIPPITY, but you
absolutely want your accomplished, certified professional surgeon
to refresh themselves on the specificities of this procedure.
Is there anything new state of art in the literature
that's come out since the last time I did one?
And figuring those things out and adapting and assimilating new information.
You need the baseline.
It turns out amateur surgery is not a thing.
It's just sparkling butchery.
So there, there is a limit here of how much you can
pick up on the fly, bringing that to technology.
I'm not going to go and sell people on hiring me as a database
consultant and then learn the night before how databases work,
but I might very well look up that night before on what their
particular database engine has been doing in the last three months.
Yes.
So there's a similar, there's an algorithm that's sort of in this region
called "explore versus exploit." And this algorithm is why we see so
many movies these days that are like sequels or remakes, because the
idea of it explore versus exploit is to start with you explore, you
know, what are all your various options, like golden age of movies.
People are like, "Oh, let's just see what, you know, what we can make."
We have all sorts of interesting movies, we have
art house movies, let's just see what works.
And that's "explore." And now, movies.
I think it's fair to say are becoming less popular.
Fewer people are going to the theater to see a movie.
Studios can't do that sort of experimentation
anymore because the, you know, the budget's tighter.
So what's going to work for them is making sequels because
they know that's going to make them a ton of money.
So they did the "explore," now it's time to do the "exploit." The
"exploit," the fact that they have all these great franchises.
You can do a similar thing in learning.
Something I do is like, just learn different things that you find interesting.
You don't need to have a purpose, you know, you don't need to have a reason
for doing it, but at some point in the future, you might say, "Oh, thank
goodness I took that CSS course by Josh Como because now I have to build this
whole front end and that thing is going to come in really handy for this."
There's a lot that can be said for, honestly, improving recall, because that's
part of the issue too, is I can sit here and read five algorithms books, great.
Three years pass.
How much of that am I really going to retain in the moment on these things?
It's important to be able to know where to go look
for these things instead trying to just memorize it
forevermore.
Yes, and that's why my posts, I always try
to do like a summary, including an image.
Because again, I'm sort of writing for me also, so I want to be able to
go back and say, okay, roughly remember all the set up networking set up.
I need to do to get things working, but instead of reading through all these
posts, I just want to look at one image that gives me the summary of those.
That's honestly why I do a lot of pictures in general,
because I think you're more likely to remember the
content if you have a nice, clear visual to go with it.
Absolutely.
I read a lot of articles, some well written, some
not as much, but very few have drawings of ducks.
I'm sure.
I really want to thank you for taking the time to speak with me about this.
If people want to learn more, where's the best place for them to find you?
People should go to www.ducktyped.org.
That's the Substack.
Excellent.
And we will, of course, put a link to that in the show notes.
Aditya, thank you so much for taking the time to speak with me today.
I really appreciate it.
Thank you.
It was great to be here.
Absolutely.
And thank you all for listening.
Aditya Bhargava, staff software engineer at Etsy.
I'm cloud economist, Corey Quinn, and this is Screaming in the Cloud.
If you've enjoyed this conversation, please leave a
five star review on your podcast platform of choice.
Whereas you've hated this conversation, please leave a five star
review on your podcast platform of choice, along with an angry,
insulting comment, making sure to include a drawing of a duck.