What makes X hard?

Mark Guzdial has written a nice article, What makes programming so hard?

But I say, "Programming: Easy. Dancing: Hard." What he is really talking about is the bimodal nature of skill acquisition. In many areas: Some people really get it; and others don't get it at all, and then there is the group in the middle who kinda get it.

Of course this, split is not accepted in certain fundamental skills: Talking, walking, self-feeding, toileting, where only those with significant disabilities are excused a reasonable competence.

In fact, everyone will find many things hard and many things easy. For example, when I audited a drama subject as part of a teaching degree I found a bunch of (lovely) people who united in their terror of mathematics. In my mathematics subjects, I am sure that I would have found some who felt the same way about getting up on stage.

So what are the elements of (basic) programming?

* Composition
* Decomposition
* Visualization
* Precision and clarity
* Use of and acquisition of formal language
* Memory
* Planning
* Logic
* Numeracy

Deficiency in any of these is likely to lead to frustration. But I maintain that there are two qualities that are necessary for any kind of learning:

* Wanting to learn X
* Patience when an element of X does not come easily

Another factor is having learned something in the past which interferes with the new area of learning. Examples:

* Tennis requires a firm wrist on impact; squash a flexible wrist
* Riding a bike caused me to almost throw myself off an adult-sized trike
* My English grammar makes it hard for me to adapt to Hebrew
* "You can teach anyone Lisp in 1 day, but it takes 3 if they already know C" (the use of parentheses is radically different)

If someone really wants to learn something, and is patient and quietly determined, and has access to an instructor who can help in the basic areas, learning is possible, and may be surprisingly fruitful.

One test of a dance teacher is whether (s)he can teach someone who lacks a sense of rhythm or is uncoordinated can teach these fundamentals, not just so that they can be applied in learning dances, but are transferable to other areas.

Similarly for other teachers.

How many boys? How many girls?

I hadn’t heard this one before, but I like it a lot:

In a country in which people only want boys, every family continues to have children until they have a boy. If they have a girl, they have another child. If they have a boy, they stop.

What is the proportion of boys to girls in the country?

Apparently used as a Google interview question (not that I’m a great fan of puzzle-based interviewing).

My long solution first

Distribution of families as proportions of all families in the country:

½: B
¼: GB
1/8: GGB
1/16: GGGB
etc.

Let F be the number of families.

How many boys?

Since every family stops after they get a boy the number of boys is F.

Alternatively, we can count the contributions of the different families:

Total boys = F x (½ + ¼ + 1/8 + 1/16 + ...)

This demonstrates that the infinite sequence

½ + ¼ + 1/8 + 1/16 + …

sums to 1, which is also apparent if you stand 1 meter from a wall and 50 cm then 25 cm etc., etc.

How many girls?

Again we sum:

Total girls / F = ¼ x 1 + 1/8 x 2 + 1/16 x 3 + …

= 1/4 + 1/8 + 1/16 + …
+ 1/8 + 1/16 + …
+ 1/16 + …
+ …

= 1/2 x (½ + ¼ + 1/8 + 1/16 + ...)
+ 1/4 x (½ + ¼ + 1/8 + 1/16 + ...)
+ 1/8 x (½ + ¼ + 1/8 + 1/16 + ...)
+ …

= 1/2 x 1
+ 1/4 x 1
+ 1/8 x 1
+ …

= ½ + ¼ + 1/8 + 1/16 + ...

= 1

So, Total girls = F

Solution

Equal numbers!

Simplifying assumptions?

Birth rate of 50-50

• No multiple births
• Large population
• No account made of multiple generations

Even without these assumptions, I would guess that the solution roughly holds.

Simple solution

Each child born has a 50-50 chance of being a boy or a girl. Each birth is independent, and not influenced by decisions of this, or any other family, so naturally half are boys and half are girls.

What's important?

Computer scientist and mathematician Richard Hammond -- he of the Hamming Code -- used to ask his colleagues two questions. In order:

1. What the most important issues in your field?, and the follow-up
2. Why aren't you working on those?

Often this induced a cold-shoulder response, but others were grateful for the nudge.

I have been meditating on what the equivalent question should be in a business, as opposed to Science. My tentative questions are:

