Olivet University - Olivet Institute of Technology

Teach Yourself Programming in Ten Years

Why is everyone in such a rush?

Walk into any bookstore, and you’ll see how to Teach Yourself Java in 7 Days alongside endless variations offering to teach Visual Basic, Windows, the Internet, and so on in a few days or hours. I did the following power search at Amazon.com:

     pubdate: after 1992 and title: days and
      (title: learn or title: teach yourself)

and got back 248 hits. The first 78 were computer books (number 79 was Learn Bengali in 30 days). I replaced “days” with “hours” and got remarkably similar results: 253 more books, with 77 computer books followed by Teach Yourself Grammar and Style in 24 Hours at number 78. Out of the top 200 total, 96% were computer books.

The conclusion is that either people are in a big rush to learn about computers, or that computers are somehow fabulously easier to learn than anything else. There are no books on how to learn Beethoven, or Quantum Physics, or even Dog Grooming in a few days. Felleisen et al. give a nod to this trend in their book How to Design Programs, when they say “Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies.

All-in-all, a very interesting post by Peter Norvig, read the full article here.

Version control best practices

Best practices

• Diff before you commit
• Keep commits small and logical
• There is room for comments, use it!
• Build and test code before a commit
• Don’t leave commented code in there
• Check other people’s commits

Best practices (GIT edition)

• Use .gitignore
• Commit often
• Be careful with git reset
• Rewriting history
• Branching
• Choose a workflow for branching
• Merge often and stay up to date
• Post-merge delete
• Tag releases
• Stashing
• Experiment!

Check the whole post here and here.

NetBeans IDE 7.2: Smarter & Faster

NetBeans IDE 7.2 is alive! The NetBeans IDE 7.2 release comes with significantly improved performance and many new features in the Java Editor, with a special focus on FindBugs integration, providing new static code analysis capabilities.

Along with a vastly improved developer experience that helps you write good, bug-free code quickly, it also delivers improvements in other areas, notably in its support for JavaFX, Java EE, Maven, PHP, and Groovy.

Read all the review at DZONE.

The Old School Way for the Engineer

Many of us agree there is a certain magic related with the way computer engineers from the computers early development history(early 60s till the late 90s) did things, a time when certainly the computers were much less amiable and the engineers truly dwelt in the same binary language as the computers.

One of the pearls of that time was a pretty interesting book written on 1971 named The Psychology of Computer Programming.

In this book we can find the “The Ten Commandments of Egoless Programming”, a very interesting guideline for programmers, essential even today as it was back then to promote a healthy atmosphere of co-working between peers:

1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
   
   
2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.
   
   
3. No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it’s not needed.
   
   
4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
   
   
5. Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don’t reinforce this stereotype with anger and impatience.
   
   
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
   
   
7. The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect – so if you want respect in an egoless environment, cultivate knowledge.
   
   
8. Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don’t take revenge or say, “I told you so” more than a few times at most, and don’t make your dearly departed idea a martyr or rallying cry.
   
   
9. Don’t be “the guy in the room.” Don’t be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
   
   
10. Critique code instead of people – be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.

A truly classical that is a jewel even for the modern engineer.

(Source: codinghorror.com)