Becoming a Technical Leader

is an excellent book by Jerry Weinberg (isbn 0-932633-02-1). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
From working with systems, I have learned that the process of change is always organic.
Organic models may be characterized by "systems thinking": the belief that event X is the outcome of hundreds of other factors, including the passage of time.
People improve their performance not by amputating their old behaviors, but by adding new ones.
There are many technical workers who enjoy wandering so much that, like Alice in Wonderland, they don't much care where they go, so long as they get somewhere. Computer programmers call this process "hacking"
In front of each plateau is a ravine.
Probably the most widespread and pernicious myth about leadership is that only Leaders can lead, where the capital L indicates that someone has been appointed to the position of leadership. ... It's only in threat/reward models that leadership and management are synonymous.
You can develop your ability to see and hear more effectively.
People aren't used to thinking in terms of relationships.
I first look for personal power, which can be converted into almost anything.
Break down big learnings into a sequence of little ones, pay attention to the efficiency of your educational strategies, and become aware of your emotional reaction to learning.

CyberDojos

I've run a couple more CyberDojo's recently. The first was with Kevlin Henney during an onsite run of our Mastering Agile Practice course for commasoft in Bonn, Germany.

The second was for Mott MacDonald, in Croydon, England. Here's some feedback from the sessions:
  • an awesome afternoon!
  • It has been the single most useful training exercises I have attended at motts.
  • it was an excellent team building exercise and a fun introduction to some development concepts we're not familiar with, in particular pair programming and test driven development, but also the concept of 'deliberate practice'.
  • helped improve the cooperation within the team
  • Great!
  • I want more Dojos


Tests as specifications

The other day I was doing the yahtzee kata in C in CyberDojo and I got caught (not for the first time) by a classic gotcha...

I wrote my tests very very simply as follows:


...
static void two_pairs_scored_as_one_pair_is_spots_on_highest_pair(void)
{
    assert(...);
}

static void full_house_scored_as_one_pair_is_spots_on_the_pair(void)
{
    assert(...);
}
...

typedef void test(void);

static test * tests[] =
{
    two_pairs_scored_as_one_pair_is_spots_on_highest_pair,
    full_house_scored_as_one_pair_is_spots_on_the_pair,
    ...,
    NULL,
};

int main(void)
{
    for (int at = 0; tests[at] != NULL; at++)
        tests[at]();
    return 0;
}


I wrote another test and hit the Run-Tests button. But the new test didn't get run because I'd forgotten to add the name of the function to the tests array. Ooops. The new test compiled ok, and I'd tripped up thinking the test was passing when it wasn't even being run.

I've practised in CyberDojo enough that I don't get "sucked into the code" as much as I used to and when something like that happens there's now a fair chance I'll have enough awareness to notice it as it happens.

I stopped and thought about what had happened for a moment and I realized something. My problem was that I was writing the test function definition first. I should be writing the name of the test in the tests array first. And only once I've done that should I define it. There is a nice echo of the idea of Test First Design to this.

Of course in a language with reflection you only need to write the test function. Be that as it is, I like the the way the contents of the tests array lists the function names as specifications. In a language with reflection you don't get that.

The Secrets of Consulting

is an excellent book by Jerry Weinberg (isbn 0-0-932633-01-3). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
Consultants deal in change.
Consulting is the art of influencing people at their request.
..there is the problem of balancing certainty now versus uncertainty in the future.
Consultants are less adapted to the present situation, and therefore are potentially more adaptable.
The toughest problems don't come in neatly labelled packages. Or they come in packages with the wrong labels.
The bigness is not the horse.
The true expert can see multiple aspects of a situation, but the novice sees only... whatever is most conspicuous.
We all know that things tend to fall between cracks and that cracks occur at boundaries, where one system joins another.
For a trigger to be effective, the timing must be perfect: Too late means you're already committed to the troublesome action, while too early means you may forget again betwixt the cup and the lip.
There are always opportunities to jiggle.

Six memos for the next millenium

is an excellent book by Italo Calvino (isbn 0-099-73051-0). As usual I'm going to quote from a few pages:
Lightness for me goes with precision and determination, not with vagueness and the haphazard... (One should be light like a bird and not like a feather)...
... even correctness of style is a question of quick adjustment, of agility of both thought and expression.
... each value or virtue I chose as the subject for my lecture does not exclude its opposite.
Poetry is the great enemy of chance, in spite of also being a daughter of chance.
On folio 265 of the Codex Atlanticus, Leonardo begins to jot down evidence to prove a theory of the growth of the earth. After giving examples of buried cities swallowed up by the soil, he goes on to the marine fossils found in the mountains and in particular to certain bones that he supposes must have belonged to an antediluvian sea monster. At this moment his imagination must have been caught by a vision of the immense animal as it was swimming among the waves. At any rate, he turns the page upside down and tries to capture the image of the animal, three times attempting a sentence that will convey all the wonder of that evocation.
It is useless at every circle to invent a new form of metarepresentation.
What tends to emerge from the great novels of the twentieth century is the idea of an open encyclopedia, an adjective that certainly contradicts the noun encyclopedia, which etymologically implies an attempt to exhaust knowledge of the world by enclosing it in a circle.
There is a type of work that, in the attempt to contain everything possible, does not manage to take on a form, to create outlines for itself, and so remains incomplete by its very nature.
... the collection of objects of which only one specimen exists.
The classical author who wrote his tragedy observing a certain number of known rules is freer that the poet who writes down whatever comes into his head and is slave to other rules of which he knows nothing.

Synectics

