Today at RC I’m a little stuck so here’s a very short reflection on how to do hard programming problems :)

I was talking to a friend yesterday about how to do programming projects that are a bit out of your comfort zone, and I realized that there’s a pattern to how I approach new-to-me topics! Here I’m especially thinking about little side projects where you want to get the thing done pretty efficiently.

When I start on a new project using some technology I haven’t worked with before, I often:

1. Find some code on the internet that already does something a little like what I want
2. Incrementally modify that code until it does what I want, often completely changing everything about the original code in the process

Here are a couple of quick thoughts about this process:

it’s important that the initial code works

Often when I’m out looking for examples, I’ll find a lot of code that I can’t get to work quickly, often because the code is kind of old and things have changed since then. Whenever possible, I try to find code that I can get to work on my computer pretty quickly.

It’s been pretty helpful to me to give up relatively quickly on code that I can’t get to work right away and look for another example – often there is something out there that’s more recent and that I can get to work more quickly!

you have to be able to incrementally change the code into what you want

Today I’ve been working with some neural network code, and one thing I’m really struggling with for the last couple of days is that I find it pretty easy to find somewhat relevant Jupyter notebooks that do RNN things, and pretty hard to modify those examples to do something closer to what I want. They keep breaking and I then don’t know how to fix them.

Last week I was working on a Rails app, which I think is something that’s very easy to incrementally change into the program you want: rails new gives you a webserver that does almost nothing, but it works! And then you just need to change it one tiny step at a time into the website you want to build.

examples of “something that works”

• If you want to write a window manager, tinywm is a window manager in 50 lines of C!
• this tiny kernel written in Rust that does nothing was a fun starting point for an operating system https://github.com/charliesome/rustboot (probably it’s not a good starting point today)
• rails new, like I talked about above
• I love that https://glitch.com/ projects let you “view source” on the backend of any Glitch project
• Jupyter notebooks, like these great NLP tutorials by Allison Parrish

that’s all!

I think little starting points like this are so important and can be really magical. Finding the right starting point can be hard, but when I find a good one it makes everything so much easier!

Sumana Harihareswara wrote an interesting blog post Plain Language Choices recently, about writing about complicated topics using simple language and how it can sometimes come off as condescending.

I really like explaining complicated topics while trying to avoid unnecessary jargon, and I realized that I’ve thought a lot about how to do it well. So here are a bunch of things I try to do when I use simple language to avoid coming off as condescending.

use some jargon to give the reader search terms

Sometimes I see writing that completely avoids all jargon and instead substitutes simple language for all “jargon”-y words.

I like to include some jargon in my explanations because otherwise it’s impossible for the reader to search & learn more about the concept they’re trying to learn about.

write (mostly) true explanations

Something else I see sometimes in ELI5-type explanations is an explanation in plain language that’s not actually true in a useful way. I’m pretty sympathetic to why people do this – it’s super hard to write simple explanations that are also true!

And actually sometimes when I’m trying to write down a simple/clear explanation for a concept, I realize that I don’t actually understand the concept as well as I thought and that I’m not able to explain it. That’s okay!

I think there are a few options here:

• try to say only things that are true (or at least which are a useful model for how the world works even if they’re not 100% true)
• write things that are not really true / that you’re not sure of, but point out that they may not be true (“I think it works like X, but I realize now that it might be Y instead, I’m not sure!“)

only use “fun” visual elements on explanations that are actually well written & easy to understand

This happens more with visual aids than with simple language but I’ll include it anyway. Sometimes I see explanations which have “fun” elements to it to make it them seem more approachable where the explanation itself is still pretty unclear.

I try to be careful about this in my own work – I try to only attach “fun” elements (like a fun illustrated cover) to explanations that I’ve spent a lot of time on making really clear. Basically to me “fun” things are a signal that the content itself is really clear/accessible, and I try to not misuse that signal.

I think why’s poignant guide to ruby is a nice example of something that’s fun and clear and which has helped a lot of people learn Ruby.

Another nice example of this is: I know someone who got her master’s thesis printed as a paperback book and illustrated with some great drawings related to the topic of her thesis (trans represensentation in media). It’s called “I’m supposed to relate to this?”, here’s the paperback.

I ended up reading the whole thing because, in addition to having the fun illustrations, her master’s thesis was really well written and interesting! The fact that she did the work to print a paperback book of her thesis and get it illustrated was a sign that she’d worked on making the writing accessible to a non-academic audience, and it was true!

