|< How to write about a topic that has already been covered elsewhere||Tips for delivering a programming talk >|
Recorded – watch the full episode on YouTube.
Can you summarize for us what the John Sundell writing process looks like?
John Sundell: This is something I've been also shaping over the years, but I started out with a kind of rigid process.
This is something that I think also led to me being able to consistently write every single week is that I decided that I am not going to spend days or weeks writing articles, because had tried that before. That's again why the Sundell Swift failed. That's why I had 50 different drafts in my medium account with super long elaborate articles that was super advanced that never kind of were published and never got anywhere, because I just had too grand ambitions for everything. And I felt like I needed to do that in order to write something relevant.
"I decided that I am not going to spend days or weeks writing articles, because had tried that before."
I just needed to decide I need a more streamlined process. So I decided that I'm not going to write an article that's going to take more than three hours to write. From the moment I sit down till the moment I publish, it's just going to be three hours. That's how I started, because that's what I felt like, that's the time I had to dedicate every single week. This is a big commitment to do every single week, even if you're traveling or you're sick or you're working or you're busy, you have to find that time. And I felt like three hours was something that I could spare every single week.
So what did that mean? Well, can you write anything in three hours? No, of course not. You have to then adapt your topics. You have to adapt how you write to the timeframe. I think that's also important. When you're scoping out a project, there's this classic thing, you can either cut scope or you can give yourself more time. And for me, I didn't want to give myself more time, so I needed to cut scope. So that's why my articles naturally became short, easier to write, easier to read also. And I could keep producing them every single week.
Since then, now that I've, for the last year, I've been doing this full time, which means that I have more time to write. So now I will do sometimes a little bit more ambitious articles. Like, the last article I published, which was a guide to the SwiftUI layout system, which is a two parter, which I'm finishing tomorrow. And that's another thing about cutting scope. I realized that article was going long, so how do I cut scope then. I was in the middle of writing. I was like, “Well, I'm just going to do a two parter.” And that's something that I do occasionally as well. I just split things up into two parts and then I can do part one one week and part two the second week.
“So my process has evolved over the years and I think it needs to always, to keep things fresh.”
But that's the type of article that I probably wouldn't have written back in the day. Not that broad. Like, let me write a guide to the SwiftUI system. I would probably have narrowed it down a lot more and say, I'm just going to write about
VStack or I'm just going to write about this or that to narrow it down more. So my process has evolved over the years and I think it needs to always, to keep things fresh. I'm very happy with the way I started with that like, narrow time constraints in order to be able to deliver every single week.
Paul Hudson: I seem to recall again, from your Sundell’s Swift talk at App Builders, you mentioned that a marker for you, a clear point where you've gone wrong was, if you have to have a table of contents in your article, it's too long. You've got to start cutting stuff back.
“So keeping things lean and simple has always been important for me, to keep the word count fairly low, to keep things so you can read them in like 15 minutes maximum or something like that.”
John Sundell: Exactly. I never want to have a table of contents. In fact, myself also, when I open up an article that someone linked to me or something, and it starts with a table of contents, I will almost always just close it. Sorry for anyone who writes table of contents in their articles. I rarely have the time to really sit down and read such a piece, especially if I'm just on the computer at the time just doing some other work.
So keeping things lean and simple has always been important for me, to keep the word count fairly low, to keep things so you can read them in like 15 minutes maximum or something like that. That's always been very important for me. So, yeah, that's, that's definitely like if you feel like you need to add a table of contents, I would punch that. Maybe you just split it up into multiple articles or you need to find a way to specialize your topic a little bit more so that you can write about it in a more concise way.
This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.
SPONSORED ViRE offers discoverable way of working with regex. It provides really readable regex experience, code complete & cheat sheet, unit tests, powerful replace system, step-by-step search & replace, regex visual scheme, regex history & playground. ViRE is available on Mac & iPad.
Link copied to your pasteboard.