note
eyepopslikeamosquito
<P>
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> <I>"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live"</I> (Damian Conway)
</ul>
Many of these tips were taken from [id://744932].
</P>
<P>
Many years ago, I was lucky enough to meet Bjarne Stroustrup.
I remember him telling me that <I>"you can't learn to ride a bicycle by a correspondence course"</I>.
That is, becoming a good programmer takes <I>practice</I>, 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>.
</P>
914881
914881