Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier.

Chris Coyier: [Laughter] I thought you were going to be like, "Chris, the Quill, Coyier," or like, Chris--

Dave: Chris Blog-o-matic Coyier.

Chris: Hmm. There you go. That's a proper intro.

Dave: Yeah.

Chris: Yeah. We're going to do a whole show this week on the idea of writing and, specifically, technical writing. We have somebody on the podcast who has probably done more technical writing than maybe just about anybody on Earth as far as Web technical writing is concerned, and that's Rachel Andrew. Hey, Rachel.

Rachel Andrew: Hi. It's good to be here.

Chris: Yeah, and it really does feel like decades, I'm sure, and dozens of books later. Rachel, you've done so much. I guess, more recently, you've become Editor of "Smashing Magazine," so, like me, you read a lot of pitches for articles and help people get their writing published as well. You do a ton of writing and you help other people do writing. Is that right?

Rachel: Yeah. Yeah, and I still do a lot of writing myself, both at Smashing and other places as well. Yeah, writing is probably the main thing that I do, really, at this point.

Chris: Yeah. I've heard so many people over the years say that it was instrumental early in their career, but just for the whole thing, and that writing is kind of "the thing" that unlocked doors for them.

Rachel: Yeah, definitely. I started writing really because I was just writing down what I was doing. That tends to be what I do. I write down everything I'm doing because I can't remember it afterwards, so I make notes.

[Laughter]

Rachel: Then I thought, "Oh, these might be handy for someone else," so I'd publish them, and that was really where it started. It's really not much different now.

Chris: It's funny, though, because it must be like--I don't know--you must have had margins on the brain or something. Just in this last week, I've seen your article. It's something like, "Everything You Need to Know About CSS Margins," or something for Smashing be linked to just about everywhere.

Rachel: Yeah, well, I mean that sort of thing comes from because obviously I work on specifications. I'm a CSS working group member, so I have to understand, at a very deep level, how CSS works in order to be able to edit my specs and to be able to contribute well. There's an awful lot of just digging around that I do just for my own knowledge. I need to know this stuff.

Chris: Mm-hmm.

Rachel: Then when I'm doing that, I'm kind of like, "Well, that's really interesting. That might be useful to someone," and so a lot of my writing at the moment, this sort of in-depth look at bits of CSS, are literally because I had to know that. I'm like, well, now that I've figured this out, I might as well share this. It's interesting.

Chris: Yeah. It's that repurposing. It's like getting double your money for what you did. It's like you had to do it anyway, so why not get a free blog post out of it.

Rachel: Yeah, and just to share this stuff because people ask questions. I think, "Oh, I know that. I know about that," and how do I then explain it? Really, it was the same as the writing I used to. I was building websites, I'd find something out, and think, "Oh, that's pretty cool. That might be useful to someone else," and I'd write it up. That's really what I've been doing for 20 years or something.

[Laughter]

Chris: Yeah. Yeah, and so an article like that that's just like, "Here's a deep dive into margins," is it largely the same approach as a talk, a book, or anything else? Do you find it very different when you have to switch modes like that and be like, "This is really a chapter of a book and this is a blog post. They're distinctly different"?

Rachel: To some extent. There are different ways of writing. For instance, the way I'd write something for MDN--I do quite a lot of writing for MDN; essentially a document in the Web platform--and that is very much sort of documentation. I write there in a slightly different way than I would write, say, on "Smashing Magazine" where I'm trying to kind of make an interesting article out of the thing.

Chris: Mm-hmm.

Rachel: Not that the documentation wouldn't be interesting, but I think there's a different approach if you're just documenting and trying to be very, very correct about things.

Chris: You just know, like, "This is an MDN thing. I'm just going to be very matter of fact."

Rachel: Yeah. Yeah. Well, it needs to be very sort of correct and accurate and you're not trying to make this sort of engaging piece that's going to make someone think, "Oh, actually, maybe I do want to know about margins." [Laughter] You know.

I think you might add a bit more color or add some personal notes or a bit more usage stuff or whatever to send as an article for that for, say, Smashing. I think it's that just sort of changing slightly the way you write. I think my stuff tends to be quite similarly structured because I've kind of figured out a way that I do things. Unless somebody tells me to do something else, that's what I'll do.

Chris: [Laughter]

Rachel: Yeah but, also, I'm very happy to follow a house style guide. I've ghostwritten a couple of things before in somebody else's voice. I did things like I did the second edition of Jeremy Keith's book in which I tried to sort of keep his tone throughout the stuff that I added rather than there be this sort of big disconnect between the Jeremy stuff and the Rachel stuff.

Chris: Oh, sure. Yeah.

Rachel: So, I think it does depend on what you're doing. Sometimes people have got very strict house style guides and you just have to write in the way they want things written.

Chris: Does Smashing have that that you need to enforce, in a way? It's not like the author is hiding on "Smashing Magazine," by any means. It's very clearly like any author has their photo and name presented there clearly. I'm sure, to some degree, it can be in their voice, but do you try to encourage an overall vibe?

Rachel: Yeah. We use sort of international English and things. We will edit stuff that is potentially confusing. I think one of the things that you learn by writing to a lot of international audiences are the number of things that are just completely baffling outside of your own culture. [Laughter]

Chris: Yeah.

Rachel: Like the Brits. You know there are things that I would say or do. I'm a northern Brit. I've got some very strange things that I might say. Over time, I've realized the things that don't translate between people who speak English, but also between people who are using English as a second language. I'll normally look out for that kind of stuff.

Chris: Right.

Rachel: Things that are obviously just not going to be understood. I do a bit of making sure that people aren't using exclusive language, so if something comes in and all the developers are men and the people in marketing are women, which I've seen, or people are using things that really bug me like calling code "sexy." [Laughter]

Chris: Mm-hmm.

Rachel: You know that sort of stuff. I try and edit out that kind of thing because it's not that it bothers me because I really don't care too much about the stuff I read. It doesn't affect me personally, but I know that it bothers a lot of people. We don't want to create this exclusive looking environment where things look like a bit of a boy's club or whatever because that's certainly not what we're about at Smashing. I will take that stuff out if I see it, and I will comment on it.

Chris: Yeah, surely. You'd think there's probably a level where, if it's bad enough, you're just like, "You know, let's maybe not publish this at all." [Laughter]

Rachel: Yeah. Oh, yeah. You know. I've certainly pushed back on stuff because a lot of that sort of thing. I try and be sensitive to the fact that, in some parts of the world, they're not quite as caught up on this as perhaps we are in the U.K. and America. Working in sort of our industry, I think we're all quite aware of these issues and how exclusive language, you know.

It's taken me forever to stop using "guys" to refer to groups of people. [Laughter] I think I've more or less managed to get it out of my own language. You know we've all been on that kind of process. Sometimes we get stuff from people who haven't figured that out yet and they'd be quite surprised when you say to them, "Hey, can you perhaps have some women being developers in this story?" or whatever.

Chris: Right.

