Stop Teaching Code.

Solicit Predictions Instead.

Photo credit: @adityaries

I’m serious — stop it with the gatekeeper introductions to content.

In theory, it makes sense to start with the core building blocks and work your way up. That’s why so many CS lessons on functions start with “Today we’ll be learning about functions. Functions are a repeatable, customizable blocks of code which can be defined with the keyword def and which can …”

Before you know it, you’ve wound up explaining the difference between a reference type and a value type to someone before they could possibly give a hoot about the difference.

If your students are already 100% on board with CS, then at best they’ll have already mined this information on their own on YouTube or reddit. At worst, they’ll endure the lecture while you slog your way through. But the students who weren’t sure if this was the right class for them? You’ve just confirmed what they feared — that this class only welcomes those who could already pass it.

To be honest, starting in the world of the theoretical isn’t inherently flawed. David Malan does a really great job of this bottom-up approach to code without accidentally screening for prior knowledge in Harvard’s CS50 course. Whenever he calls on a student, he celebrates the reasonable misconceptions of beginners, and acknowledges but does not glorify the more advanced students’ out-of-scope questions (which can alienate those with less experience).

But odds are, you aren’t David Malan. So I want to propose an inversion of the lesson structure that lets you welcome beginners with the same enthusiasm that he does.

Here goes.

DON’T: The Academic Model

Teachers feel the need to be the source of truth. I say this from a place of humility, because I was perhaps the worst offender at my school in my first year of teaching English. I was 23, only 5 years older than my high school seniors. It didn’t feel like enough of an age gap to inherently demand respect, and so tried to command respect in two other ways: I wore a tie, and I pretended to know everything.

To be honest, it almost worked, but it also meant that a lot of my lessons involved throwing up a slide with a definition of a poetic or rhetorical device on it, having students write down the definition, showing an example, and then being disappointed when they couldn’t identify another example of that device later on in the lesson.

If we were to break that into steps, it looked something like this:

  1. Identify academic vocabulary word students should know.
  2. Show definition. Insist that this definition is important.
  3. Show example.
  4. Ask students to “create” own example.
  5. Repeat 1–3 for about five (5) total terms.
  6. Give a multiple choice quiz with *other* examples and ask students to identify which definitions mapped onto which examples. In other words, ask them to solve a puzzle (for a grade!).
  7. Despair as only my most privileged and well-read students succeed.

This approach wasn’t my own invention — I was following the “I do, we do, you do, assess” instructional model that had been handed to me. I was doing my level best, and I was following all the rules, but it just wasn’t working.

The problem with this model in any discipline, but especially in a coding classroom, is that it asks students to memorize nuanced differences between different situations without ever putting them in a situation where knowing those nuanced differences is helpful.

DO: The Prediction-First Method

So my proposal is simple. Just take those steps up there and reverse the model.

  1. Present a puzzle for students to solve. The puzzle is complicated, and involves all of the composing pieces you intend to teach for the day.
  2. Ask students to create something based on that puzzle.
  3. Show your own example of what the thing we’re doing looks like, ideally in its most perfect form.
  4. Take the mental model students have built, and paste the academic vocabulary and definitions on last.

In other words, find a way for students to sense deep within themselves what a line of code does before ever asking them to learn the name for the individual parts of that line of code.

Code for Predictions

When I say puzzle, I don’t mean skipping right to “Let’s build bubble sort from scratch!” on the day 1.

In fact, you should NEVER have students guess new elements of a language’s syntax, and you should also refrain from teaching new syntax and new algorithms at the same time.

What I do mean is that you should simply present finished programs and then ask students what these programs do. In other words, have students read and understand code before you ask them to write it.

Here’s an example — the second thing I ever show students, right after print("hello world") , is this right here:

name = "Tamara"
print("Hello" + name)

And then I ask one simple question:

Don’t answer out loud — just think. What will happen when you run this program? 
Don’t answer. Just think. What will happen?
Turn and ask your neighbor for their prediction.

Literally every student intuits that this program is going to greet Tamara.

And then after that, we run the program, find out that it prints HelloTamarawithout a space, and we also do our first round of debugging. High fives all around!

You’ll notice that we haven’t yet said the words stringconcatenate, or variable, but now we have enough context that I could dive in and have students handle whichever of those is most critical for the day’s lesson. But we truly don’t have to cover any of those before asking students to write a program that greets their favorite fictional character, historical figure, or classmate. We’re ready to build.

