You're using it wrong if you expect it to be prod grade. New comers have a big task of understanding the language & framework. Writing "prod" worthy things is the last thing on their minds

As a side note, I've found some 'gems' from tutorials that I knew were shitty novices or intermediate devs at best just writing to expand their career or do inbound marketing or something, but they made me think about a solution to something differently, or they touched on something I didn't know anything about, having never done it before like some api or auth system.

TLDR: I think with all tutorials it's buyer beware - especially coding tutorials, filter by date, don't expect perfect 10x dev tips unless you're on egghead, laracasts, railscasts, pluralsight (some other coding mooc that claims master level expertise), and if you write posts as a jr/intermediate dev, maybe try coming back to them when you 'level up' and make them better/more relevant.

I was setting up emacs + evil mode the other night to give it a real spin for the first time, one blog post from 2014 was pretty helpful but I suspected I'd have to throw out a bunch of things (if they worked at all) as I got further along and learned more about the ecosystem. Sure enough the way people add packages has changed, but this blog author helpfully updated the post in 2016 with the new information (and left the marked-as-old info there for context).

One reason I hate video tutorials -- I don't want to sit through 30 minutes to figure out the 20 second tidbit I need to know, I don't even read 50% of blog posts I just scan it for what I want and go... lol

If you're going to teach things, make it actually work for what the person reading needs. Personally, the chances of me reading a tutorial for interest vs wanting to accomplish a task are minimal.

Tutorials for learning, articles for interest. I'd say you could do the latter without expert knowledge, but the former needs to be pretty tight.

(All of this with the knowledge that imposter syndrome is so prevalent that we don't want to put off technically brilliant people writing tutorials when they think they might not be up to snuff).

Lots of people on HN bemoan the lack of formalised education and crappy code stitched together, but that's what half arsed tutorials and impenetrable documentation breed.

Well, Google should have done that from the start and there wouldn't be a problem...

Because John experiments with X for the first time and writes about it on his blog. Janette has the same problem while learning about X so she takes his code, makes a few changes and puts it on her blog. This scenario happens 8 more times and we have 10 low quality tutorials about how to do things, but none of the authors has experience and expertise in X, and they won't admit it. Bad practice is copied to many places. 1000 garbage kill 1 gold.

Non experts look for tutorials,

They chance upon tutorials by non-experts

They don't know enough to tell they're junk

They use the code, link to, and suggest those tutorials to others

Those tutorials are getting higher ranks, attracting even more non-experts

There's your problem. If you are writing a "here's how I did it" post, you should be clear that you don't have any idea what you're doing.

There are many more poor quality tutorials written than high quality tutorials because high quality tutorials are much harder to write.

The writer has to know the domain, be up-to-date in the domain, have the communication skills and the time to write and edit.

Learning math makes you feel stupid.

That said...ideally if the author abides by (1) do proper research and (2) "Your tutorial can be reviewed by other brilliant engineers who can point out your mistakes" then there's no reason why you couldn't produce a reasonable quality tutorial in this way.

I think this article is written for developers/engineers who's overall skill level and expertise is a cut above inexperienced folks who're just starting out. i.e. you know how to research, you have a working familiarity with the tech stack you're working with (and broader awareness of other tech stacks), you know how to ask a "good question" on Stack Overflow (or have read and understood Jon Skeet's "Writing the perfect question" article[0]).

It's kinda like taking rubber ducking to the next level and sharing your learning experience.

[0]: https://codeblog.jonskeet.uk/2010/08/29/writing-the-perfect-...

First, some people probably will find what you write to be somewhat useful. Second, it's the absolute best way to learn something.

In your example, the problem was Google, not the myriad of people learning and writing what they learned.

The problem with blog tutorials is that it is democratization without meritocracy. There is no curation mechanism to bubble the good stuff to the top. Search engines rank by popularity, not quality. At least with forums and Q&A sites, there are natural feedback/reputation mechanisms to achieve some semblance of quality control. Blogs don't have that (they only have commenting, which depends on someone caring enough to comment).

This results in very low signal to noise, and a tragedy of the commons situation happens. In most systems, there is a cost to high-volume low-quality content because it discourages participants. (I don't know if you remember MySpace...)

You can't stop people from publishing low quality content, but if only there was a way to curate such content based on some standards (not gatekeeping... but curation). Quora tried and was successful in the early days because it started with a high quality contributor base, but that base has now been diluted and the platform no longer offers an enjoyable experience.

You mean "how not to do things in a stupid way", right?

This especially is annoying when there are simpler parts of some of these currently dense technologies and it's just a bunch of jargon, of what is supposedly introductory content.

I’d rather say, “no tutorial? Ok, to the docs like the old days,” than be misled by a shitty tutorial.

Idk about HN-ers, but I find myself in this situation at least few times a week since the beginning of my webdev.