Rachel: They've not thought about it. You know, I don't want to make everyone feel like they're wrong for not knowing. But then, I hope that once it is explained to them that they'll think about it in the future, maybe.

Chris: You're in the position of delivering on teachable moments pretty regularly, which is cool. I'm sure you've had thoughts about writing forever but, on Twitter, some stuff seems to bubble up that you'd probably see again and again, which makes its way into a tweet or something. I've seen you tweet that the intro is often a problematic area of a blog post. An otherwise fairly good post might have just an intro that needs quite a bit of work. I found that to be true myself, too. Not that I'm some Master of It or anything but, usually, when things come in the door, perhaps the thing that needs the most massaging is that intro thing.

Rachel: Yeah. Yeah, I mean the usual saying is, you get this lengthy story that goes on for 600 words before you even say what the article is about. I'm like, people are gone. [Laughter] They're not going to read your story.

Dave: In 1992, I built my first website.

Rachel: Yeah.

Chris: That's so common.

Rachel: Yeah.

Dave: Yeah.

Rachel: The whole story thing, and it's like everyone is writing one of those recipe blog posts where they tell you this enormous story at the bottom of the recipe.

Chris: [Laughter]

Rachel: Right?

Chris: Right.

Rachel: I'm just like, "No. Who is this for? What are they going to learn if they've read it?" If there's some context you want to set, well, do that afterwards. Tell them what they're going to learn and why they should be reading this. If you need to do some scene setting, that's cool, but do that after you've sort of introduced the thing.

Chris: Right. It doesn't mean that all this thought, time, and effort you put into this lovely little story you're going to tell needs to be thrown away. Sometimes it does need to be thrown away, I think. [Laughter]

Rachel: Yes.

Chris: But it means that that first paragraph means that you can be really clear. It is a "consider your audience" thing, isn't it? As a developer, if I land on it, I've tried to use this and I'm not sure how effective I've been. I've tried to say, imagine yourself landing on this article because you've searched for that topic and now you've found this article. Have you found what you were looking for?

Rachel: Yes.

Chris: Would you be or not?

Rachel: Yeah, that's exactly it. People are busy. I think both of us are dealing with audiences that are quite similar, so professional Web developers, fairly experienced people who are just, a lot of the time, searching the Web going, "Right, you know, I need this thing. I don't understand how to do this. Here's an article that's come up. Is this the thing?"

Don't have a huge amount of time to read through a sort of lengthy pros about that. So, yeah, intros. Intro is the thing that I edit the most or pushback and say, "I need an intro, an actual intro to this article." [Laughter]

Dave: Do you have, like, three rules of thumb? There's the classic, you know, "In the following article we will learn the following five things."

Chris: That's a little boring too, so that's tricky.

Rachel: Yeah. Really, from the intro, I want to know, is this for me? If I have come across this, I want to know, is this article for someone like me? What do I need to know before I can follow this? Sometimes you might have an article which is sort of a higher take on something. It's past the beginner stage so, okay, you need to understand about Docker already to be able to follow this. It's not going to go through your setup, so what do you need to know?

Then, what are you going to learn? You followed it through. You're the right sort of person for this article. You've got the skills to actually follow it. What will you know by the end of it? I think those are the three things that I want every intro to say so that people know.

Chris: It doesn't mean it's a list of three things.

Rachel: Yeah.

Chris: You can deliver that with some pizazz. [Laughter]

Rachel: Yeah. Yeah. Yeah, exactly. I think that's really where someone in the first minute or so can be like, "Oh, yeah, this is going to help me solve my problem." But we are talking. Although we're not talking documentation here, we are talking about practical pieces of writing to help people do their jobs. There are some articles which are much more maybe an opinion piece of what have you.

Chris: Yeah, editorial.

Rachel: Yeah, and they're a little bit different. I think the average technical tutorial, what you're doing is you're letting someone achieve a task, essentially. You need to know upfront that what you're going to be doing is actually going to fix your problem or teach you the thing that you want to learn because you need to know how to do that thing for your job.

Chris: I try not to let it go too far before there's some kind of -- it feels so general because, like you said, there are so many different types of articles out there. A blog post can be a poem for God's sake. It could really be anything. Generally, here, we're talking about technical writing. The reason that it exists is for reference and is for someone to do a Web search on, find it, read it, and get their answer.

Whatever that answer is they're looking for, imagine what that answer is. Imagine why someone is landing on this thing. They're probably immediately going to start scrolling and just be like, "Where is the little chunk of code that I'm looking for?" I think there's just a high chance that they're looking for some kind of "show me the code" moment.

Rachel: Mm-hmm. Yeah. Yeah, a lot of the time. Yeah. It's that, really. It's just making sure that you pitch it right. There are so many really good articles I get that don't start being good until 600 to 800 words. I'm like, no one is going to get to that bit. [Laughter]

Chris: Mm-hmm.

Dave: I guess, is that salvageable?

Rachel: Yeah, generally, it is.

Dave: Do you have to crumple up the piece of paper? [Laughter]

Rachel: Yeah, I mean a lot of it is pointing that out to people. I think sometimes people think they need to write all this stuff. They think, "Oh, it's too short," or it's a bit boring because it's just this technical stuff. Then they feel they need to write all this stuff.

Sometimes, when you sort of say, "You know we could probably get into the code quicker," sometimes people would actually say, "I thought I really ought to introduce it more." They felt they needed to do that--

Chris: Yeah, right.

Rachel: --rather than it being important to them personally that it was there.

Chris: It brings me to the idea of word limits because I think a lot of people -- I have the experience of a lot of people asking what it is or, if not a limit, a target, like how long should these things be. I'm wondering if I should have one because I haven't. My normal answer to that is like, "I don't care. Just write a draft. We'll get to it from there."

The reason I say that is because I found it goes either way. It's common that somebody writes to long and it's common that it's not meaty enough. They don't cover enough ground. It's too short. I was like, "Why give you a target if it's--?"

Dave: Well, Chris. In my eight-part series, you will see--

[Laughter]

Chris: That's another one just to bring up really quick. I find it amazing how often that's right in the first few sentences of their pitch. "I'd like to write a multipart article on--"

Rachel: Yes. Yeah, we get that as well. Now, I partly wondered if this was because people want to be paid for multiple articles.

Chris: Hmm.

Rachel: I wonder if that's what's going on there. The wordcount thing, Smashing had a bit of a reputation for very long articles. This is because--

Dave: Really, Smashing? Really?

[Laughter]

Rachel: Vitaly is a bit like me, you know, can't have a thought without writing 4,000 words about it.

Dave: Vitaly wants to go the full avenue.

Rachel: Yeah.

Dave: Oh, we're talking about fonts? Let's talk about Unicode in its entirety.

Rachel: Yeah. Vitaly is great at these really longform pieces of writing. I tend to write because I find writing relatively easy once I've kind of got an idea for something. I can also do exactly the same thing, just write and write and write.

I think people often come to Smashing worried that they're going to need to kind of write this sort of epic. Actually, the feedback we get is that some of the articles are just too long. The articles we do on Smashing do tend to be a bit meatier than on some sites, I think.

