12. Functions - NariShakti 12. Functions | NariShakti Humane ClubMade in Humane Club

12. Functions

Functions

Eleven sessions. Eleven games. One game waiting in the backlog since day one. She didn’t ask about the Sherlock Holmes game at the end of this session. She didn’t need to. She was already there.


A set of steps with a name

A function is a set of steps bundled together and given a name. Instead of writing or saying the same sequence of instructions every time, you write it once, name it, and call the name whenever you need it.

I started with her skin routine. Every morning, same steps, same order. She doesn’t think through each step individually. She runs the routine. The routine is the function.

Then I told her about the house cleaning checklist I’d made. Clean kitchen doesn’t mean one thing. It means wipe the counters, clean the stove, empty the bin, wash the dishes, mop the floor, put things back in their places. Fifteen tasks. But I don’t recite all fifteen every time. I say clean kitchen and everyone knows what that means.

And then the dessert we’d invented together. Hung curd, chopped fruit, a specific way of mixing it. We’d named it Bu Yum. Now when anyone in the house says Bu Yum, the whole recipe is implied. The name carries the function.

She understood it immediately. But understanding a concept and knowing how to build a game around it are different things. And this was the session where that gap showed up first.

Bu Yum arrived in this session as an example and it worked better than I expected. She didn’t just recognise it as a function. She recognised that she was the one who’d named it. The naming had been hers. The concept gave a structure to something she’d done instinctively. This session had more of that moment than any other.

How she chose what to build

Her first attempt was a game called Name the Game.

She’d understood that functions bundle steps and give them a name, so she designed a game where the player names what a stick figure is doing based on its actions.

A stick figure turns around, waves, wriggles, and sits down. Is it in dance class? Trying to make a baby laugh? Signalling for help?

A stick figure picks up a teapot, pours tea, sips it, then dances happily. Did it get a caffeine rush? Is it teaching someone to dance? Trying to make a baby laugh?

The idea was there. The stick figure’s actions were the steps. The player had to name the function — identify what bundle of actions added up to.

But the game wasn’t performing any functions. It was describing them. The player was recognising named actions, not calling a function and watching it execute.

I told her. She understood the difference but got stuck on how to build a game where a function actually ran — where you called a name and something happened as a result.

I gave her the dance example. Imagine four moves: jump, wave, spin, cartwheel. Those are the steps. Now bundle them in different orders and name each combination. Silly Dance: wave, spin, wave. Athletic Dance: jump, cartwheel, jump. Party Dance: spin, wave, cartwheel, spin. Each name calls a specific sequence. Each sequence produces a different performance.

She sat with that for a moment.

Then she mentioned Joy.

She and her best friend Joy have a game they play: they reverse each other’s names as a kind of code language. YOJ and IBUS. They’ve been playing scrabble together for a few years. A reversal is a function. Input goes in. The reversal rule is applied. Output comes out. Every time.

The Secret Spy game arrived fully formed almost immediately after that.

I want to name something about this session that the post doesn’t quite say. The maths question i.e is a function in maths the same as a function in computational thinking, wasn’t just a smart question. It was evidence that eleven sessions of naming things had built a habit: check whether something is actually new before treating it as new. She’d been doing that instinctively since session one. By session eleven she was doing it consciously. That’s the series working.

The design doc


Each instance uses a different cipher, a different function. Same input format, a coded message, but a different transformation rule applied each time. The player’s job is to identify the function from its output. Work backwards from what came out to understand the rule that produced it.

That’s a sophisticated game design decision. She’s not asking the player to apply a function. She’s asking the player to reverse-engineer one.

And the password in Instance 2:WEE WILLY WONKA: is pure nine-year-old. Some things don’t need explaining.

Design → Build → Ship

Clean build. The concept was clear, the game idea was precise, and the design doc reflected both.

She’d been building under the constraint for six sessions now. The brief was tight. The output matched.

No significant bugs. No tears. No twelve-prompt debugging sessions. A session that moved as quickly as the concept had landed — which was quickly, once Joy and the reversed names unlocked it.

What this is actually building

The maths question is the thing I keep coming back to.

She asked it before building anything. Before the stick figure attempt, before the Name the Game confusion, before Joy and the spy game arrived. She sat with the concept for a few minutes and asked: is this the same as what I already know?

That’s the instinct of someone who has learned to look for connections before accepting that something is entirely new. Eleven sessions of naming concepts that were already present in her experience had built a habit: when you encounter something new, ask first whether it’s actually new or whether it’s something familiar seen from a different angle.

The answer, in this case, was mostly the same thing but bigger. She accepted that and moved on.

The stick figure attempt matters. Not because it worked but because it showed exactly where the gap was. She understood the concept. She couldn’t yet translate it into a game mechanic. That gap, between understanding and building, is real. It’s different from not understanding. The dance example closed it. Joy closed the rest.

Functions is where she learned that the best designs come from problems you’ve already lived, and that a childhood code language with a best friend is a function you’ve been calling for years without knowing the name.

Functions is where she knew it was almost over. And she was ready. ⚡️

What I understand now: the Name the Game attempt, the stick figure game that described functions without performing them, was not a wrong turn. It was the exact gap that needed to be visible. She understood the concept. She couldn’t translate it into a mechanic. That gap, between conceptual understanding and design execution, is real and specific, and it’s different from not understanding. If she hadn’t hit it here, she might have hit it in the final free build.

What’s next

She knew this was the last concept before the free build.

Eleven sessions. Eleven games. And one game that had been waiting in the backlog since day one.

She didn’t ask about the Sherlock Holmes game at the end of this session. She didn’t need to. She was already there.

Your turn

Use this section as a reference before and after the session. The memoir above is our story. This is the kit is for you to try.

The concept

A function is a set of steps bundled together and given a name. Instead of repeating the same sequence every time, you write it once, name it, and call the name whenever you need it. At 8–12 the interesting question is not what a function is but what makes a good name for one: a name that communicates the whole bundle without explaining every step. For example: a recipe, clean kitchen, morning routine. Naming a function well requires knowing what the steps are for, not just what they are.


Green flag: your child invents a name for something they do repeatedly and the name immediately communicates what happens, without further explanation needed.

Try this

Ask them to list three things they do every day that have multiple steps. Then ask: if you had to name each one so that someone else could call it by name and know exactly what to do, what would you call it? Then ask: what’s the difference between a good name for a function and a bad one? A good name communicates the whole bundle. A bad name requires explanation.

Before the design challenge: a screen-free activity (15 minutes)

Write three daily routines on separate pieces of paper without naming them. Just the steps. Ask your child to name each routine in one word or phrase.

Then swap. Your child writes an unnamed routine, you name it. Compare the names. Did the same steps produce the same name?

Where the names diverged is where the concept lives: a function’s name reflects what the namer thinks the steps are for. Two people can look at the same steps and name them differently because they’re abstracting to different purposes.

Going further

If your child races through this:

Ask them to design a personal function library: a list of ten named functions from their own life, each with the steps bundled underneath. Then ask: which functions do you call most often? Which could you combine into a higher-level function? That last question (functions calling other functions) is how complex software is actually built, and it’s within reach once the basic concept is solid.

If your child needs more time:

Stay with the naming exercise longer before moving to a game. A function is only as useful as its name is clear. Take five different activities and practise naming them precisely. Not ‘do stuff in the kitchen’ but ‘prepare breakfast.’ The constraint: the name must communicate the purpose, not just the activity. That distinction is harder than it sounds and worth spending time on before the design challenge begins.


New here? Start with the series introduction. Parent’s Guide: Computational Thinking for Pre-Teens