If I'm trying to BUILD an audience, I'm going to write content for free. If I already have a website I post content on, you bet I'm going to keep posting my free content there. Why am I competing with Substack on SEO for my own free content? That's just stupid.
Eventually, if I actually get an audience that's willing to pay, I would use Substack to offer that walled garden. Just like Youtube creators offer their free content on Youtube, and paid content through other means like Patreon.
Even Medium supports canonical URLs. I'm not sure why Substack isn't satisfied with being the distributor of my content, but also wants to be the home for it.
That was one of the reasons I decided to go with my own platform. But Substack is not like Medium because it provides less discovery and more of a platform for writers. Medium, on the other hand, is more like an aggregator.
I was glad to see the canonical URL issue mentioned in your post, since that was the main thing bugging me about Substack. Thanks for writing this!
When I sent Substack Support an email about the issues of content ownership and canonical URLs in late May this year, I got this response:
>On Substack writers own all of their content, but we don't support synchronizing with external website or have external websites as the canonical url. Substack is meant to be the home for individual writers. Sorry about that
I love many things about Substack. Chiefly, the user experience of setting up the newsletters, and the iframe embed (though it can be improved) are great.
But I hope Substack reconsiders what their idea of being a "home for individual writers" means. Substack shouldn't have to be the source of my content, but rather be the plumbing for it. It seems not supporting custom canonical URLs was a conscious decision to force me to make Substack the source of my content, which is disappointing.
I'll have to look into ConvertKit in the meantime.
I was only given at most a couple of weeks to provide feedback which like everyone else here was negative.
But to have it launch now means that they never had any intention of listening to real feedback. They just wanted to see if there were any showstopper bugs.
I gave feedback too and never heard anything. The rounded corners look cartoonish, the header is terrible, moving releases and using a new column at the right is terrible. Seriously w-t-h are they thinking? there was literally nothing wrong with their existing UI.
I'd make the languages bar expanded by default, and for repositories where I rarely contribute hide file list elsewhere (like on mobile), bringing README to the top.
Not necessarily. I've seen the concept of "vocal minority vs silent majority" used as justification to push through a change. So even if you get only bad feedback, it still goes through because most people said nothing, which means most people like it.
Or most people hated it but didn't love the product enough to care to comment. Perhaps the design of the feedback form matters. I wasn't part of the beta so I don't know how they asked.
They didn't ask, you have to go into the feature view menu (under profile) and then click a link there to go to another page and then have a form to fill out.
They know UX for sure!
Maybe we should send them a copy of Don't Make Me Think
Same here - but it also feels like I got the feature preview notification maybe a week before the feature actually launched, two weeks max. Didn't feel like enough time for me to properly test the new interface, or for them to properly evaluate feedback.
I gave some feedback on this as well but unfortunately I only saw the preview like, two days ago. Have I just missed it or did they not roll this preview out earlier?
I got it on 19th June (I remember because it was the day GitHub went down). I left feedback, but it feels like it would've been a foregone conclusion at that point.
I think there's four things I suggest you consider.
1. Writing is thinking [1][2][3]
There are a number of articles that explain this concept better than I can here, but assuming you understand the idea, I'll continue.
The next time you're thinking about some problem, try to write your thoughts and reasoning down as notes. Your writing should be an extension of reasoning, and help formulate and refine your ideas. Whether your notes are on paper or by pixel shouldn't matter, but just get your ideas down. Next, order these ideas by logical progression: maybe one concept leads you to the next, so order them in that progression. Finally, make sure the links between each idea are not leaps in thought but rather fluid and clear progressions. Fill in the gaps as necessary.
Now you should have an outline for your article. At this point, I've found it's more or less a matter of expanding on and explaining each idea more thoroughly. Of course, the hook and conclusion are less well-defined.
For me, if it's really something I care about writing a post about, I've found I've already done the note-taking part at least. After that, the post seems to write itself.
If you don't already take notes or use writing to help you think, I recommend taking this as a first step to helping you write your blog posts. I personally prefer pen and paper, since I can still keep the mistakes around!
2. Write for yourself
Assume no one is going to read your article, at first. Write the article that you would enjoy reading, had you found it on the internet. If you chase external gratifications like writing for others' approval or maybe view counts, your consistency and follow-through will suffer. If you write for your own satisfaction, regardless of whether or not anyone will ever read it, you probably have a better chance of finishing the piece. Because it's what you really want to do! Try not to think about how many hits your article will or won't get, or whether or not people will like it. That stuff comes later.
When you write something for yourself, the care and attention you give it will definitely show. I'm sure you've heard of the idea that internal motivation is generally stronger than external kinds.
Once you've come up with something you're reasonably satisfied with, send it to your friends and family to read over and edit. Maybe ask people you respect (and trust) in the community to help you edit your posts before publication (if correctness about your ideas is something you're really worried about). Just because you wrote something for yourself does not mean it's perfect and exempt from criticism.
3. Write the poetry later
If you struggle as I do with making each sentence "perfect" before moving onto the next, know that you're not alone. But sometimes it's just best to write the ideas down, get the meat of the content written out and explained, and then come back later to frame it as a story. Maybe this is a matter of 'do as I say, and not as I do' ;)
4. Consistency is a consequence of planning
If you don't set aside time in your day to write or do your thinking, kiss your chances goodbye. Treat it like a side-project, or better yet your job, to write this blog post. Set reasonable goals for yourself, just like you would with a software project. Start small, by writing your thoughts down and ordering them like I mentioned above. Always keep in mind why you're writing the post in the first place!
Thanks so much for the detailed response. That's all great advice.
I especially like "1. Writing is thinking", I've always thought of blog posts to be like story-telling, but for many technical blog-posts story-telling doesn't work. I guess just explaining the idea logically is a much better approach... (I can't believe how obvious this sounds)
Simon Peyton-Jones expands on the GP's 1st point – that you don't afterwards write up your 'research' (i.e. anything you are thinking about/learning/doing etc), but before, during, after - the writing guides, informs, directs what you learn, every step of the way:
Most of that applies to all kinds of non-fiction writing I think. A lot of it's common-sense principles that sound obvious, but most people don't actually follow, so their writing isn't great. If you loved that, you'll also like his How To Give a Great Research Talkhttps://www.youtube.com/watch?v=sT_-owjKIbA
When I first encountered Go in 2015, it was exciting because it made concurrent programming accessible and easy compared to the competition. Fast forward to 2020, and many languages have either caught up or improved on the advances Go made (e.g. Kotlin, Rust, Elixir, Scala, etc.). That being said, I think you might be in a bubble if you don't know anyone using Go. It's everywhere nowadays, for better or worse.
I agree with you that I think they're slow to improve. I'm not sure if innovation is necessary though, since most people rely on the language being stable going forward.
Personally I struggle with deciding when to use Go for a new project. With so many languages now supporting different concurrency paradigms, and containers abstracting away prior deployment pain points, I'm not sure why I'd reach for Go over any of the others.
Agreed, and thanks for links!