   Programming skill level
  I was just curious on how most people from around this forum measure programming skills. Do you go by the amount of theory learned or maybe go by how many games you completed so far? When was the point in your programming history when you came to realize that you were good enough to move on and escape being "new" to the game programming scene?   
  I would say I stopped being 'new' to programming once I started understanding a bit more of the theory of the language. I came to realize things about the language, not just memorize. Suddenly I was able to understand a lot more.   ;  As a general rule, I try not to measure programming skills as much as it can be avoided.  Everyone always has something new to learn, and even very good programmers will make bad design decisions and silly mistakes, especially when working in an unfamiliar area, or with unfamilar tools and/or languages.However, I tend to treat someone as no longer a beginner when they reach the point where they can succesfully take an idea and implement it using an appropriately selected method that gets the job done and isn't overly complex (relative to the task; some tasks are of course just intrinsically complicated).You can be a very good programmer and not have any completed games under your belt for a number of reasons; poor planning/project management skills, lack of assets, lack of time, been working on something else, etc. so I don't really think that's a good way to measure it.Likewise, knowing a lot of theory doesn't mean much if you can't apply it to create a working solution to a given problem.Quote:When was the point in your programming history when you came to realize that you were good enough to move on and escape being "new" to the game programming scene?I think that point would probably be when I realised I was able to help out with a lot of the questions other people often had, and that far more often than not I was able to find answers and solutions to my own problems by myself rather than needing help.  As a beginner I'd tend to ask how I could do something; now when I have questions I'm more likely to be asking how to improve a solution I've already created, or if anyone can point me in the direction of a more elegant solution.   ;  I think I moved up a level when I found that when faced with a problem, I would be thinking of the design of the solution more abstractly than how I would implement it in my language of choice.   ;Quote:Original post by EndarI think I moved up a level when I found that when faced with a problem, I would be thinking of the design of the solution more abstractly than how I would implement it in my language of choice.Well put, that does indeed seem to make a good indicator, I find you tend to come up with better solutions that way.   ;  He who knows not, and knows he knows not, is a beginner. His code has programming errors, and he has not gotten his mind around the fundamental elements of programming in the language he studies. He asks for help (sometimes in an inefficient way) and is grateful for any he receives. Aspect: His code is usually a patchwork of code he has found in tutorials. The indentation is chaotic — often associated with his discovery of a new language feature.New features: The code is modified on the run in an unelegant and inefficient way to create more features.Documentation: Documentation is absent or useless in most cases.Comments: Beginner-oriented comments are sprinkled all around.Safety: The code is mostly unsafe, does not check for exceptional situations, bad input or allocation problems. Code reuse: Wheels are reinvented frequently.Errors: The most frequent compiler errors are syntax errors, typographic errors in identifiers, and similar errors.Then, some beginners think they know enough. They still know not, but do not know they know not. They will comment on languages they have never used, speak as experts and give bad advice on programming concepts they do not fully master. Their early learning steps have crystallized in a particular coding style and approach they will apply to all the problems they encounter. Aspect: Their code is clean — they have a clear idea of how it should be laid out, indented, commented and capitalized. New features: The code they write is usually adapted to executing the task at hand, and either painstakingly readapted or left as-is when the specifications change. Documentation: Documentation explains the intended effects of functions and objects.Comments: Comments explain code that was difficult to write. They explain the 'how', not the 'why'.Safety: In most cases, the only runtime checks present are used to detect runtime errors. Code reuse: Some keep on reinventing wheels. Others embed libraries into their programs.Errors: The most frequent compiler errors are esoteric and compain about non-const referencing to temporary objects, ambiguous base class reinterpret casts, incorrect module signature restriction of a class non-private method, or other advanced errors.Then comes the realization: I know my knowledge is limited. I know my abilities are as well. The defective part in any computer system is the programmer. I realize that I cannot achieve my goal of writing a perfect program from scratch and juggle with concepts it employs at the same time. I understand that my goal is not to write code that runs fast — too many parameters for my brain to handle — or will be useful later — I cannot predict the exact things I will need. Instead, I will write code that can be easily rewritten when necessary — because I cannot plan my program from the beginning — and which protects itself against me — because I am the one true source of all bugs. Aspect: Code is clean and readable. Language features are used to make all operations idiomatic, making the code self-commenting. New features: The parts that require modification are cleanly destroyed and rewritten — source control keeps the old version, and the code was written so rewriting is easy. Documentation: Documentation explains the full behavior of objects and functions. This includes design rationales, behavior in correct and incorrect input or state situations. Important features and modules also get unit and regression tests, examples of idiomatic use, and several hand-picked analogies to give a correct mental picture of the object.Comments: Comments explain code that is difficult to read. It explains the assumptions made, the intent of the code, and why it was written that way instead of another. Only the 'why' is commented, as the 'how' is already handled by self-commenting code.Safety: The code is littered with assertions. A complete minefield is deployed for the bug-prone programmers to wade through.  Code reuse: non-proprietary code is widely used and wrapped in a thin (easy to rewrite) layer of abstraction. Throw-away prototypes and spikes are frequently written apart from the real code, to determine the best use, idiomatic approaches and frequent programmer errors, and then scrapped.Errors: The most frequent compiler error is 'warning treated as error'. The compiler is used with maximum warning settings, and no warnings are left behind.Perhaps there are levels above this one, but I do not know enough to tell.   ;Quote:Original post by ToohrVykThen, some beginners think they know enough. They still know not, but do not know they know not. They will comment on languages they have never used, speak as experts and give bad advice on programming concepts they do not fully master. Their early learning steps have crystallized in a particular coding style and approach they will apply to all the problems they encounter. Aspect: Their code is clean — they have a clear idea of how it should be laid out, indented, commented and capitalized. New features: The code they write is usually adapted to executing the task at hand, and either painstakingly readapted or left as-is when the specifications change. Documentation: Documentation explains the intended effects of functions and objects.Comments: Comments explain code that was difficult to write. They explain the 'how', not the 'why'.Safety: In most cases, the only runtime checks present are used to detect runtime errors. Code reuse: Some keep on reinventing wheels. Others embed libraries into their programs.Errors: The most frequent compiler errors are esoteric and compain about non-const referencing to temporary objects, ambiguous base class reinterpret casts, incorrect module signature restriction of a class non-private method, or other advanced errors.Oh! Oh! Oh! This is me!! Yay, I've levelled up! [wink]I also know that I know nothing so maybe one day I will attained the vaulted third level...[smile][smile][smile]