note eyepopslikeamosquito I suggest you start at least thinking about the basic skills needed by working developers. My experience with new graduates at our company is that, despite having studied "computer science" for a number of years, there are often gaping holes in their basic, practical software development technique, such as: <ul> <li> Always use a revision control system. <li> Use a single-step automated build. <li> Avoid duplication (<a href="http://en.wikipedia.org/wiki/Don't_repeat_yourself">DRY</a>). <li> Descriptive, explanatory, consistent and regular names. <li> Useful commenting and documentation. <li> Design the module's interface first. <li> Sound domain abstractions. <li> Wise program decomposition. <li> Encapsulation. <li> Highly cohesive, loosely coupled modules. <li> Minimize the exposure of implementation details. <li> Minimize the scope of variables, pragmas, etc. <li> Write components that are testable in isolation. <li> Write the test cases before you write the code. <li> Add new test cases before you start debugging. <li> Establish a rational error handling policy and follow it strictly. <li> "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live" (Damian Conway) </ul> Many of these tips were taken from [id://744932]. Many years ago, I was lucky enough to meet Bjarne Stroustrup. I remember him telling me that "you can't learn to ride a bicycle by a correspondence course". That is, becoming a good programmer takes practice, lots of practice. So you will need to find a little project to develop, to practice many of the techniques above. See also <a href="http://codekata.pragprog.com/">code kata</a>. 914881 914881