Hey there fellow developers!
Today, I would like to request your input on a topic that's been on my mind for a while:
**When it comes to technical writing, what do you prefer: a series of smaller articles or a single long one?**
โโโ
I have been thinking of writing about Kotlin functions for a while. I would like to cover the basics, then explain first-class citizenship (lambdas and higher order functions), and finally show one of my favourite concepts: extension functions. But I can't decide between writing one long article or splitting it up into a series of three small ones.
Some people might prefer the convenience of having all the information in one place, and it would make it easier to grasp the links between the concepts. On the other hand, others might like the ability to digest the information in smaller chunks - and long articles may be daring: I may lose my readers mid-point.
So, I would request your input:
- ๐ as readers, what do you prefer? Would you be interested enough to wait on a follow-up in case of a Series?
- ๐ as a writer, what was your experience? Did you witness more or fewer interactions with Series? What would you choose?
I would be very interested in your point of view. Let's start a discussion in the comments and see where it takes us ๐. Your input will definitely help shape the direction of future technical writing.
๐ Thanks for taking the time to read this, and I can't wait to hear your thoughts!
Top comments (19)
As a reader I do believe shorter content are better. You can filter it better, read through everything faster and get the value from the text in less time.
For large chunks of content, a series of short articles is the way to go for me!
I don't have experience as a writer but I'm about to get my feet wet! And shorter articles will be my way to go.
I organize posts as series but I don't actually plan. It is more like me saying to myself "hey these posts relate to each other." There may be several weeks or even months between 2 posts in one of my series. Once in a while 2 posts in a row may end up in same series, in which case I may write as if it was on purpose.
One potential benefit to how I use series is that a new post may draw readers to the old related posts.
From reading perspective, it depends on how long a long article is. It also depends on whether the author is someone I've read before. I mostly browse DEV in the morning while drinking tea or coffee and in evening drinking tea. So I tend to shy away from longer articles. My attention span at those times isn't up to it. But if written by someone I've read often, and if on topic I'm interested in, then I am at least somewhat more willing to read a long post than if author is someone I've never read.
thank you for taking the time!
I must admit the planning is the part I find daring with Series, but your comment makes me realise all doesn't need to be perfectly planned, I should have a try and see.
Another point with Series is, I fear I will want to amend part (if not all) of the previous articles when I start writing a new one on the same subject, and I usually try to avoid editing an article once it is live. One big article written in one go is easier. What is your politic on this? Do you often amend your articles?
I haven't amended many times. When I do, it is mainly to fix a mistake. One example I can think of was when I realized I left out a step in an example GitHub Actions workflow demonstrating how to use an Action I maintain. Most of the times when I edit, it is usually not long after posting it to begin with. Reading it again and realizing I said something poorly. Or discovering a typo. I try not to go back and read older ones or else I'll drive myself nuts fixing things. If an example becomes obsolete because something changed in a library, etc, I'd rather just write something new than to continually update the old (maybe the old version is still useful to someone).
I am for the short article series:
thank you so much for taking the time to share your opinion!
As a writer I tend to favour long articles, as I can write them in one go and stop thinking about it. My opinion is thus biased due to my lack of organisation ^^'. I also fear losing readers, as there is no way to "follow" a single series on dev.to.
In case of a series, how would you organise it? One article per week or per day, publish them all in one go? I am really curious of what others are doing.
One solution would be to write the entire article in another application (e.g. Obsidian), and then publish it "serially" simply by copying and pasting the various sections.
I as a reader (and I think many on this site) follow different tags, and also other feeds (Medium, Hackernews, etc.), so I prefer to have shorter articles, which I can possibly pre-filter already from the content (functions in Kotlin already know them? Perfect, skip the article and wait for next).
If a reader is registered to your feed, they will be notified of each new article (maybe adding links to the series' articles, I often see it done here on dev.to). With a single article instead all updates to the article itself may not be notified to followers and be lost.
About the frequency of publication, I think it depends on your productivity: do you have many articles ready? Then publish them daily. Otherwise, you could keep some "backup" articles and publish them when you have little time to delve into other topics or the "writerโs block" hits you.
This is an example of an article "part of the series": you can see at the beginning of the article a sort of index/TOC that refers to all the articles in the series
I now write most of my articles first in hashnode (blog.derlin.ch) and then crosspost on dev.to. I like your approach, I may test it on the Kotlin article*s*, thank you!
All in one is still the best. If you can't control yourself in the quantities you are digesting, I feel pity. Having to scratch around to find the other bits-n-pieces is frustrating and a waste of time. I mean, use a bookmark to continue where you paused processing. Geez, can it be that hard?
A topic never consists of a single aspect. To process information this way is like reading a comic book through a toilet paper roll; one image at a time. Our minds are more than capable of lateral processing. Think peripheral vision. If we were meant to take in concepts by looking down a pipe, the world would have been designed that way. It isn't.
This goes for writing as well. How can a writer create continuation and flow by stitching something together piecemeal one document at a time. It's unnatural and counterproductive.
Wow, that's a vindictive way of giving your opinion ๐
You make some good points and as a reader I personally prefer the all-in-one as well. I, however, disagree in saying "if you can't take it you suck". Everyone is different, and if as writers we can better convey information and help some readers by splitting it up, I don't see the harm. The question is not "can you take it?" but "how do you like it"?
What I retain is: there is an easy way for readers to turn an article into a series (by bookmarking or such), it is garder the other way around. Thanks for this perspective!
Yes, it is a bit snarky, and I apologise. Call it a bad hair day. Not that I have a lot of it, but yeah. And hey, I never said "suck" anywhere, did I ..? ๐ณ
It frustrates me to find 90% click-bait information out on the web and then it's presented half-assed in about 80% of that 90% of times. The "rush-culture" is breaking us and devolving humanity IMO.
When I read stuff pre-2010-ish the people seem to have done far better work. Detailed, clear, explicit, and yes, long and all in one article. One link, one bookmark and easy to reference in personal notes. If you have a good browser bookmarking system with search functionality town to individual characters, it becomes even easier.
" The question is not 'can you take it?' but 'how do you like it'? "
It should read:
"You can take it to where you want and then stop for a coffee whenever you need to ๐"
I feel you! No offence taken, everyone gets a bit snarky sometimes (and correct: you never said suck, it was over interpretation on my part, sorry).
I agree that the quality can be very low, especially on dev.to. This is especially annoying when as a writer you spend weeks on an article and get 2 upvotes, when a billionth "hidden git commands you must know" listing
pullandpushgets 100.My conundrum is that I love crafting meticulously a nice long article, but I feel like it doesn't get the attention it should. I am wondering if I should "capitulate" and try out Series, which are more in today's trend and would thus boost their chances of getting noticed. But your comments make me wonder. I mostly write for the pleasure of sharing, not for the attention, so following your logic I should stick to the singles. I love your "coffee break" point - this a highly valid one. (Gosh, I am back to square one now ^^').
I totally agree with you about the value most people seem to place on reading material. I have personally decided to ignore all outside trends regarding trying to get people to read. Went the Substack way, tried to get my RSS feed to auto cross-post here to DEV, etc. And found it exactly as you said above; 100 likes for 100-times repeated (and mostly half so, work) and anything that is longer than a 3-min read gets totally ignored.
I learn so much better when โ to quote you โ "crafting meticulously" at something I'm interested in understanding well. And the tools we have available today are great!
I write "manuals" about all the software dev topics I'm learning, 30-50-80 page monsters sometimes. And I make sure that I put them together in a way to make it easy to; find relevant info quickly and easily, even dynamically reference to other "manuals" or a specific section in one, and build up a library covering anything from basic HTML/CSS/JS dev through to NodeJS+PHP back-ends, micro-services, DevOps, CySec, NginX/Apache server config, Cloudflare CDNs, Cloud DBs, API sec, etc.
I mean SW dev is NOT easy. The abstraction layers are hectically fuzzy and obscure to any experienced observer. Adding the IaaS, PaaS underneath it all makes it 10X worse. However, after two years doing this, it's as if the fog is lifting. Frustration levels are down 95% and I can start to see the way all the interdependent components interrelate and form into one huge organism.
And sorry you can't cover that kind of complexity in 3-minute pretzel crumbs, expecting to understand remotely how these things are connected and dependent on each other. If the crumbs aren't connected into a whole pretzel, you have no idea you're even eating a pretzel, forget how it's supposed to look or taste.
I'm chuckling, because it's sad and ironic. People that put their hearts into something and create really good stuff simply gets ignored in favour of the "3-minute Goldfish" material that continues to swirl round and round in a bowl, endlessly repeating itself. In the beginning I had hell eating goldfish food. You spot something new and seemingly shiny, just to find it thin and flaky. Having no substance whatsoever.
So, I decided to start writing for myself, and nobody else. And I love it! If someone really wants to know one possible solution to A,B, or C, that I've covered in public, then great if they read the whole damn thing and benefit from it. There are no "publishing timelines" as I decide to share what I have learned when I'm happy it's of value and forms a distinguishable part of the whole, referencing the whole, and placing it into proper context.
If you feel the need, you can always feed it to folks one page at a time, but the admin load going with that is not worth it in my opinion.
If you want some reading material on SW dev with more substance and value for money, Substack is NOT the place. Well it might change, seeing that you can publish books on there now too it seems, and they have a Stripe payment platform integrated should you want to get paid for your more hardcore stuff. I find SitePoint a very valuable paid subscription seeing there you get steak, eggs, fries, a salad, desert AND a cappuccino for your money. Not to forget Quincy Larson's freeCodeCamp stuff. Many valuable materials and references to quality info there too. DEV.TO has it's value for me in the sense sometimes the commentors refer you to valuable tools and resources, or al least to a starting point of such. And of course to have long-winded conversations here with cool people like you now and then :-)
In ref to; "My conundrum is that I love crafting meticulously a nice long article + (Gosh, I am back to square one now ^^')".
Stick to your guns Lucy. Someday, there will be a reward and an appropriate one. Probably not from the quadrants in the galaxy you are expecting them to come from at the moment, but who knows, you might just peak the interest of the Vulcans or Asgard out there.
I just started a series by writing a long article (8 minute read) and decided to split it.
So I found a natural transition point, wrote and ending/transition paragraph and cut the rest of the article to a new draft. Then wrote an intro reminding the reader where I had stopped in the prior post.
I haven't scheduled publication on it yet, but it's in the chute.
Out of curiosity, how long do you make your posts? I think Vincent may be a typical reader, so I try to keep them under 4 minutes.
Mine are way too long ๐ . And the more I publish, the longer they get. I had some successes on long articles, but it is starting to get out of hand, hence this discussion.
How do you plan to schedule, once a week?
I don't write that much, so probably in two weeks.
If you are looking at more than a 10 minutes read and expect the user to
follow along or the material is dense, I would suggest splitting it into a series. Even two parts is a series.
As a reader I prefer series, as I don't think there is a Table of Contents functionality available.
As a writer, I prefer a single article, because I haven't yet figured out how to create a series.
Actually there is ๐
Finally a clean and easy way to add Table of Contents to dev.to articles ๐คฉ
Lucy Linder ใป Jan 2 ใป 4 min read