is an excellent book by William J.J. Gordon (isbn 978-0060324308). As usual I'm going to quote from a few pages:
The word Synectics, from the Greek, means the joining together of different and apparently irrelevant elements.
Abstraction breeds more abstraction and more generality instead of leading to tough yes-no tests.
Words like intuition, empathy, and play are merely names put to complex activities in the hope that the naming of the activity will in fact describe it.
Human beings are heir to a legacy of frozen words and ways of perceiving which wrap their world in comfortable familiarity.
Synectics theory agrees with the conviction that a man does not know even his own science if he knows only it.
"All the crappy solutions in the world have been rationalized by deadlines."
He refused to recognize the fact that his search for the perfect problem was a way of avoiding failure in solving a less perfect one.
Invention is akin to painting for in practice, the element being constructed has the capacity to tell the builder what the next step should be. In invention this is much more critical than in engineering because the inventor is always attempting to do something new.
When this forgetfulness is formalized into a methodology, it reinforces the rejection of the commonplace.
Organic functions are unfinished, cylical, and self-reproductive... Synthetic functions are complete and more obviously subject to decay.
Conventions as abstractions from reality constitute a virtually complete and unassailable pattern, whereas the commonplace is infinitely repatternable.
The child who asks: "What's that funny noise?" is told the noise is thunder in such a way that speculation is supposed to stop... But naming the noise does not describe it. It does not answer the question, it kills it.

Why do car drivers brake?

Recently I wrote a small blog entry Why to cars have brakes? It's getting a lot of hits. Well, a lot for me. So naturally in my quest for even more hits here's a follow up...

Imagine you're in a car. Driving along. Why do you brake? I'm not asking what happens when you press the brake pedal? That's too easy (the car stops). I'm asking why…?


.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Here are two reasons:

Reason one: because there's danger ahead

This corresponds to a failing test. More specifically, it's when a test runs and asserts. A red. Perhaps there's a queue of traffic ahead (often a problem on the orbital car park known as the M25). Perhaps the road is closed off because workmen are working on it. Or maybe the local council has been meddling and the road is now a one-way-but-not-the-way-you-want-to-go road. Whatever the reason, something is not as expected.

Reason two: because you've arrived!

This corresponds to a passing test. A green. Wherever it is you're going, you've got there. Nothing unexpected happened. No traffic queues. No closed off roads. No meddling local council. Incredible!

In my entirely unscientific sampling almost everyone answers with the first reason. The second reason is not nearly as common. I find this interesting. I think maybe it's a reflection of the thinking statically vs thinking dynamically thing again. A perception that tests are most useful when they fire red. That tests which run to completion without incident are not so useful. But they are. Maybe more so.

Brakes help me stop. And stopping implies I'm already moving - I'm already going somewhere. But where? If I don't know where I'm going why am I moving at all? If I don't know where I'm going I'm just as lost as if I don't know where I am.

Tests are useful not just because of the I-didn't-arrive effect when they fail, they're also useful because of the I-did-arrive effect when they pass.

Another reason passing tests are really useful is the elves. But the elves will have to wait for another time.

Peopleware