Chris: Mm-hmm.

Rachel: We sort of say, around 2,000 words is probably the amount of detail we're expecting for an article, but not getting huge. Sometimes things can be longer and be fine but around 2,000 words is kind of a sweet spot. The multiple article thing, I will split down articles. I help people to split down articles if I think it calls for it. Sometimes that makes sense.

Chris: It's kind of an editorial choice not an author choice, I think.

Rachel: Yes. Yeah, that's it. We get people; typically, if someone comes and says, "I want to do a multipart article," no, they haven't got enough material for it. They need to edit it down into one.

But we do get stuff in progress that is becoming so big and, yet, all the bits are interesting that it's actually worth saying to the person, "Hey, look. There are kind of two or three distinct chunks of this that standalone as useful things. Let's split it down because it's actually easier to read."

Chris: Yeah, that standalone thing is important, too, right?

Rachel: Uh-huh.

Chris: You're like, why would you take--? Just because it's good or super long, there's no technological reason that you need to split it in half. I think there's more reason to keep it all together, to have it be this super guide. Splitting it in half, down the middle of one distinct thought, that's not going to do any good for your SEO, for example. I don't think it's particularly helpful for anybody reading the article either.

Rachel: Yeah.

Chris: It needs to be too long and have distinct thoughts. That's a good point.

Rachel: Yeah. We do a bit of that. Yeah, typically, if people come proposing a multipart article, they just need to edit their article.

[Laughter]

Rachel: That's really what's going on there, but not always. Particularly the more experienced people, they're able to see that themselves that these are three sort of distinct things or two distinct things and could make for two pieces. I'm certainly up for that. You know it's sort of more things to publish. It can sometimes help people to find stuff because, if they are two very distinct parts of building something, for instance. Say you've just done a front and back-end split on something. Well, actually, some people may only be interested in half of that. Then they're not put off by the bit that they don't really understand. I think sometimes the multipart thing can work.

[Banjo music]

Chris: This episode of ShopTalk Show was brought to you in part by Web Unleashed 2019. It is a conference coming up in Toronto, Canada. It is the conference for front-end developers. I went a couple of years ago and just had an absolute great time. Guess what? I'm going back this year.

It's coming up September 13th and 14th, again in Toronto. It's put on by FITC who puts on a bunch of other great conferences too. This is the one that you want to go to if you're a front-end developer.

I'm going to be there, of course, giving a talk I can't wait to give. It's going to be fun. I think I'm also going to be doing a few other things there. I'm going to be leading a roundtable discussion about some stuff. I don't know. it's going to be great.

Like I said, it just has a good vibe to it. You can kind of craft the conference to your own and go see the stuff that you want to see or just chill for parts of it or whatever. It has a very positive vibe and a lot of learning to be had at this thing. Again, it's September 13th and 14th. There are a bunch of workshops and, of course, the vibe of a workshop is just a total focus on one topic where you're going to go and you're going to leave there leveled up and learned up in a particular subject. Then there's the conference itself, which you're going to learn from, but it's more of the point of going to a conference and seeing a wide variety of talks.

It just expands your mind to the possibilities of things and dig a little bit into different topics. You come home excited about X, Y, and Z, and are going to dig into probably just Z. You know what I mean. I don't know.

It's coming up in Toronto. The URL is FITC.ca will get you to the FITC. The actual landing page for Web Unleashed is a little deeper, but you can find it through there.

Then there's a discount code. If you use CHRISCOYIER as a discount code, you'll save $200. There's a special link for that for registering. You might as well save $200. Why not?

It looks like, on the homepage of the site too, they're saying, "Stay at the hotel that there's a block for, for the conference, and save $100 off the ticket, too, in case you don't live in Toronto and want to stay at the hotel nearby. Save even more money on the ticket and dampen the cost a little bit. Pretty fantastic, Web Unleashed 2019, coming up in September in Toronto.

[Banjo music]

Dave: I like this idea. You're very comfortable with 2,000 word articles because, as a reader, I used to have guilt about, "Oh, I didn't get through the article. I failed myself." I think, as I've gotten older, I don't know; if you're not getting it in the first two paragraphs, it's probably not for you. You could bail out of an article at any point. It's great.

Chris: Oh, yeah. Let's be real here. I mean I probably look at 50, 100 different articles a day of some kind through RSS, email, and just Twitter. Click, click, click, click, click, click, click, click tabs. The amount of those I get all the way through and read every word of--I don't know--one or two, maybe.

Rachel: Yeah. Yeah, that's it. People are scanning. I think that's the whole thing about making that what they see upfront, making that intro really interesting and telling them if it's worth them spending their time on it. We don't want people spending their time reading things that aren't helpful to them. [Laughter] We'd rather they skip on and go and read something else that is more useful. That's, I think, really important because we all do this. We all scroll through this stuff and look for the little bits that we want to read.

Dave: With that idea comes the idea of scannable headlines, right? Almost like a screen reader where you're just reading the H1, 2, 3, 4, 5, 6, or the document outline. Is that something you pay attention to, like, how the headline, the shape, or even just the content of the headlines?

Rachel: Yeah, I think there are a lot of articles that benefit from adding more headings, too, particularly when you're talking about what people are reading on the Web. For that reason, really, because it allows people to maybe look at the intro and then saying, "Oh, yeah. This might solve my problem," and them just hop down quickly and be like, "Oh, yes. Yes, that's the sort of thing I'm talking about," because they can see it in the headings. That, sometimes, you can do an editing point with your own stuff or other people's stuff is to break it up a little bit with logical headings and so on. It just helps the reader to locate where they are in the document.

Dave: Do you have any tips for writing good headlines?

Rachel: Headlines are really hard. I ask Drew sometimes.

[Laughter]

Dave: You A/B test.

Rachel: Some people are really good at headlines and titles.

Chris: I agree.

Rachel: I am not.

Chris: I'm not particularly good at it.

Rachel: Yeah, I'm not that person.

Chris: How often do you think of the author's own headline makes it all the way to production?

Rachel: Yeah, some of them are very long, like they've tried to put the intro in the heading. That's the thing that people do.

[Laughter]

Rachel: I've not told you anything in the intro, but I've put it all in the heading. That's quite a common thing.

Dave: In this eight-part series, you will see that I am the master of--

Chris: Ugh.

[Laughter]

Rachel: They'll try and put a funny heading, which just doesn't make any sense, really. You think, yeah, all of our English as a second language speakers are going to be baffled by that. Yeah, it is really difficult to try and make it a title that is going to grab attention, is going to look good when it pops up on Twitter or wherever, you know, because that's really what you need to be thinking about is the searching for it. If someone sees it in a search listing, on Twitter, or wherever, is that actually going to tell them anything about the article, enough for them to click through? That may well be all they see is that heading.

