[Help!] What would you show/teach with Pokitto to shy 10-12 yr olds?

Hello everyone!

Today I visited a code school class with a dozen 10-12yr olds. I showed the Pokitto to them and I am due to hold a 1-hour class to them.


  1. all of them were quite shy. It seems they prefer to work alone instead of as a group
  2. even though they’ve had several classes this semester, they’re pretty beginners. They do Scratch and Python
  3. many of them were ‘stuck’ in doodling graphics with Scratch

Now, point #3.

I am wondering if Scratch really is the right way to start learning programming. Instead of grasping the concept of programming, many of them spent the hour fine-tuning their Scratch program background images. And this was their 6th lesson.

It was a sobering encounter. I didn’t realize this is the normal situation.

If you have any good ideas what I could teach to complete beginners, something that can be accomplished in 1 hour, and would be fun on a Pokitto then help me with your ideas!

I would not want to turn them to making graphics editing of any sort because that will be the entire hour gone. I would really like to teach some real concept of programming instead.

1 Like

I have seen many turning to scratch as a crutch more than a stepping block to more practical programming code.

Maybe it would be possible to fit in a number guessing game? And have the pokitto face for happy or sad on success or failure?

Yes, I was thinking about that also. But since there is no number keys, its kind of hard.

I am about to start teaching kids about this age programming in Snap (similar to Scratch) sometime this month. I have some very basic games ready. Some of the simplest that could be made within an hour (that’s really too little time for anything more complex than really trivial though):

Then I also have an aquarium and a rallye game, but that’s most likely too much for one hour lesson.


It’s a tough question. Kids associate computers nowadays with something with a touchscreen. Writing code involves a learning curve that wasn’t there for people who started using computers with a terminal.

That said, if you’re trying to get them to do actual code… The first thing anyone does in any new language is print “hello world”.
Once output is taken care of, now they need input: give them an ask function that blocks until a button is pressed.

With that they’ll be able to print the number of the button and that’s all you need for a rough guessing game: printf("The dice rolled %d, you guessed %d.", random(1, 6), ask());

Next teach them if and they can print “you win” or “you lose”. Maybe also teach how to declare variables.

At this point they know all that’s needed for a simple text adventure game. Add loops and they can have a state machine for complex text adventures.

I suppose making an up or down selector would be a bit much when included with the math logic…

I’m going to ramble my thoughts out loud in case I say something useful.
(If not, we’ll just have another incoherant word wall to add to the collection.)

I highlighted the important bits if you don’t have time for my ramblings.

You don’t need number keys.

Provide them with an extra library/utility that prints a number and that number goes up when they press up and down when they press down (and possibly cap it to something sensible, like 0-10).

class NumberGadget
	int getNumber(void) const;
	void increaseNumber(void);
	void decreaseNumber(void);

NumberGadget numberGadget;

using Pokitto::Core;
using Pokitto::Buttons;
using Pokitto::Display;

int main(void)
	// ...
	Display::setCursor(60, 40);
	// ...

Remember, half the point of an API is to create an easy-to-use interface so that the end user doesn’t have to care about how it’s implemented.
You can use that to your advantage.

E.g., if you want to show off the traffic light hat:

class TrafficLight
	void redLightOn(void);
	void redLightOff(void);
	void yellowLightOn(void);
	void yellowLightOff(void);
	void greenLightOn(void);
	void greenLightOff(void);

If you make the API simple enough, a 10 year old genuinely can understand it.
That’s how Arduino came about after all.

That may or may not be a bad sign, I think it depends on:

  • How many lessons there are in total
  • What they’ve covered in previous lessons
  • How the teachers are teaching them
  • Cultural elements (e.g. here in Britain we start school at age 4, whereas other countries start aged 5)

It could just be that they aren’t as far in as you think.
And in all fariness, it’s hard enough getting teenagers and adults interested in programming, so I would expect it to be difficult to get children interested.

Personally I dislike Scratch and other forms of block code.
I think things like flowol/flow charts are good for understanding and visualising algorithms, but they always feel like a bit of a lie because they’re so far removed from the real deal.

The problem here is finding something that interests them.
Not many younglings are going to be particularly interested in maths or physics, even if they have useful aplication in games.

