Someone recently asked me – “how do you deal with writing in public? People onthe internet are such assholes!”I’ve often heard the advice “don’t read the comments”, but actually I’velearned a huge amount from reading internet comments on my posts from strangersover the years, even if sometimes people are jerks. So I want to explain sometactics I use to try to make the comments on my posts more informative anduseful to me, and to try to minimize the number of annoying comments I get.On here I mostly talk about facts – either facts about computers, or storiesabout my experiences using computers.For example this post about tcpdump contains some basic facts about how to use tcpdump,as well as an example of how I’ve used it in the past.Talking about facts means I get a lot of fact-based comments like:In general, I’d say that people’s comments about facts tend to stay prettynormal. The main kinds of negative comments I get about facts are:I think stories encourage pretty good discussion. For example, why you should understand (a little) about TCPis a story about a time it was important for me to understand how TCP worked.When I share stories about problems I solved, the comments really help meunderstand how what I learned fits into a bigger context. For example:Also I think these kinds of stories are incredibly important – that postdescribes a bug that was VERY hard for me to solve, and the only reason I wasable to figure it out in the first place was that I read this blog post.Often in my blog posts I ask technical questions that I don’t know the answerto (or just mention “I don’t know X…”). This helps people focus theirreplies a little bit – an obvious comment to make is to provide an answer tothe question, or explain the thing I didn’t know!This is fun because it feels like a guaranteed way to get value out of people’scomments – people LOVE answering questions, and so they get to look smart, andI get the answer to a question I have! Everyone wins!I make a lot of mistakes in my blog posts, because I write about a lot ofthings that are on the edge of my knowledge. When people point out mistakes, Ioften edit the blog post to fix it.Usually I’ll stay near a computer for a few hours after I post a blog post sothat I can fix mistakes quickly as they come up.Some people are very careful to list every single error they made in their blogposts (“errata: the post previously said X which was wrong, I have corrected itto say Y”). Personally I make mistakes constantly and I don’t have time forthat so I just edit the post to fix the mistakes.A lot of the time when I post a blog post, people on Twitter/Mastodon willreply with various opinions they have about the thing. For example, someonerecently replied to a blog post about DNS saying that they love using zonefiles and dislike web interfaces for managing DNS records. That’s not anopinion I share, so I asked them why.They explained that there are some Dns Record Types (specifically TLSA) that they findoften aren’t supported in web interfaces. I didn’t know that people used TLSArecords, so I learned something! Cool!I’ve found that asking people to share their experiences (“I wanted to useX DNS record type and I couldn’t”) instead of their opinions (“DNS webadmin interfaces are bad”) leads to a lot of useful information anddiscussion. I’ve learned a lot from it over the years, and written a lot oftweets like “which DNS record types have you needed?” to try to extract moreinformation about people’s experiences.I try to model the same behaviour in my own work when I can – if I have anopinion, I’ll try to explain the experiences I’ve had with computers thatcaused me to have that opinion.I think internet strangers are more likely to reply in a weird way when theyhave no idea who you are or why you’re writing this thing. It’s easy to makeincorrect assumptions! So often I’ll mention a little context about why I’mwriting this particular blog post.For example:A little while ago I started using a Mac, and one of my biggest frustrationswith it is that often I need to run Linux-specific software.orI’ve started to run a few more servers recently (nginx playground, mess withdns, dns lookup), so I’ve been thinking about monitoring.orLast night, I needed to scan some documents for some bureaucratic reasons.I’d never used a scanner on Linux before and I was worried it would take hoursto figure out…There are some kinds of programming conversations that I find extremely boring(like “should people learn vim?” or “is Functional Programming better thanimperative programming?“). So I generally try to avoid writing blog posts thatI think will result in a conversation/comment thread that I find annoying orboring.For example, I wouldn’t write about my opinions about functional programming: Idon’t really have anything interesting to say about it and I think it wouldlead to a conversation that I’m not interested in having.I don’t always succeed at this of course (it’s impossible to predict whatpeople are going to want to comment about!), but I try to avoid the mostobvious flamebait triggers I’ve seen in the past.There are a bunch of “flamebait” triggers that can set people off on aconversation that I find boring: cryptocurrency, tailwind, DNSSEC/DoH, etc. SoI have a weird catalog in my head of things not to mention if I don’t want tostart the same discussion about that thing for the 50th time.Of course, if you think that conversations about functional programming areinteresting, you should write about functional programming and start theconversations you want to have!Also, it’s often possible to start an interesting conversation about a topicwhere the conversation is normally boring. For example I often see the sametalking points about IPv6 vs IPv4 over and over again, but I remember thecomments on Reasons for servers to support IPv6being pretty interesting. In general if I really care about a topic I’ll talkabout it anyway, but I don’t care about functional programming very much so Idon’t see the point of bringing it up.Another kind of “boring conversation” I try to avoid is suggestions of things Ihave already considered. Like when someone says “you should do X” but Ialready know I could have done X and chose not to because of A B C.So I often will add a short note like “I decided not to do X because of A BC” or “you can also do X” or “normally I would do X, here I didn’t because…”.For example, in this post about nix, I list a bunchof Nix features I’m choosing not to use (nix-shell, nix flakes, home manager)to avoid a bunch of helpful people telling me that I should use flakes.Listing the things I’m not doing is also helpful to readers – maybesomeone new to nix will discover nix flakes through that post and decide to usethem! Or maybe someone will learn that there are exceptions to when a certain“best practice” is appropriate.Recently on Mastodon I complained about some gross terminology that I’d just noticed in the dig man page. A few dudes in thereplies asked me to prove that the original author intended it to beoffensive (which of course is besides the point, there’s just no need to havea term widely understood to be referring to sexual assaultin the dig man page) or tried to explain to me whyit actually wasn’t a problem.So I blocked a few people and wrote a quick post:man so many dudes in the replies demanding that i prove that the person whonamed dig “domain information groper” intended it in an offensive way. Big dayfor the block button I guess :)I don’t do this too often, but I think it’s very important on social media tooccasionally set some rules about what kind of behaviour I won’t tolerate. Mygoal here is usually to drive away some of the assholes (they can unfollow me!)and try to create a more healthy space for everyone else to have a conversationabout computers in.Obviously this only works in situations (like Twitter/Mastodon) where I havethe ability to garden my following a little bit over time – I can’t do this onHN or Reddit or Lobsters or whatever and wouldn’t try.(you might notice that this section is breaking the “avoid boringconversations” rule above, this section was certain to start a very boringargument, but I felt it was important to talk about boundaries so I left it in)Sometimes people seem to want to get into arguments or make dismissivecomments. I don’t reply to them, even if they’re wrong. I dislike arguing onthe internet and I’m extremely bad at it, so it’s not a good use of my time.If I get a lot of negative comments that I didn’t expect, I try to see if I canget something useful out of it.For example, I wrote a toy DNS resolver once and some of the commenterswere upset that I didn’t handle parsing the DNS packet. At the time I thoughtthis was silly (I thought DNS parsing was really straightforward and that itwas obvious how to do it, who cares that I didn’t handle it?) but I realizedthat maybe the commenters didn’t think it was easy or obvious, and wanted toknow how to do it. Which makes sense! It’s not obvious at all if you haven’tdone it before!Those comments partly inspired implement DNS in a weekend, which focuses much moreheavily on the parsing aspects, and which I think is a much better explanationhow to write a DNS resolver. So ultimately those comments helped me a lot, evenif I found them annoying at the time.(I realize this section makes me sound like a Perfectly Logical Person who doesnot get upset by negative public criticism, I promise this is not at all thecase and I have 100000 feelings about everything that happens on the internetand get upset all the time. But I find that analyzing the criticism and tryingto take away something useful from it helps a bit)Thanks to Shae, Aditya, Brian, and Kamal for reading a draft of this.Some other similar posts I’ve written in the past: Behind "Hello World" on Linux You might also like the Recurse Center, my very favorite programming community (my posts about it)