Chris: Yeah. I would optimize for SEO 100 times more than I would optimize for Twitter, personally. At the end of the year, I end up looking, deep diving into my stats and seeing where stuff came from. I'm like, we didn't get crap from Twitter. I think there's a lot of value in it, in staying in touch, generating ideas, and conversing with people but from a business perspective of just driving raw traffic to the site, it's a tiny fraction for us at CSS-Tricks.

Rachel: Yeah, I think so. The interesting thing I find about the search traffic and the articles from search traffic is that we have articles that do really, really well when they first launch. You probably have the same. It gets picked up. Loads of people tweet about it. On their first week or whatever, they're in all of the CSS publications.

Chris: Right. Right, right.

Rachel: They'd have a really, really great first week, but the articles that do well over time are completely different. That's when it sort of falls back into, we've got all this collection of content and people are typically finding it via search. They're not finding it because people are linking to it on Twitter because it's old news. Once it's a week out, nobody cares anymore about the … stuff from "Smashing Magazine."

Dave: Yeah. If it's over 48 hours, that's ancient. Yeah.

Rachel: Yeah, and so then you start to see it even out. It's very interesting, the stuff that rises to the top in terms of what is most useful on the site over time. I find that very fascinating to go back and just sort of ignore everything from the last month and see what is actually doing the best.

Chris: Oh, yeah. Go look. I would say anybody with a technical publication, they'll tell you that that top list all has super boring, super clear titles that just explain exactly what the content is in that article.

Rachel: Yeah. Yeah, totally practical solving problems. Not the stuff that's a bit controversial. Not the stuff about the latest technology. It's stuff like, how do I create a print style sheet? Really obvious things that people need to know about.

That's interesting because people worry about their first week. They're like, "How much traffic did my article get?" They only care about it for about two weeks. Then you never year from them again. [Laughter] Really, it's actually, how much traffic did that post get over a year or whatever because that would be very different.

Chris: Related to that, I always steer people away from editorial. We do it on CSS-Tricks sometimes, but it's often from me or staff where it's just a post that's like, here are some thoughts, a collection of other people's thoughts, or something. I tend to not want to pay somebody else to do that. Not that other publications can't or it's a bad idea or anything, but I just don't want to be this home for whoever wants to barf out some thoughts like why CSS is bad or something. It's always some controversial crap anyway. I can't find enough value in those. I don't want to pay for that. If I'm paying you money, I want technical referential content.

Rachel: Yeah. Yeah, unless it's someone who is a real known expert in some area, I think those kinds of editorial opinion pieces are not hugely valuable for people running sites like ours. I think people don't come to us for that kind of content, particularly. I think they're much more into getting to know about CSS, JavaScript, or whatever it is. Yeah, I think there is a place for a little bit of that and we sort of experiment with bits and pieces of that. Our print magazine that's coming out is all about ethics and the tone of that is very different. It is much more of that kind of essay like opinion pieces and things.

Chris: Oh, I didn't even know a "Smashing Magazine" magazine.

Rachel: Yeah, so a print magazine that's about to come out. Yeah, that was an interesting thing to edit.

Chris: Wow.

Rachel: [Laughter] Yeah, I think, on the magazine, we know what our audience is. They're professional Web developers. They're really busy, and they just want to solve the problems they've got, most of the time, not read someone's argument as to why we should replace CSS with something else or whatever.

Chris: Yeah, right. It's just inflammatory or whatever. Here's another Rachel tweet gem. There's a sweet spot for writing technical posts and tutorials. Write for the professional who hasn't had time to learn that thing yet and link it back to things that they already know. For example, explaining a modern JavaScript technique for someone who knows jQuery.

Rachel: Yeah. That is such a good way to write this stuff because there is so much. The biggest complaint people have who are Web developers now is, "Ugh, there is all this stuff I've got to learn." Everyone feels overwhelmed. Maybe they want to get a job and they're realizing that, "Oh, everyone says I need to know React now. I don't know any React." Maybe they want to just improve their skills because they were a freelancer. They want to be able to use some of these new, trending techniques that I've read about.

Everyone is a beginner at something. In fact, all of us are beginners at loads of stuff. [Laughter] There is so much that we could be learning now. It's taking stuff and saying, okay, you know PHP. You've been working with WordPress, for instance. You want to start working with static sites. Well, how can I write that so that it's understandable if what you've actually done before is you've worked with WordPress or something like that.

Yeah. You jQuery to Vue or those sort of things saying, well, I know you're an experienced professional. You don't need how do code explained to you. What you want to know is this very specific based on the experience you've already got. That is so useful to people who have been doing this for a long time.

Chris: You know those posts tend to do really well, too, so it's kind of a trick. If you're looking for a good poster, I'd say that's really clutch advice that you should take to heart.

Rachel: Yeah. If you are someone who has moved from one of those things to another, you've moved from one language to another, you moved from one framework to another, write that up because that's going to be so useful to anyone else making the journey.

Chris: Oh, for sure. Do you know what doesn't change on the Web is what we're actually doing, in the end? React might seem really foreign and weird to you, but what it's trying to do is the same old stuff that we've been doing forward. It's like, "Oh, you need to render some stuff on the page and then it does something when you click on it? We used to do it this way and now we do it this way, so explain that."

Rachel: Yeah. Yeah, and that's it. That referring back is what's really important because I think if you have been stuck in sort of one way of doing things on the Web for a long time, it can just seem quite frightening, almost, how much things have changed recently. I think that that's a really nice way to approach it just to say, "Well, you know this thing. You're ally good at this thing. This is not so different. It just looks a bit different on the surface, but here we go. Let's join the dots.

[Banjo music]

Chris: This episode of ShopTalk Show was brought to you by Jetpack, Jetpack.com. It's a plugin by Automattic for your selfhosted WordPress site that brings a lot of the power from WordPress.com, in a way, to your own site. Now, you don't have to think about it in that way. Another way to think about it is, you get a crap load of features all in one plugin. There is a bunch of performance stuff. You get lazy loading. You get CDN hosted images and CDN hosted core WordPress files, which is pretty impression and just a darn good idea for the performance of your site. Now all you've got to do is flip a switch. They have all these "flip a switch" features in Jetpack. They're just like, "Do you want this incredible benefit? Flip a switch. You flip a switch to turn on security tools, login blocking, and all that kind of stuff. It also adds a bunch of extra functionality. There's a bunch of Gutenberg blocks that are all pretty cool and custom that you get for free.

One of the biggest ones for me is backups. You get kind of real time backups of your database. Not just your database, but literally everything across your entire site with it, which is pretty darn powerful, if you ask me. It's one of those no-brainer plugins for me. I literally pay for it and install it on every single WordPress site> I have because it's kind of a peace of mind thing for me. Even down to tiny little stuff like you can use Markdown if you have Jetpack installed. Of course, I like to blog in Markdown and have Markdown available for comments and things like that.

Easy-peasy with Jetpack, pretty cool. Thanks, Jetpack, for your long-term sponsorship.

[Banjo music]

Chris: What do you think, Dave? You do plenty of technical writing on your own site.

