选题[tech]: 20230605 Some blogging myths

sources/tech/20230605 Some blogging myths.md
This commit is contained in:
DarkSun 2023-06-06 05:03:34 +08:00
parent dd113f8b67
commit cd2e7acebb

View File

@ -0,0 +1,182 @@
[#]: subject: "Some blogging myths"
[#]: via: "https://jvns.ca/blog/2023/06/05/some-blogging-myths/"
[#]: author: "Julia Evans https://jvns.ca/"
[#]: collector: "lujun9972"
[#]: translator: " "
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
Some blogging myths
======
A few years ago I gave a short talk ([slides][1]) about myths that discourage people from blogging. I was chatting with a friend about blogging the other day and it made me want to write up that talk as a blog post.
here are the myths:
* [myth: you need to be original][2]
* [myth: you need to be an expert][3]
* [myth: posts need to be 100% correct][4]
* [myth: writing boring posts is bad][5]
* [myth: you need to explain every concept][6]
* [myth: page views matter][7]
* [myth: more material is always better][8]
### myth: you need to be original
This is probably the one I hear the most often “Someone has written about this before! Whos going to care about what I have to say?“.
The main way I think about this personally is:
1. identify something I personally have found confusing or interesting
2. write about it
The idea is that if I found it confusing, lots of other people probably did too, even though the information might theoretically be out there on the internet somewhere. Just because there is information on the internet, it doesnt get magically teleported into peoples brains!
I sometimes store up things that I find confusing for many months or years for example right now Im confused about some specific details of how Docker networking works on Mac, but I havent figured it out enough to be able to write about it. If I ever figure it out to my satisfaction Ill probably write a blog post.
Sometimes when I write a blog post, someone will link me to a great existing explanation of the thing that I hadnt seen. I try to think of this as a good thing it means that I get a new resource that I couldnt find, and maybe other people find out about it too. Often Ill update the blog post to link to it.
A couple of other notes about this one:
* technology changes, and the details matter. Maybe the exact details about how to do something have changed in the last 5 years, and there isnt much written about the situation in 2023!
* personal stories are really valuable. For example I love my friend Mikkels [Git is my buddy][9] post about how he uses Git. Its not the same way that I use it, and I like seeing his approach.
### a bit more about my love for personal stories
I think the reason I keep writing these blog posts encouraging people to blog is that I _love_ reading peoples personal stories about how they do stuff with computers, and I want more of them. For example, I started using a Mac recently, and Ive been very annoyed by the lack of tracing tools like strace.
So I would love to read a story about how someone is using tracing tools to debug on their Mac in 2023! I found [one from 2016][10], but I think the situation with system integrity protection has changed since then and the instructions dont work for me.
Thats just one example, but there are a million other things on computers that I do not know how to do, where I would love to read 1 persons story of exactly how they did it in 2023.
### myth: you need to be an expert
The second myth is that you need to be an expert in the thing youre writing about. If youve been reading this blog, you probably know that Ive written a lot of “hey, I just learned this!” posts over the years, where I:
1. Learn an interesting thing (“hey, I didnt know how gdb works, thats cool!”)
2. Write a short blog post about what I learned ([how does gdb work?][11])
You actually just need to know 1-2 interesting things that the reader doesnt. And if you just learned the thing yesterday, its certain that lots of other people dont know it either.
### myth: posts need to be 100% correct
I try to my make my posts _mostly_ correct, and Ive gotten a bit better at that over time.
My main strategy here is to just add qualifiers like “My understanding is..” or “I think..” before statements that Im not totally sure of. This saves a lot of time fact checking statements that Im honestly not sure how to fact check most of the time.
Some examples of “I think…s” from my past blog posts:
> I think people are replacing “how many golf balls can fit in the Empire State Building” with more concrete [interview] questions about estimating program runtime and space requirements.
>
> I think the most important thing with bridges is to set up the route tables correctly. So far my understanding is that there are 2 route table entries you need to set: …
>
> Etsy uses PHP, which I think means they cant have long-lived persistent TCP connections
>
> I think the MTU on my local network is 1500 bytes.
I still dont know if all of those statements are true (is it true that PHP programs cant have long-lived persistent TCP connections? maybe not!), so the qualifiers are useful. I dont really know anything about PHP so I dont have much interest in fact checking that PHP statement Im happy to leave it as an “I think” and potentially correct later it if someone tells me its wrong.
I do tend to overdo the “I think that…” statements a bit (bad habit!) and sometimes I need to edit them out when actually its something Im 100% sure of.
### myth: writing boring posts is bad
The reality of publishing things on the internet is that interesting things get boosted, and boring things get ignored. So people are basically guaranteed to think your posts are much more interesting that they actually are, because theyre more likely to see your interesting posts.
Also its hard to guess in advance what people will think is interesting, so I try to not worry too much about predicting that in advance. I really Darius Kazemis [How I Won The Lottery][12] talk on this topic about how putting things on the internet is like buying lots of lottery tickets, and the best way to “win” is to make a lot of stuff.
### myth: you need to explain every concept
Its common for people writing advanced posts (like “how malloc works”) to try to include very basic definitions for beginners.
The problem is that you end up writing something that feels like it wasnt written for **anyone** : beginners will get confused (its very hard to bring someone from “I have no idea what memory allocation is” to “in depth notes about the internals of malloc” in a single blog post), and more advanced readers will be bored and put off by the overly basic explanations.
I found that the easiest way to start was to **pick one person and write for them**.
You can pick a friend, a coworker, or just a past version of yourself. Writing for just 1 person might feel insufficiently general (“what about all the other people??“) but writing thats easy to understand for 1 person (other than you!) has a good chance of being easy to understand for many other people as well.
### writing has gotten harder as I get more experienced
Someone who read this mentioned that they feel like writing has gotten harder as they get more experienced, and I feel the same way.
I think this is because the gap between me and who Im writing for has gotten a bigger over time, and so it gets a little harder for me to relate to people who know less about the topic. I think on the balance having more experience makes my writing better (I have more perspective!), but it feels harder.
I dont have any advice to give about this right now. I just want to acknowledge that its hard because someone who read a draft of this mentioned it.
### myth: page views matter
Ive looked at page view analytics a lot in my life, and Ive never really gotten anything out of it. Comments like this one mean a lot more to me:
> Hey, @b0rk. Just wanted to let you know that [this post][13] really helped me to improve my skill of understanding a complex concept. Thanks! :)
If it helps one person, I figure Ive won. And probably it helped 10 other people who didnt say anything too!
### myth: more material is always better
I appreciate the work that goes into extremely deep dive blog posts, but honestly theyre not really my thing. Id rather read something short, learn a couple of new things, and move on.
So thats how I approach writing as well. Ill share a couple of interesting things and then leave anything extra for another post. For me this works well because short posts take less time to write.
This one is obviously a personal preference: short posts arent “better” either, I just like them more.
But I often see people get tripped up by wanting to include EVERYTHING in their blog post and then never publishing anything and I think its worth considering just making the post shorter and publishing it.
### some notes on pedantic/annoying comments
Someone who read a draft of this mentioned struggling with comments that are pedantic or annoying or mean or argumentative. That ones definitely not a myth, Ive read a lot of comments like that about my work. (as well as a lot more comments where people are being constructive, but those ones arent the problem)
A few notes on how I deal with it:
* The “dont read the comments” advice has never worked for me, for better or for worse. I read all of them.
* I dont reply to them. Even if theyre [wrong][14]. I dislike arguing on the internet and Im extremely bad at it, so its not a good use of my time.
* Sometimes I can learn something new from the comment, and I try to take that as a win, even if the thing is kind of minor or the comment is phrased in a way that I find annoying.
* Sometimes Ill update the post to fix mistakes.
* Ive sometimes found it helpful to reinterpret people being mad as people being confused or curious. I wrote a [toy DNS resolver][15] once and some of the commenters were upset that I didnt handle parsing the DNS packet. At the time I thought this was silly (I thought DNS parsing was really straightforward and that it was obvious how to do it) but I realized that maybe the commenters didnt think it was easy or obvious, and wanted to know how do it. Which makes sense! Its not obvious! Those comments partly inspired [implement DNS in a weekend][16], which focuses much more heavily on the parsing aspects.
As with everything I dont think this is the “best” way to deal with pedantic/annoying comments, its just what I do.
### thats all for now!
Probably Ill write another meta post about blogging in a couple of years since apparently thats what I do :)
Thanks to Ed, Jeff, Brian, Hazem, Zachary, and Miccah for reading a draft of this
--------------------------------------------------------------------------------
via: https://jvns.ca/blog/2023/06/05/some-blogging-myths/
作者:[Julia Evans][a]
选题:[lujun9972][b]
译者:[译者ID](https://github.com/译者ID)
校对:[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://jvns.ca/
[b]: https://github.com/lujun9972
[1]: https://jvns.ca/blog/2020/12/10/day-24--a-short-talk-about-blogging-myths/
[2]: tmp.Qqrv69sbMf#myth-you-need-to-be-original
[3]: tmp.Qqrv69sbMf#myth-you-need-to-be-an-expert
[4]: tmp.Qqrv69sbMf#myth-posts-need-to-be-100-correct
[5]: tmp.Qqrv69sbMf#myth-writing-boring-posts-is-bad
[6]: tmp.Qqrv69sbMf#myth-you-need-to-explain-every-concept
[7]: tmp.Qqrv69sbMf#myth-page-views-matter
[8]: tmp.Qqrv69sbMf#myth-more-material-is-always-better
[9]: https://mikkel.ca/blog/git-is-my-buddy-effective-solo-developer/
[10]: https://bryce.is/writing/code/2016/07/30/debugging-using-system-calls.html
[11]: https://jvns.ca/blog/2016/08/10/how-does-gdb-work/
[12]: https://www.youtube.com/watch?v=l_F9jxsfGCw
[13]: https://jvns.ca/blog/2018/09/01/learning-skills-you-can-practice/
[14]: https://xkcd.com/386/
[15]: https://jvns.ca/blog/2022/02/01/a-dns-resolver-in-80-lines-of-go/
[16]: https://implement-dns.wizardzines.com/