The principle of least astonishment (POLA/PLA) applies to user interface design, software design, and ergonomics. It is alternatively referred to as the rule or law of least astonishment, or the rule or principle of least surprise (POLS).

The POLA states that, when two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the user; in particular a programmer should try to think of the behavior that will least surprise someone who uses the program, rather than that behavior that is natural from knowing the inner workings of the program.

Interesting.

I usually prescribe the same sequence for anyone who wants to learn programming. It's very theoretical, but it lays a good foundation. It should take three or four months of fulltime study, but programming isn't something you learn overnight.

If you can't get through this sequence, you're not going to be able to program, so you might as well give up now.

1. Code, by Charles Petzold.
2. The C Programming Language, K&R
3. The Structure and Interpretation of Computer Programs, Abelson and Sussman.

My rule is: work your way through those three books by sheer force, if necessary. Ask any questions you have, but only after struggling to figure it out on your own. If you can make it through those three books, congratulations, you're a programmer, now I can throw you PERL IN 15 MINUTES or whatever rubbish is at the bookstore in the Big Bookcase of Java and you will manage fine. If you can't make it through those three books, give up, go home, you're never going to get it.

I don't think you need to learn C and Scheme, to be honest. They're just a foundation for future learning. These two fairly simple books are both very simple on the surface (C and Scheme are super-easy languages) but they get very deep on the real art of programming without wasting time on confusing syntax, so they are excellent to start to re-wire your brain to be a good programmer.

Attempts to take a shortcut and go directly to learning the exact thing you want to learn right now (like starting with C# and ASP.NET) are doomed.

<div class="yt-alert yt-alert-error yt-alert-player yt-rounded "><img src="//s.ytimg.com/yt/img/pixel-vfl3z5WfW.gif" class="icon master-sprite" alt="Alert icon"><div class="yt-alert-content"> You need Adobe Flash Player to watch this video. <br> Download it from Adobe. </div></div>

Great if you're an übergeek.

• Definitions
• git's Index
• Branches
• Remote Repositories
• Merges
• Managing a Website Using git
• Essential Commands

I've posted a new primer -- this one on git. It gives an overview of how git works conceptually and hopefully it can help it become more approachable for people who read it.

Four years ago I wrote about a way to encode the latitude and longitude of any point on the Earth's surface to 10m of accuracy with a 10 character code. Apart from a modification to the way the check digit is calculated, the code remains unchanged.

The idea is this: instead of giving people addresses, or coordinates, you can give them something like a post code for any point on the Earth's surface. This can then be entered into a GPS device and decoded. Thus a business can provide its 10:10 code and know that people will be able to find it.

As computing resources continue to grow, efficiency falls further behind another concern when writing code, though. That concern is the cleanness of the code itself. Mostly, this boils down to readability and comprehensibility. Programmers need to be able to read and comprehend your code — programmers that will come along after you have moved on and even when you come back to your own code in six months.

Without readability and comprehensibility, you cannot easily reuse your code. You will be forced to reinvent the wheel many times over if you decide it is easier to write from scratch than use what you have already written when that would otherwise serve perfectly well. When writing open source software, the same problem applies to other people. Even worse when writing open source software, if your code is unreadable or — once read — incomprehensible, nobody else will bother looking at the code very much; you will not get any feedback on it other than (perhaps) complaints about that, you will not get code contributions, and ultimately your “open source” will be so opaque as to be effectively closed. It may be easier for others to just rewrite the needed functionality and put your project “out of business”. This is happening to GNU Screen right now.

I've always known this. An interface to a tool, and it's ability to be understood and used properly, is more important than how effective it is. But this is only true when all tools are mostly effective. That's why this has only become true in the last decade or so. Before then it was all about effectiveness.

Ideally, people would learn to program the same way “normal” people learn to play instruments: Slowly over several years, with lots of practice. However, this is not practical at the university level.

The foreign language model is closer to being practical. At Grand Valley, students study a foreign language for four semesters before beginning a serious study of literature and composition in that language. In theory, I think a similar model would for programming would be much more effective. As with foreign language, students could test into the appropriate place in the four-semester sequence. However, I see two problems.

Great analysis.

Description: Reports of crime that have been verified.
Agency Name: San Francisco Police Department
Time Period: Last 90 days rolling
Frequency: Daily
Location of dataset: http://apps.sfgov.org/datafiles/download.php?file=sfpd_incidents
Format: KML, shapefile, CSV

I love that great cities such as New York and San Francisco are making this type of data available.