How to Give Your Postgres Blog Posts: An Outsize Impact
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Title of Series | ||
Number of Parts | 542 | |
Author | ||
License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/61926 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
FOSDEM 2023409 / 542
2
5
10
14
15
16
22
24
27
29
31
36
43
48
56
63
74
78
83
87
89
95
96
99
104
106
107
117
119
121
122
125
126
128
130
132
134
135
136
141
143
146
148
152
155
157
159
161
165
166
168
170
173
176
180
181
185
191
194
196
197
198
199
206
207
209
210
211
212
216
219
220
227
228
229
231
232
233
236
250
252
256
258
260
263
264
267
271
273
275
276
278
282
286
292
293
298
299
300
302
312
316
321
322
324
339
341
342
343
344
351
352
354
355
356
357
359
369
370
372
373
376
378
379
380
382
383
387
390
394
395
401
405
406
410
411
413
415
416
421
426
430
437
438
440
441
443
444
445
446
448
449
450
451
458
464
468
472
475
476
479
481
493
494
498
499
502
509
513
516
517
520
522
524
525
531
534
535
537
538
541
00:00
Core dumpRange (statistics)Multiplication signBlogComputer virusPoint (geometry)InformationFreezingDiagramComputer animation
01:42
Group actionProduct (business)Software developerKernel (computing)Storage area networkBitData management
02:47
Extension (kinesiology)DatabaseSource codeSoftware repositoryExtension (kinesiology)Open sourceDatabaseNumberValidity (statistics)Right angleContent (media)Open setBlogComputer animation
03:46
Cycle (graph theory)Cycle (graph theory)Frame problemBitDistribution (mathematics)Blog2 (number)Content (media)Coefficient of determinationComputer animation
04:34
Gamma functionBlogComputer animation
05:29
1 (number)Data conversionDatabaseBlogEmailInternetworkingMultiplication signBuffer overflowStack (abstract data type)Computer animation
06:41
Source codeFrame problemOvalComputer animation
07:24
BlogLink (knot theory)Keyboard shortcutSimilarity (geometry)Moment (mathematics)
08:15
Pole (complex analysis)Inclusion mapVirtual machineGradientSource codePort scannerACIDLink (knot theory)Latent heatComputer fontBlogTable (information)MereologySheaf (mathematics)Moment (mathematics)InternetworkingPopulation densityBenchmark
10:23
Sheaf (mathematics)EmailVacuumCheat <Computerspiel>Sheaf (mathematics)2 (number)Connected spaceCartesian coordinate systemBlogLatent heatComputer animation
11:30
InformationProcess (computing)File formatCodeBlock (periodic table)BlogType theoryDiagramInformationVariety (linguistics)DiagramDifferent (Kate Ryan album)Multiplication signTouchscreenCodeBlock (periodic table)File formatPoint cloudBlogWordProcess (computing)Table (information)
12:39
TouchscreenSource codeGradientComplex (psychology)WritingDatabaseVacuumBlogBlogResultantGradientQuicksortInclusion mapData conversionDivisorMereologyProcess (computing)Computing platformSearch engine (computing)EmailLevel (video gaming)AuthorizationAreaCuboidFile formatWritingTouchscreenSoftware developerInstance (computer science)DiagramMobile appMultiplication signDifferent (Kate Ryan album)WordSheaf (mathematics)Hand fanFormal languageFormal grammarComputer animation
17:28
Sheaf (mathematics)Computer fontTable (information)Variety (linguistics)File formatGradientWritingBlock (periodic table)CodeTouchscreenSheaf (mathematics)Hand fanChecklistField (computer science)Variety (linguistics)File formatCycle (graph theory)Frame problemMass
18:10
Frame problemHill differential equationRewritingBlogIterationBlogLine (geometry)Expert systemIterationCycle (graph theory)Hand fanTwitterWritingMereologyProgram flowchartComputer animation
19:46
FeedbackFocus (optics)FlagCycle (graph theory)FlagFeedbackMedical imagingDiagramResultantGoodness of fitBlogRight angleMereologyFocus (optics)Keyboard shortcutInheritance (object-oriented programming)AreaWritingSound effectLatent heatRow (database)Multiplication signComputer animation
23:18
WritingWritingGreatest elementBlogSheaf (mathematics)NumberProcess (computing)Right angleNoise (electronics)Hand fanMereologySoftwareComputer animation
25:12
BlogOverhead (computing)ScalabilityLimit (category theory)AnalogyHacker (term)Different (Kate Ryan album)Cycle (graph theory)Web pageGradientInformationBlogAnalogyHeegaard splittingScalabilityEndliche ModelltheorieLevel (video gaming)Connected spaceMultiplication signComputer animation
26:53
Expert systemDivisorBlogError messageSearch engine (computing)Data conversionResultantMathematical optimizationAttribute grammarGoodness of fitWeb pageReading (process)Expert systemMultiplication signNumberComputer animation
29:22
GoogolTerm (mathematics)Computer configurationDatabaseWeb pageSearch engine (computing)Distribution (mathematics)Scale (map)Table (information)Interrupt <Informatik>Extension (kinesiology)Point (geometry)Term (mathematics)BlogNoise (electronics)WordWeb browserMultiplication signResultantConnected spaceRight angleLine (geometry)Table (information)Concurrency (computer science)Open sourceInterrupt <Informatik>Computer animation
31:37
Term (mathematics)Uniform resource locatorHyperlinkExpert systemWritingChecklistDatabaseDescriptive statisticsField (computer science)BlogWebsiteAuthorizationTrailWordElectronic mailing listBitCore dumpLink (knot theory)HyperlinkGeneric programmingSearch engine (computing)Computer animation
34:10
Term (mathematics)Uniform resource locatorHyperlinkIterationFeedbackFocus (optics)Distribution (mathematics)Content (media)Slide ruleContent (media)Cycle (graph theory)DivisorBlogComputer animation
35:06
Content (media)TwitterUniform resource locatorMultiplication signComputing platformDistribution (mathematics)Focus (optics)BlogMeta elementTwitterTerm (mathematics)2 (number)Uniform resource locatorShared memoryDifferent (Kate Ryan album)
36:25
BlogInternet forumWebsiteTwitterLinker (computing)Hacker (term)NewsletterLink (knot theory)Software repositoryTime zoneDifferent (Kate Ryan album)Time zonePlug-in (computing)BitTwitterSlide ruleBlogDifferent (Kate Ryan album)Inheritance (object-oriented programming)Profil (magazine)Greatest elementMultiplication signLine (geometry)Computing platformRight angleStatisticsRobotNumberComputer animation
38:39
Time zoneFrequencyWordMultiplication signDifferent (Kate Ryan album)MultiplicationBoss CorporationVideoconferencingComputer animation
39:27
MomentumTwitterDistribution (mathematics)Scale (map)Heegaard splittingInterrupt <Informatik>LogicReplication (computing)Source codeQuery languageMereologyoutputSoftware developerEnterprise architectureChecklistBlogExpert systemChecklistBlogMomentumTwitterDatabaseInternet forumCase moddingShared memoryMereologyNumberWordComputer animation
41:50
FeedbackTrailBroadcast programmingWeb pageLink (knot theory)Greatest elementMultiplication signSlide ruleFeedbackNumberScheduling (computing)Inheritance (object-oriented programming)Link (knot theory)Online helpFood energyComputer animation
42:55
Lemma (mathematics)InformationDatabaseCodeHacker (term)TwitterBitExpert systemMereologyProcess (computing)FeedbackAddress spaceSlide ruleMultiplication signGaussian elimination1 (number)Uniqueness quantificationField (computer science)BuildingPoint (geometry)View (database)Line (geometry)File formatThermal conductivityElectronic program guideMoment (mathematics)Hand fanSpacetimeNoise (electronics)BlogComputing platformSoftware repositoryShared memoryLink (knot theory)Open sourceComputer animation
50:05
Program flowchart
Transcript: English(auto-generated)
00:13
Hello. Oh, that works. Cool. So, welcome to the PostgreSQL Dev Room. If you just got here, you missed all the early morning excitement.
00:23
These guys know. Can I please ask you, because this is a very loud room, take care with the seats, because they're very loud, and please silence your phones. Now, can we please welcome Claire Giordano, who's going to speak about Postgres blog posts and how to give them an outsize impact.
00:52
I have to get my phone so that I can take a selfie at some point in this talk. All right, so how many of you, is it your first day of Fozdom or your second?
01:02
How many of you are here for your first day of Fozdom? Okay, most of you were here yesterday? Yeah, and I love that it's not freezing cold this year. It's actually comfortable. All right, well, I thank you for coming. This is my third Fozdom, my second time giving a talk here in the Postgres Dev Room.
01:23
Boris, I promise to stay in the proper range now, okay? Am I good? All right, so I'm here to talk to you about how to give your Postgres blog posts an outsize impact. And I'm really happy to talk about it because sharing information about Postgres and our projects, new features, new capabilities,
01:48
is just super important to growing the community and having more people learn about it, use it, become developers on it. So before I dive in a bit about my background, I started my career as an engineer in the developer tools group at Sun Microsystems.
02:05
I worked on a predecessor to a predecessor to modern day GitHub and Git, and then I spent many years as an engineering manager in the kernel group at Sun. Before moving into product management, product marketing roles, I think of myself as a writer. That's why I care about blogging.
02:24
And about six years ago, I joined a small startup in San Francisco. Well, not so small, but a startup nonetheless called Citus Data. Have any of you heard of Citus? Okay, so some of you didn't raise your hands, but I know you've heard of Citus.
02:41
And then after a couple years, we were acquired by Microsoft. So I work at Microsoft, and this is a screenshot of the GitHub repo for the Citus database extension, which is an open source extension that I spend most of my days working on. And I put the screenshot there with the stars over on the right because I'm on a mission to make sure people who know it, use
03:06
it, like it, are supporters of it, actually do go and give it a star so I can bump that number up and get some validation. So the reason I created this talk is I ran across this quote somewhere where somebody said about Postgres that it's not just open source, it's open engineering.
03:25
And I'm looking at Joe Conway. Did that quote come from you? Or was it Peter Eisentrout? I'm not sure who it was, but it's a fabulous quote. And so I thought about, well, why not share the techniques and the best practices that we use, not just in engineering, but in engineering the blog posts and the content that we create.
03:46
Now, before I dive in, I have to give you a warning. There's a lot of dog illustrations in this talk, and that's because I'm here in Brussels and back home in California is my chocolate Labrador named Zuka. So I don't know, I had to inspire myself to think of her as I was working on it.
04:00
Now, the talk is going to have two parts. The first is what you write, the actual kind of drafting of the blog post, and the second is where you send it, who you send it to. And in marketing speak, that means we're going to talk about content, and then we're going to talk about distribution. Now let's dive into content first. And in this area, I want to start with you in your frame of mind when you're creating these blog posts.
04:28
And then we'll talk a bit about the edit cycle after that, which is also super important. And I think my first tip for you when you're creating a blog is to write with a specific reader in mind.
04:42
Now, and think of, who's this person that you want to read it? What kind of skills do they have? What kind of problems? See, those are those that, sorry, the seats are really loud in here, aren't they? Yeah, welcome. I'm glad you're here. Who do you want to read it? What are their skills? What are their interests? And write to that individual.
05:02
This may seem obvious, but for a lot of us, when we try to write to this vague, big, amorphous world out there, the blog post kind of ends up like hotel food. And I mean bad, boring hotel food, where it's trying to appeal to everybody and doesn't dare have any strong flavors or strong spices and ends up being very bland.
05:25
So write to that specific person as you're creating it. And then the second tip is also obvious. Pick good topics. But I put it up there because in many, well, there have been many conversations I've had with people where they've said, you know, I want to start blogging, I want to start sharing my expertise, but I don't know what to write about.
05:46
And so I just want to tell you that the world, the Internet is full of inspiration of what to write about. And every time you send an internal email answering a question or somebody comes, if you're working in an office or with a team of people in person, someone comes in and asks you a question.
06:05
Maybe your answer is good fodder for a post. Maybe more than that person has that question and it should be shared more broadly. So whether it's Stack Overflow as well or the Postgres Slack, the IRC channel, Reddit,
06:22
there's a lot of there's different subreddits. There's one for Postgres, but there's other ones that deal with databases and distributed systems as well. There's questions that come up there that might make a good blog topic, too. And then just make sure those blogs are interesting, like that, again, not bland, not boring.
06:42
OK. And the third tip, when you think about your frame of mind, is to have empathy for your reader. That's probably the most important takeaway from this talk is to have empathy. And so what does empathy mean? It does not mean sympathy. I love this cartoon from Hugh McLeod of Gaping Void.
07:01
And on the left, he describes empathy as I feel your pain. I physically feel how you feel. I really understand and have empathy for your situation. Whereas sympathy is just, oh, I'm sorry that you're in pain, which is kind of just words.
07:20
It doesn't have the same impact. So the goal is to have empathy be your true north. And that means you're going to care about the reader more than you care about yourself. It means you're going to put in some extra effort in creating the blog post and recognize that they're busy. They're in a hurry. So you should write and create this post so that it's easy for them to quickly get answers to their questions.
07:45
And just remember that they don't know what you know. So when you work with a team of people who have similar knowledge, expertise and skills, we use a lot of shortcuts. Like we use acronyms and we don't have to define or explain concepts. We all understand.
08:00
Anybody who works with CITUS understands what sharding is, for example. But the reader doesn't necessarily know what you know. So taking a few moments to define a term or explain a concept or link to a background blog is super helpful to them. All right. So let's dive into specific tactics that you can use to apply empathy and really care about your readers.
08:24
And the first is to make your blog posts scannable. I grabbed these two big, chunky, dense paragraphs from the Internet as an example of what you should not do. I can't even bring myself to read them. They're in my talk and I've not read those paragraphs because it's just blah, blah, blah.
08:43
My brain cannot embrace whatever they're trying to tell me. So because people are in a hurry, you've got to make it easy for them to find the part of the post that will help them. And one mistake a lot of people make is they – it's okay. It's totally okay.
09:03
They assume someone's going to read the whole post from the beginning to the end, but they're not. They're going to jump around. Maybe they'll start in the middle. And so when I think about how to make things scannable, there's a bunch of techniques that I just wanted to point out that are super useful.
09:20
The first is to have section headlines that break up the post, H2s, if you will. But they should not be subject titles, and we'll talk about that in a moment. They should actually be headlines, like headlines you'd see in a newspaper. Use bullets. Bullets are fabulous for scanning. If the bullets are multi-line bullets, put a bold font prefix at the beginning
09:41
of each one, just like two, three words, that tells them what that bullet is about. And then most people will just read those bold font prefixes, and they may not read the rest of it if it's not what they're looking for. Short sentences and short paragraphs are your friend. Whitespace is also a big friend. And then tables are super helpful too.
10:02
I was reviewing a blog post with someone once, and they were sharing just three or four pieces of performance benchmark data, but they were doing it in sentences, like in the copy. And when we took those numbers out and we put them in a super small two-by -three table, all of a sudden the conclusion just popped, whereas before it was hidden in the paragraphs.
10:24
So I said we'd talk about the section headlines, the H2s, a few seconds ago. So here's a couple examples. And these are actual examples from actual blogs that I worked on with people. And in this first example, literally the H2 said example, which is nice.
10:42
It tells you, okay, we're going to look at something that will help show me what we're talking about. But in fact, it's much better if it were to say a real world example, a multi-tenant to-do application. It gives more specifics about what's going to be in that section. Similarly, I was working on a blog post with, I don't even remember who it was with.
11:03
And the H2 just said PG bouncer, which is great. It tells you that section is about PG bouncer. That's useful. But it's even more useful if we tell you in the H2 that this is about how to set up PG bouncer. And oh, by the way, it's our preferred connection pooler. So just being more specific can help the reader.
11:23
And it primes their brain as to what they're going to get or tells them whether to even read that section. Now, not everybody is a reader. So I already said people aren't going to read the whole thing. They're going to bounce around. But people's brains process information differently.
11:41
So how many of you think of yourselves as being visual in how you process information? Okay, and how many of you, when you're explaining something to a colleague, the first thing you do is jump up to a white board and start sketching diagrams? Yeah, okay. So to make your blog post more accessible to more people, it shouldn't just be paragraphs and words and sentences.
12:05
But obviously a picture speaks a thousand words. So including a diagram in there and taking the time to figure out what should that diagram be can make a world of difference. I gave you the example of tables before. Those are super helpful when you're sharing numeric information.
12:22
For those of us who work on cloud services, sometimes having that screen shot of whatever is going on in the UI can be really helpful. And then code blocks as well. Particularly when you're talking about some new capability or trying to show someone how to use something, that code block is huge. So the variety of formats can help.
12:42
I took this screen shot, don't worry about it, from a blog post that David Rowley wrote last year about speeding up sort performance in Postgres 15. He's one of the Postgres contributors that works on my team at Microsoft. And without this chart, the blog post would have been nice, it would have been good,
13:03
but it was so much more powerful when you show visually what the results were and how sort performance was sped up. And when you do include diagrams or charts, it's important to remember to put alt text in there.
13:21
Not just because we care about people who are visually impaired and are using screen readers, but also it influences how your blog post will get ranked on search engines because alt text is one of the factors and things that the search engines look for. Using H2s as well can also help screen readers.
13:40
So don't just, when you have those section headlines we talked about earlier, don't just like put a bold font in and make it a bigger font size. Actually change the paragraph format to H2 or section header or whatever it's called in your platform. And that will help those screen readers too. The other thing I'll say about this chart is it looked totally different at first.
14:03
Like we iterated on it to try to figure out how do we make the story pop. We ended up pivoting it by 90 degrees, changing the title, changing how we label things, and doing our best to make it drop dead easy to understand. Alright, the third technique in the empathy area that I want to point out is readability.
14:27
And I always recommend to people that you write at the third or fifth grade level. Maybe sixth grade is okay. But a lot of us in engineering were trained to write in very formal, academic, dry tones of voice.
14:46
And even at the 16th grade level, at the 14th grade level. And that's hard for people to read, especially when they're in a hurry and trying to get something done. So if you simplify your writing, that can make a big difference. This is a screenshot of a tool that I use called the Hemingway app.
15:04
And if you go and you put copy from your blog post in there, it'll tell you what grade level it's written at. It will give you some specific suggestions about how you can simplify your writing. And that assumes you're writing in English. I don't know if it has support for other languages.
15:22
Other people are big fans of Grammarly and I'm glad you're here. So absolutely recommend this. The other aspect of readability that I want to point out, I always recommend people write in a conversational tone of voice. Again, going back to how we were taught to write, it was very formal, pedantic even, official, academic.
15:49
But actually when people are in a hurry, their brains are wired for conversation. So if you write in that easy, accessible, conversational tone of voice, you're going to have more people recommending your blog post.
16:01
You're going to have more people actually reading it versus just bouncing and leaving and deciding, oh, this is too much work. Or the worst is, I'll read this later, which of course most people don't ever do. So part of writing in a conversational tone of voice, like how do you do it? I always tell people to imagine that they're sitting over coffee and trying to
16:23
explain to another engineer or developer how this thing works or whatever the topic is. And maybe that person is their best friend and they're going for a job interview and they really need to understand. How are you going to explain it to them so that it makes sense, so that they get it? That's the kind of conversational tone of voice that you want to employ.
16:43
And then I also recommend people write in the second person you. And that's because your reader doesn't care about yourself. They don't care about the author. They care about themselves. So when you speak to you, when you write about you, and in the screenshot here I put little, I don't know if you can see them, oh yes you can,
17:04
the yellow boxes around all the instances of the word you. And a lot of times in the first draft the word you won't even show up. People will just say I, I, we, we, I'm doing this, this is all about me. Kind of like in the beginning of this talk when I introduced myself.
17:20
Probably a lot of you didn't care. You just wanted to get to the meat of the topic. So speak to you and write in that conversational tone of voice. So I'm a big fan of checklists. I don't know how many of you have read this wonderful book by Atul Gawande called The Checklist Manifesto. Anybody?
17:41
Oh, cool. Strong recommend. It's a really wonderful book and it talks about using checklists not just in his field, which is medicine and surgery, but also in other fields like airline pilots and people in charge of big massive like skyscraper construction projects. Anyway, so big fan of checklists.
18:01
So here's a checklist that summarizes the three things we just talked about regarding scannability, variety of formats and readability. All right. And now we're going to pivot away from you and your frame of mind and empathy and talk about the edit cycle. So I think the first thing I tell people who are starting off blogging or even
18:24
experts who are looking to get better is to just embrace the edit cycle and the iteration. You have to do the work. Now, I suppose that's not true for everybody. I do know some people who are kind of famous and they can write really crappy
18:41
blog posts and people are going to give it a plus one and and promote it. And they'll get a lot of traffic, even though it's not actually very helpful, it's not actually very good, but they're famous. And so they get that kind of benefit. But for most of us mere humans, we've got to do the work to make something usable by people.
19:01
I'm a fan of this writer named David Perel. And I grabbed this screenshot of a tweet that he did. And you don't really need to read the words, but the visual kind of tells the story that when you are creating a blog and probably the same is true for coding, you end up going down a lot of dead ends. And that's what all those gray lines are meant to represent.
19:23
There are things that you thought were going to be part of the blog, ways of explaining that you thought were going to be useful, but they weren't and you had to throw them away. And it's only in, and these are his words, good writing is only obvious in retrospect. And so that purple line could not have been found without all those gray dead ends.
19:44
And yeah, so you've got to edit. The other thing that is important is that it's okay for your first draft to suck. So especially with people who are creating blogs for the first time, they'll get a little bit stuck. Because they're not sure how to say it, and literally their hands are frozen over the keyboard.
20:05
And you just have to recognize that dirty little secret that everybody's first drafts suck. And that's okay. So once you give yourself permission to write something bad, then you're well on your way to having a good end result.
20:22
So the other quote people often use is, perfect is the enemy of the good. These images of these artists, though, are kind of interesting. Because when you think about artists, because their initial sketches are typically not shared with a team, they feel free.
20:40
They don't have anybody judging them. And they can go scribble and draw and experiment and create some really amazing things by exploring in ways that they wouldn't be able to do if they felt like they had an audience right there. So the technique that some people do is they just go, okay, I'm not going to share my first draft with anybody.
21:03
I'm going to wait until it's a second draft and it's a little more refined. And maybe that's what you have to tell yourself. I just write crappy first drafts and I'm not embarrassed by it. Because I know the end result is going to be really freaking good. All right. Feedback is a gift. So if you find good reviewers, they're gold and say thank you and have gratitude for it.
21:26
I've worked with some brilliant bloggers in my career who, if you ask them to review your post, you'll get, oh, yeah, it looks fine. It looks pretty good. You got some typo in the fourth paragraph. But other than that, it looks good. And that's generally not complete feedback.
21:42
And maybe they didn't even read the thing. So hopefully you can find people who will look at what's missing or who will give you specific actionable ideas for how you can improve it or flag the things that are confusing. Now, one of the things I do, particularly when I'm working with folks who are super crazy busy and
22:04
who I know are really carving out part of their weekend time or their evening time to give me feedback, is I will ask them to focus on something specific. So like if you're giving some important post out to three engineers, give them each a different part, a different assignment.
22:20
Hey, Joe, I want you to look at the conclusion and make sure I didn't miss anything. Bertrand, can you look at the diagrams in the middle and make sure that they're clear? I'm just calling you guys out because you're in the back row. So hello. So giving people those areas of focus can help. I don't know who to attribute this screenshot here, but I have used it with people and it's super effective.
22:45
I'll tell them to flag anything that's confusing, flag anything where their mind starts to wander, because when their mind wanders, then that means they're probably bored and I need to go cut or fix it or do something.
23:01
To flag maybe the 10% that they love that I better not throw away in my next edit cycle and then scribble any ideas for what might be missing. And people have loved that technique and have said thank you to me for making it easy for them to help me. Okay. Fifth tip in the edit cycle is just be willing to get your scissors out and to cut and to cut.
23:25
Have any of you ever, are any of you Stephen King fans? One, two, three, four, half, four and a half, okay. So Stephen King wrote, I'm actually not a big fan of his horror books, but over the years I've found some of his books that I absolutely love.
23:46
And the one I love the most is called On Writing. And we all know if you work in engineering and you work with software that a big part of your job is communicating, right. It is explaining things to other people. So if you've ever wanted to get better at writing, that is the book to read.
24:02
And it's part autobiographical and was written by, well he wrote it as he was recovering from an accident where he'd been hit by a car. But it's part about the craft of writing. And in it he has a quote that says, Kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler's heart.
24:24
Kill your darlings. And I just love that quote. A lot of people misquote it as kill your babies, which I think is rather grotesque. But the idea is you've got to be willing to throw stuff away. And if you can't bring yourself to throw stuff away and delete it, one of the things I do is I just put a section at the bottom of the document called the cutting room floor.
24:43
And I just move stuff down there. And then I somehow feel better about it. Like well I'll be able to go back and get it if I decide it really should be reinstated. That never happens. It never gets reinstated. But psychologically putting it in the cutting room floor for me is better than killing it.
25:01
But you've just got to be willing to cut. Otherwise people will get bored and they will leave your blog because it will be full of noise. And you won't have enough signal to noise in that ratio. All right. Number six. Forking your blog post into several shorter blogs. So Andres Freund, who some of you probably saw.
25:22
He was here at FOSDEM PG Day on Friday and he's probably around right now. No, he's probably on his way to the airport. I worked with him on some blog posts that he wrote over a year ago about connection scalability and postgres. And when he shared the first draft with me, it was really freaking long.
25:40
And I didn't even have to tell him that it was long. He started off with, yeah, maybe I should split this into two different posts. Well, he ended up splitting it into three different posts. And I think all three of them hit front page hacker news. And they all got a ton of traffic and they were all useful. And I would argue that having three shorter posts made the information more accessible to people.
26:04
People tend to have shorter amounts of time available to read or to learn. So this is a technique that can work wonders for you in the edit cycle is to cut things apart. And then just keeping it simple, which is really hard to do, especially when you're trying to explain a concept that's complicated.
26:23
But, you know, you can keep it simple in a lot of different ways. Like one of the things you can do is just move certain details into footnotes. So they're not fluttering your main points, but they're still there. You can also use analogies to help people understand a difficult concept. To make it easier for them to put that concept that's new to them in a mental model that they already have.
26:47
And then, of course, writing at that third or fifth grade level will help keep things simple as well. And then number eight, reading it out loud. So it's interesting. And this is true for many people.
27:02
When I read something silently in my head, if there's a mistake in it, my brain will self-correct it. And I won't even notice the mistake. I'll be oblivious to it. But if I read it out loud, I hear it immediately. It's like nails on a chalkboard. I hear it.
27:20
So reading out loud is a great way to find errors in what you've written. Or to find that it's confusing or long-winded. You almost run out of breath when you're reading it. You're like, oh, maybe I should simplify that or shorten it. It's also a good way to assess if you've written in that conversational tone of voice.
27:41
If, when you're reading it out loud, you're like, oh, I would never say that. Well, then it's time to get your red pen out and go fix it to make it more conversational. All right. So then the nice tip is to optimize for SEO. So most of you know SEO stands for search engine optimization.
28:00
And improving some basic SEO attributes of your post will make it more likely that your post will show up on that first page of search results. And you do not need to be an SEO expert at all. You just need a few very, very basic skills that you can learn today. And as long as you retain them, you're good to go.
28:21
But I have to tell you first that all these few basic SEO tips are not worth your time if you don't have good content, right? If it's not scannable, if it's not readable, if you haven't written in a conversational tone of voice, then the SEO stuff is not going to help you at all.
28:40
So starting with good content, there are a few things you can do. And the first is just to spend a few extra minutes, maybe 10 minutes, 15 minutes on the title. The title is what's going to cause people to click or not click if they discover or see your blog post somewhere in search results.
29:03
And also the keywords in the title are going to affect on what search results your blog is going to show up. Not just the keywords in the title. Obviously the search engines use a lot of factors. But it's very, very important.
29:20
So what I've found is I have to create at least 15 bad titles to come up with one good title. And it's interesting because a lot of times when people on my team will create blogs, they'll literally just create one title. And that's just the starting point. They think they're at the finish point, but it's just the starting point.
29:40
And then we riff from there to come up with other alternatives. So this is an example of a screenshot of 15 different titles that Marco Slott and I were experimenting with and fiddling with for some blog last October about the Citus 11.1 open source release. And it looks like noise.
30:02
I probably should have displayed these in categories, but there really is a method to the madness here. Like some of these titles use Postgres as well as Citus in the title for people who don't know the connection. It's an important connection. So maybe the title had to include both. We were fiddling with different ways to talk about like without blocking rights or without interruption or how are the other ways.
30:29
Using create distributed table concurrently. So using different terms to express the same concept. 15 minutes. I better talk faster, huh? Okay, I'll get going.
30:41
So the bottom line is don't be afraid to generate a whole bunch of titles and fiddle and experiment to try to come up with what the right answer is. Now there's three techniques for assessing once you have a list. The first is are the most important terms in the first 60 characters. So on a Google search results page, they will truncate the title after 60 characters.
31:00
So don't take the most important word and put it later in the title because then people are never going to see it and it's not going to cause them to click. Also just is it boring versus is it interesting and I'll often use incognito browser searches to figure out what other things are popping up already for those particular search keywords and terms.
31:26
And I definitely don't want to use a title that somebody else has already used. Like that would be a bad thing. So that's one reason to kind of compare to what's out there in the world. All right. And then a few more bullets here on the right-hand side of things to pay attention to.
31:43
I will often advise people to avoid general terms like solution. I can't stand that one. Like why say solution when you could just say database or Postgres or Citus. I really pay attention to pronouns like it and this. A lot of us like to be efficient in our writing and so using it makes things sound a little bit less repetitive and I get it.
32:06
But almost always that pronoun introduces an ambiguity because it could be referring to this noun or maybe to that noun. And for somebody who's in a hurry, it stops them dead in their tracks to try to figure out what you're referring to and they're not quite sure what you meant.
32:21
So that's another tip. And then I try to, when you create hyperlinks, like it's a really bad idea to ever use like the word here as the anchor text for a hyperlink. Or anything generic. You want the anchor text that has the underline under it that links to wherever you're
32:43
taking them off the site to have very specific and relevant keywords to wherever you're taking them. Not vague and general ones. And you'll, it's actually something that matters to the search engines. So those are some SEO tips but I'm going to move on as quickly as I can because there's more to talk about.
33:02
Alt text for graphics, I mentioned that earlier. And then Google actually also cares about this thing called EAT for author bios. And that stands for expertise, authoritativeness, and trustworthiness. And so, on your blog platform, wherever you publish, make sure that there's a bio description for you.
33:22
And it's always, it's nice to make it fun. In my case, I would say that I love Chocolate Labradors or I love Sailing in Greece. But it's even more important to show your expertise and your trustworthiness. You know, the examples, let's see, do I have two examples here? Yeah, so in Marco's case, the second one down, I showed that he has a PhD in distributed systems
33:44
and that he's the lead engineer on the Citus database team. And also like what conferences he's spoken at. Apparently the EAT team of reviewers care a lot about conference talks. That's one of the ways they decide somebody is credible in a field. For Thomas Monroe, who's another Postgres engineer on our team,
34:03
again, list what conferences that he spoke at and the fact that, you know, he's a core developer, et cetera, et cetera. Okay, so again, another checklist. I will be publishing my slides afterwards, so you'll be able to grab these if you find them useful.
34:20
And I think I've got all of the editing tips here, as well as the SEO tips. Cool? So now we're done with content. Both you as well as the edit cycle. And I want to talk for just a few minutes on distribution, which is kind of how do you publish. So first I want to ask a question, which is, somebody said this to me once,
34:41
we're going to know which blog posts are good by how much traffic they get. True? Show of hands? False. Show of hands. Okay, so it's false. Like, typically, how much traffic something gets is more a factor of how much was it shared, how much was it promoted.
35:02
Did you actually distribute it and get it out into the world? Distribution trumps content almost all of the time. So there's two aspects of distribution. The publishing platform itself, which you need to be smart about that, but we're not going to talk about that today.
35:20
We'll focus instead on how to promote your blog posts. So one pro tip I always share with people is before you, as soon as you publish, but before you start sharing it, before anybody starts sharing it, double check what I call the unfurl of that URL. That might be a Slack term, so I'm sure there's another term for it.
35:42
But basically, when you share your URL on different platforms, the HTML metadata will get displayed, right? The HTML title, the HTML description, as is here, title, description, as well as the OG image, right? Or the social graphic or the teaser graphic, different blog platforms call it different things.
36:00
And sometimes people have screwed up and they have the wrong graphic or they didn't fix their description, and then some of these social platforms cache the graphic in particular. So if you notice the mistake seconds after you tweet it out the first time, Twitter is going to cache that graphic for 24 to 48 hours, and you can fix it, but people are still going to see the wrong one.
36:22
So it's just worth double checking that before you start sharing. And then I always put a plug in for Planet Postgres. If your blog is about Postgres and it complies with all of the Planet Postgres policies, syndicating it there is a great way to get it into people's RSS feeds. And also you'll see on the right here that there's a Planet Postgres Twitter account,
36:45
and on Mastodon there's a Planet Postgres unofficial bot account too. And so then people follow that account on Mastodon or on Twitter, and it's another way to reach people. So that's a fabulous way to reach people. And the bottom line thing is just go to where your readers are.
37:02
And so what that means for me and our team is that we end up sharing our blog posts on pretty much all of these different social platforms, because there's no one social platform that everybody subscribes to. And did I add Mastodon to this list? Oh, I need to update this and add Mastodon.
37:22
I created this slide back in October. Things were a little bit different back then. But actually on most of these slides I have my Mastodon account is now listed. So Twitter is just the Claire Jordana bit, but I'm on hackyderm.io, which I probably mispronounced. Okay, another tip. Rinse, lather, repeat.
37:42
And that just means if you're going to share it, don't be afraid to share it a few times at different times a day. Like the Postgres audience is global, and something that you tweet in the morning in Europe is not going to reach people in California necessarily, unless they're super night elves, and vice versa.
38:02
So I know a bunch of engineers who are like, oh, I already tweeted it once. I don't want to pollute my profile with it more than once. But if you want to reach your friends, you're going to have to hit different time zones. And just keep in mind that statistically only one to two percent of your Twitter followers would see a given tweet.
38:22
I don't actually know what that statistic is on Mastodon. Yeah, Devrim, do you want me to go faster? No, no, I mean, you may define it as a cost thing or pay the cost thing. Yeah, the number may be lower now. Things are definitely changing in the Twitter world. An example of rinse, lather, repeat too.
38:43
Some of my colleagues, my boss actually, was interviewed on Azure Friday, which is this wonderful video show put on by Scott Hanselman, who I think is a fabulous human being. And the person in charge of the Azure Friday show tweeted about it multiple times,
39:00
but with different graphics each time and different words each time. And I actually think that's a good technique because the different graphics are bound to appeal to different people. I mean, I suppose it's not unlike Netflix having different graphics that they use to promote a movie, and something that appeals to Boris is not necessarily going to be what appeals to me.
39:23
So I bet we see different graphics for these various shows. All right, and you can keep your Twitter momentum by recycling tweets. The same is true on Mastodon as well. So just, you know, you can quote tweet on Twitter and not on Mastodon yet. Your mileage may vary, but it's super effective, and also having other people on the team share it.
39:46
So for example, let's see, I think Devroom took something that I tweeted recently, and then he quote tweeted it, and it reached a ton more people as a result. So just keep recycling it, and eventually you will hit more people.
40:02
On Reddit, it's super important to be there for the Q&A. Most of the moderators will say that one-way promotion is considered advertising. They don't like that, and then you can end up getting blocked by the mods explicitly or by the bots, you know, sometimes by mistake. But if you go in there and you make a comment and you say, hey, we're here to answer questions, let's discuss this,
40:25
and you facilitate a conversation, that's quite welcome. But then you have to be willing to participate. And there were a ton of questions on this particular topic when we open-sourced Citus last year, and so Yelte had a lot of work to do to get answers to those questions.
40:41
Five minutes left. Number seven is that Karma is a two-way street. So if you want your Postgres colleagues or people who work on the same team as you to help spread the word on some blog post that you've written, turn the table around and help them when they've got something new and that they're publishing and they're trying to get it out there.
41:07
And that's something that I think we all should do more of. The more we help amplify each other's work on Postgres and on Citus, the more people will discover what's going on, learn about it, become expert in it, and join the community.
41:24
Again, another set of tips. And here for promotion, your checklist, like your mileage, is going to vary. So I didn't give an explicit checklist because what you want to do is going to be different based on whatever part of the database you're working on. So you'll have to create your own promotion checklist, but hopefully these tips will be helpful.
41:43
And I put it all together here because the devil is in the details and there is a lot to do. And if there's one thing you're going to remember, conversational tone of voice, speak to you, make things scannable,
42:03
readable, simple, take the time to explain things, prioritize and care about your reader more than you care about yourself. There are a whole bunch of people who helped me and inspired me in writing this talk, so I had to throw that slide up there to thank them. And there is a feedback link for all of the talks here in the Postgres Dev Room.
42:24
So if you go into Phosdom.org 2023 schedule and you go to the Postgres Dev Room track, you can see all of our talks listed, and you can click on any one of them, and in the bottom left there's a submit feedback link. And I don't know how many of you generally give feedback on your Phosdom talks? Show of hands?
42:43
Okay. Let's try to increase that number this year because it's super helpful. People pour a lot of energy into creating these talks and organizing the Dev Room, and we would love to get your feedback. I put my addresses up there on Mastodon and on Twitter. If any of you want
43:00
to follow me, I will be posting a link to the slides on both of those accounts. And I put the Citus GitHub repo on there too, so that if it is something that you appreciate, you can be sure to drop it a star as well. And then I know that we need to move on to the next talk. I think I'm out of time, so I don't know. Do we have any time for questions?
43:22
Okay. So we have a few minutes for questions. I also wanted to say that I have some Postgres and some Citus database socks up here. I have 40 pairs. I also have a whole bunch of stickers of the Citus Elicorn open source mascot too. So feel free to come and get them afterwards and wear them in good health.
43:42
But first, questions? Any? So, great talk. So in tech, many folks have strong opinions about certain things to a point, like some people take religiously certain stuff.
44:08
And when you are in the edit cycle, would you eliminate such pieces of information that will cause a sparking reaction from such folks? Or would you let the disagreement ensue because knowing that disagreement is information.
44:22
So what should one do in such a certain situation when they want to like have such pieces of information in their blog post? I think that's a really good question. So where's the line between having an opinion on something, right? An opinion that might be unique in your own and being offensive perhaps to other groups or hurtful or overly critical.
44:43
And I kind of use the code of conduct as my guide. Like how far have I stepped from expressing my opinion into trashing somebody else's opinion? I think I fall back on that. Other questions? There's one behind you, Jimmy.
45:06
It's a small question, but what's the different tips you can say about presenting something in your team to your colleagues, whatever? It's not blogging something, but still it's a lot of things you mentioned here and etc. Maybe you have some tips as well to say?
45:26
I do, but there's no way I could answer that question succinctly in the time that we have. But I will say that a lot of these same tips about communicating in the format of a blog also make a lot of sense in the format of a presentation, right?
45:42
It's just, for example, the white space that I talked about in your blog, that breathing room, it's the pause when you're giving a talk. It's the taking a moment to speak slowly when you're giving a talk, for example. I'm also a big fan of spreading things out on multiple slides so that any one slide only says one thing versus having a lot of noise up there.
46:04
So the signal to noise ratio lesson is the same in both too. Okay, another question. Oh, and just be careful with the seats, people. When you sit down, it's very loud. Go for it. So I'm a personal blogger, and let's say I don't have all the
46:20
resources to promote on all the possible websites, Reddit, Hacker News, post to Twitter. So if I can choose, let's say, two or three major promotion resources, what's your advice for choosing them? Which social platforms to pick if you only have time to publish on a few of them? Is that the question?
46:41
Yeah, shall I choose Reddit over Hacker News? I can't prescribe that for you. What I would recommend is that you experiment, right? Because it depends on where your friends are, who your customers and users are, where they are. It's that advice about go to where your audience is, that's where you need to go.
47:00
And so you might try these two first, and then try these two another time. I also don't think I would just give a particular social platform one chance, because it might be the right platform for you, but you post it at the wrong time of day, or the wrong day of week. So I think you're just going to have to experiment a little bit there.
47:22
Thank you. Any other questions, or are we out of time, Jimmy? No, we've got two minutes. Okay, Karen has a question. I'll repeat the question if you want. Hey, thank you very much. I didn't manage to catch your talk last time you did it, so I'm really glad I was here today.
47:45
Lots of us in IT, from speaking to many people, don't find it natural to promote ourselves, or to put ourselves out there and write blog posts and promote our tweets and things.
48:01
Have you got specific advice for that? That is a really good question, and I struggle with it, because it's back to why I made that karma point, too. Sometimes people also have trouble promoting their teammates' work, because that might be seen as too self-serving also. But the fact is, if we want the Postgres community to grow,
48:24
if we want the information that we're sharing to get out there, then we kind of do have to promote it. I don't know how to really address that concern, except to suggest that you just have to let it go, right?
48:40
We just have to do it. You have to see it as part of the job. It does become more comfortable over time. It's not unlike anything. With practice, and you know what will happen? When you promote something, and you get the feedback from someone, Pavlo sends you a note and says, hey, that was really useful. I especially liked the bit about this.
49:01
And then your brain starts to connect the dots, like, oh, Pavlo wouldn't have even known about it if I hadn't shared it. Okay, maybe sharing is a good thing. I don't know. So you get the positive validation, and that might help. Any other questions? How to cope with imposter syndrome is the question, and it's a really good question.
49:32
I think a lot more people feel imposter syndrome than we realize. I bet there's a lot of speakers here at Fosdom who are experts in their field that maybe felt like imposters
49:44
as they were walking into the building today and wondering why they're the ones giving the talk. I'm not a psychologist, so I don't think I have a good answer, except to say that you're not alone. And everybody has a story to tell, and everybody has a unique point of view and lessons.
50:01
And just...