Dave: Yeah. Here's my question. [Laughter] What's the difference between a technical writer and somebody who blogs? I think even this came up with a client. They were like, "Do you know any technical writes?" We were like, "Well, I blog, I guess." [Laughter] Even like, "We know a content strategist who is really good at establishing a voice and tone. How do I know if I'm a technical writer or should pursue that? How does that work?

Chris: Oh, my gosh. What makes me think is, like--I don't know--you just call yourself that, I guess. Just put it on your business card.

Dave: Is there a difference between a blogger and a technical writer, like in tech, I guess?

Rachel: Yeah, I mean I do, because like I said, I do quite a bit of work with MDN. MDN have a fantastic team of what I would definitely refer to as technical writers. They are people who can take any technology, really, research it and write it up in a very clear way. Essentially, they're writing documentation. I think that's probably mostly the job of someone who is purely a technical writer. You're kind of thinking of someone who is writing documentation and is very good at taking some bit of technology or a specification or whatever it is and then clearly writing it up and documenting it.

I think that a lot of bloggers are doing that as well. I think a lot of people are writing for Smashing or for CSS-Tricks are also doing that to some extent. I think it goes back to that slight difference between just documenting and making an engaging article. I think that obviously there's a kind of gray area in the middle. You need to be a good technical writer to be able to write about this stuff, but I think if you're purely a technical writer, you're probably doing a lot more of that, "Well, I need to research how this thing works and then I'm going to document it."

Maybe a little bit more on our sort of sites, what we're doing is we're actually saying, "Well, I've used this. I've used this thing making my own website and here's some stuff I've learned," which is slightly more like writing a blog post or an article, a magazine article than just pure technical writing. That's a fairly rough sort of split, I guess.

Dave: Okay. Okay. It kind of helps me.

Chris: Maybe you need to prove it. If somebody is like, "We're looking for a technical writer," and then the person that you find can say, "Hi, I'm one of those. I've written this, this, this, and this," and they're not just on your personal blog, then you're a technical writer. You've done it.

Dave: How do you measure success? Ooh. Here we are, business doc. How do you measure success on a piece of technical writing?

Rachel: I mean if it's pure documentation, it's how many times did people come into support asking the questions having said, "Oh, I've looked at this," and then are still having to come into support for help. I have products. I'm kind of used to doing writing for that as well. I think that we've failed with our documentation if we've got documentation for a thing and people are still turning up in support referencing that documentation and haven't been able to achieve what it wants to achieve. That documentation then has failed.

I think, if you're just talking about pure technical documentation it's, well, is it letting people achieve what they need to achieve? That's really the end goal.

For blog posts and things, I mean you're not necessarily digging into every side of things, are you? You might be saying, "Well, I used this thing to do this other thing and here's what I learned." You're not actually describing every little thing about it. You're not writing documentation.

It's much more, do people get inspired, perhaps, to use this technology; to try it out themselves? Does it help them think in a slightly different way about how they're using it? It may be a bit different to just writing up the docs for a spec or a product.

Chris: I've got a couple of fails recently of examples of the opposite of success. [Laughter] We published one this week. It was an article that was kind of like a real world chatroom thing. The whole point of it was just to pick a demo to showcase a whole bunch of different React hooks and where you might use those in a real world scenario.

I was like, that's kind of cool because I don't care that it's a chatroom, but there are five or six different React hooks being showcased here in a somewhat relatable, real world experience kind of thing. We published it. It was alright. It was a pretty good article, I thought. I approved it. I did some light technical editing on it.

There are a few things I didn't catch and then a few things that were referred to as hooks that weren't. Now I have Dan Abramov in my DMs being like, "What the hell is this?" He didn't say that.

Rachel: [Laughter]

Chris: He's obviously extremely nice, but he pointed out some weirdnesses in the article and I was like, "Oh, crap. I really should have caught that." It was kind of like this got a little farther than it should have without better review kind of thing. I don't know if that's a total fail because it still did some of the work that it was supposed to do.

Here's another fail. I was trying to host a website. I found this ancient website that I was shutting down a server and I wanted to just move it off there. I built it in 2008 for a friend of my dad's. It's a bunch of flat PHP files. I was like, I just want to throw this up somewhere really quick and easy. I found a place to do that - whatever.

I was trying to map a domain to it, so they needed docs in this services thing that would explain to me how the heck you map a domain to this service. DNS is weird, right? If you have an IP, you can point an A-Record at it, but it didn't have an IP, but they have static deploy kind of thing so I could point a C-Name at it but it couldn't be the root domain. It had to be a subdomain, so you had to use www to do it. I was like, uh, that's weird.

Then it was like, "Or you could use our name servers," but it didn't really clearly say what those name servers were or how to get them. I was like, okay, I don't know. I'm just a newbie here, so maybe it's more obvious to people that use the service more. But I was like, to me it's a little bit of a documentation fail when I need real deep, personal handholding to accomplish this task because your docs couldn't get me there.

Rachel: Yeah. There is a lot of that. A lot of that comes from assumptions. People assume that the reader knows a lot more than they do. It comes back, I think, to telling people what they need to know first.

We get a lot of that with purchase support with the CMS. We kind of always assumed that people would understand how to build a website. They could build a website. They wanted to put content management on it. Then we discovered that a lot of the time the problems people were having weren't anything to do with our system. It was due to the fact that they didn't actually understand how websites went together, so they didn't understand that when they got a 404, they didn't know what they had. They didn't know what that error message actually meant.

Chris: Wow.

Rachel: That was our assumption that everybody who would use Perch would know that sort of thing. We were getting people into support and, you know, why aren't these people understanding what's happening here? It's because they didn't have that bit of knowledge.

I think, often, that's where it comes down to failed assumptions or the fact that maybe the product has got wider than you first imagined, and so you've got more people coming in who don't have the background that you expected. Of course, the background that people have in the Web industry is very different now to what it was.

Going back to writing stuff for sites like ours, a lot of the people who are building for the Web, they've never had to host some PHP thing on their own server. [Laughter]

Chris: Yeah.

Rachel: There's a whole bunch of knowledge that those of us of a certain age have about how the Web goes together and how websites work at an underlying level that you just don't need; you don't need now. You can build your site. You can sling it up on Netlify or whatever.

Chris: Yeah.

Rachel: It's just all going to work. You're not messing around with Web servers and the complexities of DNS or whatever.

Chris: Yeah. Sometimes your old knowledge almost hurts you in a way.

Rachel: Yeah.

Chris: You're overthinking this.

Rachel: Yes.

Chris: Just commit it. [Laughter]

Rachel: Yeah. Yeah, and also just that you can very easily make assumptions. Often, as a writer, just make assumptions about what my audience already know, forgetting that my audience, some of them have never had some of the experiences that I've had because they've not needed to because the Web has got, this stuff has got a lot easier and different as well. The starting points are different, and so people are coming into Web development through frameworks and aren't looking at a blank HTML document and starting writing from there, which I think is an assumption that a lot of us make, and that's changed.