I recognize that in this form, it’s a coding class and not a computer science classroom. But I also think that’s okay. You don’t need to know the difference between value and reference types to build a cool project on your first day. And once you believe that computer science allows you to build cool projects, you’re much more likely to be hungry for the theoretical complexity underlying it.

What I’m driving at here is that cooking is to chemistry as coding is to computer science.

You don’t need to know that Python comes with strings and C doesn’t in order to write your own silly version of The Oregon Trail, any more that you’d need to understand the chemical changes that take place when cooking an egg in order to make an omelette.

That’s not to say that underlying complexity (of both programming and omelette-making) isn’t interesting. In fact, if some of your students ultimately want to be thought leaders in the discipline, the formal definitions and best practices are critically important. But if your goal is to pass your enthusiasm about computer science on to your students, these details are not the right entry point to the discipline.

And if you’ll allow me to push this food metaphor to its breaking point, no one has ever applied to the culinary institute because they wanted to be a chemist — it’s because consuming great food is fun, and they want to create great food. Our students will love these granular, academic details in the same way we do later, after they’ve seen how powerful their code can be. So let’s stop with the hour-long lectures about ingredients, and start giving our students playtime in the kitchen.

Bad Examples Made Good

Let’s take a quick look at some old coding standbys that we should really retire. We’ll convert each one into a great prediction challenge by making a few small tweaks.

Example 1: Conditionals

Here’s the most common example I see when an academic teaches conditionals in any language.

if 1 > 2:
    print("1 is greater than 2")
else:
    print("1 is not greater than 2")

Yikes.

1 is not greater than 2. I know that’s the point, but this is an example that requires students to see code in its least authentic form. This example asks students approach conditionals from the never-useful case where you compare two literals.

Also, bonus bad-example points when a text or tutorial relies on the inherently meaningless print("foo") and print("bar") as outcomes — they tell you nothing about the program.

How about this as an alternative?

age = 15
if age >= 18:
    print("You're old enough to buy a ticket for an R-rated film.")
else:
    print(f"You'll be old enough in {18 - age} years")

As it’s written right now, what’s going to print out in the terminal?
3 isn’t anywhere on screen. How did you know it would say “3 years”?
How could we change the program to make the other statement display instead?
What does indentation appear to do to our program?

Even with the out-of-nowhere addition of string formatting, students can immediately figure out what’s happening here. Use guided questions to probe about syntax after students have already intuited how the indentations work. And of course, you can change the indentation question to be about curly braces or do and end depending on what language you’re teaching — it always works.

After going over these questions, you can brainstorm a dozen other age breakpoints (driver’s permit, license, car rental, double digits, triple digits, oldest person alive, etc.) for the create task. Ask if they need any additional help before getting started, give them whatever they ask for (even if they don’t know the exact names like elif or and), and then watch them go!

Example 2: Collections

The bad example used for collections has to be my absolute favorite:

a = [3, 2, 7, 5, 3, 9]
print(a[2]) 
# returns 7

Stop using numerical indexing to organize numerical information — as written, this example is at best inscrutable (“Why would 2 return 7?”), and at worst implies incorrect understanding (“Oh, does it just return the next number?”), but it doesn’t have to be this way.

Here’s my revision:

favorite_foods = ["Sushi", "Tamales", "Mofongo", "Pizza", "Chicken Tikka"]

print(favorite_foods[2])

Which food will print out?
[After testing]: How could I print out the first food?
How could I print out the last food?
Why would favorite_foods[10] cause a problem?

That first question in particular is loaded with assumptions, and that’s on purpose. I’m directing my students’ focus to the number 2, and using that as the key to understanding the purpose of structuring the list in the way I have.

After this single example, students understand listsindexes and even index out of range errors. For the create task, they can start by declaring their own list, and if they’ve also already got for loops under their belts, they can use this as the starting point for a CLI to-do-list generator.

Example 3: Objects

Objects is another one where it’s tempting to start as small as possible in order to tackle this pretty giant topic. Here’s what I usually see:

