Tricky Triplets - a storified replacement for Two Fer

[kytrinyx]

Background

When we redesigned Exercism we gave each exercise its own icon. This made a huge difference. The tracks feel a lot more fun and approachable.

A common complaint about exercises is that they feel overwhelming or unapproachable or hard to understand. Often this is because there's too much jargon in the description. Other times it's because the domain is foreign to the reader.

Lately @iHiD, @nicolechalmers, and I have been discussing how we'd like every single exercise on Exercism to be fun and approachable, and we've been discussing how we might accomplish this.

Suggested solution

The approach that we think has a lot of merit is to ensure that each exercise has

1. an appealing icon
2. an inviting title
3. an engaging storyline

We aren't going to go all out just yet and mandate that every single exercise be transformed into a story, however we would very much like to talk about stories for any new exercises that are introduced.

Also, we are open to people proposing stories to either tweak or replace an existing exercise.

There will be a balance to strike with stories. We want to hit the goldilocks zone of "not to little" and "not too much". E.g. "two fer" is not quite enough, but we also don't want to have to invent a whole new alternate universe with magical laws and a complex cast of characters.

Since this can feel really abstract to talk about without an example, we looked at what it could mean to turn the two-fer exercise into a story, and it boils down to this:

• strip away all the details
• determine what the technical challenge is

For two-fer, if you strip everything away, the fundamental challenge is to format a simple string with user-provided input, and provide a default/fallback for when the user did not provide a value.

It doesn't matter what the string actually says, what the values are, or what the default value is. That said, we decided to stick with the basic "one for {x, you}, one for me" that two fer already has.

Here's the story that we came up with, as a starting point:

---

Tricky Triplets

One year ago, Lori gave birth to three beautiful daughters - Toa, Layla, and Adra - identical triplets. She hasn't slept much since!

Lori recently started introducing her daughters to solid food and is using the time-old tradition of eating a bit herself to encourage them: "One for Toa, one for me!", substituting the name of the baby in question, of course.

Recently, her parents came to visit, and they love helping out with the triplets. Unfortunately, they can't always tell them apart.

Your task is to provide a safety net for whichever adult happens to be feeding the triplets. When they can remember the name, they'll use it, but when they can't, they'll just say "you" instead.

In coding terms, you're going to write a short program which can be called in two ways, to either encourage a specific baby by name, or to encourage whichever baby is being fed at the time.

If you call encourage "Adra", the output should be "One for Adra, one for me.". Otherwise, the output should be "One for you, one for me.".

Can you make all the tests pass and ensure that Lori's children don't end up frustrated with their grandparents' ability to tell them apart?

---

What we want your help with is to finalize the story.

Is this story too much? Too little? Is it missing a key component? Is it problematic in any way?

Once we're certain the story itself is what we want it to be we'll also want to do copy-editing to ensure that it's as expressive as possible, flows well, and is grammatically correct and has no typos.

[iHiD]

(cc @exercism/track-maintainers before we march ahead 🙂)

[rpottsoh]

We want to hit the goldilocks zone of "not to little" and "not too much"

I don't know what this looks like.

[Cohen-Carlisle]

I think the story is fine (cute, even), but I'm not sure I like the title being so closely tied to the story instead of the exercise. When I first read the title I started imagining an exercise about having to choose between three options with some kind of algorithm.

[rpottsoh]

I am reading @Cohen-Carlisle's comment above and I agree. The title of the exercise ought to foreshadow what the problem is about that the student is being challenged to solve. For me, Two-Fer kinda does that. The fact that the description is a story about triplets is a random occurrence. The story could easily be about a kid divvying up marbles with his friends who has a poor sense of what is fair. One for you, two for me.

[iHiD]

Thanks for comments :)

So I disagree. I think these core exercises should be about the story, not the function, in all element (title, image, story, etc). For side exercises, where you need to choose which one to explore, quickly guessing the algorithm makes sense (e.g. isograph, pangram, grains, acronym). However, for core exercises, where someone does them in order, I think I want people to feel like there is a relevant story that they're solving, not just a wrapper for an algorithm they have to learn. Also, this exercise will generally be someone's first introduction to Exercism, and I don't think they'll have the pre-association at that point with "exercise == algorithm" that we instinctively have as regular users.

Two-fer is a great example. Before doing it, I had no preconceived association or idea about what the title meant, and now I've done it, I couldn't tell you the story behind the exercise. There was no reason for me to do it, other than it was a coding challenge, no emotional pull, no smile, etc. It's purely a functional challenge, quickly done and quickly forgotten. The reason that I like Bob or Food Chain as exercises is that I remember them fondly because I can tell you what they're about - why I solved them. I feel that that is lacking in many/most exercises right now.

[bencoman]

Really like the story line. For the title, I think use of "Triplets" creates misdirection. Nothing in
the exercise is related to the number of bubs. "Toddler" is a stronger word association to bubs than "Triplets". A title of "Toddler Twofer" better reflects the story, plus provides pleasant alliteration.

[Cohen-Carlisle]