Instinctually I would say: try to set them a challenge.
Programming isn’t about punching numbers into a terminal, it’s about problem solving and critical thinking.
We may be architects of the abstract, but there’s always an end goal - always a problem to overcome.

Rather than trying to get them to make a program from scratch (if you’ll pardon the pun) I think it would be better to provide them with a half-finished program and get them to finish it.

A lot of people, when they start out with programming, really struggle to think for themselves.
They can verbalise an answer to the problem, but they don’t understand the language enough to know how to formalise that thought stream as code.

By giving them half-finished code, you give them a leg-up.
Not only does it test their ability to read code and understand it, but hopefully it will make it feel like you’re cooperating with them rather than demanding something from them.

When they complete the challenge, or even if they don’t complete it, you should encourage them to play around with the code in an attempt to do something interesting.

I can’t remember who said it, but I remember back when Space Engineers used to put quotes on the loading screeen, one of the quotes was something like:
“If you want to understand something, study it when it’s coming apart.”

The same is true of programming, to understand the wheel you must break it apart and reinvent it.
The main reason I understand quite a lot about the inner workings of the stdlib is because I’ve attempted to reimplement a lot of it at various points in time, and I’ve looked at different implementations - disecting them to understand how they work.

Also, humans learn from failure - trial and error is a perfectly valid learning strategy.
(Without it, we wouldn’t know which berries are poisonous.)

If you were looking for a more concrete sugggestion…

Noughts and crosses is always one of my favourite games for testing a system’s capabilities, but even if you implemented most of it and got the kids to do the finishing touches I’m slightly worried that it might involve concepts they aren’t ready for.

A number guessing game as others have suggsted could be good if you want to touch on conditional expressions.

Fundamentally I think what you demonstrate to them or ask them to do will be governed by a fundamental question:
How much (and what exactly) do you plan to teach them?


From my point of view (feels like being on the outside looking in!) I would go with whatever software teaches the point of the lesson. Sorry if that is obvious but if you bombard people with C++ (for example) then they aren’t necessarily going to grasp it with both hands.

There are so many different programming languages available that that in itself can be a daunting prospect.

So lesson 1 would be, ideally, what languages are available and what famous software they were used to create - forge a link with your audience.

Lesson 2 might be some BASIC, learning a bit of Boolean operators and the like,

Lesson 3 loops - using SonicPi. It’s brilliant for just that purpose

And so on…Use the best tool for the job - being the one that is most engaging - and then highlight what the lesson means (vars, loops etc.)

Does that sound about right?

Note:- Forgot to add that the addition of visual / aural stimulus is vital (imo). But it’s all very well showing a demoscene show reel so long as you don’t go straight into assembler :wink:

1 Like

Some advice from a seasoned expert (or an arrogant buffoon, depending on your viewpoint :P),
once you’ve got experience in one programming language and start learning a second one,
it gets a lot easier to pick up new ones after that.

You eventually realise that actually programming is all about problem solving and conceptual ideas,
and that programming languages are just a tool for expressing those ideas to the computer (and other programmers).

That said, languages still have different nuances and everyone has their preferred languages and hated languages,
but once you’re reasonably skilled in one language it doesn’t take very long to learn the basics of another language.
It will always take a long time to ‘master’ a language (if anyone actually can) and/or to learn all its little quirks and idioms,
but the more experienced you get, the less time it takes to go from knowing nothing about a language to being able to do something useful with it.

Fundamentally, pretty much all languages have variables, expressions, functions and data structures.

I feel the need to say that bacause I don’t think it gets said often enough and it probably isn’t obvious given the number of people who like to war over languages (myself included).

Technically speaking the language is called ‘an assembly language’ and the tool that ‘assembles’ that into machine code is called ‘an assembler’.


You mean almost like… math? Reference to our private conversation :slight_smile:

Anyway, you’ve pointed out an important idea about the languages that makes me want to add this advice:

When introducing beginners to programming languages, explicitly make it clear they’re very different from human languages.

I say this because when a newcomer to programming hears “programming language” they probably think it’s like a foreign language and that it takes many years to be able to effectively use any one. The word language must sound scary. So be sure to tell them it’s as @Pharap says: the first one takes a while to learn, though not nearly as long as a foreign language, and then the new ones are very easy to pick up, as they reuse most ideas.

