If You Know How to Program…

Recently I have come across a slightly different view of programming. In this view, programming is used as a way of learning Mathematics and other topics.

The premise of books in the Think X series is that if you know how to program, you can use that skill to learn other topics.

from Think Bayes by Allen B. Downey.

I see programming as a way of learning Mathematics.

Recently, several countries have included basic programming in the national curriculum. In some of these countries (such as Estonia and France) programming is placed in direct curricular connection to mathematics, whereas in others (England, and Sweden) programming is related more to a design and engineering agenda. However, in all cases the focus is not on developing general “humanistic” skills with technology, rather it is on thinking in algorithms, writing programs, and developing technology. In other countries such curricular changes are being discussed and tested on a small scale. Hence, it makes sense to take a closer look at the arguments that have previously been proposed for utilising programming in mathematics education.

from Learning Mathematics through Programming

This is a fascinating concept. If we believe in it (after looking at various case studies), teaching kids programming may be a good move. I always thought of programming as a way of thinking and solving problems.


There was a course on Coursera called “Coding the Matrix: Linear Algebra through Computer Science Applications”. But I am not able to locate it now.


LinkLog: Why Functional Programming Matters?

A couple of days ago, I went into the wrong networking event by mistake. This is one of those, where exchanging cards seems to be the main activity. The only saving grace was that I bumped into a programmer. We got to chatting and I asked him about his favorite programming languages. Pat came the reply “Haskell”. Before I could dig deeper, we were called into a formal (rather boring) meeting. So I went and Googled “Why functional programming” and here is one the neat papers I came across. It is kind of old but, will give you a sense of why you should consider giving it a try.

Functional programmers argue that there are great material benefits – that
a functional programmer is an order of magnitude more productive than his
conventional counterpart, because functional programs are an order of magnitude
shorter. Yet why should this be?

You can Read the full paper.

LinkLog: Programmer Competency Matrix

On a winter day in Boston, I sat through a two hour lecture on B-Trees. There was snow outside and we all sat spell bound as Greg Basset, our instructor taught us how Digital’s RMS-11K (the record management system) worked. The concept of incremental loading, fill factors, splitting data and index buckets and compression of duplicate keys, is still fresh in my memory. I gave that talk several times later in my life when I was teaching the subject. In each repetition, I learned a little bit more, answering questions. A few years later, I had the chance to use many of the ideas when we built C-Trieve and Objectrieve, two record management systems on top of which we built an SQL relational database. That was more than a couple of decades ago.

Looking at the Programmers Competency Matrix brought back lots of those memories. I think I am going to make a custom version of this matrix, make a poster and put it up on the wall of my class. A lot of these topics are not needed for the application programming today. But for a few of those intensely curious students, this is a kind of road map.


Reddit is a great source of interesting posts, especially for programmers. I should thank the kind soul who posted this link.

LinkLog: Do What You Love

From a Non-Programmer’s Apology, Aaron produces one of the best articles I have read – “To be or not to be” a programmer.

Learning is like compound interest. A little bit of knowledge makes it easier to pick up more. Knowing what addition is and how to do it, you can then read a wide variety of things that use addition, thus knowing even more and being able to use that knowledge in a similar manner.5 And so, the growth in knowledge accelerates.6 This is why children who get started on something at a young age, as Mozart did, grow up to have such an advantage.

But there is another, more important motivator – interest.

And even if (highly implausibly) we were able to control the circumstances in which all children grew up so as to maximize their ability to perform the most important tasks, that still would not be enough, since in addition to aptitude there is also interest.

A quote in his notes, provides some clue on how to tackle such dilemmas – where you are good at one thing but would really like to do something else.

“when it comes to choosing a life path, you should do what you love — because if you don’t love it, you are unlikely to work hard enough to get very good. Most people naturally don’t like to do things they aren’t ‘good’ at. So they often give up, telling themselves they simply don’t possess the talent for math or skiing or the violin. But what they really lack is the desire to be good and to undertake the deliberate practice that would make them better.”

Related The Definition of Work (originally titled “It is hard to find work you love”)

Golden Rule of Documenting Software Design

In the Next Programming Skill You Should Learn, Scott Hackett talks about the ability to communicate well, especially in writing. I totally agree. The post is certainly worth a read.

An unexpected bonus in this post is Scott’s tips on the golden rule of documenting software design.

The golden rule of documenting software design

Try to document whatever you are working on. It doesn’t have to be the worlds most perfect UML and you don’t need an expensive tool to do it. In fact, Wordpad and Paint are sufficient, and don’t tell me you don’t have those. Write in a way that best expresses your intent and your thought process in coming to the design decisions you did. I have a golden rule of documenting software design:

Describe your design to others as you would have others describe their design to you.