Also, this exercise will generally be someone's first introduction to Exercism, and I don't think they'll have the pre-association at that point with "exercise == algorithm" that we instinctively have as regular users.

That's a good point. But I would echo @bencoman's suggestion, which is basically
why not both

animated gif

https://66.media.tumblr.com/0ae4a458b02b1705c96dd846493e2aad/tumblr_inline_n3ghj9J3u91qcklud.gif

I think having the name be associated with the story but also call to mind the code that was written will help it be even more memorable.

[rpottsoh]

I can see how a story can help one retain a memory of the exercise.

I conducted a little experiment just now. I asked my 15 year old daughter, who knows nothing about programming, to read two-fer and then tricky triplets. She found two-fer easier to comprehend because it was shorter and to the point. This was not a scientific experiment but I found the result interesting just the same.

I do agree, @iHiD, that there is value in a story if it helps one better retain a memory of the exercise. Tricky triplets does that, two-fer doesn't.

[macta]

Just a small reaction to this - the goal is a good one but if the descriptions get too elaborate and wordy it becomes too much of a chore to get going. You may find that you have two types of audience - the typical hacker learning a new language that wants to get going (hence succinct) and a newbie that wants a cuter description.

You can definitely support both, but I would try not to be too cute with the descriptions.

[bitfield]

animated gif

[kytrinyx]

Note: I've edited the conversation above to collapse animated gifs in HTTP details blocks, as I have a condition that makes it extraordinarily difficult to read a conversation with moving images in it.

We want to hit the goldilocks zone of "not to little" and "not too much"

I don't know what this looks like.

@rpottsoh that's why I opened this issue, so that we can explore that line.

The fact that the description is a story about triplets is a random occurrence. The story could easily be about a kid divvying up marbles with his friends who has a poor sense of what is fair. One for you, two for me.

Yes! Exactly. The story is not about the algorithmic part of the challenge. It doesn't matter what it is, only that it is memorable, and doesn't get in the way of understanding what you're supposed to do.

if the descriptions get too elaborate and wordy it becomes too much of a chore to get going

@macta Yes, I completely agree. This is where I think we need to find the balance. I'd actually love to see a couple of experiments:

1. The triplets story, except more succinct. Can we find a balance that keeps the emotional potential without making it onerous to get going?
2. The marbles story I like the poor sense of fairness thing. It also packs an emotional punch. Can we look at what two-fer would look like rewritten (equally succinctly) to be about the marbles (or candies, or cookies or whatever)

For the title, I think use of "Triplets" creates misdirection. Nothing in
the exercise is related to the number of bubs.

This is interesting. I don't think the title needs to be about the specific challenge. The title is (to my mind) only a mnemonic hook so that you remember which exercise is what, and a way to talk about it either in GitHub issues or on Slack or at meetups or whatever.

[bencoman]

For the title, I think use of "Triplets" creates misdirection. Nothing in
the exercise is related to the number of bubs.

This is interesting. I don't think the title needs to be about the specific challenge.

I agree. But whoops, I re-read the challenge and it does actually say "Toa, Layla, and Adra - identical triplets." Now what is interesting is why that didn't stick in my head so I made my comment above? Maybe because that information was irrelevant to challenge. But that could just be me - so here is an experiment you might do... Get a few people locally to read the story without the titles, then five minutes later give them the two titles in random order to choose between. Go with whichever has getss the most hits.

[NobbZ]

The problem I see with this story, it encourages hard coding the names. There are exactly 3 triplets and we know their names at implementation time.

In most languages I'd create a sum/enum type with 4 values. One for each of the triplets and the "unknown" case.

If though the tests would pop up with a random name, I'd say it invalidates the story/exercise assignment.

I really like the idea of the story, but we need to come up with one that still encourages a generic implementation.

[Cohen-Carlisle]

Sorry about the animated gif, @kytrinyx, and thanks for handling it with grace.

I didn't think of it at the time but I do agree with @NobbZ on the story being too specific while the implementation is intended to be general. So in my opinion,

1. the story would need to be as specific or general as the implementation should be, and
2. the title should help you remember the whole exercise, and hence be related to both the story and implementation.

[bencoman]

A more generic story would be a child care center.

Toddler Twofer
Lori recently started work at a child-care center. When introducing toddlers to solid food she uses the time-old tradition of eating a bit herself to encourage them: "One for Mary, one for me!", substituting the name of the baby in question.

But there are so many new names to remember.

Your task is to provide a safety net for her. When she remembers a name, she'll use it, but when she can't, she'll just say "you" instead.

In coding terms, you're going to write a short program which can be called in two ways, to either encourage a specific baby by name, or to encourage whichever baby is being fed at the time.

If you call "encourage Justin", the output should be "One for Justin, one for me."
If you call "encourage" with no name, the output should be "One for you, one for me.".

Can you make all the tests pass to ensure the children don't end up frustrated with her ability to tell them apart?

[bencoman]

Or...

Toddler Twofer
A child care center has an automated baby feeding robot that feeds toddlers using the time-old tradition of eating a bit itself to encourage them. "One for Mary, one for me!" it says, substituting the name of the baby in question.

