There are of course exceptions to this, but it covers at least 90% of the people who create courses for sites like Udemy.
Comes back to the old saying, "Those who can, do. Those who can't, teach."
There are of course exceptions to this, but it covers at least 90% of the people who create courses for sites like Udemy.
Comes back to the old saying, "Those who can, do. Those who can't, teach."
My theory is that exposition is hard. Most people are shit at teaching.
To summarize them, people write free tutorials because they cannot do (they're bad developers), because they reap some sort of financial gain, or because they actually want to ruin an HNer's day who demanded amazing, free content.
I encourage all of you to try and write a tutorial. You'll see that it's simply hard. You have to decide on what level of skill to aim at, you need to think what this hypothetical person already knows vs doesn't know, you have to keep your tutorial aimed at this balance, you have to resist the temptation to yak-shave, and you have to resist the temptation to adulterate your tutorial with production concerns.
It's not clear-cut at all. Do you add this package because it's how you do it in production? Or do you show how to do it without it? And if you go for the latter, you probably want to at least point out that the package exists. And while you're there, why not include a quick example of how that package can sponge up some of the tutorial code? Maybe that would be more encouraging/illuminating? Are you going to help more people with this example than you're going to confuse? Is someone on HN going to call you meandering and incompetent because you chose to?
Teaching is a skill. Criticism can help people to learn how to do it better, devaluing everyone who even tries leads to culture where people won't put effort into it even if they could be good. All that because someone needed to feel superior for doing nothing.
"Those who can, do; Those who can't, teach."
You don't realize who bad most tutorials/courses are until you encounter one that is as logical, well-explained, and progressive as Maximilian's are.
Not just writers, most tutorials are objectively terrible.
Trying to find a reasonable example on how to get something moderately complex off the ground is a humbling reminder of the Dunning-Kruger effect. The probability of an internet resource being highly ranked and visible has a near-linear correlation with the resource's unsuitability.
In fact, when it comes to technology, it appears to me that the most prominent authors are barely novices themselves. To make things worse, the instructions and "guidelines" they come up with are invariably as competent as encouraging to use SSL_NO_VERIFY flag because passing CA path is too difficult.
My mechanism for coping on the internet is simple: whenever I see a tutorial on anything non-trivial, I just assume it's been written on Sunday afternoon, after the author discovered the software on Friday night. These tutorials should be considered the modern-day equivalent of their author smiling from ear to ear and shouting "look ma, no hands!".
Which traditionally has been the augur of "look ma, no teef!"
And if they did spend extra time on that people would complain they are trying to teach two technologies at once.
Also that’s something everyone unless it is part of their day job has to look up a tutorial on how to do it.
Just a passing “this is for ease of use, don’t do it in production and consult a manual” would suffice.
It's the ones where spotting and debugging the source of the problem depends on fine-grained conceptual understanding, that leads to documentation that gives you a metaphorical blank stare and shrug.
"Those who can, do. Those who can't, teach. Those who can't teach, CONSULT."