2022-06-25 18:40:58 +00:00
|
|
|
|
---
|
|
|
|
|
title: Writing Coherently At Scale
|
2022-06-29 23:54:07 +00:00
|
|
|
|
date: 2022-06-29
|
2022-06-25 18:40:58 +00:00
|
|
|
|
tags:
|
|
|
|
|
- writing
|
2022-06-25 22:40:24 +00:00
|
|
|
|
vod:
|
|
|
|
|
youtube: https://youtu.be/pDOoqqu06-8
|
|
|
|
|
twitch: https://www.twitch.tv/videos/1513874389
|
2022-06-25 18:40:58 +00:00
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
As someone who does a lot of writing, I have been asked how to write about
|
|
|
|
|
things. I have been asked about it enough that I am documenting this here so you
|
|
|
|
|
can all understand my process. This is not a prescriptive system that you must
|
|
|
|
|
do in order to make Quality Content™️, this is what I do.
|
|
|
|
|
|
|
|
|
|
<xeblog-conv name="Cadey" mood="coffee">I honestly have no idea if this is a
|
|
|
|
|
"correct" way of doing things, but it seems to work well enough. Especially so
|
|
|
|
|
if you are reading this.</xeblog-conv>
|
|
|
|
|
|
|
|
|
|
<xeblog-hero file="great-wave-cyberpunk" prompt="the great wave off of kanagawa, cyberpunk, hanzi inscription"></xeblog-hero>
|
|
|
|
|
|
|
|
|
|
## The Planning Phase
|
|
|
|
|
|
|
|
|
|
To start out the process of writing about something, I usually like to start
|
|
|
|
|
with the end goal in mind. If I am writing about an event or technology thing,
|
|
|
|
|
I'll start out with a goal that looks something like this:
|
|
|
|
|
|
|
|
|
|
> Explain a split DNS setup and its advantages and weaknesses so that people can
|
|
|
|
|
> make more informed decisions about their technical setups.
|
|
|
|
|
|
|
|
|
|
It doesn't have to be very complicated or intricate. Most of the complexity
|
|
|
|
|
comes up naturally during the process of writing the intermediate steps. Think
|
|
|
|
|
about the end goal or what you want people to gain from reading the article.
|
|
|
|
|
|
|
|
|
|
I've also found it helps to think about the target audience and assumed skills
|
|
|
|
|
of the reader. I'll usually list out the kind of person that would benefit from
|
|
|
|
|
this the most and how it will help them. Here's an example:
|
|
|
|
|
|
|
|
|
|
> The reader is assumed to have some context about what DNS is and wants to help
|
|
|
|
|
> make their production environment more secure, but isn't totally clear on how
|
|
|
|
|
> it helps and what tradeoffs are made.
|
|
|
|
|
|
|
|
|
|
State what the reader is to you and how the post benefits them. Underthink it.
|
|
|
|
|
It's tempting to overthink this, but really don't. You can overthink the
|
|
|
|
|
explanations later.
|
|
|
|
|
|
|
|
|
|
### The Outline
|
|
|
|
|
|
|
|
|
|
Once I have an end goal and the target audience in mind, then I make an outline
|
|
|
|
|
of what I want the post to contain. This outline will have top level items for
|
|
|
|
|
generic parts of the article or major concepts/steps and then I will go in and
|
|
|
|
|
add more detail inside each top level item. Here is an example set of top level
|
|
|
|
|
items for that split DNS post:
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
- Introduction
|
|
|
|
|
- Define split DNS
|
|
|
|
|
- How split DNS is different
|
|
|
|
|
- Where you can use split DNS
|
|
|
|
|
- Advantages of split DNS
|
|
|
|
|
- Tradeoffs of split DNS
|
|
|
|
|
- Conclusion
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Each step should build on the last and help you reach towards the end goal.
|
|
|
|
|
|
|
|
|
|
After I write the top level outline, I start drilling down into more detail. As
|
|
|
|
|
I drill down into more detail about a thing, the bullet points get nested
|
|
|
|
|
deeper, but when topics change then I go down a line. Here's an example:
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
- Introduction
|
|
|
|
|
- What is DNS?
|
|
|
|
|
- Domain Name Service
|
|
|
|
|
- Maps names to IP addresses
|
|
|
|
|
- Sometimes it does other things, but we're not worrying about that today
|
|
|
|
|
- Distributed system
|
|
|
|
|
- Intended to have the same data everywhere in the world
|
|
|
|
|
- It can take time for records to be usable from everywhere
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Then I will go in and start filling in the bullet tree with links and references
|
|
|
|
|
to each major concept or other opinions that people have had about the topic.
|
|
|
|
|
For example:
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
- Introduction
|
|
|
|
|
- What is DNS?
|
|
|
|
|
- Domain Name Service
|
|
|
|
|
- https://datatracker.ietf.org/doc/html/rfc1035
|
|
|
|
|
- Maps names to IP addresses
|
|
|
|
|
- Sometimes it does other things, but we're not worrying about that today
|
|
|
|
|
- Distributed system
|
|
|
|
|
- Intended to have the same data everywhere in the world
|
|
|
|
|
- It can take time for records to be usable from everywhere
|
|
|
|
|
- https://jvns.ca/blog/2021/12/06/dns-doesn-t-propagate/
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
These help me write about the topic and give me links to add to the post so that
|
|
|
|
|
people can understand more if they want to. You should spend most of your time
|
|
|
|
|
writing the outline. The rest is really just restating the outline in sentences.
|
|
|
|
|
|
|
|
|
|
## Writing The Post
|
|
|
|
|
|
|
|
|
|
After each top level item is fleshed out enough, I usually pick somewhere to
|
|
|
|
|
start and add some space after a top level item. Then I just start writing. Each
|
|
|
|
|
top level item usually maps to a few paragraphs / a section of the post. I
|
|
|
|
|
usually like to have each section have its own little goal / context to it so
|
|
|
|
|
that readers start out from not understanding something and end up understanding
|
|
|
|
|
it better. Here's an example:
|
|
|
|
|
|
|
|
|
|
> If you have used a computer in the last few decades or so, you have probably
|
|
|
|
|
> used the Domain Name Service (DNS). DNS maps human-readable names (like
|
|
|
|
|
> `google.com`) to machine-readable IP addresses (like `182.48.247.12`). Because
|
|
|
|
|
> of this, DNS is one of the bedrock protocols of the modern internet and it
|
|
|
|
|
> usually is the cause of most failures in big companies.
|
|
|
|
|
>
|
|
|
|
|
> DNS is a globally distributed system without any authentication or way to
|
|
|
|
|
> ensure that only authorized parties can query IP addresses for specific domain
|
|
|
|
|
> names. As a consequence of this, this means that anyone can get the IP address
|
|
|
|
|
> of a given server if they have the DNS name for it. This also means that
|
|
|
|
|
> updating a DNS record can take a nontrivial amount of time to be visible from
|
|
|
|
|
> everywhere in the world.
|
|
|
|
|
>
|
|
|
|
|
> Instead of using public DNS records for internal services, you can set up a
|
|
|
|
|
> split DNS configuration so that you run an internal DNS server that has your
|
|
|
|
|
> internal service IP addresses obscured away from the public internet. This
|
|
|
|
|
> means that attackers can't get their hands on the IP addresses of your
|
|
|
|
|
> services so that they are harder to attack. In this article, I'm going to
|
|
|
|
|
> spell out how this works, the advantages of this setup, the tradeoffs made in
|
|
|
|
|
> the process and how you can implement something like this for yourself.
|
|
|
|
|
|
|
|
|
|
In the process of writing, I will find gaps in the outline and just fix it by
|
|
|
|
|
writing more words than the outline suggested. This is okay, and somewhat
|
|
|
|
|
normal. Go with the flow.
|
|
|
|
|
|
|
|
|
|
I expand each major thing into its component paragraphs and will break things up
|
|
|
|
|
into sections with markdown headers if there is a huge change in topics. Adding
|
|
|
|
|
section breaks can also help people stay engaged with the post. Giant walls of
|
|
|
|
|
text are hard to read and can make people lose focus easily.
|
|
|
|
|
|
|
|
|
|
Another trick I use to avoid my posts being giant walls of text is what I call
|
|
|
|
|
"conversation snippets". These look like this:
|
|
|
|
|
|
|
|
|
|
<xeblog-conv name="Mara" mood="hacker">These are words and I am saying
|
|
|
|
|
them!</xeblog-conv>
|
|
|
|
|
|
|
|
|
|
I use them for both creating [Socratic
|
|
|
|
|
dialogue](https://en.wikipedia.org/wiki/Socratic_dialogue) and to add prose
|
|
|
|
|
flair to my writing. I am more of a prose writer [by
|
|
|
|
|
nature](https://xeiaso.net/blog/the-oasis), and I find that this mix allows me
|
|
|
|
|
to keep both technical and artistic writing up to snuff.
|
|
|
|
|
|
|
|
|
|
<xeblog-conv name="Cadey" mood="enby">Amusingly, I get asked if the characters
|
|
|
|
|
in my blog are separate people all giving their input into things. They are
|
|
|
|
|
characters, nothing more. If you ever got an impression otherwise, then I have
|
|
|
|
|
done my job as a writer _incredibly well_.</xeblog-conv>
|
|
|
|
|
|
|
|
|
|
Just flesh things out and progressively delete parts of the outline as you go.
|
|
|
|
|
It gets easier.
|
|
|
|
|
|
|
|
|
|
### Writing The Conclusion
|
|
|
|
|
|
|
|
|
|
I have to admit, I really suck at writing conclusions. They are annoying for me
|
|
|
|
|
to write because I usually don't know what to put there. Sometimes I won't even
|
|
|
|
|
write a conclusion at all and just end the article there. This doesn't always
|
|
|
|
|
work though.
|
|
|
|
|
|
|
|
|
|
A lot of the time when I am describing how to do things I will end the article
|
|
|
|
|
with a "call to action". This is a few sentences that encourages the reader to
|
|
|
|
|
try the thing that I've been writing about out for themselves. If I was turning
|
|
|
|
|
that split DNS article from earlier into a full article, the conclusion
|
|
|
|
|
could look something like this:
|
|
|
|
|
|
|
|
|
|
> ---
|
|
|
|
|
>
|
|
|
|
|
> If you want an easy way to try out a split DNS configuration, install
|
|
|
|
|
> [Tailscale](https://tailscale.com/) on a couple virtual machines and enable
|
|
|
|
|
> [MagicDNS](https://tailscale.com/kb/1081/magicdns/). This will set up a split
|
|
|
|
|
> DNS configuration with a domain that won't resolve globally, such as
|
|
|
|
|
> `hostname.example.com.beta.tailscale.net`, or just `hostname` for short.
|
|
|
|
|
>
|
|
|
|
|
> I use this in my own infrastructure constantly. It has gotten to the point
|
|
|
|
|
> where I regularly forget that Tailscale is involved at all, and become
|
|
|
|
|
> surprised when I can't just access machines by name.
|
|
|
|
|
>
|
|
|
|
|
> A split DNS setup isn't a security feature (if anything, it's more of an
|
|
|
|
|
> obscurity feature), but you can use it to help administrate your systems by
|
|
|
|
|
> making your life easier. You can update records on your own schedule and you
|
|
|
|
|
> don't have to worry about outside attackers getting the IP addresses of your
|
|
|
|
|
> services.
|
|
|
|
|
|
|
|
|
|
I don't like giving the conclusion a heading, so I'll usually use a [horizontal
|
|
|
|
|
rule (`---` or `<hr
|
|
|
|
|
/>`)](https://www.coffeecup.com/help/articles/what-is-a-horizontal-rule/) to
|
|
|
|
|
break it off.
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
This is how I write about things. Do you have a topic in mind that you have
|
|
|
|
|
wanted to write about for a while? Try this system out! If you get something
|
|
|
|
|
that you like and want feedback on how to make it shine, email me at
|
|
|
|
|
`iwroteanarticle at xeserv dot us` with either a link to it or the draft
|
|
|
|
|
somehow. I'll be sure to read it and reply back with both what I liked and some
|
|
|
|
|
advice on how to make it even better.
|