Frankly, I am a little disappointment in the general tone of this thread. With the exception of Nercury. Whom seems to have actually taken the time to look at the tutorial in question. From there he seems to offer constructive critisism. In my mind that deserves a big plus.

Where I am disapointed is that most (Not All) are to eagar to condem the original critisizer to Superman, apparently equally as harsh as we are assuming he critisized Superman.

Over Time coming here and Have gained a great amount of respect for everyone in the way you help others including Ms. L.Spiro, but in this matter, and please correct me if I am Mis-interperting what I read, ( That happens from time to time, and if I am wrong, then I am wrong ) but I get the generalization as if she is condoning bad coding simply because someone else may have critisized.

Again, I maybe reading it incorrectly, I personally am a little tired today, but felt compelled to comment.

I disagree with the "If it works, you are a good programmer" comment made earlier in this thread. Anyone can write a program by making mass use of copy and paste, thoroughly violate the Law of Demeter, use nothing but globals, use only gotos for program flow, put all the code in one source file etc, and create a perfectly functioning program.

Frankly I think the best person to judge whether you are a "bad programmer" or not, is the person who has to maintain your code, though that's only fair if that code is not very old.
Even then, what would really make such a person a "bad programmer" in my view, would be someone who did not learn from their mistakes.

In your tutorial, there are a few things that I would tidy up.
Remove the semi-colon from this line:

In this case, we #include <iostream>;.

endl should not appear with a captial E, even if it starts a sentence.
It now goes from _tmain to main, then back to _tmain and finally back to main again. Having main at all rather than _tmain, makes this seem a bit silly, imho. You're clearly very much teaching someone how to make their first program in Visual Studio, and immediately try and abandon what will work perfectly fine in Visual Studio, with no explanation as to why. Chances are, they are better off leaving well alone and wont care about portability yet.
There's nothing wrong with having using namespace std; in the cpp file with such a small program either. Don't just change these things because one person prefers doing it a different way. Instead, I would explain why it is there, and when one would be better off to remove it.

Sometimes the critic is wrong, and yes that will sometimes mean me too.

Frankly, I am a little disappointment in the general tone of this thread. With the exception of Nercury. Whom seems to have actually taken the time to look at the tutorial in question. From there he seems to offer constructive critisism. In my mind that deserves a big plus.

Where I am disapointed is that most (Not All) are to eagar to condem the original critisizer to Superman, apparently equally as harsh as we are assuming he critisized Superman.

Over Time coming here and Have gained a great amount of respect for everyone in the way you help others including Ms. L.Spiro, but in this matter, and please correct me if I am Mis-interperting what I read, ( That happens from time to time, and if I am wrong, then I am wrong ) but I get the generalization as if she is condoning bad coding simply because someone else may have critisized.

Again, I maybe reading it incorrectly, I personally am a little tired today, but felt compelled to comment.

I was not able to find the actual tutorial, but I wanted to make it clear that someone’s code may still be crap.
That still doesn’t make one a bad programmer. I too have made tutorials with crap code.

The point is it doesn’t really matter so much when you are just starting out and even less when you are trying to help a community.
There is a tolerance level that changes depending on what you are doing, and even when that level is breached the people who call you out on it still need to show a little tact.

I did look for the tutorial but since I could not find it I don’t know how it was criticized. But it’s generally not done well on those kinds of sites (don’t let sites such as this spoil you) and it seems to have left a mark on the original poster.


L. Spiro

A bad programmer is unwilling to learn and develop their craft. An inexperienced programmer is new to the craft. These are not the same.

I disagree with the mentality that you should be an expert in your field before offering advice or tutorials. Sharing information, (even small snippets) to help others get started is a key way of distributing knowledge in communities. Though, if you're going to offer advice, its your responsibility to amend that information if you discover it is wrong or "not the done thing".

Trying to teach other people what you know (especially through some sort of peer-reviewed process), is the surest way of finding out what you *really* know about a topic, as opposed to what you *think* you know.

I cannot fault the OP's attempts to pass information on. Even experts get started by reading someone else's tutorials.

The question shouldn't be "Am I a bad programmer" because it may be that we were ALL bad programmer when we're just learning. I know I was.

But, at the time, I didn't realize I was a bad programmer (this was before the internet). I would have probably been proud of my work, but that's because I didn't know...what I didn't know (Reminds me of the Oscar Wilde quote, "Youth is wasted on the young.")

Anyway, the question you should be asking is "Am I an experienced enough programmer to provide tutorials?" Because "bad" and "inexperienced" often could be seen as going hand and hand.

Couldn't have said it better. Everyone was once a bad programmer. Even good programmers have room to improve -- you are always learning. With that being said, BeerNutts is right. The question is "Am I an experienced enough programmer to provide tutorials." Even if you can answer that question with a yes, you have to realize that this is the internet, and on the internet, you are going to get critiqued.

Someone could get upset at a hello world app tutorial because an application that only writes out a line of hard coded text is essentially useless, but that is not a reflection on the tutorial's quality.

Very true -- I would just chalk it up to "haters gonna' hate" and move on.

Finally, like a lot of people, I would advise against the "System("pause")" call. Unless the tutorial is specifically about the Windows, and even then, there are better ways of doing it.

In my opinion, there's no clear-cut way to decide when one is qualified to write a tutorial, but. whoever does should be expert enough to know and tell about simplifying shortcuts like system("pause"). On the other side, it's sometimes pretty hard to write a concise tutorial for beginners without using shortcuts, swamping the newbie with endless details about why not to use "using namespace std" and to use "std::cin.get()" instead of "system("pause")". The key here is to know what you're writing about, who you're talking to and to keep it to the point.