tell a relevant story

Stories can really help people learn! For example, something I’ve done a lot on this blog is talk about a problem I ran into in the course of my job and what I did to solve that problem.

Some kinds of stories that I think work well:

• a real problem that someone ran into, to motivate why the concept is interesting / important to learn
• something that’s happening on a computer, framed as a “story” (for example https://howdns.works/ tells a story about how DNS works. Everything in the story literally corresponds to exactly what happens when you make a DNS query)

Sometimes I see stories used to explain concepts that don’t fit into either of these and feel kind of pasted on, like they’re there to help the concept seem “fun” but don’t actually illustrate the concept or motivate why it might be useful to learn it.

have a specific audience in mind

I try to write relatively simple explanations, but when I write I also generally assume a lot of knowledge on the part of my audience.

Sometimes I see explanations of complicated concepts that start with explaining the very basics of the topic. This usually isn’t that effective: if someone is trying to understand some super technical aspect of containers, they probably understand the basics of containers already!

“Have an audience” is more of a general writing tip so I’ll leave it at that.

on using simple language as a joke for people who already understand the idea

Here’s a very fun explanation of a complicated thing using simple language: Gödel’s Second Incompleteness Theorem Explained in Words of One Syllable.

On one hand, this is fun! I enjoyed reading it. On the other hand, I think the main audience for this is probably people who already more or less understand Gödel’s Second Incompleteness Theorem.

For example, someone pointed out that “if math is a not a load of bunk” in this text is code for “Peano arithmetic is consistent” with (“math” being “Peano arithmetic” and “not a load of bunk” meaning “consistent”). Which I find very charming, but also I found it a little hard to decode when reading it.

And (as we talked about before about jargon), if you know that “Peano arithmetic is consistent” is the relevant bit of jargon, you can find all kind of fascinating things, like a blog post by John Baez from 2011 discussing an attempted proof that Peano arithmetic was inconsistent)

(I’m also reminded here of the XKCD up goer five, which is very delightful, but I don’t think I learned anything about spaceships from reading it)

that’s all!

I’d love to hear more thoughts on this – I think there are probably more ways that simple explanations can feel condescending that I’ve missed!

I really don’t think they need to feel condescending though – to me the point of writing a clear/simple explanation is usually that I think the idea is not actually fundamentally that complicated and so I’m just explaining it in a way that’s exactly as complicated as it needs to be.

In the last few weeks I’ve been editing 2 zines and getting them ready to release: one on CSS and one on bash.

I have a lot of ways I get feedback on my zines to make them better, including:

1. post individual pages on Twitter and see what people say
2. hire someone to go over the zine in depth and see what they find confusing (I do this with my friend Dolly, who always points out a million things that don’t make sense and helps me come up with ideas for new pages on topics that I’ve totally forgotten to explain)
3. hire a technical reviewer
4. ask a friend to casually look at parts of it and see what they think (the diagrams in the SQL zine are thanks to my friend Anton who told me “these diagrams are confusing, what if you did them like this instead?”)
5. ask my partner to read it
6. hire a copy editor near the end

But I still felt like I wasn’t getting quite enough feedback about which parts of the zine were confusing and needed to be made more clear.

So this round of zine editing, I had an idea: what if I recruited 10-20 beta readers and got their thoughts? I thought this worked really well, so here’s my process for doing this in case it’s useful for someone else writing a book.

(and since a few people have offered: I’ll say to start out that I’m not looking for new beta readers right now, but I really appreciate everyone who has helped with this!)

step 1: email my mailing list and ask for beta readers

I sent a quick note out to part of my mailing list, like this:

If you’d be interested in reading through a draft of the zine and sending me some feedback about which parts are confusing, email me at REDACTED! I’m especially interested in hearing from people who know some basic CSS, but still get really confused & frustrated every time they try to get something done.

Anyone who gives me beta reader feedback on the zine will get a free copy of the zine when it comes out, as a thank you :)

Julia

I think there were 3 important things here:

1. the number of people I sent it to: I sent this to about 300-600 people, and about 5% of the people I emailed replied – 10-30 beta readers. I think that gave me a good range of feedback and that I’d aim for a similar number in the future. I think that if I emailed way more people (like 2000), it would be hard to manage emailing all of them and digesting all the feedback
2. saying who specifically I want feedback from. In this case, I said that I wanted to hear from “people who know some basic CSS, but still get really confused & frustrated every time they try to get something done.” I think this is important because it lets me focus on feedback from people who are in the audience for the zine.
3. ask people to briefly summarize their experience with the topic. This is something I didn’t ask for, but that most people naturally did on their own when emailing me – they’d write a sentence or two about their experience with CSS. I think that next time I’d ask people to do this because I found it VERY helpful to understand a little bit about the person’s experience when reading their feedback.

