• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
superman3275

Am I a bad programmer?

29 posts in this topic

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.

0

Share this post


Link to post
Share on other sites

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).
1

Share this post


Link to post
Share on other sites

Should we call that user a bad critic?

 

It is unhealthy an unnecessary to resort to personal judgments of author when critiquing his work.

Fine: "code has A and B problems".

Unnecessary: "therefore author is a bad coder".

1

Share this post


Link to post
Share on other sites
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.
1

Share this post


Link to post
Share on other sites

It was a tutorial specifically for Visual Studio. Thus the system("pause"); and pre-compiled headers.

Edited by superman3275
0

Share this post


Link to post
Share on other sites

Can you post a link to your tutorial, I am intrigued now. Is it the currently unavailable site at hackforums.net?

 

Well if you are going to say that you are writing a book on C++, expect all sorts of critique :)

0

Share this post


Link to post
Share on other sites

This guy just sounds like he wanted to be an asshole. Just improve by further education and at your own pace, you should just not listen to people who are mean and cruel on the internet.

0

Share this post


Link to post
Share on other sites

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.

2

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

I've made the tutorial non-platform specific. Thanks for all the replies.

 

Cheers :)!

0

Share this post


Link to post
Share on other sites

http://scientificninja.com/blog/dont-write-tutorials - Here's a link to an article people have referenced again and again about not writing tutorials when you don't know what you are talking about.

 

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
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. Edited by iMalc
0

Share this post


Link to post
Share on other sites

Unfortunately programming is one of those endeavours where making mistakes is almost a requirement for learning.  Its also one where the vast majority of people aren't at your skill level (ie. in the general populace/school/ect...) and you will mostly find peers either online or at the workplace.  Sadly neither of those 2 places are conducive to making mistakes.  Discussing the pros/cons and hashing over problems should be the norm, but sadly its not.  I post as little as possible online, simply because everything's an argument, nothing's a discussion.  You can post a great response and/or answer (or in your case tutorial) but one little minor mistake that means nothing to the larger picture and you'll be roasted.

 

The only 2 places I've known online (in regards to programming) that had people nice enough that I feel I can post freely is TigSource.com and an indie-gaming facebook page.  The rest I mostly just lurk around on, its not worth the therapy attempting otherwise.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0