is an excellent book by Tim Lister and Tom DeMarco (isbn 0-932633-43-9). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
Development is inherently different from production.
Most organizations don't set out consciously to kill teams. They just act that way.
The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted. [Tajima and Matsubara]
The manager's function is not to make people work, but to make it possible for people to work.
The trick isn't in the technology; it's in the changing of habits.
An age-old pattern of interior space is one that has a smooth "intimacy gradient" as you move toward the interior.
Employee turnover costs about twenty percent of all manpower expense. But that's only the visible cost of turnover. There's an ugly invisible cost that can be far worse.
It's only the right to be wrong that makes you free.
The structure of a team is a network, not a hierarchy.
Everyone quickly understands that the presence of the posters is a sure sign of the absence of hard work and talent.
The more you improve the way you go about your work, the harder the work will be.
The manager of a large project in Minneapolis has refused to move his people to the new quarters. ("New in this case just meant smaller and noisier.) Administrators were simply stunned at his refusal; they had never considered the possibility.

Just one more thing

is an excellent book by Peter Falk (isbn 978-0-099-50955-4). As usual I'm going to quote from a few pages
My object is to keep you awake.
I didn't stay in college the full four years. I quit after three months and joined the Merchant Marines. Men with one eye were not drafted and in the Merchant Marines they were not allowed to work on deck or below deck, but they could work in the kitchen. I sailed out as third cook. My specialty was pork chops.
About the third time I was late, even before I hit my seat, LaGallienne froze me with a question: "Why are you always late?" I said I had to drive down from Hartford. She asked coldly, "What do you do there? There are no theatres in Hartford. How do you make a living?" I told the truth. "I'm not an actor." She snapped back "Well you should be, now sit down."
I remember vividly that particular performance when for the first time I was suddenly startled by a new totally unexpected sound - a rich, deep authentic snore. Holy jamolies. There is someone on this stage that is sleeping - really sleeping.
I have never been arrested in the United States but I have been arrested in Paris, Moscow, Havana, Genoa, Belgrade, and Trieste.
Did he want to be buried or cremated? His answer to them was brief - "Surprise me."
"Here and there you'll find a raisin."
I was struck very early by the dramatic possibilities of playing a man who housed within himself two opposite traits.
For me The Princess Bride was a movie without a blemish, perfect for both kids and adults.

An Introduction to General Systems Thinking

is an excellent book by Jerry Weinberg (isbn 0-932633-49-8). As usual I'm going to quote from a few pages. I know I've snippeted this book before, but I read it again and a really good book deserves a repeat snippet.
The average scientist is good for at most one revolution.
"Proof" in its original sense was a test applied to substances to determine if they are of satisfactory quality... Over the centuries, the meaning of the word "prove" began to shift, eliminating the negative possibilities...
They know "better" - which is to say that their illusion is stronger.
We drive more slowly at night to give us more time to observe potentially dangerous situations.
More probable states are more likely to be observed than less probable states, unless specific constraints exist to keep them from occurring.
Things we see more frequently are more frequent: 1. because there is some physical reason to favor certain states, or 2. because there is some mental reason.
The Axiom of Experience can, like all of our principles, be turned around, to become a definition of what we mean by the word "like": Two things are alike if one in the present can be substituted for one in the past.
a "boundary" may not be infinitely thin, precisely so it can partake of both system and environment. Rather than separating, such a boundary connects.
We can learn, if nothing else, proper caution in our speech, which will inevitably lead to proper caution in our thought...

Test-driven development for embedded c

is the title of an excellent book by James Grenning (isbn 978-1-93435-662-3). As usual I'm going to quote from a few pages:
A good design is a testable design.
TDD helps you go faster... Slowing down is exactly what is needed to go fast!
Like TDD, if testing is hard, do it all the time - it gets easier.
Test automation is the gift that keeps on giving.
One test result is worth 1,000 expert opinions [Wernher von Braun]
You get a shot of testability with a portability chaser.
If we can identify a particular code smell, we have a better chance of eliminating the bad smell.
Shifting levels of abstraction should happen for a purpose.
Refactoring should be part of everyday development. It's not on the schedule, and you don't ask for permission to refactor.
The industry norm is for code to incrementally worsen with each change. We need to reverse that.
Dual-targetting, like TDD, has another benefit: it influences your design. Paying attention to the boundaries between software and hardware produces more modular designs.

why do cars have brakes?

I don't remember where I was when Kevlin Henney asked me:

Why do cars have brakes?

but I do remember his answer as a definite light-bulb moment. What's your answer?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A very common answer is

to stop

or some variation thereof. In other words, to brake. It reminds me of the noun-verb thing again. Lights light. Irons iron. Compilers compile. Brakes brake. But that was not Kevlin's answer. Kevlin's answer was:

So you can drive faster.

His answer feels paradoxical which usually means there's a deep truth. Brakes allow you to stop when you want. Brakes allow you to stop where you want. Software tests are like brakes. They help you drive faster.

I'm also reminded of the P.W.Bridgman quote at start of chapter 6 of Jerry Weinberg's Introduction to General Systems Thinking:

...it is better to analyze in terms of doings or happenings than in terms of objects or static abstractions.

Thinking about brakes allowing you to stop is thinking statically. Thinking about braking allowing you to drive faster is thinking dynamically.

If you liked this post you might like the follow up Why do car drivers brake?.

A singleton refactoring

Here's a refactoring I often teach. It's particularly applicable if you're wanting to refactor legacy code. I'll show it in C++ in honour of the excellent developers at Promethean.

I'll start with a typical Singleton:

class singleton
{
public:
    static singleton & instance();
    void f(int value);
    int g(const std::string & path);
private:
    singleton();
    ~singleton();
};

Together with typical piece of client client code that I'm wanting to unit-test:

int client::eg1()
{
    stuff();
    more_stuff();
    int r = singleton::instance().g("Hello world");
    return yet_more_stuff(r);
}

My problem is that singleton leads to one or more external dependencies I'd like my unit-tests to bypass. My first step is to create an interface for the singleton:

class singleton_interface
{
public:
    virtual void f(int value) = 0;
    virtual int g(const std::string & path) = 0;
    ...
};

And then make singleton implement the interface. (The saving grace of singleton is that its methods are at least instance methods.)

class singleton : public singleton_interface
{
public:
    static singleton & instance();
    void f(int value);
    int g(const std::string & path);
private:
    singleton();
    ~singleton();
};

Now I can overload eg1 as follows:

int client::eg1(singleton_interface & instance)
{
    stuff();
    more_stuff();
    int r = instance.g("Hello world");
    return yet_more_stuff(r);
}

int client::eg1()
{
    return eg1(singleton::instance());
}

And finally, I can create singleton_interface sub-classes and use them in my unit-tests:

struct my_mock_singleton : singleton_interface
{
    explicit my_mock_singleton(int g_result) 
        : g_result(g_result) 
    {
    }
    void f(int value) 
    {
    }
    int g(const std::string & s) 
    { 
        return g_result; 
    }
    int g_result;
};

void test_client_eg1_hitch_hiker_is_42()
{
    assert(42 == client().eg1(my_mock_singleton(6*9)));
}


Micro refactoring - from here to there

One of my Mastery book snippets from a few days ago reads:

Masters ... are zealots of practice, connoisseurs of the small, incremental step.

I was doing the roman numerals kata in ruby and something related to small incremental steps occurred to me. Here's three tests:

def test_to_roman
  assert_equal "I", to_roman(1)
  assert_equal "II", to_roman(2)
  assert_equal "III", to_roman(3)
end

and here's the first code snippet:

def to_roman(n) 
  roman = ''
  if n == 3
    roman = 'III' 
  end
  if n == 2
    roman = 'II'
  end
  if n == 1
    roman = 'I'
  end
  roman
end

I can refactor these three if statements into a single while statement, in very small steps, as follows:

def to_roman(n) 
  roman = ''
  if n >= 3
    roman += 'I'
    n -= 1
  end
  if n >= 2
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1 
  end
  roman
end

and then:

def to_roman(n) 
  roman = ''
  if n >= 1
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1
  end
  if n >= 1
    roman += 'I'
    n -= 1 
  end
  roman
end

and then:

def to_roman(n) 
  roman = ''
  while n >= 1
    roman += 'I'
    n -= 1
  end
  roman
end

Ok. Now here's the original again:

def to_roman(n) 
  roman = ''
  if n == 3
    roman = 'III'
  end
  if n == 2
    roman = 'II'
  end
  if n == 1
    roman = 'I'
  end
  roman
end

And this time I refactor in a different direction, towards an array lookup:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[3]
  end
  if n == 2
    roman = units[2]
  end
  if n == 1
    roman = units[1]
  end
  roman
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[n]
  end
  if n == 2
    roman = units[n]
  end
  if n == 1
    roman = units[n]
  end
  roman
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  roman = ''
  if n == 3
    roman = units[n]
  end
  if n == 2
    roman = units[n]
  end
  if n == 1
    roman = units[n]
  end
  roman
  units[n]
end

And then:

def to_roman(n) 
  units = [ '', 'I', 'II', 'III' ]
  units[n]
end

In this case I can refactor from a sequence of if statements in two directions equally easy - towards a while or towards an array lookup. Ok. Now consider the situation if I was starting from a switch instead of a sequence of ifs:

def to_roman(n) 
  case n
  when 3 then 'III'
  when 2 then 'II'
  when 1 then 'I'
  end
end

From this I can easily refactor towards an array lookup but refactoring towards a while is perhaps not quite so straightforward.

I'm suggesting that a construct is useful not just in it's own right but also in relation to all the other constructs it might get refactored to or from. How easily can I move from one construct to another? Do some constructs live only on one-way roads? Do some lead you down more dead-ends than others?

I'm reminded of the family on holiday in the West Country who got thoroughly lost. Spotting a farmer leaning on a gate they stop the car, wind down the window and ask

Excuse me. Can you tell me how to get to Nempnett Thrubwell?

The old farmer looks at them and says

Well.... you don't want to start from here.


Test-gunpowder-pudding driven development

I was rereading chapter 3, Systems and Illusion in Jerry Weinberg's excellent An Introduction to General Systems Thinking yesterday. On page 56-57 Jerry writes:

If I say: "The exception proves the rule" in front of a large class, there will be a division in understanding... Some will believe I have uttered nonsense, while others will understand "The exception puts the rule to the test"

I've read the book four times. I'm a slow learner but this time something clicked and I immediately understood the earlier passage:

...the exception does not prove the rule, it teaches it.

Jerry goes on:

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

I was struck by two thoughts when I read this. One was the parallel with testing. Of a test as a "proof". The other was the word original. I realized that when I hear the word "proof" I have a strong association with its noun meaning rather than its verb meaning. I tend to think of a proof as a finished proof that completely proves something. It's the noun-verb thing I've blogged about before. I wondered if there were any old dictionaries online so I could get a feel for how the generally accepted meaning of the word proof might have changed over time. There is. http://machaut.uchicago.edu/websters has two Webster's dictionaries. The 1828 dictionary came back with:

Proof [noun] 1. Trial; essay; experiment; any effort, process or operation that ascertains truth or fact. Thus the quality of spirit is ascertained by proof; the strength of gun-powder, ...

The 1913 one came back with:

Proof [noun] 1. Any effort, process, or operation designed to establish or discover a fact or truth; an act of testing; a test; a trial.

and a modern dictionary http://www.thefreedictionary.com/proof said:

Proof [noun]. 1. The evidence or argument that compels the mind to accept an assertion as true.

I find the difference fascinating. The 1828 and the 1913 definitions define the noun as the process whereas the modern one defines the noun as the evidence resulting from the process.

Jerry continues:

We retain this meaning in the "proofs" of printing and photography, in the "proof" of whiskey, and in "the proof of the pudding." Over the centuries, the meaning of the word "prove" began to shift, eliminating the negative possibilities to take on an additional sense: "To establish, to demonstrate, or to show truth or genuineness."

At first I didn't understand the bit about "eliminating the negative possibilities". I think it's partly to do with my ITA spelling at school. But I am persistant. Slowly it came to me. The word that did it for me in...

"Proof" in its original sense was "a test applied to substances to determine if they are of satisfactory quality."

...was the word if. To determine if they are of satisfactory quality. The proof was an act. There was the possibility of failure.

I started thinking about the word proof a bit more. I googled the phrase "the proof of the pudding". If you think this phrase is pretty meaningless then you're right - it's a shortened version of:

The proof of the pudding is in the eating.

Again it's about the possibility of failure. It reminds me of the scene in the film The Cat in the Hat (another film Patrick and I love watching) where the Cat has just made some cupcakes (with the amazing kupcake-inator). He tries one and says:

"Yeuch. They're horrible. Who want's some?"

I love that line. I also googled the word proof as related to alcohol content. The history behind the phrase is just wonderful. In the 18th century spirits were graded with gunpowder. Imagine you're buying some spirits. How would you know if an unscrupulous merchant had watered it down? You couldn't tell just by looking. What they did was pour a sample of the solution onto a pinch of gunpowder. If the wet gunpowder could still be ignited then the solution had proved itself. Don't you just love that?

So let's hear it for pudding and for spirits and for gunpowder and for tests. And for the possibility of failure.

The timeless way of building

is an excellent book by Christopher Alexander (isbn 0-19-502402-8). As usual I'm going to quote from a few pages:
A thing which has the quality without a name never fit any image exactly. What is exact is its adaptation to the forces which are in it.
The fact is that the elements themselves are patterns of relationships.
Any thing which lives can only be achieved as the end product of a process, whose force takes over and replaces the willful act of creation.
The mastery of what is made does not lie in the depths of some impenetrable ego; it lies, instead, in the simple mastery of the steps in the process, and in the definition of those steps.
How does the pattern language, which exists behind this flux, steer it, and enter into it? It hinges on the close relationship between the process of creation and the process of repair.
As in the organism, there is no sharp difference between the process of construction and the process of repair. Each process of construction helps repair some larger whole, of which it is merely a part. No thing is whole unto itself.
Within this process, every individual act of building is a process in which space gets differentiated. It is not a process of addition, in which pre-formed parts are combined to create a whole: but a process of unfolding, like the evolution of an embryo, in which the whole precedes its parts, and actually gives birth to them, by splitting.
The form of the whole, and the parts, come into being simultaneously.
This can only happen if the design is represented in an utterly fluid medium; it cannot happen in any medium where there is even the slightest resistance to change.
No building is ever perfect.

Yahtzee in ruby in cyber-dojo

I've been doing the Yahtzee kata in cyber-dojo to improve my Ruby. During the 247 increments I learned about...
  • any?
  • send
  • [lo...hi]
  • reduce
  • :+
  • module names start with a capital
It's also on pastie if you like a black background. You can use Cyber-Dojo to step through the diffs of every single increment!
module Yahtzee

  def self.score dice, category, n=nil
    return -1 if invalid(dice, category)
    if category == :value
      value(dice, n)
    else
      send(category, dice)
    end
  end

  def self.chance dice
    dice.reduce(:+)
  end

  def self.yahtzee dice
    dice.uniq.length == 1 ? 50 : 0
  end

  def self.value dice, n
    dice.count{|die| die == n } * n
  end

  def self.one_pair dice
    die(tally(dice).find{|n| pair?n }) * 2
  end

  def self.two_pair dice
    score_tally dice, [2,2]
  end

  def self.three_of_a_kind dice
    score_tally dice, [3]
  end

  def self.four_of_a_kind dice
    score_tally dice, [4]
  end

  def self.full_house dice
    score_tally dice, [3,2]
  end
  
  def self.small_straight dice
    dice.sort == [1,2,3,4,5] ? 15 : 0
  end

  def self.large_straight dice
    dice.sort == [2,3,4,5,6] ? 20 : 0
  end

  #- - - - - - - - - - - - - - - - - - - - - - - 

  def self.categories
    [:value, :chance, :yahtzee, :one_pair, :two_pair,
     :three_of_a_kind, :four_of_a_kind, :full_house,
     :small_straight, :large_straight
    ]
  end

  def self.invalid dice, category
    dice == nil \
      or dice.length != 5 \
        or dice.any?{|die| die < 1 or die > 6 } \
          or !categories.include? category
  end

  def self.score_tally dice, pattern
    starts?(pattern, tallies(dice)) \
      ? sum(dice, pattern.length) \
      : 0
  end

  def self.starts? short, long
    long[0...short.length] == short
  end

  def self.tallies dice
    tally(dice).map{|n| count(n) }
  end

  def self.rolls dice
    tally(dice).map{|n| die(n) }
  end

  def self.tally dice
    dice.uniq.map {|die| [dice.count(die),die] }.sort.reverse 
  end

  def self.sum dice, n
    sum2(rolls(dice)[0...n], dice)
  end

  def self.sum2 scorers, dice
    dice.select {|die| scorers.include?die }.reduce(:+)
  end

  def self.pair? n
    count(n) == 2
  end

  def self.count n
    n[0]
  end

  def self.die n
    n ? n[1] : 0
  end

end
I challenged myself to write the code in a functional style with no local variables - it's a bit 'dense' in places as a result.

Disabling professions

is an excellent book by Ivan Illich et al (isbn 0-7145-2510-3). As usual I'm going to quote from a few pages:
Finally there is is the American valuation on instrumentalism - an emphasis on doing - on doing something, almost anything when confronted with a problem. "Doing nothing in a difficult situation" was interestingly enough an item diagnostic of neuroticism on a popular American psychological test. Sometimes the emphasis on movement became so great that speed itself was emphasised - sometimes for no logical reason.
It does not strike me as inconsistent, that religion and notions of the hereafter are especially relevant when "the here" is so lousy and so short.
Man has no nature, only a history [Ortega Y Gassett]
there seems to be an absence of informal and comfortable places to gather and talk and thus a further reduction in "informal networks of help".
The business of modern society is service… Thus, service is to care which is to love and love is the universal apolitical value.
The tool defines the problem rather than the problem defining the tool.
There is no greater power than the right to define the question.
The easiest way to create a monopoly is to invent a language and procedure which will be unintelligible to the layman.
When we talk about skilled work it is not the nature of the craft, but the social relation of the worker to management that is under discussion. The full expression of the worker's skill conflicts directly with the needs of management.
One of the real satisfactions of skilled work is that, like an artist, your hands produce what your mind conceives.
The frustration of not being able to apply his skills on the job is often the motivation for doing it at home.

Working effectively with legacy code

is an excellent book by Michael Feathers (isbn 0-13-117705-2). As usual I'm going to quote from a few pages:
A few years ago, I gave my friend Erik Meade a call after I'd finished work one night. I knew Erik had just started a consulting gig with a new team, so I asked him, "How are they doing?" He said, "They're writing legacy code, man."
To me, legacy code is simply code without tests. I've gotten some grief for this definition… I have no problem defining legacy code as code without tests. It is a good working definition, and it points to a solution.
In nearly every legacy system, what the system does is more important than what it is supposed to do… Frankly, it's very important to have that knowledge of what the system actually does someplace.
When teams aren't aware of their architecture, it tends to degrade. What gets in the way of this awareness? … The brutal truth is that architecture is too important to be left exclusively to a few people.
When you have tests around the areas in which you are going to make changes, they act as a software vise [vice]. You can keep most of the behaviour fixed and know that you are changing only what you intended to.
The most subtle bugs that we can inject are bugs related to inheritance. … The language feature that gives us the most possibility for error when we lean is inheritance.
Orthogonality is a fancy word for independence… One of the startling things that you discover when you start removing duplication zealously is that designs emerge.
Sometimes it makes sense to add a variable to a class and use it to sense conditions in the method that we want to refactor.
…not all behaviours are equal in an application.
Code is pretty fragile material.
At this point in my career, I think I'm a much better programmer than I used to be, even though I know less about the details of each language I work in.
The primary purpose of a compiler is to translate source code into some other form, but in statically typed languages, you can do much more with a compiler.

Mastery

is an excellent book by George Leonard (isbn 0-452-26756-0). As usual I'm going to quote from a few pages:
You have to be willing to spend most of your time on a plateau, to keep practising even when you seem to be getting nowhere.
Our hyped-up consumerist society is engaged, in fact, in an all-out war on mastery.
Sometimes, when the moment came to go to class, I would be feeling particularly lazy. On those occasions I would be tempted to do almost anything rather than face myself once again on the mat.
Practice, the path of mastery, exists only in the present.
To see the teacher clearly, look at the students… The best teacher generally strives to point out what the student is doing right at least as frequently as what she or he is doing wrong.
A doctor practises medicine and an attorney practises law, each each of them also has a practice.
The master of any game is generally a master of practice.
The courage of a master is measured by his or her willingness to surrender. This means surrendering to your teacher and to the demands of your discipline. It also means surrendering your own hard-won proficiency from time to time in order to reach a higher or different level of proficiency.
The essence of boredom is to be found in the obsessive search for novelty. Satisfaction lies in mindful repetition, the discovery of endless richness in subtle variations on familiar themes.
For the master, surrender means there are no experts. There are only learners.
It can be argued that what is most abstract is most fundamental and often most persistent over time.
Those we know as masters are dedicated to the fundamentals of their calling. They are zealots of practice, connoisseurs of the small, incremental step. At the same time - and here's the paradox - these people, these masters, are precisely the ones who are likely to challenge previous limits.

NDC cyber-dojos

Last week Olve Maudal and I ran two cyber-dojos at the NDC conference in Oslo. The first one attracted only a few people, partly due to some confusion about where it was being held. But what it lacked in quantity it more than made up for in quality. Uncle Bob and Corey Haines seemed to invent a new style of pair programming where Uncle Bob used his left hand and Corey used his right hand! Several people posted encouraging tweets:
  • @KevlinHenney: If you are at #ndc2011 today, I strongly recommend the cyber-dojo with @JonJagger and @olvemaudal this afternoon.
  • @UncleBobMartin: #ndc2011 cyber-dojo was very cool. Too bad you missed it. Must not be very many programmers here
  • @CoreyHaines: Terrific fun at #cyber-dojo at #ndc2010 Only 4 of us there today, you should come to the repeat on Friday after lunch!
  • @occulto: Best thing today: doing a kata in #cyber-dojo with @sondreb, @unclebobmartin and @coreyhaines #ndc2011 try it on Friday!


More people attended the second one. Corey was there again, along with Michael Feathers and Jon Skeet. Once again the tweets were very encouraging.





In the evening Olve created a TurnKey Linux VirtualBox server image to make it super-easy to run your own cyber-dojo. It's less than 500MB and downloadable from http://dl.dropbox.com/u/22404698/TurnKey-CyberDojo-20110610.ova.

Mike Long has written a pdf on how to set it up.

Thankyou to Olve and Mike and to everyone who attended.


Lean on the Compiler by Hiding (C++)

My Lean on the Java Compiler by Hiding post has proved quite popular so I've been thinking about if it could also work for C++... It can. I'll use Singleton as a example again. Suppose you have a C++ class like this:



class legacy
{
public:
    legacy();
    void eg1();
    void eg2();
    ...
};
#include "legacy.hpp"
#include "singleton.hpp"

void legacy::eg1()
{
    singleton::instance()->call();
}

void legacy::eg2()
{
    singleton::instance()->call();
}

Again, you want to create a seam for singleton access. The first step is to introduce the hiding identifier in the header file:

class legacy
{
public:
    legacy();
    void eg1();
    void eg2();
    ...
private:
    class singleton;  // <-----
};


Now Lean on the Compiler. All the calls to singleton::instance() no longer compile because the global singleton class is now hidden by the local singleton class just introduced. Next, in the source file add a global variable called instance of type singleton* and refactor all occurrences of singleton::instance() to instance.
#include "legacy.hpp"
#include "singleton.hpp"

singleton * instance;

void legacy::eg1()
{
    instance->call();
}

void legacy::eg2()
{
    instance->call();
}

Then Lean on the Compiler again to make sure there are no typos. Next remove the global variable called instance from the source file and refactor the header file to this:

class singleton; // <-----

class legacy
{
public:
    legacy();
    void eg1();
    void eg2();
    ...
private:
    singleton * instance; // <-----
};

Finally, initialize the instance member in the constructor definition.

legacy::legacy()
    : instance(singleton::instance())
{
}

I haven't tried this on real legacy code either. Caveat emptor!

Lean on the Compiler by Hiding (Java)

Here's a small trick which might not be out of place in Michael Feather's excellent book. I'll use Singleton as a example. Suppose you have a class like this (Java):



public class Legacy
{
    public void eg1()
    {
        stuff(Singleton.getInstance().call());
    }
    public void eg2()
    {
        more_stuff(Singleton.getInstance().call());
    }
}

And you want to create a seam for the singleton access. The first step is to introduce two public fields:

public class Legacy
{
    public int Singleton;
    public Singleton instance;

    public void eg1()
    {
        stuff(Singleton.getInstance().call());
    }
    public void eg2()
    {
        more_stuff(Singleton.getInstance().call());
    }
}

Now Lean on the Compiler. All the calls to Singleton.getInstance() no longer compile because the Singleton class is now hidden by the int Singleton just introduced. Next refactor all occurences of Singleton.getInstance() to instance (the other identifier just introduced, you can pick any name for this one but it's type must be Singleton).

public class Legacy
{
    public int Singleton;
    public Singleton instance;

    public void eg1()
    {
        stuff(instance.call());
    }
    public void eg2()
    {
        more_stuff(instance.call());
    }
}

Then Lean on the Compiler again to make sure there's no typos. Finally refactor to this:

public class Legacy
{
    public Singleton instance = Singleton.getInstance();

    public void eg1()
    {
        stuff(instance.call());
    }
    public void eg2()
    {
        more_stuff(instance.call());
    }
}

The name lookup rules for Java allow this to work but I don't think this idea will work in C++ (for example). I haven't got time to try it now as I'm heading off to the NDC conference in Oslo. I only thought of it yesterday. I haven't tried this on real legacy code. Caveat emptor!

Update. I have a C++ version aswell.

Adapt Parameter and Preserve Signature

Working Effectively With Legacy Code by Michael Feathers (isbn 0-13-117705-2) is a great book. The very first dependency breaking technique (p326) is called Adapt Parameter. It uses this Java example:



public class ARMDispatcher
{
    public void populate(ParameterSource request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put( 
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }
    ...
}


Michael writes:

In this class, the populate method accepts an HttpServletRequest as a parameter. ... It would be great to use Extract Interface (362) to make a narrower interface that supplies only the methods we need, but we can't extract an interface from another interface. ...


and a bit later...

Adapt Parameter is one case in which we don't Preserve Signatures (312). Use extra care.


Well, here's a variation on Adapt Parameter where we do Preserve Signatures. I'll stick with the Java example, but the idea is broadly applicable...

First we create our ParameterSource interface and fill it with the signatures of the methods in HttpServletRequest that our populate method calls:

public interface ParameterSource
{
    String[] getParameters(String name);
}
then we implement the adapter for HttpServletRequest:
public class HttpServletRequestParameterSource 
    implements ParameterSource
{
    public HttpServletRequestParameterSource(HttpServletRequest request) {
        this.request = request;
    }

    public String[] getParameters(String name) {
        return request.getParameters(name);
    }

    private HttpServletRequest request;
}
Next we add an overload of populate taking a ParameterSource and implement it with an exact copy-paste:
public class ARMDispatcher
{
    public void populate(ParameterSource request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put(
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }

    public void populate(HttpServletRequest request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put(
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }
    ...
}
Now we Lean on the Compiler (315) to make sure we haven't missed any methods in HttpServletRequest that our populate method calls. Add any we missed to the ParameterSource interface. Implement them in HttpServletRequestParameterSource as one liners. When it compiles we can refactor to this:
public class ARMDispatcher
{
    public void populate(ParameterSource request) {
        String[] values
            = request.getParameters(pageStateName);
        if (values != null && values.length > 0)
        {
            marketBindings.put(
                pageStateName + getDateStamp(),
                values[0]);
        }
        ...        
    }

    public void populate(HttpServletRequest request) {
        populate(new HttpServletRequestParameterSource(request));
    }
   ...
}
And now we have a seam we can pick it at...
public class FakeParameterSource 
    implements ParameterSource
{
    public String[] values;

    public String[] getParameters(String name) {
        return values;
    }
}


Tao Te Ching

is an excellent book translated by R.L.Wing (isbn 0-7225-3491-4). As usual I'm going to quote from a few pages

In trying to understand a work like the Tao Te Ching, it is important to keep in mind that Chinese characters are not so much representations of words as they are symbols of ideas.
Because of its idea-embedded nature, the Tao Te Ching is a work that brings truth to the adage: It is better to read one book one-hundred times than one-hundred books one time.
True power is the ability to influence and change the world while living a simple, intelligent, and experientially rich existence.
Simplicity in conduct, in beliefs, and in environment brings an individual very close to the truth of reality.
When expectations are dropped, the mind expands, and reality expands along with the mind.
Nothing exists without the presence of its opposite.
Practice non-interference.
A house filled with riches cannot be defended.
Individuals who master themselves become less egocentric
Evolved Individuals strive to be intuitive, spontaneous, and simple.
Never fall completely into step with current society.


Spot the Tao Te Ching Bug

Most mornings I read one of the 81 entries in Tao Te Ching . My copy is called The Tao of Power, translated by R.L.Wing. Highly recommended. I use dice together with the chart in the picture (from page 19) to make a random selection. This morning I happened to notice that I never seem to get certain numbers. Closer inspection of the chart shows why...

Pride and revulsion

Here's a bug that bit me recently. I wrote a very small quick and dirty TDD header for C in my CyberDojo. It has a macro called CHECK_EQ which you use as follows:
CHECK_EQ(int, 42, 9*6);
Part of the macro looks like this:
#define CHECK_EQ(type, expected, actual) \
    ... \
    type e = expected; \
    type a = actual; \
    ... \
Can you see the problem? Well, suppose it's used like this:
    int e = 42;
    CHECK_EQ(int, e, 9*6);
Can you see it now? The problem is that this line in the macro
    type e = expected; \
gets expanded into this line:
    type e = e; \
Ooops. I thought about choosing a very cryptic name instead of x. Perhaps incorporating __LINE__ as a suffix. But I felt there had to be a solution that would always work. After some thought I came up with this. Brace yourself...
#define CHECK_EQ(type, expected, actual) \
   ...
   if (#expected[0] != 'x') \
   { \
       type x0 = expected; \
       type x1 = actual; \
       ... \
   } \
   else \
   { \
       type y0 = expected; \
       type y1 = actual; \
       ... \
   } \
   ...
Like Tom Duff, I feel a mixture of pride and revulsion at this discovery.

The war of art

is an excellent book by Steven Pressfield (isbn 0-446-69143-7). As usual I'm going to quote from a few pages:
Every sun casts a shadow, and genius's shadow is Resistance.
The enemy is a very good teacher [Dalai Lama]
The human being isn't wired to function as an individual.
The truly free individual is free only to the extent of his own self-mastery.
Rationalization is Resistance's spin doctor.
Nothing is as empowering as real-world validation, even if it's for failure.
That's when I realized I had become a pro. I had not yet had a success. But I had had a real failure.
The professional knows that by toiling beside the front door of technique, he leaves room for genius to enter by the back.
Whatever you can do, or dream you can, begin it. Boldness has genius, magic, and power in it. Begin it now. [Goethe]
The Self wishes to create, to evolve. The Ego likes things just the way they are.
We humans seem to have been wired by our evolutionary past to function most comfortably in a tribe of twenty to, say, eight hundred.

Kluge

is an excellent book by Gary Marcus (isbn 978-0-571-23652-7). As usual I'm going to quote from a few pages:
The best science, like the best engineering, often comes from understanding not just how things are, but how else they could have been.
One molecule of DNA polymerase does its job in a perfectly straight-forward fashion, but the other does so in a back-and-forth, herky-jerky way that would drive any rational engineer insane. Nature is prone to making kluges because it doesn't "care" whether its products are perfect or elegant. If something works, it spreads. If it doesn't, it dies out.
What can evolve at any given point in time is heavily constrained by what has evolved before.
The vast majority of our genetic material evolved in the context of creatures who didn't have language, didn't have culture, and didn't reason deliberately.
What is recent is rarely fully debugged.
Our memory is organized to focus primarily on our own experiences.
Other studies have showed that people are more likely to accept falsehoods if they are distracted or put under time pressure.
Organisms tend to value the present far more than the future.
That which is clumsy is rarely reliable.
In physics, they have laws; in biology, we have gadgets [Francis Crick]
The value of imperfections extends far beyond simple balance, however. Scientifically, every kluge contains a clue to our past; wherever there is a cumbersome solution, there is insight into how nature layered our brain together; it is no exaggeration to say that the history of evolution is a history of overlaid technologies, and kluges help expose the seams.

How do you make toast?

I'm doing two days consultancy in Cornwall. Yesterday for the folks at Research Instruments in Falmouth and today for the folks at Absolute Software in Redruth. Both are really great places to work and it's a joy visiting them.

I'm staying at the Penventon hotel. My usual breakfast routine is tea, porridge, and toast. They have a big silver toaster. You put your slices of bread into the front, it pulls them in slowly, applies a lot of heat, and then drops them down a shute.

Yesterday they came out mostly black.

I tried scraping them with a knife. I won't bother next time. They never taste good when you do that. All I did was create black dust for someone to waste time cleaning up. They didn't taste good. I didn't eat them.

I was reminded of the joke:

How do you make toast?

You burn bread and scrape the burn off.

Today I put my toast in the same as before. The toaster slowly pulled them in, applied heat, and dropped them down the chute. The slices were under toasted this time. So I put the slices in again. The toaster pulled them in again, applied heat again, and dropped them down the chute again. Just right. No knives. No scraping. No black dust. No cleaning up. I added marmalade. I ate them. Lovely.

Free

is an excellent book by Chris Anderson (isbn 978-1-9052-1148-7). As usual I'm going to quote from a few pages:
The internet is the first distribution system in history that is as well suited for the niche as for the mass, for the obscure as well as the mainstream.
Just as Moore's Law dictates that a unit of computer processing power halves in price every two years, the price of bandwidth and storage is dropping even faster.
For most of human history manure has determined how much food we had... Historians often look at the great civilizations of the ancient world through the lens of three grains: rice, wheat, and corn. Rice is protein rich but extremely hard to grow. Wheat is easy to grow but protein poor. Only corn is both easy to grow and plump with protein.
Humans are wired to understand scarcity better than abundance.
At some point in your life, you may wake up and realize that you have more money than time.
What [Alan] Kay realized was that a technologist's job is not to figure out what technology is good for. Instead it is to make technology so cheap, easy to use, and ubiquitous that anybody can use it.
Abundant information wants to be free. Scarce information wants to be expensive.
Paradoxes are the opposite of contradictions. Contradictions shut themselves down, but paradoxes keep themselves going, because every time you acknowledge the truth of one side you're going to get caught from behind by the truth on the other side.
Information is what British anthropologist Gregory Bateson described as "a difference that makes a difference."
The electricity consumed by a server now costs more over the life of that server than the server itself.
Rather than depriving life of purpose, material abundance created a scarcity of meaning.

Bounce

is an excellent book by Matthew Syed, subtitled The myth of talent and the power of practice (isbn 978-0-00-73505404). As usual I'm going to quote from a few pages:
Ericsson also found that there were no exceptions to this pattern: nobody who had reached the elite group without copious practice, and nobody who had worked their socks off but failed to excel.
It is the quality and quantity of practice, not genes, that is driving progress.
The ascendency of the mental and the acquired over the physical and the innate has been confirmed again and again.
My dad never asked me to play golf. I asked him. [Tiger Woods]
Child prodigies do not have unusual genes; they have unusual upbringings.
Top skaters fall over more during their practice sessions.
But while the adaptability of the human body is impressive, it is the plasticity of the brain that has astonished researchers.
If you don't know what you are doing wrong, you can never know what you are doing right.
These were some of the clearest findings I've ever seen. Praising children's intelligence harms their motivation, and it harms their performance. [Carol Dweck]
Lowering standards just leads to poorly educated students who feel entitled to easy work and lavish praise. [Carol Dweck]
Many of the contemporaries of Galileo (inventor of the modern telescope) really did think there was something morally dubious about the telescope; that it was taking humanity beyond the powers expressly sanctioned by God.

JavaScript: The Good Parts

is an excellent book by Douglas Crockford (isbn 978-0-596-51774-8). As usual I'm going to quote from a few pages:
This is not a book for beginners... This book is small but it is dense. There is a lot of material packed into it. Don't be discouraged if it takes multiple readings to get it. Your efforts will be rewarded.
JavaScript's popularity is almost completely independent of its qualities as a programming language.
JavaScript is the first lambda language to go mainstream. Deep down, JavaScript has more in common with Lisp and Scheme than with Java.
strong typing does not eliminate the need for careful testing.
despite its deficiencies, JavaScript is really good.
Unlike many other languages, blocks in JavaScript do not create a new scope, so variables should be defined at the top of the function, not in blocks.
An object is a container of properties, where a property has a name and a value. A property name can be any string, including the empty string. A property value can be any JavaScript value except for undefined.
An inner function also enjoys access to the parameters and variables of the functions it is nested within... This is called closure. This is the source of enormous expressive power.
That act of nothingness gives us confidence that the function does not recurse forever.
What matters about an object is what it can do, not what it is descended from. JavaScript provides a much richer set of code reuse patterns.
Much of the complexity of class hierarchies is motivated by the constraints of static type checking.
var memoizer = function(memo, formula) {
    var recur = function(n) {
        var result = memo[n];
        if (typeof result !== 'number') {
            result = formula(recur, n);
            memo[n] = result;
        }
        return result;
    };
    return recur;
};

var fibonacci = memoizer([0, 1], function(recur, n) {
    return recur(n - 1) + recur(n - 2);
});

Simple and Usable

is an excellent book by Giles Colborne (isbn 0-321-70354-5). As usual I'm going to quote from a few pages:
If you ask people they'll say everything is important and anything is feasible.
We tend to keep things, even when they're broken.
Your first design may seem like a solution, but it's usually just an early definition of the problem you are trying to solve. [Luke Wroblewski]
Broken gets fixed. Shoddy lasts forever. [Jack Moffett]
Feature lists sell so as long customers don't get a chance to use the product.
Mainstreamers want "good enough quickly;" experts want "perfect in as long as it takes."
People prefer to be pilots, not passengers.
"Seven plus or minus two." Many psychologists now believe short-term memory may be rather smaller - perhaps just four items.
Simple organization is about what feels good as you're using the software, not what looks logical in a plan.
Designing simple user experiences often turns out not to be about "How can I make this simple?" but rather "Where should I move the complexity?"
The secret to creating a simple user experience is to shift complexity into the right place, so that each moment feels simple.
Don't try to fill your user's mind with your design.

Nudge

is an excellent book by Richard Thaler and Cass Sunstein (isbn 978-0-141-04001-1). As usual I'm going to quote from a few pages:
School children, like adults, can be greatly influenced by small changes in the context.
There is no such things as a 'neutral design.'
Roughly speaking, losing something makes you twice as miserable as gaining the same same thing makes you happy. In more technical language, people are 'loss averse'... Loss aversion helps produce inertia.
Most teachers know that students tend to sit in the same seats in class, even without a seating chart.
Eating turns out to be one of the most mindless activities we do. Many of us simply eat what is put in front of us.
Social scientists generally find less conformity, in the same basic circumstances as Asch's experiments, when people are asked to give anonymous answers.
On average, those who eat with one other person eat about 35 percent more than they do when they are alone; members of a group of four eat about 75 percent more; those in groups of seven or more eat 96 percent more.
Self-control issues are most likely to arise when choices and their consequences are separated in time.
Even hard problems become easier with practice.
The best way to help Humans improve their performance is to provide feedback.
For most of their time on earth, Humans did not have to worry much about saving for retirement, because most people did not live long enough to have much of a retirement period.

public: footpath

You know you know C++ when you see a sign like this and you think, "there's a colon missing after public."