Genesis

So, here I am at the genesis of a new blog, which I created on a whim as a way to share some of the developer notes I've been saving for a while, as well as new thoughts and ideas that apply to the use of analytical engines (which some call computers).

I recently found these 10 Rules to Be a Better Programmer, and thought the list to be a pretty good summation of some things I've learned, and am still learning. My comments are italicised (and use Java terminology, but are mostly generalisable).

1. Don't repeat yourself
   This takes some wisdom, but in general it's true. If you find yourself writing the same bit of code more than a handful of lines more than twice, it's time to encapsulate.
2. Name your variables to say what they are for, not what data type they are.
   Yes! Hungarian notation is anathema left over from the bad old days of using tonnes of global variables! If you can't remember the data types of your variables, your routines are too big! Variables (and packages, interfaces, classes, enumerations) should be nouns or noun phrases. A special exception applies to loop counter variables, where "i", "j", "k", and so forth may used by long-standing convention; even there, something like "nameCount" isn't always bad.
3. Give your methods a clear name for what they are going to do.
   See the previous item. Methods should be verbs or verb phrases. Names like "retrieveDocument()" or "isReady()" are good, while "documents()" or "ready()" are not so much.
4. Don't use magic numbers or string literals.
   There are exceptions, but yeah, in general.
5. Write your methods so they can be tested without having any dependencies on other parts of the application, where possible.
   A very good idea. And a good mocking package is a big help.
6. Don't be afraid to ask for help.
   Of these recommendations, I find this one of the most important, and yet I continually forget it. I do count searching via Google, and developer-specific sites like Stack overflow and Code Ranch to be a partial implementation, but I still need to learn to ask people directly.
7. Follow the boy scout rule; fix buggy or messy code; don't leave it for someone else. "Do a good turn daily." But don't fall into the trap of constantly refactoring, and never moving on.
8. Share knowledge with others.
   This is the reciprocation of asking for help. There are many ways to share knowledge, including, oh, I don't know, maybe writing a blog. We'll see how that goes.
9. Don't interrupt your colleagues whilst they are in flow.
   Yes! Working in a cubicle farm does not give you permission, either. Headphones can be a useful indicator.
10. Use criticism as a positive instead of a negative.
    The word "critic" comes to us from a Greek root that has to do with judging, and is related to "crisis". (Etymonline) It's better to mentor and teach via dialogue, I think.