Reading the community journals these days is a disheartening task of shoveling through the mud and the muck to find rare gems. As the layers of filth get deeper and deeper, the payoff becomes less and less worth it; hence, The Downward Spiral.

Today I ran across the start of a so-called "tutorial series" on software engineering: The Begining [sic]. I tried to post my thoughts there as a comment, but in the infinite wisdom of the new forum software, users are allowed to moderate comments to their own blogs, so I had to make a separate entry. Besides being a prime example of the previously mentioned "mud and muck", it's also the poster child for Josh Petrie's seminal blog post: Don't Write Tutorials. I'll highlight some relevant sections for you in case you don't want to read it:

Josh Petrie said:

The larger problem with tutorials is that there are just so many of them, and most of them are written by people who at best have only a passing understanding of the subject. Frequently the author lacks even that basic foundation, and just thinks he or she understands the material (see "Unskilled and Unaware of It")..

Stonemetal's tutorial is not software engineering. Encouraging people to do error checking, which is a basic programming practice, is a good idea of course, but he's picked one of the lousiest possible examples to explain it with. But disregarding the "moral" of the post, which is ridiculously narrow and yet manages to be so overly broad as to be useless, let's look at the far worse transgression:

Josh Petrie said:

In short, tutorials should only be written by people who are very experienced – indeed, experts – in the problem domain. Even then there are dangers; just because somebody knows the subject well does not mean they have the requisite communications skill to pass that information on in a clear, understandable format.

Now, it's obvious that stonemetal isn't an expert here. But more than that, the layout, structure, formatting, mechanics, and grammar are absolutely hideous. He's misspelled several words, including the very name of the entry. Furthermore his explanations are scatterbrained, anecdotal, and filled with vague speculation and nonsense like this:

stonemetal said:

So now some definitions of technical terms: right: this method has worked for me in this situation in the past, wrong: doing this has blown up in my face before or typically it makes things harder than necessary.

Since when are those technical terms, and why didn't anyone else get the memo?

stonemetal said:

so how would we do this with exceptions why the function std::cout.exceptions gives you access to what will throw an exception and allow you to set what will throw an exception.

I can't even begin to comprehend what this... "sentence"... is trying to explain, but it's hardly even English.

Please journal writers, for the love of all that is good and decent, do not write more of this. Perpetuating more of this filth on the unsuspecting internet is not only pointless from your end but damaging to any beginners who read it and think you might know what you're talking about. You should spend your time studying real software engineering and programming practices, and work on your communication skills as well while you're at it.