There's also many ways to approach and solve a problem, and in tutorials you may see suggestions like "I would have done it this way, it would run more efficiently" or similar responses.

There is a place and situation for each kind of approach. Depending on the level of expertise targeted for the tutorial, it may not be ideal to use the best solution but the one that makes the most sense for that audience. But what is more important is that if there are any notable bugs or mistakes in the tutorial that make the sample not work as intended, they should be pointed out and corrected when they are found.

As someone who writes a great deal of tutorials, and even just published his very first book just recently, this is an area I find a bit tricky.

It's not a matter of being qualified to write a tutorial, I wrote a C++ tutorial that has been incredibly well received, but I am by no means the greatest C++ programmer in the world. ( Far from it, I've been using higher level languages for most of the prior decade, so I certainly don't know the nitty gritty and can get absolutely schooled on the subject by some of the posters on this forum ).

So, why did I write it? Mostly because I looked at the other tutorials out there and found them really really really bad. The basic "qualification" for writing a tutorial is knowledge of a subject and a willingness to sacrifice your time. Not really all the much more.

The biggest thing though, I vetted my tutorial, this one and all others I've written, and respond to the feedback of others. If you make a mistake, address it. I was really lazy about my const-ness for example. If you don't really understand the topic you are writing about, please just don't do it. We all make mistakes, it's a matter of fixing them, as if you make a mistake in a tutorial, its magnified many times over by the people that read it.

That's the painful part of it. Many people are writing tutorials, or worse, recording screencasts and teaching subjects they REALLY shouldn't be talking about. They perpetrate harmful falsehoods, or worse, teach outright bad information. I have heard this complaint levelled against The New Boston, many many many times, although I've never personally gone through his tutorials.

This ranks up with people making language recommendations in the beginner forums, who have no experience. It's nice that you want to help with your 2cents, but in many cases, you in fact aren't helping. You can't honestly comment on a programming language's merits for example, until you've had years of experience, with i and other languages. Otherwise you are mostly just spreading misinformation and hearsay.

I remember you specifically, on these forums when you just joined, creating a tutorial at the same time you were fumbling through the basics of C++. You took a lot of flak for it here too, and pulled your tutorial down. You've gained a deal of experience since, so I am not making any acquisitions but generally you shouldn't make tutorials before you really understand a concept. Instead perhaps release it as a developer diary, there is a difference.

The final thing to remember, especially if you are going to create tutorials or guides, or whatever... a lot of people on the internet are dicks. Truth told though, they are mostly a minority. When I do tutorials, even if I make a mistake or outright get somethings wrong ( we are all human ), I find the majority of people are incredibly thankful and pleasant over all.

If you are doing a tutorial series, vet it here. Don't post it as a tutorial, post it as a WIP. The community will do a damned good job of letting you know if you are ready or not to be creating tutorials on the subject or not, and if you incorporate the best of the feedback, your tutorial will be all the better for it.

One other thing to keep in mind is, you will also run into situation where people disagree with *HOW* you do something... this is the art side of programming coming to the fore. It is quite possible for both parties ( you and your criticizer ) to be right, or both wrong. So just because someone disagrees with you, it doesn't mean you are wrong.

Finally, if you launch an application in Visual studio with CTRL + F5 ( I believe thats the key combo ), it will automatically prompt for a keypress before closing the console window.

Finally, if you launch an application in Visual studio with CTRL + F5 ( I believe thats the key combo ), it will automatically prompt for a keypress before closing the console window.

That shortcut is extremely useful, but it's important to remember that it means "run without debugging". You can't step through your code or hit breakpoints. Of course that shouldn't be an issue, because if you ARE debugging, just set a breakpoint at the end of main. Also, it only works if you configure the project to "system" console (if you created an empty project, you have to do that manually).

Writing a good tutorial has two requirements. You don't just need a good grasp of the subject at hand, but you also need the ability to teach and explain. We had plenty of tutors at university who really knew their stuff, but absolutely sucked at conveying that knowledge. So the tutors where happy to get their money and the students stopped showing up, because it was a waste of time.

So essentially the number of people qualified and willing to write a really good tutorial is rather limited.

In terms of diary, I remember doing that when I felt like rewriting JA2. I gave up after 5 days, because I spent more time writing than programming. Of course if you write about it, you get ideas or notice mistakes, so you always constantly change between coding and blabbering. Technically a good thing for your code, but also very time consuming. Looking at it now, it just makes me cringe and go "why didn't you just use TBB and boost instead of rolling your own?" However, it had the advantage of not hurting anyone. Not only because nobody ever read it, but because it never had the intention of "teaching how it's done".

I'd still suggest doing that instead, because explaining why you do something forces you to think about it, which will typically lead to research and understanding.

While I'd like to think I'm good enough at C++, I still wouldn't write tutorials, because I suck at explaining things in a concise way while still being "complete". Also, there already are a million books and tutorials about all the basic stuff, so I would just add to the noise. Maybe if I ever come up with something that I feel is "new" or important enough to be shared.

But heads up, the price for worst C++ tutorial ever goes to whoever wrote that the "int" in "int main" means "start program execution here" and that the "return 0" at the end doesn't really mean anything, but just has to be there. That looked like somebody just read the back cover of "C++ for Dummies" and felt like writing a tutorial about all the things that mystified him.