Class Dog:
    def __init__(self):
        pass
    
    def speak(self):
        print("woof!)

Fido = Dog()
Fido.speak()

I love the intention behind this. It’s so much better than “foo” and “bar” that I almost want to give it a pass.

But I have some complaints:

  • Dogs don’t exist in cyberspace.
  • You’ve used nine lines to create and call a function. I can write code that does the exact same thing in three lines without objects.
  • At this point, 100% of dogs created are the same, so why make a class?

We can do better. How about this:

user1 = User("Ty", "Tdog@aol.com", 16, "Pa$$word")
user2 = User("Sarai", "SMendes@hotmail.com", 15, "Kangaroo!")
user3 = User("Osu", "Osu22@gmail.com", 12, "12345abcde")
print(user2.age)

What’s the first user’s email?
Which user has the weakest password? (I don’t care about a right answer, but forming an opinion about it requires understanding how these objects will be used)
What will the last line print out?

Depending on their comfort level with risk-taking, I can even sometimes get students to correctly answer this one:

“Can anyone guess how I can get the string Osu to be printed?”

And to be honest, I praise the risk-taking necessary to make that guess more than I do the thought behind it — you get from students who are willing to try things.

After students have bought in to the purpose of OOP (“So each user has their own name, email, age, and password, and you can instantly create lots of different users?”) then you can sell them on the importance of knowing the syntax used to create the class (“Yup! Want to see how to set that up?”).

An important thing to notice here is that this code isn’t simple — it’s actually pretty complex. But it is clear, and I’m starting to realize that clarity matters more than simplicity.

Let’s Zoom Out

Here’s my thesis: If you write good code examples, students will infer the purpose and master the content.

So here are the criteria I use to determine whether a code example counts as “good”:

  • Can students who don’t know this syntax yet still figure out what this code does?
  • Is the code reasonably similar to what one might see “in the wild” later on?
  • Are my literals meaningful (no foos and bars) and are my variables well named (no str1 and myarray)?
  • Do my questions allow students to focus in on the most important part of what’s happening here?
  • Do my examples rely on prior experience marketed to just one subset of my students (e.g. video games) or am I digging for examples that nearly everyone can relate to (e.g favorite foods)?

When I’m confident that the puzzles which open my lesson stand up to the scrutiny of these five questions, I know I’m making inroads instead of gatekeeping.

The Takeaway

Write readable code, and then let your students form their own understanding. Definitions are important in computer science, but the love of definitions never made anyone a computer scientist.

Written by Jeff Olsen and published by Upperline Code

Students Don’t Need Simple Examples

Teach pre teens syntax coding clearly

They need clear ones

In my post about coding for predictions, I wrote a sentence that was edited out of the final draft, but that’s played on repeat in my head ever since.

Students don’t need simple examples. They need clear ones.

I’m realizing that this catchy little antithesis is essentially my whole teaching philosophy rolled up into one line.

Pseudocontext

Before we get too much further, I need to introduce some vocabulary to you that I’ve come to rely on. I borrowed the word “pseudocontext” from master teacher and founder of Desmos, Dan Meyer, who in turn borrowed it from education researcher Jo Boaler.

You should absolutely go and read their more-thoughtfully crafted definitions of the word, but if you’re in a rush, I’ll share my favorite example.

Dan Meyer explains pseudocontext with the following word problem. It is from a section of the textbook called “real-world connections” but I’ll let you decide how “real-world” it really is:

In January of the year 2000, I was one more than eleven times as old as my son William. In January of 2009, I was seven more than three times as old as him. How old was my son in January of 2000?

I’ve compiled a non-comprehensive list of complaints I have for this real-world problem’s narrator:

  • Why do we care how old your son was in January 2000?
  • Why don’t you know how old your son was?
  • Wouldn’t birth years be an easier way of computing ages at a given time?
  • Who honestly keeps track of ages in terms of multiples of other ages, but doesn’t keep track of actual ages??
  • As a math teacher, I know you want me to use this system of equations: 
    A = 1 + 11(S) and (A+9) = 7 + 3(S+9), but even knowing what you want me to do, I’m not going to do it, because your method is actually a lot harder than plugging in and guessing.

I could go on, but you get my drift.

From this example, we can derive a working definition of Pseudocontext that we can use to examine CS tasks.

  • Pseudocontext: A learning task or situation where the question being asked is not the most natural and interesting question, and the tools available are not the most natural and useful tools.

So here’s the thesis of this article: Any time your code snippets for students use non-meaningful placeholders like “foo” or “bar”, you’ve created pseudocontext.

Real Context

Looking at the definition of pseudocontext, we can reverse engineer its antonym.Looking at the definition of pseudocontext, we can reverse engineer its antonym.

  • Real Context: A learning task where the question being asked is the most natural and interesting question, and the tools available are the most natural tools.

You may notice that by this definition, real context doesn’t actually require using intricate technical best practices — it just requires thinking about whether or not the user is being asked to do something that they might, even without your direction, still choose to do out of curiosity.

So now that we’ve got our working definition in place, let’s examine some code snippets.

In theory, a code snippet is an example of the concept “in action,” and so a lot of learn-to-code guides seem to be written with the assumption that seeing any code snippet at all counts as real-world context. But if those code snippets include strings like "foo" and "bar" or variable names like my_str or my_list, then that’s a good sign that the code lacks any real context.

All of the following example code snippets are taken from well-respected online guides and resources intended for beginners. I’ve withheld the names of the specific sources and authors because this blog isn’t meant to roast them— indeed some of those guides are overall very useful. But I have some ideas for how to improve each example before using it with a class of students.

Example 1: Strings

If I ever write “foo” or “bar” in my code, I know I’ve messed up.

Here’s what I mean:

str1 = "foo"
str2 = "bar"

str3 = str1 + str2
print(str3)

The structure of this example is actually really wonderful. You’re showing concatenation in action. But because we’ve stripped this code of all its context, there’s no reason a first-time learner would intuit what’s happening here.

Here’s the revision:

first_name = "Ada"
last_name = "Lovelace"

full_name = first_name + last_name
print(full_name)

You’ve shown the exact same mechanical operation as before, only now you’re allowing your students to apply their intuition about the external world to their programming.

This isn’t making things easier — it’s making them clearer.

Example 2: Functions

If I find myself using the name my_function I’ve definitely missed the mark.

Here’s an example from a really well-respected online Python guide:

def my_function():
print("Hello from a function")

my_function()

This is a function in its most atomic form, and so in theory it makes sense as the starting point. But starting here means that a first time learner can’t figure out why this would ever be useful. From their perspective, we’ve just written three lines of code to print a string — something we could already do in a single line.

I’m not just being critical from my high horse; I made this exact mistake the first few times I taught functions. When I used say_hello() as my introductory example, my beginners started to suspect that functions don’t add any utility. One of them even put it to me really directly: “This seems like print statements with extra steps…”

Layering in functionality after that took about 10 more examples, and about 45 minutes, and that’s just simply too long to make using functions feel helpful. Even though students self-reported that they “mostly understood” the lesson in their exit tickets, their performance the following day revealed that most of them were still confused.

Here’s a revision that adds some context:

def get_permissions(name, age):
  permissions = ["G", "PG"]
  if age > 12:
    permissions.append("PG-13")
  if age > 17:
    permissions.append("R")
  print(f'Permissions granted for {name}')
  return permissions

user1_permissions = get_permissions("Yessenia", 17)
user2_permissions = get_permissions("Grace", 14)

print(user2_permissions)

This setup is complicated, but in my experience, not prohibitively so. If students have some working knowledge of lists, they’re ready to tackle this example with the support of some scaffolded questions:

How many times am I defining get_permissions? How did you know?
How many times am I calling (using/running) get_permissions?

In this example, how old is Yessenia? Which movies should she be allowed to see?
What’s the name of the variable where I’m storing Yessenia’s permissions?

When I run get_permissions for Grace, which movies should be in her list?

When I run this code, why will I see Grace’s list, but not Yessenia’s?

After we run this example, I find it helpful to play with it a bit more: “Okay, Javi, let’s do yours. You’re 18, correct? We’ll make you user 3.”

After that, students may not have recognized the full extent of how powerful functions can be, but they will have a really firm grasp of how get_permissions works. With that working understanding established, they’ll be ready to pin down important vocabulary like functionscallsargumentsparameters, and return in a far more meaningful way.

We can conclude this intro with a conversation about how we could do this without using a function, and why this approach is far more efficient. In total, it takes about half the time to teach functions starting with this more complex example, and I have significantly fewer students who finish the day confused.

Example 3: Object Orientation

I think in general, OO is an interesting topic to examine, because we’ve already improved so much as a community. I haven’t seen this specific example in a while, but it still sticks out to me pretty vividly.

class Foo: def __init__(self, bar):
self.bar = bar
foo = Foo("Bar")print(foo.bar)

The wildest part: this example is simultaneously too broad and too specific. It’s using the same two placeholders foo and bar as five different things: a class, a variable, a string, a parameter, and an instance variable, and the very specific mapping of a string to an identically-named instance variable means that a student has no opportunity to draw any connections themselves.

They might very reasonably assume that print(foo.elephant) would produce the string “Elephant” because there’s no reason, rhyme, or rationale for why this code snippet operates the way it does.

Instead, what about this?

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

user1 = User("Jeff", "Jj123@gmail.com")
user2 = User("Beyonce", "TheBoss@beyonce.com")

print(user2.email)

We’ve named our instance variables something intuitive, and we’ve passed in some strings that a student can parse really easily.

Furthermore, by using two instances instead of one, and using variable names user1 and user2, we’ve already hinted at the idea that the User class serves as a blueprint/archetype used to create instances, even without explicitly offering those terms.

Bonus Topic: When to Use Bad Names

(updated 1/30)

I got some excellent feedback on this post from Jesse Farmer and others about something I do, but didn’t mention: after a few good examples, show something absurd so that students start to recognize the value of naming variables well.

I usually hit this topic really hard on day 1, and then touch on it more briefly later, so I’ll reuse the string example from above, and change the variables

x = "Ada"
y = "Lovelace"
z = x + y
print(z)

Usually I ask “will this still work?”

Students make predictions, we run the code, and we draw some conclusions. Even still, since this draws a tiny bit on math prior knowledge, sometimes students may have a limited understanding of what variables can be called. I usually follow up with this example:

pineapple = "Ada"
mango = "Lovelace"
fruit_salad = pineapple + mango
print(fruit_salad)

We finish up with our last round of questions.

“Will this still work?”

“Well then out of all these options, first_name , x , and pineapple, if they all work, which one should we use? Why?”

Students almost always answer in a way that proves they have, in one 90-second example, grasped both the full extent of the freedom they have with variables, as well as the rationale for naming them well.

Later on, we talk about language-specific nuances & no-nos like capital letters and 1st_favorite_food when these issues pop up in student work. Generally, though, students are more likely to over-match the teacher’s conventions rather than under-match them, so these issues tend to be the exception, not the rule.

The Takeaway

When you’re working with beginners, “Foo” and “Bar” should be red flags that your examples need reworking. Their less sinister but more pervasive counterparts sci, and arr should also be signals that your code lacks context.

That said, I don’t mean to imply that Beyonce’s fake email or my function to get movie permissions belong on w3schools or in any official Python documentation — these examples are specific to me and to my students, and those more formal resources have to be useful for audiences of all ages, the world over.

do think that if you lift your code snippets directly from documentation or tutorials without modifying them to leverage your students’ existing working knowledge of the world around them, you may be missing opportunities to make students feel powerful and intellectually satisfied.

Students don’t need simple examples, they just needs clear ones. They need examples that let them use their intuition instead of asking them to check it at the door.

Written by Jeff Olsen and published by Upperline Code

Get Excited about Explaining Outcomes, not Syntax Guessing

Students learning code together

How to increase thinking in the computer science classroom

Photo by NESA by Makers on Unsplash

I’ve always believed that students should be made to figure things out for themselves. Knowledge is deeper and longer-lasting when it is created rather than received. This, by the way, is classic constructivist pedagogy. But there are actually some types of knowledge that our students can’t — and shouldn’t — construct themselves. It’s important to know the difference: when do we make students think, and when do we just tell them the answer? I can finally articulate the distinction in a way that feels right.

It began when I attended a workshop to learn how to teach in Snap!. At one point, the instructor asked us to guess the name of a particular section on our screen. After some silence, he asked, “Well, what’s the place where we keep animals on a farm?” The question bothered me, but I didn’t know why. I was frustrated with myself for not knowing the answer, but I was also vaguely annoyed at the question itself. (The answer, by the way, is the “corral.”) If it’s good to ask your students lots of questions, then why did this question bother me so much?

from snap.berkeley.edu

In search of an answer, I went back to my science teaching background. In Modeling instruction, students manipulate materials to figure out for themselves how things work. After they have developed their mental models, the teacher gives them the conventional words and symbols for the concepts they have constructed. For example, a student might infer, after a series of observations, that there is a type of energy associated with motion. The teacher would then explain that physicists call it “kinetic energy.” We use the word “kinetic” by convention. We could call it anything, and it wouldn’t make a difference — as long as we all agree to use the same word, so we know we’re all talking about the same thing. What really matters is the conceptMeaningful student engagement comes from discovering and articulating the concept, not from guessing the word we conventionally use to denote said concept. My physics students know the distinction between scientific law and scientific convention. They work to discover the former, and I give them the latter. The convention then facilitates their communication with others, which enables us to build jointly upon our shared knowledge.

So how does this translate to computer science? When teaching coding, I never make students guess syntax. Instead, I ask students to describe their algorithm (what they want their program to do, step-by-step), and then I guide them to the resources that will give them the coding syntax they need. For example, a student learning Python for the first time might say, “I want to write a program that greets the user.” She then translates this into an algorithm: “My program will ask the user her name, and then it will output the phrase, ‘Hello, [user name]!’” At this point, the student has done the cognitive pre-work and it is time to write the code.

There are still two ways I might go from here. I could either (a) suggest that the student write “print(‘Hello, ’ + name)” and then run the program, or (b) have the student do a google search for how to output text to the terminal in Python. So when do I use (a) versus (b)? It depends on the case at hand. Approach (a) will free students’ minds to focus on the logic of the code. Approach (b) will help students become self-reliant coders who can find and use documentation appropriately.

  • Case study for (a), giving students the syntax: We just started learning Python in class. A student has defined the variable name and now wants to debug a line of code that says “print(‘Hello, ’ name)”. His understanding of string manipulation is nascent and thus tenuous. It might be distracting to do a google search, and he might not even know what terms to google. So I tell him that in Python he can “concatenate” strings using the “+” sign. With this new information, he’s off and running. He can now use this coding convention to build further (for example, by figuring out how to get that exclamation mark to appear at the end of the sentence).
  • Case study for (b), having students look it up: Now a few days have elapsed in our class, and another student wants to make multiple “print” statements all output on the same line in the terminal. This is outside the scope of the day’s learning target, but the student has already met the day’s objective and is excited about this extension. Because she already has command of the concepts at play, I challenge her to find online the documentation she needs — and then of course to share what she learned with the rest of the class!

To reiterate: in neither case do I elicit syntax conventions from students (eg, “What symbol does Python use to put strings together?”) Doing so will only alienate inexperienced coders while reinforcing the rote knowledge of those who happen to know it already. And then neither group of students is doing any real thinking. Syntax guessing distracts from real thinking — because it doesn’t matter whether the Python convention is to use a plus sign, ampersand, hyphen, or any other character to concatenate. What matters is knowing what concatenation is, and when to use it.

Good teaching does not mean turning everything into a question. It doesn’t really matter what something is called; what matters is how we use it to achieve a goal. By giving our students the basic conventions (like “this part of the screen is called the ‘corral’”), their minds are freed up for meaningful problem-solving. Don’t make your students guess syntax. Make them think instead.

This article is written by Elissa Levy and Posted on Medium/Upperline Code

White-label Case Study: Social Impact through a Coding Platform for Teens

CodeJIKA White-label Case Study

How focusing on where CodeJIKA.org had in-house excellence and partnering for the platform development, the organization was able to keep expanding and simultaneously build an impressive and versatile on-brand learning platform.

How we got here

CodeJIKA’s mission is to empower teens in Africa with digital entrepreneurship and coding skills. After building a club model and designing an offline web-development curriculum that can be used anywhere, completely for free, the  organization turned to the next big challeng – Finding a way to teach the millions of learners who would have access to mobile phones but no other devices.
 
Building in-house

After creating and running successful prototypes that attracted users and confirmed the need for the model, the team set about to build a sustainable platform. After a number of challenges and set backs it became apparent that:

A. Building software was not an expertise that the organization had in-house.

B. Was seriously distracting from the many other very impactful activities the team was good at, such as, awareness, policy, events, teacher training and community-building.

Partnership & progress

To solve this problem a partnership was established with CodeTribe to help customize and build the platform for the needs of African youth. As a founding partner, the entire platform was built around this mandate.

In 2022, this enabled the CodeJIKA team to re-double their efforts on core program expansion and built new teams, impact and communities in 8 countries throughout Africa. Impacting hundreds of schools and training tens of thousands of learners both on- and offline.

Next steps

The next technical goal in the partnership is to add multi-lingual capabilities to both the GUI (interface) and the lesson content. This will able expanded access to both Arabic and French speaking countries on the continent.

Off-platform, the organization is pushing to build a new form of CS Teacher eco-system to accelerate the nascent skills in teachers and to support this with fun and localized teacher training programs. 

—-

Interested in learning more, visit CodeJIKA.org or discover more with the CodeTribe team at: CodeTribe.com/whitelabel 

What’s the Purpose of Life?

Student Group Socializing In Communal Area Of Busy College

You’ll be shocked to know King Solomon’s conclusion, in 990 BC, after searching for the purpose of life in every pleasure, every extreme, every wealth, every work and even in wisdom:

“So I decided there is nothing better than to enjoy food and drink and to find satisfaction in work. Then I realized that these pleasures are from the hand of God.”

( Ecl. 2:24 https://www.bible.com/bible/116/ECC.2.NLT )

Purpose of Life: "So I decided there is nothing better than to enjoy food and drink and to find satisfaction in work. Then I realized that these pleasures are from the hand of God."

Another wonderful way to enjoy life and purpose is through understanding who you are.

So who am I?

You are love. (Whaat!?! ) Yep. It makes sense if you realize that God loves you, He created you and you are made for love. ( That only makes half sense, right? )

“Helllooooo!?! How is this the purpose of life?”

Well, when you know you are loved, you respect yourself, you allow yourself to love yourself.

You see value in your own ideas. You love others with the same love you have been shown.

What if no one loves me?

Yo, that’s hard,… rough.

There’s a saying I read when young, it said: “The way to be happy is to make someone happy.”

Our mind tells us that in order to be happy we have to “GET” love, money or whatever it is we think we need. But the truth is, it’s only in “GIVING” that we make ourselves free.

But that was just a tangent, here’s the summary.

Summary: The purpose of life according to Solomon,…

To love God, to work, to take pleasure in your labor & enjoy to the world around you.

To love God is to love yourself and the world, because you are made in His image. 🙂

See more: Bible.com

This article is written by Jonathan Novotny, a Social Entrepreneur and Founder of Code for Change South Africa, CodeJIKA.com & CodeTribe.com.

Top 10 tips for your first year teaching computer science

First Year Teaching Computer Science

So you’re about to enter the magical world of teaching computer science, combining the creativity of lesson planning with the satisfying problem-solving of coding. From curriculum to classroom culture, there’s a lot to think about as you dive into teaching a subject for the first time.

1. Don’t start from scratch.

If you have more than two new preps, activities in the pre-made classes can also be a fallback when life gets crazy (as it inevitably will for first-year teachers).

Some great free resources to start looking at include the Scratch Curriculum Guide (K-8), Code.org (K–12), and CodeHS (6–12).

For AP classes, using a standard curriculum can also help ensure that you cover all the material at the appropriate speed. Although options for AP Computer Science A are more limited and expensive, there are many free options for AP Computer Science Principles, such as the Beauty & Joy of Computing and Mobile CSP for less experienced students and Harvard’s CS50 for more experienced students.

Over time, you might design entire classes from scratch. But when you’re just starting out, it’s more efficient to stand on the shoulders of giants and build on what’s been done before. And you can still personalize the curriculum and make it your own!

2. Stay at least a step ahead of your students.

You may also have to learn new languages or computer programs. Even if you have a degree in Computer Science, it may not have covered Scratch, App Inventor, or p5.js! It’s best to familiarize yourself with new technology as much as possible so that you are better able to answer student questions.

3. Create a classroom culture of inquiry and mistake-making.

Encourage students to follow a personal empowerment protocol to figure things out when they have a question. Similar to “ask three, then me,” this protocol encourages students to…

  • Ask a peer
  • Google it
  • Ask the teacher

This protocol both helps students become independent problem-solvers, and also helps ensure the teacher isn’t bombarded with questions.

Finally, normalize errors and mistake-making. Assure students that errors are part of a programmer’s daily life, and model dealing with errors yourself during code-alongs. Consider starting an “Error Tally” in your classroom where you tally all the errors that occur and celebrate them as a representation of all the things the class has learned today.

4. Establish clear expectations for computer use.

Depending on the age group of the students, consider establishing routines for computer use as well. Will students be allowed to open their computers before class students, or will they need to wait for permission from you?

Students also generally will have difficulty listening to you if their computers are open, absorbing their attention. Have them put their computers at 45 degrees (halfway closed) or even fully closed whenever you need their attention. Model what this behavior looks like: should they be slouched in their chair to still see their tilted screen, fingers still moving on the keyboard? (No.) Tell them they can close their computers fully if they anticipate that the computer will still be a distraction at 45 degrees.

These are all expectations and routines that you can establish and practice in the first week of school!

5. Establish clear expectations for academic honesty.

Harvard’s CS50 course has a great set of academic honesty guidelines that can be adapted to a high school setting. Consider putting some version of these guidelines in your syllabus:

Academic Honesty Guidelines

  • You may discuss the problems with peers.
  • When asking for help, you may show a peer your code, use and cite online resources, and ask the teacher for help.
  • When giving help, you may not show a peer your code. You may critique a peer’s code and ask guiding questions to help a peer see the solution.

Discuss the guidelines on day one, and even give the students a few hypothetical situations that they can judge as violations of academic honesty or not!

6. Use pair programming.

Computers can isolate students, but they don’t have to if you use pair programming and have students complete certain labs and problems in pairs!

By working together, students help solidify each other’s programming knowledge and keep each other on task. They enjoy the class more and become less intimidated by computer science.

Pair programming is a great intermediate step between learning a new concept and solving a problem individually. Make it a routine in your class, and then give students a chance to demonstrate mastery on their own.

If you’re interested in some pair programming techniques, check out our last blog post on promoting collaboration in a computer science classroom.

7. Have a lot of back-up activities.

Extra challenges in the daily assignments can help differentiate your class and give students an opportunity to build their coding skills. Resources for extra practice, like CodingBat for Java and Python, are another great option for early finishers.

It also helps to have ongoing projects or problem sets that students can work on whenever they finish their daily assignments.

Beyond the curriculum, you can invite students to pursue any track on Codecademy or SoloLearn that interests them, and even reward them with a prize (e.g. programming-related stickers or keychains) if they finish a whole track.

You can also allow them to free create in whatever programming language you are currently using. While some students thrive on this option, others need more structure, so an array of options is helpful.

8. Connect with other computer science teachers.

It’s great to meet people in person, so attend professional development events in your local area. Make a Twitter account if you don’t have one, and stay in touch with educators you meet on there (Twitter is pretty popular among teachers).

Once you’re on Twitter, search out other K-12 CS teachers. Participate in Twitter chats like #ethicalCS and #csk8 to meet other teachers and share knowledge.

If you’re on Facebook, join the Computer Science Educators group and, if you teach APs, the AP Computer Science A Teachers and AP Computer Science Principles Teachers groups.

Here’s the crucial part: ask for advice! Research shows that asking for advice makes you look more competent, so there’s nothing to be afraid of. The computer science teacher community is generous, and you will likely receive an outpouring of responses.

9. Have a growth mindset.

Sometimes your intricately-planned lessons will flop. Whenever this happens, note it and write down the changes you’ll make next time you teach it. If you have time, you can even revamp your lesson plan and materials right then and there! See, already you’re becoming a better teacher.

10. Have a non-computing hobby.

Establish some ground rules to maintain some kind of work/life balance. A few good starter ones are not working after 8pm on school nights and picking one weekend day when you won’t do any school work (or when you’ll just work in the morning).

To help yourself stay away from work, have activities and people in your life totally unrelated to teaching or computers. Sign up for a workout class, learn Spanish, get really into cooking, go to a beach volleyball meetup… anything you enjoy that will help you recharge after teaching!

Conclusion

 

This article is written by Kelly Lougheed, who is a Software developer & educator and can be followed on Medium or here: https://blog.upperlinecode.com/@kellylougheed

Coding is Creating the Entrepreneurs and Artists of the Future

Coding Platform Partners & Resellers

Coding teaches you how to think, but that’s not all.

If practiced within a real-world environment and with targeted outcomes, the learner can go beyond concepts and into creative and technical understanding.

CodeTribe’s value proposition lies squarely in providing real-world skills that provide a coding foundation for any entrepreneur or employee. These can be used in building, modifying or simply working with online tools or services.

How?

Digital business skills often start with communications (Email), research and marketing ( WordPress content, online ads and rating services) but quickly move towards custom forms intuitive content and analyzing data.

With CodeTribe’s Core Course offering, “Tribers” quickly understand the basics of both programming languages and frontend web development. This provides a basis from which to expand into further self-learning and discovery. Through this process they become adept in any digital business environment.

The goal of CodeTribe is not progression into university, but assimilation into real-world practice and values.