Reading List

2021: Year in review from Julia Evans RSS feed.

2021: Year in review

It’s the end of the year again! This was my second full year working for myself on wizard zines.

Here are some thoughts about what I’m working towards, a bunch of things I made this year, and a few ideas and questions about 2022.

made some progress on a “mission statement”

I think the two hardest things about working for myself are working alone and having to decide what to do.

This year I spent some time trying to figure out what I’m doing with wizard zines. This is hard for me because I work in a pretty intuitive way – I have some feelings about what’s important, and even though following my feelings usually turns out well, I can’t always explain what I’m trying to do.

Here are some thoughts about what I’m trying to do:

  • I’m only interested in explaining “old” established technologies (HTTP, DNS, assembly, C, etc)
  • I want to help people who are learning about these “old” things for the first time today (whether they’re new to programming or just new to the thing)
  • I think it’s very important to learn through experimentation and actually using the thing
  • There’s a lot of hidden knowledge about these “old” tools (what are they used for? what are the common mistakes? which parts can you ignore?). I want to make that knowledge easy to find.

There’s also something which I can’t quite articulate yet, which is that computers were “simpler” in the past, and that it’s still possible in 2022 to learn programming in a “simpler” way and cut through some of the chaos and churn in modern computing.

As stated this sounds unrealistic, because you do need to use a lot of more “complicated” stuff to get things done in a real programming job. Most people can’t avoid it! But understanding the “simple” core of how computers work really gives me a lot more confidence when dealing with all of the chaos. (“I don’t know what all this nonsense is but at the end of the day it’s all just assembly instructions and memory and system calls, I can figure this out”)

So I guess I want to figure out how to help other people move towards that confidence of “ok, I know how this computer stuff works, I can figure out any weird new nonsense you throw at me”. That seems ambitious and it might be unrealistic for a collection of a few zines and and blog posts and websites but it feels important to me.

educational websites!

This year I felt more excited about making websites than making zines and so I spent more time building websites than I did writing zines. I think this is because:

  • the way I learn things is by doing, not by reading
  • I feel really comfortable experimenting and breaking things on my computer, but I get the impression that not everyone feels the same level of comfort
  • writing code is fun

I’m not going to write about each project at length here because I already wrote long blog posts about each one, but here’s a list of all of the educational websites I made this year (and one command line tool):

  1. mysteries.wizardzines.com (blog post), a choose-your-own-adventure debugging game
  2. nginx playground (blog post), where you can do nginx experiments
  3. mess with dns (blog post), where you can do DNS experiments. I built this one with Marie Claire LeBlanc Flanagan.
  4. dnspeep (blog post), a command line tool for spying on your DNS queries
  5. a simple dns lookup tool (blog post), a friendly website version of dig
  6. what happens behind the scenes when you make a DNS query, a friendly website version of dig +trace
  7. a sort of “linux challenges” site that I wrote about a lot but haven’t released yet

As you can tell, a lot of them are related to DNS :)

collaboration!

My biggest problem with working for myself is that it gets lonely sometimes, and in previous years I haven’t been very good at finding collaborators. This year I got to work with Marie on Mess With DNS. It was a lot more fun (and a lot easier!) than building it by myself would have been.

opened a print zine store!

I finally (after several years of struggling to figure it out) opened an online store that sells print versions of my zines in May.

Unlike my previous artisanal attempts where I did all the shipping myself (which was kind of fun but totally unsustainable), this time an amazing company called White Squirrel is handling the shipping.

Setting this up involved a lot of logistics (I just finished figuring out how to handle EU VAT for example), but now that it’s set up it doesn’t need too much ongoing attention except to answer occasional emails from people who run into shipping problems.

put all of my comics online!

I put all of my comics online in one place at https://wizardzines.com/comics. Here’s a blog post about that. I’m really happy about this and it’s amazing to be able to just link to any comic I want (like grep).

some partial zines!

I worked on a few zine ideas this year but did not finish any. Here are some bits and pieces that I wrote this year.

Some pages from a DNS zine draft:

I also worked on a zine about debugging that I’ve been writing on and off since 2019. Here are some pages I wrote in this year’s attempt: (you can find more by searching for “debugging” at https://wizardzines.com/comics)

I also wrote 3 pages about how things are represented in memory (hexadecimal, little-endian, bytes), but there’s a very long way to go on that project.

I got stuck writing these for the reason I usually get stuck finishing zines – I need to have a clear explanation in my mind of what the zine is about. The explanation looks something like “the reason many people struggle with TOPIC is because they don’t understand X, here’s what you need to know”. My first guess at what “X” is often wrong, and the farther I am away from learning the topic for the first time myself the more wrong I am.

But I have some thoughts about how to get unstuck, we’ll see what happens!

blog posts!

here are some of blog posts I wrote this year, by category:

“how things work”:

“how to use X tool”:

meta-posts about learning and writing:

debugging:

I’ve historically had a “never write anything negative” rule for this blog and I’m trying to back off that a little bit because it feels limiting. Specifically the posts on dns propagation, the osi model, and confusing explanations are a little more negative than what I would have written previously, and I think they’re better because of it.

Looking at this list, maybe I want to write more hands-on “how things work” / “how to use X tool” posts next year.

Also, I see people linking to Get your work recognized: write a brag document (from 2019) on Twitter all the time. I’m very happy it’s still helping people.

the business is doing well!

This past year I released a lot of free things and not as many things that cost money, but the business is doing well nonetheless and I’m happy about that.

All of the work in this post continues to be 100% funded by zine sales, which I’m grateful for.

things I might do in 2022

Here are some things I might do in 2022. I write these because it’s interesting to see at the end of the year which ones happened and which ones didn’t.

  • keep working with other people.
  • try to finish some zines
  • make more websites where people can do computer experiments
  • figure out where to take the computer mysteries project
  • give a talk (I’ve taken 3 years off writing talks, but I have some ideas)
  • try to understand what’s going on with this “mission statement”

some things I’m less likely to do, but that I’ve thought about:

  • write an actual book (for example a book about computer networking)
  • write some computer networking command line tools that are easier to use
  • collaborate with someone to write a zine about a topic that I know almost nothing about (like databases)
  • spend more (than 0) time reading papers about CS education

some questions

Here are some questions I have going into 2022.

  • What’s the scope of the “zines” project? How many more do I want to write?
  • What’s hard for developers about learning to use the Unix command line in 2021? What do I want to do about it?
  • If I keep making these educational websites, how can/should I measure how much they’re used? (I’m thinking here about this paper by Philip Guo about python tutor’s design guidelines)
  • Do any of my educational websites need to make money, or can I keep releasing them for free?