But its facial recognition system is poor. Staff complain that when it can't determine the toddler's name it gets stuck and stops feeding the child.

Your task is to provide a safety net for the bot. When it knows a name, it uses it, but when it can't it just says "you" instead to avoid stalling.

In coding terms, you're going to write a short program which can be called in two ways, to either encourage a specific baby by name, or to encourage whichever baby is being fed at the time.

Calling "encourage Justin" should output "One for Justin, one for me."
Calling "encourage" without a name should output "One for you, one for me."

Can you make all the tests pass to ensure the children don't end up frustrated with the robot's ability to tell them apart?

[bencoman]

Minor side-request:
If this change goes ahead, will the names in the canonical data will be updated? https://github.com/exercism/problem-specifications/blob/master/exercises/two-fer/canonical-data.json#L16-L18

If so, could you consider also renaming the parameter from "name" to "child".
The generated code for these alternatives would be (in Pharo)...

• twoFer child: 'Justin'
• twoFer name: 'Justin'

and the former has a nicer tone to it.

[kytrinyx]

@bencoman I just wanted to say that love your variations on this theme.

If this change goes ahead, will the names in the canonical data will be updated?

Yeah, almost certainly.

[ErikSchierboom]

I really love @bencoman's variations (with a slight preference for the first one). They are a little bit more concise, and somehow the story is more relatable (at least to me).

[NobbZ]

I like the childcare proposal as well, but strictly prefer the first over the second. The child-care-bot draws a picture of a future I'm semi-actively working for but still have massive fear about…

[emcoding]

I like the child care variation! And I prefer the second over the first, because:

• it mildly annoys me that when it's about child care, it's a 'she' :-) While making it a 'he' carer would make it conspicuously correct. So, avoiding the gender question is a plus for the robot to me.
  (Or, change to 'they' for the subject, as seems to be the common practice on Exercism.)
• more important: it explains why it must be solved with code, rather than putting up a poster with pictures on the wall ;-)

[iHiD]

I like the new versions a lot.

I still don't get why this is called "TwoFer", which to me implies the phrase "Two for one", which seems to be nothing to do with this (or the original) exercise.

With regards to the canonical data, this will be a new exercise, designed to replace TwoFer in the tracks, not a rename of TwoFer. I would expect that maintainers will choose to deprecated TwoFer at the same time.

[rpottsoh]

#290 seems to be where the two-fer seed was planted..... and later resurfaced in #548 (comment)

My understanding of twofer for example is buying 2 things for the price of 1. In the case of the two-fer description.md I think this is not conveyed clearly. The first sentence is straight forward, but I don't see how it relates to the second sentence. A simple story could be inserted between the two sentences to tie together buying 2 [somethings] for the price of one and then sharing one with a friend, one for you and one for me.......

[bencoman]

I still don't get why this is called "TwoFer", which to me implies the phrase "Two for one",

Considering "one for you, one for me" I inferred it was because count to "for"s. Maybe the exercise should be called TwoFor ? But TwoFer sounds nicer. Maybe the girl or robot originated in Ireland? "one fer you, one fer me"

[bitfield]

"two fer" is not quite enough, but we also don't want to have to invent a whole new alternate universe with magical laws and a complex cast of characters.

I understand and totally support the motivation behind this, to make Exercism exercises more memorable, fun, and involving.

However, I do think there's a danger of us getting too drawn into the story aspect of it. After all, the purpose of the exercise is to get students to write a simple program. They are already focused on this, and will likely skim-read the problem description quickly to get an idea of what they need to do. All extraneous detail is, in a sense, slowing them down and distracting them. A story like the sample ones in this thread is actually quite hard to parse, to extract what is required of your program and what is delightful, whimsical, and colourful detail.

To avoid this, perhaps we could divide the stories into two sections: the introductory part which gives the colour and detail, and a second part which gives a plain statement of what program the student is expected to write, along these lines:

Write a function ShareWith which takes a string parameter name and returns a string. If the given name is "Alice", the result should be "One for Alice, one for me." If no name is given, the result should be "One for you, one for me."

Those who are in a real hurry to get cracking can skip to the plain-language problem description, and those who want to linger over a beautifully-crafted story can get there via that route instead.

[coriolinus]

I like @bitfield's suggestion that we divide the problems into "Story" and "Problem Statement". Suggest we frame the problem statement in the broadest possible terms. Even calling the parameter name a "string" causes problems, depending on what's idiomatic for the language. For example:

def share_with(name="you"):

func ShareWith(name string) string

pub fn share_with(name: Option<&str>) -> String

All those parameters have distinct types, and all three functions have distinct ways of indicating that the default should be used. We should attempt to avoid writing the problem statement in a way which accidentally misleads for individual tracks.

[kotp]

Those who are in a real hurry to get cracking can skip to the plain-language problem description, and those who want to linger over a beautifully-crafted story can get there via that route instead.

I will sometimes do this but from the perspective of writing the program by being driven via the tests, rather than what ever the problem description is, and then going over the written description to see how closely the tests caused me to implement the solution, regarding things such as names (for the problem domain, etc.).