Chris: Yeah. I don't think I would publish a blog post. Maybe in special circumstances. But if an author took it that far back for CSS-Tricks, I don't think it would be good. I don't want an article that says, "Open up your text editor. Make a style.css file. Paste this code into it and hit Command S to save the file." Often, it's like, to have one of those that you can reference that is that fundamental, that's great. But if every single article has that in it, it's like, meh, that's not right.

Rachel: Yeah, I think that's it. It's knowing where to point people. I've just rewritten the Learn CSS section of MDN. It's the thing I've been doing. That'll be going live fairly soon because it was getting a bit old, so I rewrote that, which is basically your ground up. "You want to learn CSS. Right. Here is a blank document. This is where we start," sort of thing for people who really do want to actually understand.

That's the sort of thing that you reference. You point to MDN and you say, "If you want to learn CSS and you don't know anything about CSS, here is a good place to start. Then come back and you'll be able to follow this article," so it's that.

Chris: Sure.

Rachel: Yeah, it is that thing about saying, what do I need to know before I can follow this? If I'm not at that point, well, here is somewhere I can go to get to that point. Then this will make sense to me.

Chris: Beginner stuff is especially hard. There's a post about guest posting on CSS-Tricks. I know there is one on "Smashing Magazine" too, right? Like a URL you can send people to that's like, "You want to write for us? Here's how you do it."

One of the things I have in mind is that I don't necessarily care about the skill level thing. We often don't publish really super-duper-duper high level stuff like, "Here's how you write your own programming language," or something that's really high level. It's often a mix between beginner and intermediate. It's one of the two. It's mostly intermediate stuff.

But if you're going to go beginner, I like that. I want people to take on an article that's scoped at beginners. But just know that the bar is way higher. That's harder to write than an intermediate, I think, because you've got to get through me and I'm going to hold you to that higher bar is the problem.

The Web is saturated with beginner articles on all kinds of subjects, mostly kind of bad. I was like, if we're going to get into this game on this topic, I want to be competitive with the best articles. I want this to be one I'd be proud of.

Rachel: Yeah.

Chris: It's not just a fluff article.

Rachel: Exactly. We're talking about something that I know a lot about. For instance, the CSS Grid stuff; obviously, I've written a bunch of that stuff, so I get proposals all the time from people who want to write an article about the FR unit. I'm like, "Well, there are a lot of articles about that out there. It's not that that person's voice shouldn't be heard. It's not that it's not worth having another take on that. I'm probably not going to reserve a slot on Smashing for it just because there's nothing new there. [Laughter]

Chris: Right.

Rachel: If I wanted to point people to a basic CSS Grid article, well, I've written a bunch. I know a whole lot of other people have written them. There's stuff on MDN. There are plenty of those that we can point people to.

What else could you be writing about? That's what I say to people. They're like, "Well, okay. You'd like to write something about CSS Grid. That's great. People will be really interested in that. Can you bring us something new from your experience? What problems have you solved with it?" which may touch on some of the basics as well, and that's cool. Talk about it from the point of you've solved some problems with it or what have you. I think that is a good place to go with those rather than just, "I'm going to explain the FR unit."

Chris: Yeah. I love that. I bet you see that all the time. It's like a fluff piece on CSS Grid that just lightly covers the surface of it. Then you're like, there are two million of those.

Rachel: Yeah. I think that happens with everything. Obviously, those ones are easy for me to spot. The other thing I spot is where people have just massively ripped off somebody else's writing. I see that with the CSS ones because obviously I read a lot of CSS articles. I've got a newsletter where I'll send out some. I'll just be like, "I've seen that before." I read something and I think, I'm sure I've seen that before," and go poking around and find where they've just lightly rewritten someone's stuff.

Chris: Wow.

Rachel: We had one recently that got through that I didn't spot because it was a technology I was less familiar with. It wasn't something I'd been reading. I felt terrible about it because I sort of hate the idea of publishing something which is sort of a rip off of somebody else's stuff. It's quite hard to spot if you're not immersed in that particular technology. We cover everything from Android development right through to UX design.

Chris: Sure.

Rachel: It's very difficult to spot when someone is just doing an edit of somebody else's article and submitted it.

Chris: Terrible. I like that, how you said, you want to write. Sometimes what authors are after is they want to contribute. They want a byline. They might want the money. That's fine. Well, then write something -- when you turn it around and say, "What problems have you solved with this?" that's great! That's great. That's the meatiest stuff.

Rachel: Yeah, well, that's it. That's the thing that's hard to get. I can write some documentation, essentially, with a bit of a twist about any bit of CSS. I still build websites, but I don't build websites, you know, I'm not a freelance Web developer just building websites. I'm not in a big company with all the challenges of building a website within an enormous company, so I don't have those experiences. I can't write those articles about CSS Grid.

I can write an explanation of how Grid works. I can do a big dive into how sizing works or whatever, but I can't write the article that someone who works for a giant company and is implementing CSS Grid components; I can't write that article and I would love to have that article. [Laughter] That's what I want people to do is look at their experience and bring us that in whatever technology we're talking about because that stuff, you can't get that experience without actually living it and working on it. Then that's really valuable to other people.

Chris: People might have that and not even know it. You do have this. You work all day.

Rachel: Yeah!

Chris: You know. Tell me about it.

Rachel: That's it. That's the really useful thing, I think, for people is to start. If you want to write or speak, for that matter, which I think is fairly similar, is to start making a list of anything that you do in the course of your job where it's like a lightbulb moment and you think, "Oh, I wish I'd known that before," or any interesting thing that you sort of work through with your team and make some decisions. Make a note of that as just an article idea or maybe even write a few sentences of it. then you will get a list of things, some of which will turn into something bigger.

I do that all the time. I've got a list of about 50 or so things at any one time, which are article ideas that have come from some other thing that I've been doing. I've done that for years. I just throw these things in there. That's really, really useful.

Chris: Yeah. Yeah, yeah.

Rachel: Yeah.

Chris: Me too. All the time. I try to turn them into little nuggets lately. It depends on the mood that I'm in, but just the other day I had to code up a little admin screen for something and Data List was super useful for it as an input. I was like, "You know what? This is a little moment. I think maybe underused HTML. We've covered it before, but whatever. I'm just going to cover it again because it's kind of a cool thing, so I'm going to blast out a little article about Data List. Why not? You know."

Rachel: Yeah, exactly. I think that's something that people can start doing because if you ask people or they sort of say, "Well, I want to write something." What do you want to write about? And you can't think off the top of your head. Whereas, if you, during the day, get into this idea of just, "Oh, that was an interesting thing. That was interesting. A few things might end up being one article or you might end up having one that you can expand into something. It's just getting into that process of logging the interesting things that happen because I think most people who are working on building websites will have multiple of these a week.

Chris: Certainly. Yeah.

Rachel: It's just getting into an idea of collecting them and then you can write them up.

Chris: The worst -- I don't know if it's the worst, but this is when I get a lot that I push people away from is the, "I want to write about this new thing," and it's a library or something. Their article is a little bit too close to the docs.