step 2: explain what kind of feedback I want

I think this was the most important step. I wanted a really specific kind of feedback from my beta readers (to tell me which parts of the zine were confusing), and I knew that I wouldn’t get it if I didn’t ask for it specifically. So I wrote a pretty detailed email explaining the kinds of feedback I wanted and the kinds of feedback I didn’t want.

I also tried to be respectful of people’s time – I knew that people were busy, so I said that I appreciated any amount of feedback, even if they didn’t have time to read the whole zine.

Hi NAME! (sometimes a quick sentence personal to them here, like “You’re definitely who I want to hear from – I partly wrote this for people who wrote CSS 10 years ago and haven’t learned anything new since then”)

Here’s a link to download the current zine draft: https://www.dropbox.com/REDACTED (please don’t share it!)

Any amount of feedback really helps me – if you just read 5 pages of the zine and only have 2-3 small pieces of feedback, please send it! I’d like to get the feedback by Saturday. You can either leave comments on Dropbox or just download the PDF and send me an email with a bunch of notes like “page 6: I didn’t understand XYZ”. Whatever’s easier for you!

here’s the kind of feedback that would help me the most:

1. Things you found confusing. Things like:
   • On page 3 it uses the term “inline” and I had to look up what that meant
   • Nothing on page 10 made sense to me, I was just really confused
2. Questions you have (either big questions like “what even is the point of this feature at all?” or small questions like “what is that code supposed to output?”)
3. Specific things you learned! (for example, “I never understood what X syntax meant, and now I get it!”)

I’m generally not looking for:

1. Things that you think someone else might find confusing, but that you yourself understand. I find that most people (including me, which is why I’m asking for this feedback!) aren’t great at simulating what someone else might find confusing.
2. Technical review (I have someone else doing that and I find it’s simpler not to crowdsource tech review)

(though if you have something in these categories that you think is especially important, I’m happy to hear it!)

thanks again, and I’m excited to hear what you have to say!

Julia

step 3: consolidate the feedback!

People REALLY delivered and gave me really great feedback! I wasn’t sure if people responding would stick to the guidelines of “I found this confusing”, “here’s a question I have”, and “here’s something I learned”, but almost everyone did!

For both zines I gave people a pretty short deadline, about 6 days. So about a week later I went through all the feedback and organized everyone’s comments.

Pretty much everyone had organized their comments by page, so I created a text file that looked like this:

Page 10: specificity
NAME 1: some feedback
NAME 2: more feedback
NAME 2: a different point

Then I wrote a Python script to put all the comments for each page into the Trello card for that page (where I’ve been putting all the feedback I get from everyone)

a side excursion into Dropbox’s comments API

One small surprising thing that initially I didn’t expect is: I’d given everyone a Dropbox link to download the zine, and I’d forgotten that Dropbox has a commenting feature. So people who happened to have a Dropbox account would comment inside the Dropbox commenting feature.

I was a bit confused about how to handle this at first, because it turns out that for some reason that page renders extremely slowly on my laptop and so it was almost impossible to copy the comments out.

But then I remembered that I’m a programmer, so I:

