A few weeks ago I gave a keynote at Strange Loopcalled Making Hard Things Easy. It’s about why I think some things are hardto learn and ideas for how we can make them easier.Here’s the video, as well as the slides and a transcript of (roughly) what Isaid in the talk.I often give talks about things that I'm excited about,or that I think are really fun.But today, I want to talk about something that I'm a little bit mad about,which is that sometimes things that seem like they should be basic take me 10years or 20 years to learn, way longer than it seems like they should. And sometimes this would feel kind of personal! This shouldn't be so hardfor me! I should understand this already. It's been seven years!And this "it's just me" attitude is often encouraged -- when I write aboutfinding things hard to learn on the Internet, Internet strangers will sometimestell me: "yeah, this is easy! You should get it already! Maybe you're just notvery smart!"But luckily I have a pretty big ego so I don't take the internet strangers tooseriously. And I have a lot of patience so I'm willing to keep coming back to atopic I'm confused about. There were maybe four different things that weregoing wrong with DNS in my life and eventually I figured them all out.So, hooray! I understood DNS! I win! But then I see some of my friends struggling withthe exact same things.They're wondering, hey, my DNS isn't working. Why not? And it doesn't end. We're still having the same problems over and over and overagain. And it's frustrating! It feels redundant! It makesme mad. Especially when friends take it personally, and they feel like "hey Ishould really understand this already".Because everyone is going through this. From the sounds of recognition I hear,I think a lot of you have been through some of these same problems with DNS. I started a little publishing company called Wizard Zines where -- (applause) Wow. Where I write about some of these topics and try to demystify them. We're going to talk about Bash, HTTP, SQL, and DNS. For each of them, we're going to talk a little bit about: a. what's so hard about it? b. what are some things we can do to make it a little bit easier for each other? First, let's run this script, bad.sh: This moves a file and prints "success!". And with most of the programming languages that I use, if there's a problem, the program will stop. [laughter from audience] But I think a lot of you know from maybe sad experience that bash does not stop, right? It keeps going. And going... and sometimes very bad things happen to your computer in the process. When I run this program, here's the output: It didn't stop after the failed mv.Eventually I learned that you can write set-e at the top of your program, and that will make bash stop ifthere's a problem. When we run this new program with set -e at the top, here's the output:Here we've put our code in a function. And if the functionfails, we want to echo "failed". So use set -e at the beginning, and you might think everything should be okay. But if we run it... this is the output we getWe get the "success" message again! It didn't stop, it just kept going. This isbecause the "or" (|| echo "failed") globally disables set -e in thefunction.Which is certainly not what I wanted, and not what I would expect. But this isnot a bug in bash, it's is the documented behavior.And I think one reason this is tricky is a lot of us don't use bash very often.Maybe you write a bash script every six months and don't look at it again.When you use a system very infrequently and it's full of a lot of weird triviaand gotchas, it's hard to use the system correctly.But I would say this is factually untrue. How many of you are using bash?A lot of us ARE using it! And it doesn't always work perfectly, but oftenit gets the job done.The way I think this is -- you have some people on the left in thisdiagram who are confused about bash, who think it seems awful andincomprehensible.And some people on the right who know how to make the bash work for them,mostly.So how do we move people from the left to the right, from being overwhelmed bya pile of impossible gotchas to being able to mostly use the system correctly?And for bash, we have this incredible tool calledshellcheck.[ Applause ]Yes! Shellcheck is amazing! And shellcheck knows a lot of things that can gowrong and can tell you "oh no, you don't want to do that. You're going to havea bad time."I'm very grateful for shellcheck, it makes it much easier for me to writetiny bash scripts from time to time. Now let's do a shellcheck demo! Shellcheck gives us thislovely error message. The message isn't completely obvious on its own (and thischeck is only run if you invoke shellcheck with -o all). Butshellcheck tells you "hey, there's this problem, maybe you should be worriedabout that".And I think it's wonderful that all these tips live in this linter. I'm not trying to tell you to write linters, though I think that some of youprobably will write linters because this is that kind of crowd.I've personally never written a linter, and I'm definitely not going to createsomething as cool as shellcheck!But instead, the way I write linters is I tell people about shellcheck fromtime to time and then I feel a little like I invented shellcheck for thosepeople. Because some people didn't know about the tool until I told them aboutit!I didn't find out about shellcheck for a long time and I was kind of mad aboutit when I found out. I felt like -- excuse me? I could have been usingshellcheck this whole time? I didn't need to remember all of this stuff inmy brain?So I think an incredible thing we can do is to reflect on the tools that we'reusing to reduce our cognitive load and all the things that we can't fit intoour minds, and make sure our friends or coworkers know about them.I also like to warn people about gotchas and some of the terrible thingscomputers have done to me.I think this is an incredibly valuable community service. The example I sharedabout how set -e got disabled is something I learned from myfriend Jesse a few weeks ago. They told me how this thing happened to them, and now I know and I don't haveto go through it personally.One way I see people kind of trying to share terrible things that theircomputers have done to them is by sharing "best practices".But I really love to hear the stories behind the best practices!If someone hasa strong opinion like "nobody should ever use bash", I want to hear about thestory! What did bash do to you? I need to know.The reason I prefer stories to best practices is if I know the story about howthe bash hurt you, I can take that information and decide for myself how I wantto proceed.Maybe I feel like -- the computer did that to you? That's okay, I can deal withthat problem, I don't mind.Or I might instead feel like "oh no, I'm going to do the best practice yourecommended, because I do not want that thing to happen to me". These bash stories are a great example of that: my reaction to them is "okay,I'm going to keep using bash, I'll just use shellcheck and keep my bash scriptspretty simple". But other people see them and decide "wow, I never want to usebash for anything, that's awful, I hate it".Different people have different reactions to the same stories and that's okay.I was talking to Marco Rogers at some point, many years ago, and he mentionedsome new developers he was working with were struggling with HTTP.And at first, I was a little confused about this -- I didn't understand whatwas hard about HTTP.The way I was thinking about itat the time was that if you have an HTTP response, it has a few parts: a responsecode, some headers, and a body.I felt like -- that's a pretty simple structure, what's the problem? But ofcourse there was a problem, I just couldn't see what it was at first.So, I talked to a friend who was newer to HTTP. And they asked "why does itmatter what headers you set?"And I said: "well, the browser..."The browser!Firefox is 20 million lines of code! It's beenevolving since the '90s. There have been as I understand it, 1 millionchanges to the browser security model as people have discovered new andexciting exploits and the web has become a scarier and scarier place.The browser is really a lot to understand.One trick for understanding why a topic is hard is -- if the implementation if thething involves 20 million lines of code, maybe that's why people are confused!Though that 20 million lines of code also involves CSS and JS and many otherthings that aren't HTTP, but still.Once I thought of it in terms of how complex a modern web browser is, itmade so much more sense! Of course newcomers are confused about HTTP if youhave to understand what the browser is doing!Then my problem changed from "why is this hard?" to "how do I explain this at all?"So how do we make it easier? How do we wrap our minds around this 20 million linesof code?One way I think about this for HTTP is: here are some of the HTTP requestheaders. That's kind of a big list there are 43 headers there.There are more unofficial headers too.My brain does not contain all of those headers, I have no idea what most ofthem are.When I think about trying to explain big topics, I think about -- what isactually in my brain, which only contains a normal human number of things?This is a comic I drew about HTTP request headers.You don't have to read the whole thing. This has 15request headers.I wrote that these are "the most important headers", but what I mean by "mostimportant" here is that these are the ones that I know about and use. It's asubjective list.I wrote about 12 words about each one, which I think is approximately theamount of information about each header that lives in my mind.For example I know that you can set Accept-Encoding to gzipand then you might get back a compressed response. That's all I know,and that's usually all I need to know!This very small set of information is working pretty well for me.The general way I think about this trick is "turn a big list into a small list".Turn the set of EVERY SINGLE THING into just the things I've personally used. Ifind it helps a lot.Another example of this "turn a big list into a small list" trick is command line arguments.I use a lot of command line tools, the number of arguments they have can beoverwhelming, and I've written about them a fair amount overthe years.Here are all the flags for grep, from its man page. That's too much! I've beenusing grep for 20 years but I don't know what all that stuff is.But when I look at the grep man page, this is what I see.I think it's very helpful to newcomers when a more experienced person says"look, I've been using this system for a while, I know about 7 things about it,and here's what they are".We're just pruning those lists down to a more human scale. And it can even helpother more experienced people -- often someone else will know a slightlydifferent set of 7 things from me.But what about the stuff that doesn't fit in my brain?Because I have a few things about HTTP stored in my brain. But sometimes I needother information which is hard to remember, like maybe the exact details ofhow CORS works.I often have trouble finding the right references.For example I've been trying to learn CSS off and on for 20 years. I've made alot of progress -- it's going well!But only in the last 2 years or so I learned about this wonderful website called CSS Tricks.And I felt kind of mad when I learned about CSS Tricks! Why didn't I know aboutthis before? It would have helped me!But anyway, I'm happy to know about CSS Tricks now. (though sadly they seem tohave stopped publishing in April after the acquisition, I'm still happy the older posts are there)For HTTP, I think a lot of us use the Mozilla Developer Network. Another HTTP reference I love is the official RFC, RFC 9110 (also9111,9112,9113,9114)It's a new authoritative reference for HTTP and it was written just lastyear, in 2022! They decided to organize all the information really nicely. So if youwant to know exactly what the Connection header does, you can lookit up. This is not really my top reference. I'm usually on MDN. But I reallyappreciate that it's available.So I love to share my favorite references.I do sometimes find it tempting to kind of lie about references. Not onpurpose.But I'll see something on the internet, and I'll think it's kind of cool, andtell a friend about. But then my friend might ask me -- "when have you used this?"And I'll have to admit "oh, never, I just thought it seemed cool".I think it's important to be honest about what the references that I'm actuallyusing in real life are. Even if maybe the real references I use are a little"embarrassing", like maybe w3schools or something.I started thinking about SQL because someone mentioned they're trying to learnSQL. I get most of my zine ideas that way, one person will make an offhandcomment and I'll decide "ok, I'm going to spend 4 months writing aboutthat". It's a weird process.So I was wondering -- what's hard about SQL? What gets in the way of tryingto learn that?I want to say that when I'm confused about what's hard about something, that'sa fact about me. It's not usually that the thing is easy, it's that I need towork on understanding what's hard about it. It's easy to forget when you'vebeen using something for a while.So, I was used to reading SQL queries. For example this made up query that tries tofind people who own exactly two cats. It felt straightforwardto me, SELECT,FROM, WHERE, GROUP BY.But then I was talking to a friend about these queries who was new to SQL. Andmy friend asked -- what is this doing?I thought, hmm, fair point.And I think the point my friend was making was that the order that this SQLquery is written in, is not the order that it actually happens in. It happensin a different order, and it's not immediately obvious what that is.I like to think about: what does the computer do first?What actually happens first chronologically?Computers actually do live in the same timeline as us. Things happen. Thingshappen in an order. So what happens first?So, that's how I think about SQL. The way a query runs is firstFROM, then WHERE, GROUP BY, HAVING, SELECT, ORDER BY, LIMIT.At least conceptually. Real life databases have optimizations and it's morecomplicated than that. But this is the mental model that I use most of the timeand it works for me. Everything is in the same order as you write it,except SELECT is fifth. One is CORS, in HTTP. This comic is way too small to read on the slide.But the idea is if you're making a cross-origin request in yourbrowser, you can write down every communication that's happening between yourbrowser and the server, in chronological order.And I think writing down everything in chronological order makes it a lot easier to understand and more concrete."What happens in chronological order?" is a verystraightforward structure, which is what I like about it. "What happens first?"feels like it should be easy to answer. But it's not!I've found that it's actually very hard to know what our computers isdoing, and it's a really fun question to explore.As an example of how this is hard: I wrote a blog post recently called "Behind Hello World on Linux". It's about what happens when you run "hello world" on aLinux computer. I wrote a bunch about it, and I was really happy with it.But after I wrote the post, I thought -- haven't I written about this before? Maybe 10 years ago?And sure enough, I'd tried to write a similar post 10 years before.I think this is really cool. Because the 2013 version of this post was about 6times shorter. This isn't because Linux is more complicated than it was 10years ago -- I think everything in the 2023 post was probably also true in2013. The 2013 post just has a lot less information in it.The reason the 2023 post is longer is that I didn't know what was happeningchronologically on my computer in 2013 very well, and in 2023 I know a lotmore. Maybe in 2033 I'll know even more!I think a lot of us -- like me in 2013 and honestly me now, often don't knowthe facts of what's happening on our computers. It's very hard, which is whatmakes it such a fun question to try and discuss.I think it's cool that all of ushave different knowledge about what is happening chronologically on ourcomputers and we can all chip in to this conversation.For example when I posted this blog post about Hello World on Linux, some peoplementioned that they had a lot of thoughts about what happens exactly in yourterminal, or more details about the filesystem, or about what's happeninginternally in the Python interpreter, or any number of things. You can goreally deep.I think it's just a really fun collaborative question. I've seen "what happens chronologically?" work really well as an activity withcoworkers, where you're ask: "when a request comes into this API endpoint werun, how does that work? What happens?"What I've seen is that someone will understand some part of the system, like "Xhappens, then Y happens, then it goes over to the database and I have no ideahow that works". And then someone else can chime in and say "ah, yes, with thedatabase A B C happens, but then there's a queue and I don't know about that".I think it's really fun to get together with people who have differentspecializations and try to make these little timelines of what thecomputers are doing. I've learned a lot from doing that with people.Even though I struggled with DNS. Once I got figured it out, I felt like "dude,this is easy!". Even though it just took me 10 years to learn how itworks.But of course, DNS was pretty hard for me to learn. So -- why is that? Why didit take me so long?So, I have a little chart here of how I think about DNS.You have your browser on the left. And over on the right there's the authoritativenameservers, the source of truth of where the DNS records for a domain live. In the middle, there's a function that you call and a cache.So you have browser, function, cache, source of truth.One problem is that there are a lot of things in this diagram that aretotally hidden from you.The library code that you're using where you make a DNS request -- there are alot of different libraries you could be using, and it's not straightforward to figure out which one is being used.That was the source of some of my confusion.There's a cache which has a bunch of cached data. That's invisible to you, youcan't inspect it easily and you have no control over it. thatAnd there's a conversation between the cache and the source oftruth, these two red arrows which also you can't see at all.So this is kind of tough! How are you supposed to develop an intuition for asystem when it's mostly things that are completely hidden from you? Feels likea lot to expect.So: let's talk about these red arrowson the right.We have our cache and then we have the source of truth. This conversationis normally hidden from you because you often don't control either of theseservers. Usually they're too busy doing high-performance computing to report toyou what they're doing.But I thought: anyone can write an authoritative nameserver!In particular, I could write one that reports back every single message that it receives to its users.So, with my friend Marie, we wrote a little DNS server.This is called Mess With DNS. The idea is I have a domain name and youcan do whatever you want with it. We're going to make a DNS record calledstrangeloop, and we're going to make a CNAME record pointing atorange.jvns.ca, which is just a picture of an orange. Because Ilike oranges.And then over here, every time a request comes in from a resolver, this will --this will report back what happened. So, if we click on this link, we can see-- a Canadian DNS resolver, which is apparently what my browser is configuredto use, is requesting an IPv4 record and an IPv6 record, A and AAAA.So the trick here is to find ways to show people parts of what the computer isdoing that are normally hidden.Another great example of showing things that are hidden is this website called float.exposedby Bartosz Ciechanowski who makes a lot of incredible visualizations.So if you look at this 32-bitfloating point number and click the "up" button on the significand, it'llshow you the next floating point number, which is 2 more. And then as you makethe number bigger and bigger (by increasing the exponent), you can see that thefloating point numbers get further and further apart.Anyway, this is not a talk about floating point. I could do an entire talkabout this site and how we can use it to see how floating point works, butthat's not this talk.Another thing that makes DNS confusing is that it's a giant distributed system-- maybe you're confused because there are 5 million computers involved (really, more!).Most of which you have no control over, and someare doing not what they're supposed to do. So that's another trick for understanding why things are hard, check to see ifthere are actually 5 million computers involved.So what else is hard about DNS?We've talked about how most of the system is hidden from you, and about howit's a big distributed system.One of the hidden things I talked about was: the resolver has cached data,right? And you might be curious about whether a certain domain name is cachedor not by your resolver right now.Just to understand what's happening: am I getting this result because it wascached? What's the deal?I said this was hidden, but there are a couple of ways to query a resolver tosee what it has cached, and I want to show you one of them.With dig +norecurse jvns.ca, I'm kind of asking -- how popular is my website? Is it popular enough that someone has visited it in the last 5 minutes?Because my records are not cached for that long, only for 5 minutes.But when I look at thisresponse, I feel like "please! What is all this?"And when I show newcomers this output, they often respond by saying "wow,that's complicated, this DNS thing must be really complicated". But really thisis just not a great output format, I think someone just made some relativelyarbitrary choices about how to print this stuff out in the 90s and it's stayedthat way ever since.So a bad output format can mislead newcomers into thinking that something is more complicated than it actually is.One of my favorite tricks, I call eraser eyes.Because when I look at that output, I'm not looking at all of it, I'm justlooking at a few things. My eyes are ignoring the rest of it.When I look at the output, this is what I see: it says SERVFAIL.That's the DNS response code.Which as I understand it is a very unintuitive way of it saying, "I do not havethat in my cache". So nobody has asked that resolver about my domain name inthe last 5 minutes, which isn't very surprising.I've learned so much from people doing a little demo of a tool, and showing howthey use it and which parts of the output or UI they pay attention to, and which parts they ignore.Becuase usually we ignore most of what's on our screens!I really love to use dig even though it's a little hairy becauseit has a lot of features (I don't know of another DNS debugging that supports this+norecurse trick), it's everywhere, and it hasn't changed in along time. And I know if I learn its weird output format once I can know thatforever. Stability is really valuable to me.We've talked about some tricks I use to bring people over, like:When I practiced this talk, I got some feedback from people saying "julia! I don'tdo those things! I don't have a blog, and I'm not going to start one!"And it's true that most people are probably not going to start programming blogs.But I really don't think you need to have a public presence on the internet totell the people around you a little bit about how you use computers and how youunderstand them.My experience is that a lot of people (who do not have blogs!) have helped meunderstand how computers work and haveshared little pieces of their experience with computers with me.I've learned a lot from my friends and my coworkers and honestly a lot ofrandom strangers on the Internet too. I'm pretty sure some of you here todayhave helped me over the years, maybe on Twitter or Mastodon.So I want to talk about some archetypes of helpful peopleOne kind of person who has really helped me is thegrumpy old-timer. I'll say "this is so cool". And they'll reply yes,however, let me tell you some stories of how this has gone wrong in my life.And those stories have sometimes helped spare me some suffering.We have the loud newbie, who asks questions like "wait, how does that work?"And then everyone else feels relieved -- "oh, thank god. It's not just me."I think it's especially valuable when the person who takes the "loud newbie"role is actually a pretty senior developer. Because when you're more secure inyour position, it's easier to put yourself out there and say "uh, I don't getthis" because nobody is going to judge you for that and think you'reincompetent.And then other people who feel more like they might be judged for not knowingsomething can ride along on your coattails.Then we have the bug chronicler. Who decides "ok, that bug. This can never happen again"."I'm gonna make sure we understand what happened. Because I want this to endnow."And much like when debugging a computer program, when you have a bug, youwant to understand why the bug is happening if you're gonna fix it.If we're all struggling with the same things together for the same reasons, ifwe can figure out what those reasons are, we can do a better job of fixingthem.And that's all I have for you. Thank you.I brought some zines to the conference, if you come to the signing later on you can get one.This was the last ever Strange Loop and I’m really grateful to Alex Miller and thewhole organizing team for making such an incredible conference for so many years. Strange Loopaccepted one of my first talks (you can be a kernel hacker) 9 years ago when I hadalmost no track record as a speaker so I owe a lot to them.Thanks to Sumana for coming up with the idea for this talk, and to Marie,Danie, Kamal, Alyssa, and Maya for listening to rough drafts of it and helpingmake it better, and to Dolly, Jesse, and Marco for some of the conversations Imentioned.Also after the conference Nick Fagerland wrote a nice post with thoughts on why git is hard in response to my “Idon’t know why git is hard” comment and I really appreciated it. It had somenew-to-me ideas and I’d love to read more analyses like that. In a git repository, where do your files live? You might also like the Recurse Center, my very favorite programming community (my posts about it)