I recently went on hackforums.net and started writing tutorials. Immediately, a user called Gamma started calling me a terrible programmer, pointing out many things in my tutorials (all in the first actually. Most of them were because he hated system("pause"); and visual studio's pre-compiled headers). Do you think I'm a bad programmer? Do you know of any ways I can improve my programming.

I'm sure, that there are lot of things you can improve on, I think every programmer should improve all the time. But all programmers have their own preferences and tastes when it comes down to programming styles, workflow etc. As long as you don't write tutorials about things commonly seen as bad programming behavior and only a single person points out, that you have some issues, all is ok. Best to pick up the issues, the other programmer has pointed out, do some research and/or discuss the issues on a forum and try to learn from it, either your coding style is ok or it could be improved, both are valid results.

A bad programmer is someone whom can never get anything to work or work correctly.

It comes down to style and the flow of the code. Do you comment on your code for routines that maynot be obvious to others, especially to those who are trying to learn from your code. I know from personal experience that a lot of variables can be a lot of confussion. Many coders are consistant with their code from their point of view with their variables.

This may mean something totally different to another coder.

If it works, you are a good programmer. If no one understands why it works, you are just a bad coder.

I recently went on hackforums.net and started writing tutorials. Immediately, a user called Gamma started calling me a terrible programmer, pointing out many things in my tutorials (all in the first actually. Most of them were because he hated system("pause"); and visual studio's pre-compiled headers). Do you think I'm a bad programmer? Do you know of any ways I can improve my programming.

Regarding the system("pause") issue, I would never ever write that in code used in a tutorial for general (and especially newbie) consumption. Using it as a quick, intermediate workaround for a particular debug issue for yourself is one thing but is has too many issues to be considered for any form of general use.I'm unaware of the general audience of hackforums.net, but unless these were explicitly MSVC-only tutorials, using MSVC-specific pre-compiled headers would not sit well with me either. When I hear tutorial, I would expect them to work reasonably well on the big three (MSVC, gcc and Clang).

I would not be so hasty to judge the critic. For the general case both examples cited do not sit well with me either and I would consider them tutorial smells. If those are present, there is high danger of more problems.

The common theme is that when someone posts a tutorial, someone out there feels threatened and can’t accept growing young minds.

Those people need to hold their place of respect amongst the forum-goers (which is likely the only respect they have gotten yet) and need to bash in any way they can any new tutorials etc. that suddenly appear.

(I have been accused of needing to brush up on my psychology here. Seriously? How else do you think I got where I am?)

You need to ignore that crap and move on. Frankly their reputations can be daunting, but with time you can surpass them, especially as your own knowledge grows.

That also does not mean your content is perfect.

A real-world example is when someone posted an auto-aim tutorial on gamehacking.com using Euler angles to calculate which direction to aim, to which I strongly wanted to reply with some advice on making that calculation easier to handle (use vectors).

But it’s okay for a tutorial to have a few flaws. I have made flawed tutorials myself. I let it go because beginners can probably relate to it better anyway.

Only people with inferiority issues complain about the little details, and it is nothing but a chance for them to show to everyone else on the forum how much more than you they know.

Don’t let it get to you. You need to mainly realize when criticism is real and when it is just a power-play. Some criticism can teach you. Those people tend to seem more calm and try to shed their critiques in more positive light by trying to overshadow their negatives with positives, trying to give more compliments than criticism.

Ultimately you don’t need to worry about your own level regardless of what others say.

Firstly, I have made crap-tastic and utterly wrong tutorials or explanations myself, but I kept learning and later realized that for myself.

Everyone, including the highest-ranking members here, learns from ground zero.

I recently went on hackforums.net and started writing tutorials. Immediately, a user called Gamma started calling me a terrible programmer, pointing out many things in my tutorials (all in the first actually. Most of them were because he hated system("pause"); and visual studio's pre-compiled headers). Do you think I'm a bad programmer? Do you know of any ways I can improve my programming.

Well I can't speak for hackforums.net, but I know from what I've seen at GDN is this. If you are putting out a tutorial, there will be vigorious debate. Normally not with you, but with the other people posting in the thread. Your job however is not to get sensitive and act like the sky is falling. Your job is to take notes. Ask questions. Follow up. And demonstrate that you are bettering your code but more importantly your skills. There'll be an asshat from time to time. The community does a good job of checking those types of people. So don't worry about it. In general, tell your credentials (n00b, beginner, intermediate, "think I understand this", or advanced) and we'll give the appropriate level of feedback and guidance.

In short, NO you're NOT a bad programmer. The way you improve is to write code and post code and let others help you help yourself.

Beginner in Game Development? Read here.Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts

Spoiler

How on earth can you go around telling lies, be shown that they are lies, then continue to ignore the evidence to the contrary. I'm not qualified to deal with this, sorry. - HodgmanNever crash to desktop. That's the equivalent of a Starbucks rep punching you in the face when you try to order a coffee with soymilk when they run out of soymilk. - KoobazaurFor programmers, R & D means "Research & Duplicate".Just remember... XML is like violence. If it doesn't work, you just aren't using enough of it... - MoeEvery time I go into my account settings I feel like I've never used the internet before. - booleanPerson X: Do you want to live forever?
Person Y: No, but I want to live a long life.
Person X: Only cowards live that long.
Person Y: And yet, we travel to seek the counsel of these "cowards".

Another thing to consider is whether you are actually qualified to write a tutorial. Frankly, there's an over-abundance of increadibly bad tutorials that result from someone who spent last week reading a book, and this week writing a tuturial based on their fledgling understanding of the material. I'm not saying don't write, don't contribute, don't share -- I'm saying that a 'tutorial' ought to teach good practices, and good practices are only apparent with experience.

If you are not well-versed in the subject that you want to write about, consider writing about it in some format other than a tutorial -- Share what you learned in a blog post, for example, and disclaim that you are still learning this stuff too. This kind of content doesn't require expertise, but can still be a useful starting point for others who are trying to reach the level you got to, where they can learn from your mistakes.

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.

A "bad" programmer as opposed to a "good" programmer is pretty subjective. I say that if you can bring your software designs to life, and they're stable, then you're a decent programmer. Especially if it's complex... if you have a complex project, and it works as it should without frequent crashes, then whatever you're doing on the back end is good enough!

Keep in mind that just like everything else, programmers are going to keep getting better. Your styles will change, and the way you perceive how code works will change. If you doubt yourself, watch documentaries from Bungie, Naughty Dog, or any other AAA studio, and they'll explain how limited their first project is when they first started as a company or when they first started working on a platform. They always end up reflecting back on their last project taking the wisdom they gained from that experience. They were able to iron out the shortcomings they found from before and build on it.

Look at the jump in graphical quality between Naughty Dog's Uncharted 1 and 2, or Bungie's Halo 3 and Reach. They refined their code that worked at the time, and made something spectacular in the end.

I think that using things like system("pause") is just fine for a tutorial. for one, you would typically present a tutorial by making everything that is not what the tutorial is focused on as simple as possible. I'm sure your use of system("pause") gets the job done for what it needs, and is simpler than other solutions.

However, I would also recommend that you leave comments in your tutorial code at shortcuts like this to say something to this effect: "I used this code because it accomplishes [blah blah blah] in a quick and easy way. If the Tutorial where focused on [same blah blah blah] I would have used something like this: [link to better code example]"

The point is that a good tutorial is usually focused on covering only one key topic (potentially multiple if strongly related) and that all other areas should require as little effort in understanding as possible. 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.

Moltar - "Do you even know how to use that?"

Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."

What I really love about this is the update link added three years later, where the author has to update his explanation. So the quick tutorial about why making tutorials is wrong... was wrong.

Great tutorial writers make mistakes. That's how people learn. The only failure would be giving up and not learning from your mistakes.

I think that article is likely taking the Dunning-Kruger effect into account. The less you know, the more you think you know (or the less you can figure out what you don't know).

But it's also a common observation of mine that even masters of a craft can be terrible at teaching. I DJ as a hobby and in the DJ world Q-Bert is regarded as a god, but his video tutorial series are lacking in approach to beginners (and they were aimed for beginners). Then I find someone else's tutorials that may not have the reputation and fame of the other guy, but they are a lot more helpful and easier to understand.