1. went into the network tab and reloaded the page
2. found the request for the list_comments endpoint (or whatever it was called).
3. right clicked, clicked ‘copy as cURL`
4. pasted it into my terminal, and voila! I had a JSON file of all the comments! Way easier than manually copying and pasting everything.
5. wrote a little Python script to format the comments into a text file in a format I could use

step 4: look for patterns

Unsurprisingly, there were a lot of patterns in the feedback – most pages had feedback from maybe 5 people, and there were a few places where everyone would be confused about the exact same thing. This was SO HELPFUL because it was a clear sign that I definitely needed to change it.

Of course, sometimes people disagreed – sometimes one person would say something “this is really clear and I learned X Y Z from this page” and another person would say “this is very confusing, I have all these questions”. In cases like that, I usually tried to think about which person was closer to who I thought the audience for the zine was (which is why it’s so helpful to get a sense for each person’s background!), as well as always trying to fix the confusing thing if I could find a way to do it.

step 5: make the changes

Some confusing things were easy to fix, like “there’s a footnote here and I can’t figure out what it refers to”, or “you talk about ‘css reset’ stylesheets” but the explanation makes no sense”.

Some were harder, for example I have a page about stacking contexts that I knew was confusing, and the beta readers confirmed it was in fact pretty confusing. I think the root cause here is that stacking contexts might be actually literally impossible to explain in 100 words / 6 panels, so I approached problems like that by finding some simpler concept I could explain in a small space, like “if z-index isn’t working the way you expect, the reason is probably that you have 2 elements in different stacking contexts”.

One of the biggest changes I made to the CSS zine after getting the beta reader feedback was to add some examples (https://css-examples.wizardzines.com) focused on things that the beta readers had found confusing and mark the panels which have associated examples with a little “try me!” icon.

it really helped me feel more confident about the zine!

I always have this moment of anxiety when I release a new zine like “OH NO MAYBE THIS IS AWFUL AND NOBODY WILL UNDERSTAND ANYTHING”. Getting feedback from the beta readers has helped with this – because people both told me what they learned and what questions they had, I could see that a lot of the parts of the zine weren’t that confusing and that I was getting across a lot of the information that I’d hoped to get across.

that’s all!

Thanks so much to everyone who was a beta reader for these two zines (you know who you are!). I should say that I’m not looking for new beta readers now, but if you’re on my saturday comics mailing list, you might get an email from me at some point asking if you’re interested in being a beta reader :)

Hello! I’m going to do a batch (virtually) at the Recurse Center, starting on Monday. I’ll probably be blogging about what I learn there, so I want to talk a bit about my plans!

I’m excited about this because:

• I love RC, it’s my favourite programming community, and I’ve always been able to do fun programming projects there.
• they’ve put a lot of care into building a great virtual experience (including building some very fun custom software)
• there’s a pandemic, it’s going to be cold outside, and I think having a little bit more structure in my life is going to make me a lot happier this winter :)

what’s the Recurse Center?

The Recurse Center (which I’ll abbreviate to “RC”) is a self-directed programming retreat. It’s free to attend.

A “batch” is 1 or 6 or 12 weeks, and the idea is that during that time, you:

1. choose what things you want to learn
2. come up with a plan to learn the things (often the plan is “do some kind of fun project”, like “write a TCP stack”)
3. learn the things

Also there are a bunch of other delightful people learning things, so there’s lots of inspiration for what to learn and people to collaborate with. There are always people who are early in their programming life and looking to get their first programming job, as well as people who have been programming for a long time.

Their business model is recruiting – they partner with a bunch of companies, and if you want a job at the end of your batch, then they’ll match you with companies, and if you accept a job with one of those companies then the company pays them a fee.

I won’t say too much more about it because I’ve written 50+ other posts about how much I love RC on this blog that probably cover it :)

some ideas for what I’ll do at RC

Last time I did RC I had a bunch of plans going in and did not do any of them. I think this time it’ll probably be the same but I’ll list my ideas anyway: here are some possible things I might do.

• learn Rails! I’ve been making small websites for a very long time but I haven’t really worked as a professional web developer, and I think it might be fun to have the superpower of being able to build websites quickly. I have an idea for a silly website that I think would be a fun starter rails project.
• experiment with generative neural networks (I’ve been curious about this for years but haven’t made any progress yet)
• maybe finish up this “incidents as a service” system that I started a year and a half ago to help people learn by practicing responding to weird computer situations
• deal with some of the rbspy issues that I’ve been ignoring for months/years
• maybe build a game! (there’s a games theme week during the batch!)
• maybe learn about graphics or shaders?

In my first batch I spent a lot of time on systems / networking stuff because that felt like the hardest thing I could do. This time I feel pretty comfortable with my ability to learn about systems stuff, so I think I’ll focus on different topics!

so that’s what I’ll be writing about for a while!

I’m hoping to blog more while I’m there, maybe not “every day” exactly (it turns out that blogging every day is a lot of work!), but I think it might be fun to write a bunch of tiny blog posts about things I’m learning.

I’m also planning to release a couple of zines this month – I finished a zine about CSS, and also wrote another entire zine about bash while I was procrastinating on finishing the CSS zine in a self-imposed “write an entire zine in October” challenge, so you should see those here soon too. I’m pretty excited about both of them.

Hello! I’ve been learning a lot about business over the last few years (it’s possible to make a living by helping people learn! it’s amazing!). One of the things I’ve found hardest to get my head around was email marketing.

Like a lot of people, I get a lot of unwanted email, and at first I was really opposed to doing any kind of email marketing because I was worried I’d be the source of that unwanted email. But I’ve learned how to do it in a way that feels good to me, and where the replies to my marketing emails are usually along the lines of “wow, I love this, thank you so much!”. (literally: here are excerpts from the last 20 or so replies I’ve gotten)

I’m going to structure this as a series of beliefs I had about email marketing that turned out not to be universally true.

myth 1: selling things is an adversarial relationship

I used to think that selling things was a sort of adversarial relationship: the person selling the product wants to convince the buyer (by any means necessary) to spend as much money as possible, and that people buying things are usually kind of resentful of anyone asking them to spend money.

I’ve learned that actually a lot of people are happy (or even actively want) to spend money on something that will help them solve a problem they have.

Here’s a silly example of something illustrating this: 2 years ago, we’d hired someone to paint our new apartment. We decided to paint a lot of the walls white, and we were stuck with the impossible problem of deciding which of the 10 billion possible shades of white to paint the walls. I found a $27 ebook called white is complicated, and (long story short, this blog post is not about painting) it really helped me confidently choose a shade of white!! We spent thousands of dollars on painting, so $30 was a really good investment in making sure we’d be happy with the result.

So even though $27 for an ebook on how to choose a white seems silly at first, I was really happy to spend the money, and my guess is a lot of other people who bought that ebook are as well.

The bigger idea here is that it’s easier to run a business when you’re selling to people who are happy to buy things based on the value they’re getting from the product. In my case, I’ve found that there are lots of programmers who are happy to pay for clear, short, friendly explanations of concepts they need to understand for their jobs.

a quick note on how I learned these things: 30x500

I originally wrote this blog post about all these things I learned, and it kind of read like I figured out all of these things naturally over the course of running a business. But that’s not how it went at all! I’ve actually found it very hard to debug business problems on my own. A lot of the attitudes I had when I started out running a business were counterproductive (like thinking of selling something as an adversarial process), and I don’t know that many people who run similar businesses who I can get advice from.

I learned how to think about selling things as a non-adversarial process (and everything else in this blog post, and a lot more) from 30x500, a business class by Amy Hoy (her writing is here) and Alex Hillman that I bought a couple of years ago. 30x500 is about running a specific kind of business (very briefly: sell to people who buy based on value, decide what to build by researching your audience, market by teaching people helpful things), which happens to be the exact kind of business that I run. It’s been a really great way to learn how to run my business better.

Okay, back to my misconceptions about email marketing!

myth 2: sending email is inherently bad

The next thing I believed was that sending email from a business was somehow inherently bad and that all marketing email was unwanted.

I now realize this is untrue even for normal marketing emails – for example, lots of people subscribe to marketing newsletters for brands they like because they want to hear about new products when they come out & sales.

But marketing emails aren’t just “not inherently bad”, they can actually be really useful!

marketing is about building trust

When I started sending out business emails, I based them on the emails I was used to receiving – I’d announce new zines I’d written, and explain why the zine was useful.

But what I’ve learned is that (at least for me) marketing isn’t about describing your product to the audience, marketing is about building trust by helping people.

So, instead of just periodically emailing out “hey, here’s a new zine, here’s why it’s good”, my main marketing email list is called saturday comics, and it sends you 1 email a week with a programming comic.

What I like about this approach to marketing (“just help people learn things for free”) is that it’s literally just what I love doing anyway – I wrote this blog to help people learn things for free for years just because I think it’s fun to help people learn.

And people love the Saturday Comics! And it makes money – I announce new zines to that list as well, and lots of people buy them. It’s really simple and nice!

myth 3: you have to trick people into signing up for your email marketing list

One pattern I see a lot is that I sign up for some free service, and then I start getting deluged with marketing emails trying to convince me to upgrade to the paid tier or whatever. I used to think that this was how marketing emails had to work – you somehow get people’s email and then send them email, and hope that for some reason (???) they decide to buy things from you.

But, of course, this isn’t true! If your marketing list is actually just full of genuinely helpful emails, and you can describe who it’s intended for clearly (give people a link to the archive to see if they like what they see!), then a lot of people will be happy to sign up and receive the emails!

If you clearly communicate who your mailing list will help, then people can easily filter themselves in, and the only people on the list will be happy to be on the list. And then you don’t have to send any unwanted email at all! Hooray!

Here’s one story that influenced how I think about this: once I sent an email to everyone who had bought a past zine saying “hey, I just released this other zine, maybe you want to buy it!”. And I got an angry reply from someone saying something like “why are you emailing me, I just bought that one thing from you, I don’t want you to keep emailing me about other things”. I decided that I agreed with that, and now I’m more careful about being clear about what kinds of emails people are opting into.

marketing is about communicating clearly & honestly

One insight (from Alex Hillman) that helped me a lot recently was – when someone is dissatisfied with something they bought, it doesn’t always mean that the product is “bad”. Maybe the product is helpful to many other people!

But it definitely means that the person’s expectations weren’t met. A tiny example: one of the few refund requests I’ve gotten for a zine was from someone from who expected there to be more information about sed in the zine, and they were disappointed there was only 1 page about sed.

So if I communicate clearly & accurately what problems a product solves, who it’s for, and how it solves those problems, people are much more likely to be delighted when they buy it and be happy to buy from me again in the future!. For my zines specifically, I like to make the table of contents very easy to find so that people can see that there’s 1 page about sed :)

myth 4: you have to constantly produce new emails

I’ve tried and failed to start a lot of mailing lists. the pattern I kept getting stuck in was:

I have an idea for a weekly mailing list I send 2 emails I give up forever

This was partly because I thought that to have a weekly/biweekly mailing list, you have to write new emails every week. And some people definitely do mailing lists this way, like Austin Kleon.

But I learned that there’s a different way to write a mailing list! Instead, you:

put together a list of your best articles / comics / whatever when someone subscribes to that list, send them 1 email a week (or every 2 weeks, or whatever) with one article from the List Of Your Best Articles

The point is most people in the world probably haven’t already read your best articles, and so if you just send them one article a week from that list, it’ll probably actually be MORE helpful to them than if you were writing a new article every week. And you don’t need to write any emails every week!

I think this is called a “drip marketing campaign”, but when I search for that term I don’t find the results super helpful – there’s a lot out there about tools to do this, but as with anything I think the actual content of the emails is the most important thing.

myth 5: unsubscribes are the end of the world

Another email marketing thing I used to get stressed out about was unsubscribes. It always feels a little sad to send an email about something I’m excited about and see 20 people unsubscribe immediately, even if it’s only 0.3% of people on the mailing list.

But I know that I subscribe to mailing lists very liberally, even on topics that I’m not that interested in, and 70% of the time I decide that I’m not that interested in the topic and unsubscribe eventually. A small percentage of people unsubscribing really just isn’t that big of a deal.

myth 6: you need to optimize your open rates

There are all kinds of analytics you can do with email marketing, like open rates. I love numbers and analyzing things, but so far I really haven’t found trying to A/B test or optimize my numbers to be that productive or healthy. I’d rather spend my energy on just writing more helpful things for people to read.

The most important thing I’ve learned about website analytics is that it’s unproductive to look at random statistics like “the open rate on this email is 43% but the last one was 47%” and wonder what they mean. What has been helpful has been coming up with a few specific questions that are important to me (“are people visiting this page from links on other sites, or only from my links?”) and keeping very rough track of the answers over time.

So far I’ve really never used any of the tracking features of my email marketing software. The only thing I’ve done that I’ve found helpful is: sometimes when I release a new zine I’ll send out a discount code to people on the list, and I can tell if people bought the thing from the mailing list because they used the discount code.

it’s important to remember there are people on the other side

The last thing that’s helped me is to remember that even though emailing thousands of people sometimes feels like a weird anonymous thing, there are a lot of very delightful people on the other side! So when I write emails, I usually try to imagine that I’m writing to some very nice person I met at a conference one time who told me that they like my blog. We’re not best friends, but they know my work to some extent, and they’re interested to hear what I have to say.

I often like to remind people why they’re getting the email, especially if I haven’t emailed that list for a long time – “you signed up to get announcements when I release a new zine, so here’s an announcement!”. I think the technical email marketing term for this is a list being “cold” and “warm”, like if you don’t email a list for too long it’s “cold” and your subscribers might have forgotten that they’re on it.

that’s all!

When I started, I was really convinced that email marketing was this terrible, awful thing that I could not do that mostly involved tricking people into getting emails they don’t want (ok, I’m exaggerating a bit, but I really struggled with it). But it’s possible to do it in a transparent way where I’m mostly just sending people helpful emails that they do want!

The big surprise for me was that email marketing is not a monolithic thing. I have a lot of choices about how to do it, and if I don’t like the way someone else does email marketing, I can just make different choices when doing it myself!