When you spend the time to do this, you’ll find that many benefits will follow. You’ll get feedback from others that may have tried to solve a similar problem and have insight you may not have thought of. You’ll leave a clear trail to follow for those that work on the code after you. Most importantly, you’ll shed light on your work, which everyone who depends on your work will appreciate. Even if no one else reads what you write, you’ll still have worked through problems in your head that can only lead to better design in the long run. There is no downside to documenting your designs.

One of the experiments I am conducting with a set of interns is to make them write a LearnLog and ProjectLog – just a few bullets or short sentences. We do this in a wiki so that every one in the project has access to it.  It is also one of the easiest and most effective ways to communicate asynchronously with the team.

In the Project Log, they are supposed to write the following:

  • Design decisions
  • Decision to use libraries/tools and why
  • Problem areas and stumbling blocks and how they solved it
  • A list of links to the resources they used

It is still an uphill battle but we are getting better gradually.

Best to Market…

According to Alan Cooper, the “best to market, trumps first to market”. He gives the following examples.

  • An ergonomic peeler versus a dinky metal peeler
  • Some clunky MP3 player versus the iPod
  • AltaVista versus Google

His advice to Interaction Designers, whom he was addressing at this conference:

We need to stop asking for permission and resources and show them how to achieve to seek success. We are an insurgent cadre of revolution.

On the higher cost of building:

The most expensive thing in business is opportunity cost, which is the cost of what you didn’t do while you were busy doing whatever you did do. Thus, it’s double or triple as expensive to rush a crap product to market. There’s no group of consumers waiting for you to ship your bad product to market.

On Prototypes and Code:

Prototypes are software. I believe that there’s a role for prototypes in interaction design, but I believe it’s a very small and limited role. It’s primarily done as a narrative, not as software. The risk of doing interaction design in a medium of code is much greater than the benefits yield for you. We as competent craftspeople should be able to communicate with great precision and clarity what we intend the software to do without resorting to code.

Code is a sledgehammer here. Prototypes are code that has not achieved released. Snippets of disposable code are great tools for design engineers, but they don’t play a large role for interaction designers.

Thanks to  Ben Galbraith who is blogging about Interaction Design, including this keynote..

LinkLog: Programming

From the food pyramid: for the journeyman programmer


It is a great way to structure:

  • Teaching Software Development
  • Training new employees (the environmental training is equally important)
  • A way to understand how developers do in various activities
  • For each project move from bottom to top and repeat

Other activities, like reading and writing about programming can help developers break the monotony of just doing work by combining it with a bit of learning.

LinkLog: Programmers and Programming

I have been collecting some links that describes/categorizes programmers and their attitudes. Some of them are brutal and others hilarious. Here are a list of links.

Three Levels of Programmers

I don’t like the classification – Good, Lazy and Bad. I would rather call them – Tool makers, Tool Users, Grunt workers. A Building Tools mentality is something different from Using Tools mentality. I don’t agree that one is superior to the other.

The Cults of Programming

I can identify with a few of these myself especially Ease Cult and Uncertainty Cult.

The Cult of Language Expertise

Language expertise is fine, but it isn’t the most valuable thing out there. If someone programs conscientiously, I can work with them.

How to Recognize a Good Programmer

Passion, Self teaching and love of learning, intelligence are all mentioned in this article. Formal education is last in the list. I would add a couple of more – empathy for the users (of your software) and certain amount of Pride in your work, goes a long way too.

Teach Yourself Programming in 10 years

Researchers (Hayes, Bloom) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, painting, piano playing, swimming, tennis, and research in neuropsychology and topology.

This is my all time favorite. It is a must read for anyone aspiring to be a programmer.

I will keep this updated whenever I see a new interesting entry. If you find something interesting that should be in this list, please add a comment with a link.

Recognizing Software Metaphors

Chris Wood has a great blog post on Software Development Metaphors.

He lists a set of software metaphors under broad categories like:

Traditional Software Development Metaphors

  1. Software Development as a Factory
  2. Software Development as Engineeing
  3. Software Development as Model/Architecture
  4. Software Development as Workflow Process

Radical Software Development Metaphors:

  1. Software Development as Craft
  2. Software Development as Game Playing
  3. Software Development as Composition
  4. Software Development as Learning/Experimentation/Invention

Chris points out that different shops have different metaphors and sometimes switching metaphors may be required.

if you want to evangelize a new software development methodology (for example, those who are trying to evangelize the use of XP in a traditional RUP organization) starting with a discussion around metaphors and basic understanding of software development might help the discussion, especially with non-technical users.

This is a good post. My current job is  Teaching Software to beginners and building experimental prototypes. So my interest is more in Software as Learning/Experimentation/Invention.  The radical models may be more appealing to beginners and small teams.

If you are a startup, you may start with one metaphor and will switch metaphors as you grow. It will be nice to see what metaphors most of the Web 2.0 companies use.