It’s not just doing it again and again!

I’d like to quote some lines from Peter Norvig’s masterpiece: Learn Programming in 10 Years:

The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.


In any case, book learning alone won’t be enough. “Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter” says Eric Raymond, author of The New Hacker’s Dictionary.

Also another amazing article that you’ll like to check is Herbert Klaeren’s Epigrams on Programming.

Little thoughts about coding…

I love my code, and love each of my projects and my development environment. While sleeping I alway dream about the code and Visual Studio! One day, a friend of mine asked me why I have hundreds of lines of old code commented, I told him that I don’t have the heart to kill them! In some projects I have whole code files commented!!!! I feel that my projects are my kids, I can’t let them go, and when it comes to deployment, I feel depression!

P.S.: What encouraged me to say this is that great post by my friend Dirk Strauss ☺.

Reference- Today’s Cartoon

OMG Rumor about Priority Scheduling!

In a heavily loaded computer system, a steady stream of high-priority processes can prevent a low-priority process from ever getting resources. Generally, one of two things will happen. Either the process will eventually be run (at 2 A.M. Sunday, when the system is finally lightly loaded), or the computer system will eventually crash and lose all unfinished low-priority processes…. Rumor has it that, when they shut down the IBM 7094 at MIT in 1973, they found a low-priority process that had been submitted in 1967 and had not yet been run.

Silbershatz and Galvin, Operating System Concepts, 5.3.3 Priority Scheduling

Journey to the Center of the Database

This is one of the powerful (and most funniest) illustrations on the abstraction (i.e. normalization) design of databases. It shows a simple diagram of a database where no abstraction was considered in its design.

This illustration was originally posted in The Daily WTF.