There was one guy who was playing around with Unity. The problem is he didn’t know C#.

So he was looking for answers to Unity API questions from C# references.

I remember my own confusion when learning C++ and started with some sort of a library and was unable to distinguish the different abstraction levels

I’ve been working with middle school kids in the U.S. (11-13 year olds), and one thing that seems to engage them is the physical crafting of breadboard circuits. I give them a spool of solid core wire and some strippers and have them get all the connections as precise as they can. Maybe they would like connecting LEDs, pots or light sensors to the extension header.

I am also suspicious of block programming languages, mainly because it makes it difficult to share and discuss code.


But you can’t program computers with maths alone.
Besides which programming is arguably more fun and more useful.

Programming is to formal logic what carpentry is to geometry.
(That’s probably an analogy riddled with errors, but it sounds cool.)

That’s not entirely untrue, it does take years to get good at programming.

But it’s true that they’re much quicker to learn than foreign languages, as my poor abilities in French and Japanese will attest to.

This is one of the reasons I don’t like Unity.
It encourages people to try to make games without learning how to program.
Trying to make games without learning how to program just punishes you in the long run because you don’t learn about hardware details, why certain approaches are faster than others, and most importantly you don’t learn the problem solving skills.

I won’t deny, trying to get a dynamic-link library working with your code is one of the fiddliest things about C++.

One of the few things I learnt in college that I think was particularly useful was the black box analogy - the idea that you don’t need to know how something works to use it.

At the time I didn’t appreciate it because I wanted to know how everything worked and I didn’t realise that “you don’t need to know how it works” had the implicit exception of “you do need to have a general idea of what it does”.

But now I appreciate the analogy more, and I know how it can be improved on:
I don’t need to know how a remote control works at a circuit level to know how to change channels.
I don’t need to know how a sorting algorithm works to know it’s going to sort my objects when I give the function an array of objects.
It might take some explaining and convincing, but it’s the fundamental idea of libraries.

And of course, some people will want to know how everything works - that’s fine.
Just remind them that rome wasn’t built in a day.

I’m pretty sure at least some block languages do have file formats.
From what I can tell, scratch use JSON compressed in a .zip file with a custom file extension.

For example, this block code:
Corresponds to the JSON:

        ["doUntil", [">", ["timer"], "10"], [["gotoSpriteOrMouse:", "_mouse_"]]],
        ["think:duration:elapsed:from:", "Scratch 2.0 is amazing!", 3]]]

You can certainly see the relationship between the two,
but you probably wouldn’t want to try to edit the plaintext version.

That’s probably one the big advantages of programming languages that people take for granted - if you really want to, you can write code in any old text editor, you don’t really need a big, fancy IDE.
Sometimes I’ll even write code on paper if I’m not at a computer (though I might elide some of the syntax details, writing by hand is more effort than typing).

1 Like

Before Pokitto I did a couple of Unity games for a hobby. Unity is a huge, bloated, environment which enables you to do a lot of of things. Over the years, you probably get familiar with all the aspects in it, and everything get easier, but do not expect to be productive any time soon.

Pokitto programming was like a breath of a fresh air after that!


I dislike Unity for a different reason :wink: Luckily there is Godot.

To address the main point though: I think it’s not necessarily bad if you learn programming this way – it’s different from how programming has been taught traditionally – that is from the bottom up, command line to graphics and so on. Because traditionally there hasn’t even been any (good) alternative.

This is a different, new way of how to get there (same with Scratch) – it’s a top-down learning. You learn in different order, but the necessity will force you to eventually learn the lower level details (if you manage to persist in learning, that is).

Of course both approaches have advantages and weaknesses, but I don’t think one is necessarily superior.

(Personally I potentially see the combination of both bottom-up and top-down as the most effective.)

Same feeling here!

This is the problem - many people don’t feel the necessity to go further.

They can make fancy-looking games by just copying code snippets from the internet so they persist in doing so,
they never bother to try to go further because they’re convinced they don’t need to.

So what you end up with is someone who can’t really do much who is convinced they can make any game they want to just by copying snippets off of Unity’s forums.

Scratch is a bit better because it at least forces people to think a bit about what they’re doing at a higher level.

@Pharap I usually get Assembler and Assembly the wrong way around, it’s a feature! :+1::joy:

1 Like