1. What are the most important issues facing our customers?
   
2. Why aren't we working on those?
   

From this it follows that deeply understanding our customers' issues is of paramount importance.

Academic Cross-Training

Cross-training is not a new idea.

In most professional sports cross-training is incorporated into the usual training regime. Although weight-training and swimming are popular there are more exotic options around. Some Australian Rules footballers have even dabbled in ballet.

In cultures that emphasize the development of the individual as well as excellence, breadth and depth are valued. And for those who like the etymological definition of philosophy -- love of learning -- this is a bit of a no-brainer.

Now, if you are focussed on a narrow goal over a wide-ranging journey the diversions of breadth may prove a waste of time. But if the converse holds you will find that there is much to learn by exploring other disciplines. Here's what happened when physicist Richard Feynman ventured into biology.

If two academic disciplines are dealing with similar material at a deep level, chances are that each has something to offer an individual who crosses over from the other side.

Of course forcing everyone to compulsorily study X, usually leads to resentment from a significant proportion of those so conscripted, so when I say should study, I really mean should be encouraged to study.

In terms of excellence, someone should make a list of people who have achieved excellence after switching fields.

* * *

In sports, it is well-known that gymnasts do well after switching to diving and ski-jumping. From this I infer that gymnastics teaches transferable skills.

What are the nominations for the gymnastics of academic disciplines?

The Programming Djinni Grants Wishes

As a commercial product develops the wish-list grows longer and longer. User suggestions and feedback are collated and prioritized. Pretty soon you have a very large list.

The tragedy of the C cases
Here's the problem: Lots of worthy but little items are continually pushed to the bottom of the pile, by the latest big feature.

I call this "the tragedy of the C cases". These items of functionality may languish, if proper discipline is respected, never bubbling to the top.

There are disciplined ways around this use Scrum and XP style planning, but these require buy-in from the non-programmers and may not be achievable within your organization.

The magic approach
Here's a simple and fun alternative for a small company or department: One day per month -- customarily on the 23rd (or the nearest weekday) -- one or more programmers turn into djinnis who attempt to grant reasonable and achievable wishes to one lucky person in the company.

This breaks up the usual routine (a good thing as per the Hawthorne effect), is engaging for the lucky person -- who sees some immediate results -- and it is also good for the programmers, who get the satisfaction of working directly with a tangible person for a change rather than through a mediated priority list. And the software gets nicely polished.

Try it: See how you go; let me know.

Re-write or re-factor?

On individual projects I have usually found that a re-write leads to smaller, cleaner, faster solutions.

I attribute this to learning acquired from the previous attempts/versions, which I can incorporate in the form of improved abstractions and better trade-offs subsequently.

Some re-use of "golden nuggets" from earlier iterations may also be possible, and is certainly desirable.

Some lessons learned can be incorporated incrementally through re-factorings, but there are times when incremental improvement takes you to a local maximum and traps you there.

On big commercial projects other considerations come into play. Until the new code-base is up you need to contend with the cost of parallel development, and this period will be longer the greater the legacy. Unless, of course, your new abstractions are brilliantly efficient, and/or you can cut away a lot of stuff that was not needed.

Once a project is sufficiently large, given finite resources, it may eventually be too late to ever re-write!

Here's some more useful discussion by Adam Turoff on these issues prompted by survey question by Ovid.

Is Law a Branch of Computer Science?

I studied Law as well (as Science) early in my University career before relinquishing it on account of near-terminal boredom during Contracts (the content of the first third of which ironically proved quite useful to me subsequently).

I remember a visiting lecture by a Government draftsperson, whose job it was to draft legislation. He also happened to be blind. Aha, I thought, this is why legislation is so appallingly structured. That was undoubtedly unfair.

Later I came to the view that lawyers should study programming in order to learn how to structure large descriptions about processes and contingencies.

Now, Dave has come along with this brilliant comparison of legal language and programming languages. It is funny because there are several truths in there.

So, perhaps in the 21st century it is time to include a compulsory "programming for lawyers" unit, along with "legal process" as an introductory subject?

This would extend the wider view of Computer Science as a Natural Science, to cultural endeavours such as Law.