Rachel: Yeah.

Chris: It's not plagiarized, necessarily, but it's reworded or something. Then it's like, if I were somebody who was looking at this technology, I'd be better off reading the docs than this article.

Rachel: Right. Yes. Exactly.

Chris: Those docs are probably going to stay updated over time whereas this article will not. It's not that we don't update articles. There are thousands of them and I don't read the change log for every library mentioned over the entire CSS-Tricks and update articles. The articles largely, like that, just stay the way they are.

Rachel: Yeah. Yeah, that's it. Yes. That is a common either rejection or a kind of, okay, it would be cool to have something about this thing, but it needs to be something that is sort of adding value over what's in the docs because people refer people back to the docs for here is how you set up this thing. Then write about actually how you can use it to solve some problem that's not just documentation because, yeah, as you say, best for the docs to be with that company or that project rather than our site getting out of date.

Chris: Sure. Do you have any other kind of common rejection stories?

Rachel: Promotional stuff. We get lots of people. It's really hard because I've got products and sometimes the things that you have learned are because of the product you're working on. You can't talk about it without mentioning your product and that's fine. I don't have a problem with someone writing an article about the thing that they've worked on and mentioning it in a sort of, "Well, this is how I've learned these things. We have this type of customer, so I've learned these things." That's cool.

What we get is kind of obvious content marketing where they've kind of thought of something which is a bit about what it is they do and therefore going to essentially try and pitch their product through an article rather than really doing anything that is useful without using the product. I think that's the thing is, is the thing that you're learning from this useful without using that product or if you didn't even know what the product was? [Laughter] You know, is there actual learning based on this or is it just someone trying to pitch you to go and use their product to do this thing?

Chris: That's great. Yeah. Just because it's some plugin or something that I might not use, it might be interesting to know what it does anyway.

Rachel: Hmm. Yeah.

Chris: Yeah.

Rachel: Say if you're going to write something about templating for a PHP app because we've learned that stuff doing Perch, for example. I can't really mention that without mentioning Perch because this is where we've learned how to do this, but that's it. It shouldn't need to be more than a bit of scene setting. This is why that we know that this is a problem or whatever.

The other thing that are really weird, two author posts sometimes get proposed. Do you get two author posts proposed, like multiple?

Chris: Once in a while, we get it. We use WordPress and it doesn't really have a two author thing, so it always leads to this awkward situation where I'm like, do we make a fake new single author where the name is both of their names or what?

Rachel: Yeah.

Chris: It's a little awkward, but not regularly. That's funny that you get that a lot.

Rachel: Yeah, I get some of those. They're just odd. Often, there seems to be something odd driving it. You get someone who seems to be the subject matter expert and someone else almost writing the article on their behalf, which is odd.

Chris: That's odd.

Rachel: I can understand if we've got someone who isn't an English speaker. That makes sense and I would totally go for that being this person's work translated by or whatever. That's cool. Yeah, that's a weird thing. The other thing in a similar vein are the things where it's like, "One of our Web developers is going to write you an article." I'm like, if one of your Web developers wants to write me an article then they can email me. [Laughter]

Dave: Mm-hmm.

Chris: Yes! Oh, amen! I get that all the time, particularly for this show. Oh, my God. It feels like every day we get one that's like, "You should have our CEO on, Mike Berbliglowitcz. He's amazing."

Rachel: Yes, that's it.

Chris: Well, if Mike wants to be on the show then Mike can email me.

Rachel: Yeah, exactly. That's where we get this all the time. I'm just like, "No! No."

[Laughter]

Rachel: If they want to write, that's cool, but they can email us. Also, what really annoys me, and it's probably just petty, but are people who claim to be professional writers who have not read the information that we have about writing for us. [Laughter] I'm just like, this is kind of like Writing 101. Go to the website and see if they've got information published about writing for them.

Chris: Oh, gosh. That's unbelievable.

Rachel: Yeah. if you want to pitch an article to anyone, go and see if they have information about how they accept submissions and what they want to see in that submission. We ask for an outline first rather than people sending a full article just because we get so much of this stuff. There's no way I could read them all.

Also, if I get an outline and it's not something that we could use, quite often I can help them reshape the outline into something that we could use. I can say, "Right. Okay. We've already got something like this," or, "That's not really going to suit our audience. However, if you could propose an outline that kind of went in this direction, then I think that could be something that would work."

They've done a lot of work at that point and we're able to talk about it and then we've got something they can work on. Whereas, if someone sends me a fully finished article that is just wrong for the site, then it's just a rejection. It's like, "Oh, sorry. This isn't what we want to publish."

Dave: That's a good point.

Chris: Yeah.

Dave: You may already have 12 articles about the FR unit in the pipeline. People, I guess, shouldn't -- I guess you're submitting. Don't get too invested. Just submit the outline because otherwise, yeah, they might have an article already like that in the pipeline.

That's something I'm realizing. You don't always know what's on the plate of "Smashing Magazine" or what's in the pipeline.

Rachel: Yeah. There's usually about 100 articles ongoing at any one time. Particularly if it's a popular topic, the chances of it actually being covered is relatively high. Yeah, seeing an outline means I can say, "Right. Yes. That's great." I can earmark that subject to that author. If someone else comes along and says, "Oh, I'd like to write about this," I'm like, "Oh, we've very sorry. We've already got someone writing about that. Maybe you could take it in this direction." It's sort of trying to manage that and helping people to write something which we will be able to publish rather than write something which I'm going to have to turn down because we've already got that or it's just not sort of right for our audience.

Chris: Of course, the number one submission of all time is spam.

Rachel: Yes.

[Laughter]

Chris: It's about ten to one over here.

Rachel: Yeah.

Chris: Just people that write in with these boilerplate emails that are like, "I have been published on DZone.com. Here are three URLs to my incredible writing. Blah-blah-blah-blah-blah.

Rachel: "I could write these articles," and then three headlines that they're going to write about. [Laughter] Like someone has told them this is how to submit articles.

Chris: Mm-hmm. It kind of morphs over time, but that's a really common one right now.

Dave: Maybe a good question to end on. What hope is there for me, a man child who can barely spell, to become a technical writer or write for these magazines like Smashing or CSS-Tricks? I think I struggle with basic grammar rules and so how do I, I guess, get myself from a position of being bad at writing to being a contributor?

Rachel: I don't worry too much. We've got copy editors. We've got people because we have quite a lot of people who submit to Smashing who English is not their first language, and that is cool.

We get a lot of people who are new writers. Writing is something that you learn over time. Really, you learn by doing it.

I'm not trained to do writing. I left school at 16 with terrible grades for English. I probably do things that are terribly wrong all the time and I've been heavily edited on many occasions myself.

I'm not looking for wonderful writers. I'm looking for people who are able to clearly explain the thing they do know a lot about, which is whatever bit of technology and what have you. I'm much more interested in the idea and the ability to break that down and teach it.

Spelling, English language usage, and all that sort of stuff, well, we've got people who can look at that, but they haven't got the technical knowledge that you have about your area. I would never say to anyone that they should worry too much. Obviously, you want to try and put across something that's clear and in reasonably good English as best you can manage. But I wouldn't put someone off because they struggle to write sort of correct, good English, whatever that is, because if we've got something that is good technically, we will work with that person to make sure it also then is easy to read and people are going to enjoy reading it as well as getting the information technically from it.

Chris: I would echo that for sure. I don't care about your grammar. That'll get fixed. It's the idea that matters, in a way. Sometimes, if it's too rough, it's like… eh. Even if it's a good idea, we don't have the -- even compared to Smashing, we don't have quite the same resources to get it polished up as well.

Rachel: Yeah.

Chris: Yeah.

Rachel: Certainly, when someone proposes, again, and we do look back and say, "Well, how much work was this person's writing last time?" If we've got a lot of people proposing stuff, there is, to an extent, going to be a sort of case of, well, if we accept this article, we're just going to publish this. [Laughter] Then, certainly, if you get known as a good, reliable writer, you will be able to get published all over the place because, actually, that's quite difficult to find.

Chris: Right.

Rachel: In terms of just being reliable, just doing what you say you will do and submitting things on deadline makers you head and shoulders above the majority of people. I am pretty sure that most of my success in almost everything I've done is because I do what I say I will do on time. [Laughter] People can rely on that I will do that. I think that is really, really helpful, even if you're struggling a bit with English language or whatever it is. If you communicate well with your editor, you put stuff in on time, you hit your deadlines, and you keep talking when you're having problems and maybe you miss a deadline because you're having some problem but you talk about it, you will be known then as a good person to work with. I have got a huge amount of time for people who are nice to work with and who are trying really hard to come up with a really good piece. That's really important, too, about being this reliable person who work with our editor to get the piece really good.

Chris: The motivation is interesting, too, in that, "Why are you doing this?" in a way. Are you exploring this because you think it might be some new career? It's not. Your motivation for doing it -- it's nice. I like that we pay, I like that it's not wasting people's time, and there's a little bit of beer money or something attached to it, in a way. It's a little bit more than that, but you'd have to write so much for just your guest posts on other people's site to be a full on source of income. I guess it depends on where you live in the world and stuff, but it's not.

Dave: I mean a decent side project. Most of my side projects make zero dollars. [Laughter]

Rachel: Yeah. Yeah.

Dave: If you're treating it like that.

Chris: Sure. Like we said at the beginning; this opens up doors too.

Dave: Yeah.

Rachel: Yeah.

Chris: It's good for you in other ways.

Rachel: Yeah, I think to actually make money as a full-time writer, I mean I do a lot of writing, but I'm not really making money from my writing. I'm making money because of the things I know about that I'm able to write up. That's very different. Do you know what I mean? If you've got a niche where you know about a specific subject very, very well and you can write about it, then you're going to get paid a premium over someone who is just documenting things and is just going to do the research and document it because what you're doing there is, you're actually just transmitting your knowledge. It's almost like being a consultant. It's just that you're doing it in words.

Some people do manage to make a reasonable living as a writer, but it is hard work, particularly … submitting stuff. Yeah, I think, for most people, it's a bit of extra money, but it also means that you can put it on your CV. If you're a freelancer or whatever, you can put it on your site that you have been published in these well-known places, which I think is beneficial.

Chris: Right.

Rachel: When I started speaking, public speaking, all of my public speaking people who were contacting me and saying, "Will you speak for us?" were, "I saw this article you wrote and I would love for you to come and talk about that."

Dave: Oh. Yeah.

Chris: There you go.

Rachel: It's a way into that, potentially. If speaking is something you're interested in doing, writing about it lets you explore the subject. Then when you do a call for papers as well, you can say, "Oh, I've already written about this subject and it was published in Smashing," or CSS-Tricks. That's something you can do with your writing.

Yeah. In the early days, I was a freelancer. I mainly worked for other agencies, so we would do development work for design agencies. If I could walk into someone's office and be like, "Oh, I see you've got my book," you're much more likely to get the job. You know? [Laughter]

[Laughter]

Rachel: There are ways that writing itself tends not to make you a lot of money. Even very successful books and things don't make the author a huge amount of money. There has to be another reason, I think, as a professional to be doing that.

Chris: Yeah, it's a big soup. You do some freelance work. You do some writing. You do some speaking. You do whatever - bartending, maybe.

[Laughter]

Dave: Fair. Fair.

Chris: Make it work.

Rachel: Yeah. I do sometimes think folks have very strange expectations about what being published might get them. Also, typically, some of the people who I think would be really great to write for us think that the bar is much, much higher than it actually is, and so almost frightened to submit.

I'll ask people directly and say, "Oh, you know, that was really interesting. Perhaps you could write that up for Smashing." They're like, "Oh, I don't think I'm ready to submit something to Smashing yet." I'd be like, "You could totally be writing for Smashing." [Laughter]

I think if you've got a good idea and are willing to put a bit of work in, most people could be writing stuff. The bar is a lot lower than you think to get in. I'm sure you're the same. We will help good people to get their first piece written. It gets easier from there on in.

Chris: Absolutely. Absolutely. Maybe that's a good place to wrap up here is this, like, how do you--?

Dave: Yeah. We definitely should. Thank you, Rachel, for coming on the show. For people who aren't following you and giving you money, how can they do that?

Rachel: Follow me on Twitter. I'm @RachelAndrew and my website is RachelAndrew.co.uk. Yeah, I'm Editor in Chief of "Smashing Magazine" where there's an awful lot of my writing, as well as everything that I have been editing. That's at SmashingMagazine.com.

Dave: You've been posting about Sub Grid, which is very exciting.

Rachel: Yeah.

Dave: Tune in on your blog there. That's always exciting. Yeah. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Write a review, a technical review for "Smashing Magazine" about our podcast. [Laughter] That's a good place to start.

Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

Chris: We've got a special job opening from the ShopTalk Show job board to tell you about this is a company called Trellis. Trellis is in Medford, Massachusetts, but they're open to remote roles for this as well. They're an agency that largely does e-commerce work, so Magento, Shopify, Big Commerce, that kind of thing.

They're looking for a senior front-end developer with the skills of stuff that we talk about on this show all the time: HTML, CSS, and JavaScript, you know, Modern JavaScript, ES6+ type of stuff. If you know Vue and React, that's nice too. If you have some e-commerce experience, that's nice too, but not required on either of those things.

They're looking for a senior person here, so you're expected to be able to mentor and help other employees and just assist with the architecture of client side solutions. You know, really just think holistically, the things that a senior developer, as we've talked about, should be able to do.

This looks like a great company working in e-commerce at an agency level. Their URL is Trellis.co and the link right to the job posting, which is on their website, will be on the show too. It looks good. You should check it out. Upgrade your life. Upgrade your career.

Become a senior. What if you're not a senior developer now but you should be? Go get that title. Go get it.

Dave: Chris, do you have anything else you'd like to say?

Chris: [Whistles] ShopTalkShow.com.