Adventures in Homeschool: Our Math Additions (and Divisions)

When I was a kid, I was a star memorizer. At an early age I could memorize sections of prose, poetry, and all kinds of facts. When I started working in mathematics, we did more memorizing. I was good at that part, memorizing math facts. Trouble was, I didn’t really understand them as deeply as I needed.

Now that I found myself in charge of my son’s math education, I started to branch out from the lesson plans and exercises I had purchased and tried out. Since we were working together, and he was curious, I decided to experiment a bit. First of all, I wanted to help him with a different approach to math than I had experienced. I had struggled a lot with math, up until university. Next, I wanted to be sure our approach to math was appropriate for his learning. Instead of being guided by my own experiences, I would let them inform us, but try to get my direction from kiddo and his interests.

Looking at my own struggles with mathematics required a bit of self reflection. Over the years I had thought a lot about why I had struggled, and for me, it was often because critical information was withheld. Someone, somewhere, had decided that parts of the topics I was learning weren’t age appropriate, so I would learn a certain set of facts at a certain grade level. Later on, more information would be added, and the facts and approaches I had learned were challenged or upended completely. Those transitions were hard for me. I also had trouble because I needed to understand the topic more deeply. When I would ask questions about math topics, particularly with regards to their application in real life, I didn’t get satisfying answers.

Most of the time, the explanations from the teachers didn’t leave me feeling like I fully understood the topic. In fact, I wasn’t able to delve deeply enough in math concepts to truly own them until I took math classes in university. I memorized and applied, but I didn’t fully understand. It wasn’t until I had a math tutor in Grade 12 that I found someone who could fill in those blanks for me. When I went to university, that changed. Whenever I asked math professors “why” questions, they usually appreciated it and explained further, or pointed me to publications with alternative explanations, or trips to the library. I was also inspired by how some of my math and computer science professors taught math to their own kids. They focused on simple, intuitive application that was relevant to kiddos, and they didn’t gatekeep and withhold information. Once things began to click for my math brain in university, I vowed that my kids would get help on the “why” questions. If it was from me, then so be it.

To brainstorm, I talked to programmer friends and asked about their math learning experiences. Many of them just understood math naturally, and didn’t struggle with any of it. Many had mixed experiences, and some had experiences that sounded like mine. They didn’t like how rules changed and wished they had been given a fuller picture earlier. Furthermore, when any of us were curious about topics beyond our grade level or outside of the curriculum, that was usually discouraged. “You’ll learn that later.”

All of us found that programming helped out math skills since it was a real world application. The math facts come alive, and you understand a lot of the “whys”. For example, an abstract concept like a variable in algebra (a letter symbol in an equation) is part of what you always do when you program: you create variables and do things with them. High volume automation of math provides visualization and patterns that you can’t replicate with paper and pencil, and that provides more insight. Even better, small errors can have huge implications in a program, so your attention to detail changes.

My question for my programmer friends was: “What did you miss out on in your early math education that you think I should provide kiddo exposure to?” Their answers provided this list:

  • Zero-based counting
  • Negative numbers
  • Working with fractions earlier
  • Multiplication basics alongside arithmetic
  • Understanding decimals
  • Using variables
  • Thinking about functions
  • Sequencing and loops
  • Abstract data types: lists, arrays
  • Data operations: stacks (LIFO and FIFO, evaluation, etc.)

Some of these are quite simple and actionable. For example, starting to count with 0 instead of 1 is trivial, and should always be done, in my not so humble opinion. When you start looking at place values, or even counting beyond 10, it is extremely helpful to have started at 0. Negative numbers aren’t that easy to grasp, but you can work with them, especially with number lines. Fractions, multiplication, decimals and variables can be worked into early math exercises, but it takes a bit of thought.

About half the list relate to computer programming, so I wasn’t sure how to handle those. Kiddo wants to learn how to code, but I would really need to gauge his interest and follow his energy there. However, they can easily be broken down into concepts he can understand at 5-6 years old.

That led me to thinking I needed to help him understand math concepts at a simple, intuitive level first. If he could relate a math concept to everyday life, and to things that mean something to him, we could build on that. From there, he would need to learn and apply the concepts, and through repeated exposure, he would memorize rules and facts by doing something with them.

I went in two directions with this: utilizing informal math concepts on every day life at home, and a formal math learning structure.

First of all, I found Betty Choi’s blog, and she provided a lot of ideas on how to incorporate math into everyday activities with our kiddos. I got a lot of direction from her post: How to Teach Basic Math for Free Anytime and Everywhere and printed out the PDF and taped it to our fridge. (If you’re teaching math to young kids, download this PDF on teaching math.)

She has wonderful ideas about counting actions (claps, steps, etc.), adding and subtracting toys, multiplying with groups of objects, dividing up food (this is great for fractions too) and applying fractions from recipes. These were great, and we were able to do a lot with them to help make these concepts intuitive. For example, a kiddo who understands how to divide up chocolate chips equally will have an easier time learning division formally later on.

Food division is a lot of fun because you can really focus on the basics of division, with a payoff of a tasty treat. To start, I gathered 10 chocolate chips and asked kiddo to divide them equally so we could share. Kiddos often have an innate sense of fairness, so he carefully arranged them in two rows. At first he made a pattern and tried to make a symmetrical pattern with the other group. That was fine, but he was worried that one person might have more than the other. We played with the patterns by re-arranging them into shapes that were easier to subitize. Five is a wonderful number for this because you can create unique patterns. Next, I asked him to count each group, just to be sure. Once he was satisfied we had divided the chocolate chips equally, we ate them. Nice!

After we had worked on dividing up food objects into equal parts, either for two or three of us, I decided to see how he would manage a remainder. Instead of 10 grapes, I gave him 11 grapes, and asked him to divide them into five equal parts. He started in by making pairs, but then he ended up with an extra. I left him to twist in the wind a bit, to see how he would manage it. He tried adding it to one group, but one group had three grapes while the others had two. He kept rearranging, trying, going back to his original pairs, and puzzling over the extra. Finally, he set it to the side and asked me for help. “I can get 5 pairs, but there is an extra that doesn’t fit, so I just put it to the side.” I praised his thinking because he had just discovered remainders. “This is exactly what you do when you divide numbers and end up with some numbers left over. In division, this is called a remainder!”

Kiddo wondered what use a remainder might be. Using food as a guide, I suggested that if he was the one divvying up the chocolate chips, he could secretly eat the remainder. This is one of the perks when you cook food for others. You can surreptitiously snack as you prepare. This appealed to him greatly. It turns out, stolen edible division remainders are an effective math learning tool.

I also discovered a helpful homeschooler blog from the Natural Math community, Duct Tape Rocket. I got some helpful ideas on games to get kiddos thinking and working on simple programming concepts. After reading some of the posts on the blog, kiddo and I started playing around in the Scratch Jr. program.

We also discovered CodeSpark Academy, a fun app where kids learn programming basics in a simple game format. CodeSpark not only helps kiddos learn about sequencing, but all kinds of concepts including loops and working with stacks. Kiddo would get rewarded for his algorithms, but he got more points when he used constructs like loops. When he was disappointed he wasn’t getting full stars for a task, we had a chat and worked through the concept. He was motivated to achieve more in the game, so he started to use loops in his own work and was rewarded for it. We also spent a lot of time together figuring out how to do LIFO and FIFO tasks in the game.

Next, I formalized what we should cover based on this list from Natural Math:

  • Subitizing: The ability to instantly recognize quantities without counting
  • Counting: Addition and subtraction are based on sequences, dealing with objects one-by-one
  • Unitizing: Multiplication and division are based on equal groups or units
  • Exponentiating: Self-similar structures, such as fractals

Patterns are a clear underpinning shared with all of these concepts, so getting kiddo to work more formally with identifying and creating patterns was a natural place for us to work on. Identifying patterns and groups and performing operations on them can be done with just about anything, anywhere, especially if you are out in nature. Subitizing is also a patterns activity. Thankfully, I had a lot of helpful exercises from my kindergarten no-prep lesson plans, so we were able to move forward with pattern and subitizing exercises for a while.

Exponentiating work involved watching videos and looking for repeating patterns in nature, such as in the veins of a leaf, or in the crystal formations of ice. Unitizing was more difficult. I needed to figure out activities that were appropriate for a 5 year old, so I started to research further.

Adventures in Homeschooling: Fun With Arrays

As we transitioned to math activities that were more engaging for my kiddo, I started to notice similarities and patterns. At this point, I was using the book Moebius Noodles as our primary inspiration for math activities. For example, we would have a lot of fun playing around with body symmetry exercises, where one person mirrored the other. We would estimate height by guessing and then building a tower with Duplo blocks. The tower would inevitably collapse, leading to lessons about structure and making a solid base. We played a “program Dad” game where he would direct me around the house by telling me exactly what to do. We found that using a checkerboard tile exercise mat helped a lot. For example, kiddo would tell me to move forward three squares, then turn one square to the right. We played around with grids, working with numbers or drawing items within the shape.

I am a programmer, so playing with grids make me think of arrays. Arrays are used a lot in programming languages as handy data structures. You can use them to store and access objects that you want to interact with in a computer program. When I was learning about arrays in programming, I found simple examples made sense, but when you added more dimensions or started thinking about performance, I struggled. I had trouble with thinking in abstractions. It took a long time to overcome that. The actual concepts, code and mathematics were simple, but my brain struggled to think about something virtual with different dimensions. Similarly, when I started a linear algebra course, I spent too much brain power getting my head wrapped around how arrays were formed, and keeping track of what number was in what row or column. The actual math was often elementary level, but the abstractions were difficult to grok. I felt that adding in thinking about more than one dimension, and thinking about abstractions in math would help my kiddo develop better math skills. If he could get used to thinking about abstractions I wasn’t exposed to until I was in my late teens, what would that do to his problem solving brain?

We would also look for array patterns around the house. We would examine Duplo and Lego bricks, muffin tins, egg cartons, game boards, crayon organizers, drink holders, watercolor paint trays… the list goes on. There are array shapes everywhere, and we would find them and discuss them. What pattern do they make? What could we call this in math or programming? Soon, kiddo was spotting array patterns himself and pointing them out. Next, I wanted to add a bit of structure to his thinking about arrays. To make things more interesting, I would ask him to identify the rows (horizontal) and the columns (vertical). We would play around with that concept. For example with an egg tray, it is natural to set it down so that it has more columns than rows, because that is how it is labeled. But what happens if we turn it so it has more rows than columns? We would identify an egg and its location: 3rd row, 2nd column, and then move the egg tray. Now it is 2nd row, 3rd column. Did the egg change, or did the “address” of the egg change? Turns out the egg is the same, but the way we describe to find that exact egg can change, depending on our perspective.

Games and Arrays

Since kiddo could easily count to 30, he could easily keep track of rows and columns in a 10×10 array. I printed out a 10×10 checkerboard and we started to play with it. I would ask him to help me determine where the rows and columns were. This took some practice, and I told him that when I was taking linear algebra in university, and then later when I worked with tables in HTML, I would remember that columns were vertical, like columns holding up a roof. Rows I remembered as horizontal, like rows on the ground in a vegetable garden. Columns hold up, rows are planted on the side. Next, we would count, making sure we kept track of the row number and the column number, which is the “address” or location in the array. Once kiddo could identify rows and columns on his own, and find a location when prompted, we started to add complexity.

I would set the checkerboard down, and ask him to locate row 2, column 3. He would take his finger, and count down to row 2, and then he would move his finger 3 spots over. While my brain was thinking of patterns in applied math, his brain was spotting a familiar pattern: games. We transitioned from counting and pointing to making simple games together. Every morning, we would take out the checkerboard, and we added in dice and game play pieces. Using dice meant I needed to expand the size of our array to 12×12. Next, for playing pieces we found Lego bricks, bingo chips, and other objects worked, but we settled on mini ring fidgets. These worked best because they weren’t associated with anything else that distracted us. From there, we would take turns rolling a single die. We both started at top left, just off of the grid, and after a roll, you would count forward to match the number on the die and move your playing piece to that position. We would move row by row from beginning to end. The first person to get to the end won.

Next, we added a die so we had a pair, and rolled both dice at once. The number on the left most die represented the row, while the next number represented the column. Instead of moving through the game board from the first column and moving through from row to row, you had to keep track of the row/column pair. This added a lot of randomization, and could cause someone who was “winning” to get knocked back. Now we were thinking and playing and having more fun. To add more randomization and surprise, kiddo would add in extra objects. If you landed on a Lego brick, you had to count the rows/columns of the brick and move to that spot on the board. If you landed on a different colored fidget ring, you had to start over. If you landed on a smiley face sticker, you could skip to the end. Now we were having a lot more fun, but it was hard to “win” because of all the randomization. To move beyond this, I added in two variations. The first was to get him to create the activities from scratch, and the second was to add in zero-based counting.

We were playing with the emerging array game every weekday morning. We would set up on the floor, and we would play around and have fun. When it started to get stale, I asked him to run the sessions. At first, I just had him tell me the rules of the game, and explain how everything worked. It was often muddled, the rules would change to favor kiddo and disadvantage dad, and the lessons about arrays were completely lost. However, I was pushing for engagement rather than mastery, so I didn’t care. On days when I ran the game, we did it according to rows and columns and reviewed what we knew about arrays. On days he led the array games, whatever happened was what was supposed to happen that day.

At first I was concerned he wasn’t taking anything away from the lessons, but when we played the game the way I had set up, he seemed to grasp the concepts more firmly. The random play was reinforcing what I was hoping he would learn. Even though he wasn’t playing by “the rules”, he was exploring the boundaries and being creative. Math lessons aside, creativity with designing your own game with dad has tremendous value on its own. It was actually reinforcing the lessons, even though it didn’t seem like it at first. He was truly owning the concept and chasing down ideas he had as things in the lesson reminded him of games we played, video games, following recipes in the kitchen, etc. There were also disagreements and lessons about playing fair, being a good sport, and other important issues. It was hard at first to not correct and bring him back to the topic at hand, but I found his brain was working on it, even if I didn’t see it at first. If I could just shut up and be a 5 year old with him in the moment, good things came out of it. I realized he was doing what I was hoping for anyway, he was applying the math. He was taking the theory and making it real.

The next variation was to make it more difficult, and to keep track of rows and columns using zero-based counting. One of my frustrations when I was programming was having to switch my brain from starting at “1” to starting at “0”. Many programming languages use zero as the first number, and I found it hard to adapt at first. When I taught adults to program later on, many also struggled with this. Instead of using your programming brain, you were expending energy trying to count to 10 starting at 0. With kiddo, I am a stickler for starting counts at zero, not one. It makes everything easier for him to have that solid grasp of zero. It helped him with place values, with counting, and it helps him with simple arithmetic. Understanding zero also helps with abstract concepts as well. Since he was familiar with starting to count with zero, and using place values to increase or decrease, transitioning from 1 to 0 based counting for arrays wasn’t that much of a stretch.

Arrays and Muffin Tins

To make this come alive, I looked for kid friendly array activities to explain this better than I could. Unfortunately, I couldn’t find anything online other than identifying arrays and looking at rows and columns. Good activities, but not what I wanted. I wanted kiddo to start thinking about arrays as an abstraction, but add the realism by keeping track of rows and columns to access something stored at each address. I wondered about a cardboard fold out activity, like a mailbox. I talked to a programmer friend, and she said her daughter had worked on a “muffin tin” math activity. Each indentation in the pan was covered with cardboard, and the kiddos would take the top off to discover items in each section of the tin. This is easy enough to do, why couldn’t I do that with arrays?

A muffin tin with paper addresses for each element in an array. It starts with 0,0 at the top left and ends with 4,3 at the bottom right.
A muffin tin set up like an array with numbers representing rows and columns.

With a bit of thought, I came up with a simple activity. I printed out slips of paper with a pair of numbers to represent the row and column, which would cover the indentations of a muffin tin. Under each address, within the muffin tin indentations, I put in a small toy. I started with Lego pieces and one Lego character. Next, I asked kiddo to find the Lego character. He needed to lift up the paper that had the row/column location, look underneath, then put it back and move on. Finally, he found the Lego character. I asked him what row and column he found the character at. Unfortunately, the location papers were scattered, so we repeated the activity, but with more care this time. To add interest, I changed the location of the character, and asked him to write down the row and column on the paper, once he had found the character again. This time, it worked. He was starting to engage. To increase engagement, I turned my back, and asked him to put the character in a new location, and then I would have to find it. He started to have fun.

Kiddo hid the Lego character at a location, and put the paper locations back on top of each indentation. Trouble was, they were out of order. Instead of pointing this out, I pointed along with my finger by moving by address, rather than physical location. Instead of starting at the top corner where 0,0 should be, I started where 0,0 actually was placed, which was somewhere else on the tin. Next I found 0,1, then 0,2 and so on. Some where in the correct location, but some were not. I feigned surprise and said I was confused. Kiddo patiently explained I should start at the top and work my way down. I suggested that if that was the case, he needed to make sure the addresses of each tin indentation was in order. He quickly shuffled the papers around so that the muffin tin rows/columns matched correctly. I then started and worked my way through until I found the Lego character.

We took turns with this activity several times, and he had lots of fun. He would try to surprise me with the location of the Lego character by putting it in the last position so I had to count all the way to the end, or at the beginning so I found it right away. He would put it back in the same location, or he would try to distract me by saying something funny while I was moving through each item. There was a lot of giggling, and when the papers with the row/column addresses got mixed up, he was quick to help sort them again.

The next day, I asked him to set up the muffin tin activity. His job was to put items in each indentation, and then put the correct address slip of paper over top, in order. We had a couple of oopses with 0,0 and 3,4, but with some clarification he remembered how it worked. This time however, we got Mom to hide the Lego character, and then we took turns trying to find it. To begin, we both started at the top left and worked our way through. The next time though, I surprised him with an algorithm. When it was my turn, I didn’t start at the beginning, I started at the end. Then I switched back to the beginning, then back again and so on. I found the Lego character first, since I was using a consistent approach. Next, I checked at the end, then the middle, and then moved back and forth from middle to end, and once again, I found the Lego character first. Kiddo was disappointed and feeling a bit frustrated that I was winning. He accused me of cheating.

This turned into a wonderful teachable moment where I could explain algorithms.

How do you explain algorithms to a 5 year old? The simplest way to describe it for him was that it was a set of steps to solve a problem. We looked at recipes for food we had prepared together, we looked at Lego instructions, and we looked at simple school assignments. Next, I explained what I was doing, that I was using a strategy called Binary search to find the Lego character faster. Since the array is small, it doesn’t give me much of an advantage, but I had lucked out by winning twice in a row. That had piqued his interest. I then explained that he had intuitively used a good algorithm, linear search, and that had worked well. He had started losing the game when he got excited and stopped concentrating. Instead of using a linear search, he was using a random search which is the least efficient. He might choose the same wrong address several times using a random search. That’s not efficient, or as effective. It is more effective and efficient (ie. find the Lego character faster) by using a consistent strategy.

A consistent strategy to solve a problem is another way to think about an algorithm. When you start to lose discipline due to emotions or getting distracted, your problem solving suffers. It’s harder to keep track, it’s easy to forget, and an opponent with a consistent approach will play better.

To reinforce the algorithm idea, we worked together on using each search algorithm. Since it is a small set of data, both linear and binary search were effective. He wanted to try binary search, so we worked together on finding logical places to divide up the data, and then work within those divisions. For example, he might look at the last address first, then look at the middle address. Next, he would move between those two addresses with each turn. He might then change tactics and try a linear search from the first address to the middle. This is a bit tricky for a young mind, because kiddo has to keep track of rows and columns, as well as the artificial divisions we were making in the grid of the array. To help keep track, we used pencils or longer Lego pieces as placeholders.

After a few days, kiddo was doing really well with the muffin tin array game. He was using a strategy to choose an algorithm, and he was comfortable with zero based counting. One day I sat back and watched him. I felt amazement and joy watching him. Not only was he demonstrating a basic understanding of arrays, but he was thinking about computer programming on his own terms. This applied math, or the “why” is absolutely crucial in learning. It was within his skill level, it was relevant to his interests, and it was fun for him.

We do programming work because kiddo has an interest in it. The TedEd Think Like a Coder series was particularly interesting to him. He had discovered this series on his own, and he looked forward to new episodes when they were released. Each episode prompted a lot of discussions about coding and me trying to replicate what they were doing in the story for him on my own PC. Sometimes I would struggle, and remembering to show him my mistakes, we would talk about how my code wasn’t working, or when I needed to look something up or ask for help from a colleague with better coding skills.

Programming is also an easy place for me to answer applied math questions, and to talk about day in the life applications of math. Sometimes the only way I can start to answer a “why do we do this” question is by working it out in code to show him an example. No, we don’t learn math for no reason at all. Yes, some people work with math every day.

Making it Real With Code

Looking at array addresses of rows and columns as zeroes felt arbitrary to kiddo. While he understood it and got it right most of the time, it really felt like one of those “grown up” things that didn’t make a lot of sense. Isn’t zero just another way to describe “nothing”? To help with this, we worked together on our home address vs. that number represented as a quantity. Next, we looked at my phone number, and then represented it as a quantity. Then we added some numbers together, which made a sum. What was different? Kiddo explained that the number in our home address and in my phone number stood for something unique, so people could find it or phone me. But a quantity was an amount of objects. A sum was calculating the total of groups of objects. We played around with this concept for a while, and stuck to the idea that an address for your house is a sort of unique label. Our neighborhood has free standing mailboxes that are labelled with a unique number that is assigned for each house address, and the contents are accessed by a key. To get the mail from another part of the world to an individual here, depends on various unique number labels.

Next, we looked at array addresses. We aren’t counting items, we are using the location in an array as a unique label. When we use zero-based counting, “0,0” is the first box in a grid. If we use one-based, “1,1” is the label. But what if we used names? How about emojis? Could we use sounds? Absolutely! We could use anything at all, really. However, number labels that follow a logical pattern work well. They are efficient and effective since they are easily understood.

To take this further, we opened up a language interpreter on my PC called irb, for the programming language Ruby. Kiddo had visited a local fish hatchery, so I typed in the following:

fish_array = ["trout", "pike", "perch"]

I explained that this was a simple array of words for fish. We read through them together I asked if he could help add in more. He suggested “walleye”, “goldeye” and “sturgeon”, so I added them to the array. We now had this array of strings, or words for fish:

fish_array = ["trout", "pike", "perch", "walleye","goldeye", "sturgeon"]

Next, I told him that I was going to use a bit of code to access the first fish in the array. I typed in:

puts fish_array[1]

and the interpreter printed this to the screen:

“Aha! Dad! That’s not the first one!”

What do I need to do to fix it?

“You need to type ZERO, NOT ONE!”

I changed the code and tried again.

puts fish_array[0]

the interpreter printed this to the screen:

That worked! You fixed the bug!

Kiddo really enjoyed this. We were controlling the computer, and it was important to keep track of what you were doing, because one simple error could give you the wrong answer. I explained that in computer programming, we often call this an off by one error.

We played around with this for a while, adding in array indexes that didn’t exist, to see what error would be produced. Then, I created a larger array, and used an iterator to print through each item, rather than typing in an address. Kiddo liked the idea of looping, we could do things quickly and efficiently, and you didn’t necessarily have to figure it out yourself, you could get the computer to determine what was correct for you.

We had fun. He wasn’t learning these concepts, but I was exposing him to some simple programming basics and explaining what we were doing. He had opinions and ideas about the content of arrays, and what to print out, and I would follow his lead by adding in conditionals, branching, etc. He then asked an interesting question. Essentially, he wanted to know if we could have an array that was made up of arrays. “Of course!”

I muddled around in the code to generate an array made up of arrays, and showed him how we accessed elements in an array of arrays. This started to look to him like our muffin tin game, since we needed to keep track of more than one index or address number. After a while, we had the code looping through each array within the array and printing things out, but that was getting complex and he was getting tired.

I sat back and I felt a bit shocked. Here we were, playing around with concepts I had struggled to learn when I was nineteen or twenty, and my 5 year old kiddo had grokked the basics. He could follow the form, he could play and have fun, and he understood that things could be stored in arrays, whether they were in muffin tins or mailboxes (physical), or in computer memory (virtual).

Adventures in Homeschooling: Eliminating Fear From Learning

In my first year of university, I had a professor in a business class who was a big fan of W. Edwards Deming. Deming is credited as the founder of the quality movement, particularly in manufacturing. Deming published a list of principals called the 14 Points, a list of approaches to management to help create a quality-focused working culture.

They are incredibly useful, even today. However, Point 8, “Drive out fear” puzzled me and my classmates. This is a workplace, what could people be afraid of? They are professionals, they are doing work they have expertise in, and helping the company succeed. What could possibly make people afraid? I have to admit we snickered a bit every time it came up. “BOO!”

Our patient prof explained that there was an authoritarian management style where bosses and managers rule by fear, and use it as a motivator. He agreed with Deming, and felt this was counterproductive, since fear causes people to avoid talking about problems, and motivates them to game systems. You will have a hard time finding out the truth from people who are afraid. They will try to spin narratives towards something that reflects positively on them, rather than talking about problems customers face, for example. Under a fear based system, eventually, the system will be broken and customers will suffer, and decision makers will likely find out when it is too late. (This is often referred to as a theory x management style.)

However, there is a lot more to fear in the workplace. One of the most common underlying issues I dealt with as a consultant was fear. People have a lot of fears in the workplace, even in consensus-driven, people-focused workplaces. People are afraid of losing their jobs, or of not moving up in an organization. They are afraid of losing money or status, and what that means in their professional and personal lives. They are afraid of making a mistake. They are afraid of certain kinds of changes, and they are afraid of upheaval. They are afraid of certain tasks, and certain aspects of their jobs. They are afraid of certain people, sometimes for subtle reasons. They are afraid of looking stupid, or not knowing an answer. They are afraid of asking certain kinds of questions, and they are afraid of providing blunt, honest feedback. They are afraid of disruption, or of disrupting something themselves.

Imagine what all that fear is doing to their well being and ability to think clearly and carefully about problems, let alone what it is doing to overall team productivity.

In my experience, the less fear, the more effective a team is. In fact, one of the most effective things a team can do to build up workers and be more productive is to reduce sources of fear. Fear steals so much energy and obscures good problem solving communication. You can’t deal with all the fears we have in the workplace, and those change due to environmental conditions and events. However, when you create a culture that drives out fear, really good things happen. People are happier and more productive, and everyone benefits from that. If all I do is help a team reduce their fear, and that is all I am able to do, that team will be more productive when I move on to another project. Drive out fear is a powerful philosophy.

…one of the most effective things a team can do to build up workers and be more productive is to reduce sources of fear. Fear steals so much energy and obscures good problem solving communication.

When kiddo and I started doing homeschooling together, I observed similar patterns in him that I had seen in people in professional settings. There was a lot of fear there at times. He had similar fears. He was afraid of getting the wrong answer or just making a mistake. He was afraid of answering a question in case he got it wrong and felt foolish. He was afraid to ask me questions that might reveal he knew less than he was letting on. He was worried about my reactions, and how we dealt with conflict.

Instead of being an outside observer seeing patterns in a team, I had to face up to the fact that I was the source of a lot of his fear. That hard fact requires a lot of self reflection and working on my own behavior. It’s hard, but it’s a reality.

Observe the Child

The first thing I started to do was watch kiddo carefully. When did he stop engaging, and when did that start? When did his behavior shift from having fun to going silent? What was the source? Did he need a break? Did he need to go to the washroom? Was he just having a bad day? Or was there something in our approach together that was making him uncomfortable? When did things shift? Was it a direct question? Was it something he wanted to hide from me? Did we shift from fun to something decidedly unfun?

It was a lot of work, and I had to try to filter out typical child behaviors from those that were issues we could address. Kids get bored, or distracted, or just might not feel like doing schooly things today. To observe him while working with him was hard. I also watched him when he worked on learning apps. Learning apps tend to be based on teaching approaches, and are heavily influenced by the educational experiences of the app developers. As a result, the same patterns will appear when they are working on apps as they are in person.

I started to note the patterns where he felt pressure:

  • Direct questions about his knowledge on a topic
  • Closed ended questions
  • Worksheets
  • Starting a new topic
  • Trying an exercise on a new topic
  • Reviewing his work

I also noticed patterns in our approach where his behavior would shift from engaged to disengaged.

  • Dad talking too much
  • Spending too much time on an exercise
  • Closed ended worksheet questions
  • Time pressure

A lot of these had underlying fear issues. Many of these were a direct result of my leadership/teaching style. Gulp.

Observe Yourself!

Next I had to take a hard look at myself. Kids are kids, and we can’t expect them to manage their emotions or be as self aware as adults. I couldn’t expect him to change his behavior that much, I had to look at what I could change to support him.

One thing I noticed was my body language, my tone of voice, and how those could be sources of fear or discomfort for him. I’m bigger than him, so I would inadvertently tower over him when he felt on the spot, asking a question. Or, I might raise my voice while repeating a concept that wasn’t clicking for him. I worked on my body positioning and trying not to raise my voice, or spend too long with “teacher voice” explanations.

In my software design work, I found that body language can be subtle and influential. In my design book, I talk about how during user tests of new software designs we can unintentionally encourage test subjects with subtle body movements. We might tilt our head towards the answer we want, or shift our body slightly. We might frown when someone does something when we hope they do something else, and smile when they do what we were hoping they might do. We might tap a pointer or pen towards the answer we want.

This was a lot more difficult, but I started to work on being more bland and flat when I asked questions, and I resisted any movement that might hint at what the answer might be. I knew it was working when he would stop and observe me more carefully before committing to an activity or answer. He was looking for the cues that weren’t apparent anymore. In fact, we even had a conversation or two about it, and he admitted to gaming the system by watching my tells. Thankfully, we were able to turn this into a humorous activity and have some fun with it, which contributed to him feeling safer and more secure in his learning with me.

Make Sure Kids See You Make Mistakes!

I knew we were making progress, but I still felt like kiddo was feeling pressure from my behavior. Fortunately, I have skilled professionals I can talk to. My friend Dr. Katie Crossman is an education expert. Katie has elementary school aged kids as well, and we would share experiences as our respective kiddos were learning at home. When I talked about trying to drive out fear from our learning experiences, she suggested I point out when I make mistakes. Katie talked about her knitting hobby, where you rip out sections you have already knitted, and start over if you have made a mistake. (This is known as “frogging.”) It can look frustrating to an outsider, but it is just part of the process. Katie told me that when she discovers she needs to “rip it”, she calls over her kids to show them and talk it through. There are lots of mistakes we silently make around the home, and if we stop and show our kiddos, it is a good learning experience.

There are a couple reasons this is important. When kids are homeschooling, they are learning things that we as adults learned many years ago, and the knowledge is second nature to us. If we ask them a question, it might be a challenge and they have to think, but to us, we have the answer instantly. Since they aren’t around a group of their peers, it can make them feel like they are always wrong, and we are always right. For example, think of teaching a simple math concept like 1 + 1 to a smaller child. They pause and work through, while we answer instantly. Or, they may ask us out of context of learning, and we just know the answer, without realizing they might be testing us. We’re adding pressure, even though we don’t mean to, or are unaware of it.

The other opportunity we have with showing our mistakes is to model our behavior for them. What do we do when we make a mistake? How do we solve the problem and move on? Do we get frustrated and give up? Do we research and try again? Do we call in an expert if it is a problem we can’t fix? These are extremely important lessons that take a lot of thought and self discipline to master. (Note, surprise home repairs are not always a good learning experience unless you want to model frustrated noises, angry tool selection and swear words.)

My kiddo and I started this together, and he was shocked at first. Dad can make mistakes? Wow! Once we got over the initial surprise, I would tell him stories about mistakes I made at work, or presenting to a crowd, or working on hobbies. I shared one story of when I made a mistake woodworking with a friend. We were making a workbench for my garage, and I was supposed to drill out holes to counter sink bolts. I drilled out the holes to countersink in the wrong spot, and it looked awful. My master cabinet maker friend sent me out of the shop to get coffee. While I was gone, he ran the boards through a planer to sand away my mistake, then had me do it again. I was surprised he could figure out how to fix it, and he laughed and said: “That’s the difference between an amateur and a professional. A professional knows how to fix their mistakes.” That story resonated with him, and this phrase became a bit of a mantra in our home.

I also told of embarrassing mistakes (I once presented to a group with a line of whiteboard marker drawn across my forehead), stupid mistakes (I misspelled an item in an inventory system as a joke, which muddled up the counts), and expensive mistakes. (Early in my career I made a mistake that cost the company thousands of dollars. I was sure I was going to get fired, but my manager said, why would he fire me after spending thousands of dollars training me not to make that mistake again?)

Thanks to Katie’s advice, we started to create our own fearless culture about working with mistakes. Talking about mistakes, regaling stories of mistakes of the past, reading stories about mistakes, pointing out my mistakes and walking through how to solve them, and most importantly not punishing in any way for kiddo’s learning mistakes.

Create a Safe Learning Space

Environments are crucial to feeling secure and productive. Since we were at home, we started out by dedicating a learning space that provided consistency. I worked with kiddo to put up posters he found helpful, and to have our materials nearby. He added his own personal touches and felt like he owned the space. Previously, we had been much more ad hoc, and task switching from play to learning could be tricky. Beyond that though, I wanted to make sure we had a learning relationship where he could feel comfortable asking any question he wanted without judgment, and mistakes weren’t viewed as a negative thing.

I talked to a teacher friend, and she suggested that I create “judgment free” activities. Turn kiddo loose on an activity, and don’t evaluate it in any way. Reward for doing something, anything, even if it doesn’t resemble the goals of the activity. One of her favorites is daily journal writing. Get kiddo to write down whatever they would like, and reward them for doing the thing, not on the actual contents of their writing. This worked well for the most part. Sometimes he would scribble and doodle, other times he would draw a picture and write a few sentences. Or he might write down birthday gift ideas. On bad days, I encouraged him to write down his negative feelings about me, which he didn’t need to share. He could keep his thoughts private, or, if he was more comfortable letting me know how he really felt, he could write it down. No matter what he wrote, I didn’t judge it, and only read it if he wanted me to.

One important aspect of a safe learning space is to create safety net that encourages mistakes that don’t have overly negative consequences. I discussed this with an earlier post: Fail Fast and FAFO. It can be as simple as putting down plastic to protect surfaces from messy experiments, or as complex as a discussion about a mistake with a hard consequence.

Feeling Psychologically Safe

I described approaches to feeling psychologically safe in learning in this post: Adventures in Homeschooling: Fail Fast and FAFO. There are a couple of areas related to fear that I wanted to expand on. First of all, with the fears themselves, it is important to help kiddos identify their sources of fear. Sometimes those sources might be surprising, and sometimes they might feel a bit trivial to an adult. However, it is absolutely vital to not diminish or invalidate their fears. Imagine fears you had as a child. No matter how irrational they might seem now, they feel real, and they are stealing energy away from being happy and productive in things kids need to be happy and productive in. Whether that is play, daydreaming, solving a problem or learning with you. Identify, validate and discuss fears. Don’t dismiss them or undermine them.

The second area I want to talk about today is in creating a psychologically safe home environment. This brings us to philosophical or values-driven approaches to parenting and home life. My partner and I like the positive parenting approach. It seemed to match our values and the kind of environment we wanted for kiddo. In short, we approach with a warm, kind, yet firm approach. There is structure, but we don’t enforcement it through fear or demanding compliance. There are consequences for actions, but we want to make sure that they are understood and developmentally appropriate. There is respect, but it is earned rather than demanded. Most of all, we look at filling up self-esteem at home. The analogy of a “self esteem bucket” is a popular one. The way we interpret it is that when you are out in life, there are lots of things that can get you down. Your home is a refuge where you can always go to recharge, and part of our job as parents is to help kiddo fill his self-esteem bucket when he is with us.

While all this sounds great on paper, and we read books and attended workshops and worked on this approach, we had to adjust and make it our own. First off, as Xer parents, this is the opposite of how we were raised. Secondly, your kiddos really determine your path. What seems good on paper needs adjusting due to the needs of your own kiddo. However, even when we get it wrong, we work on creating a safe environment. We want kiddo to know that we are his biggest fans, we are always in his corner, no matter what. There is nothing he can do or get wrong that will make us stop loving him or feel supported. We want him to be fearless about solving problems and being responsible for figuring out his own life. That means he will get things wrong, he will do things we don’t like, and he will fail at things. All of these things are important to grow through, and our job is to help support him through that.

A psychologically safe learning environment means that the consequences from learning actions don’t come with moralizing or judgment. They are learning opportunities, and he is always accepted, always supported, always safe, and always loved. We try to handle conflict in supportive ways. When voices get raised, tempers flare, and we don’t respect our own approach to working together, we own up to it, apologize and work to do better. In fact, these homeschool conflicts led to a family motto:

We are a problem-solving family.

We use science, knowledge, skill, respect and empathy to work together to try to solve any problem that may come up. We often get it wrong, but we really try to work together to focus on the fact that mistakes help us learn!

Reducing Math Anxiety

I watched my kiddo when we were doing math, and I started to notice patterns where he would show signs of anxiety. He’d stop smiling, he’d stiffen up, he might go quiet, or he might start to distract to get out of doing something. At first I found this frustrating, but eventually I realized that these were important cues. At first, this would happen every time I tried to pose a math question. “How many fingers am I holding…” or “How many do I have if I add these together…” or if I put a worksheet in front of him. He might enjoy it at first, and then I would see him tense up as he answered the questions. I realized that these questions and activities are high risk for a kid. You are either correct or not. When we worked with other subjects like literacy, there were key differences. We:

  1. don’t expect perfection and exact precision.
  2. reward for engagement and effort.
  3. make room for individual ideas and creativity.
  4. are patient when a concept isn’t mastered right away.

When you compare how we teach math and how we teach kids how to read, the difference is stark. Imagine if we were working on letter sounds, and we told them they were wrong if they pronounced the “short a” sound slightly incorrectly? What do we do instead? We reward effort, we gently correct, and we give them lots of time and room to improve with practice. On the other hand, what do we do with math? We present them with a question, and if they don’t get it 100% correct, it is wrong. That’s it. While it’s important to have precision in math, we put demands on kiddos that they don’t need before they are ready.

Here is an example from an online school experience we had. Over the course of a week, kiddo was given two assignments that he could work on every day. A writing assignment, and a math assignment. His writing assignment ended up being a short “five finger” style with a topic sentence, three descriptive sentences, and one that explained his feelings on the topic. It had a run on sentence or two, some missed punctuation, and a couple of words were spelled phonetically, but incorrectly. What was his grade? Top marks. He met the rubric for the assignment, and got a big thumbs up. While he had some small mistakes, those were fine for his level, and would get dealt with as he learned more over the next couple of years. His math assignment though, was a different story. There were 25 simple arithmetic questions to complete each day, with a total of 100. He got 1 of them incorrect, and the assignment was returned to him, and he was asked to correct that one question. How do you think that made him feel? Was it necessary to demand perfect precision in a math assignment when no other subjects in first grade are marked that way?

I described some approaches of how we overcame math anxiety in this post Adventures in Homeschooling: Embracing Math Mistakes. While the topic is mathematics, these approaches help with any kind of topic where there is learning anxiety.

Reducing Writing Anxiety: Drafts vs. Final Versions

Math anxiety was the first hurdle to overcome, but similar fears cropped up in literacy and especially in handwriting. We are proponents of learning good handwriting skills, both printing and cursive. More importantly, kiddo is extremely motivated to write. He loves the Story Pirates podcast and takes part in their workshops and works on his own original stories. Handwriting helps this process, but it is challenging to learn, and it can take years to get complete mastery. Beyond handwriting, writing itself is hard, and you almost never get it right on the first try. When kiddo would get frustrated with his letter writing practice, or that something he was trying to write wasn’t clear, his Mom and I both talked about “drafts vs. final versions” in writing. Both of us are pro writers, and neither of us have submitted something to an editor and had them publish it verbatim. We’ve always had to revise a draft, often several times, before it was ready to print.

When kiddo struggles because he needs to redo writing work, we remind him that he is working on drafts, and the final version will emerge. He shouldn’t be overly focused on trying to get it right the first time, he should focus on getting his ideas and creativity out. Then you start editing, and working on your draft. Once you are happy with it, you submit it. Creating and enhancing “drafts” of writing feels safer, there is less pressure to get it right the first time, and it models real world writing. You almost never get it right the first time, and pushing to at least one draft after your first attempt always results in a better final product. This has created another family motto:

Is it a draft or a final version?

It turns out that thinking about checking and revising your work isn’t just related to writing. We can apply this to all sorts of work, and it takes the risk out of it.

Iterate towards a solution.

Drafts in a non-writing discipline can be thought of as iterative or incremental solutions. If you need to, you work through a few versions until you finalize your work. This isn’t a sign of a problem, it’s a sign that you are human and you don’t need to be perfect.

When you work in software development, you almost never get anything right the first time. In fact, because working over time towards a solution is so inherent in STEM, there are entire software development processes related to iterative design and development. Rather than feeling pressure to come up with the correct solution in a hurry, like a timed math test, you are far more productive, not to mention a lot faster and efficient, if you iterate towards a solution. You get the right answer, but you take the time to use the right problem solving approach, and you get it wrong a few times before you get it right. Over time, the simpler patterns that you use over and over become second nature, and you focus your energy on the really hard problems.

This mindset works extremely well for kiddos who are learning. We want the right answer, but going slow to go fast and working through and learning from mistakes takes a lot of pressure off of them. If they don’t feel like they have to get all the answers correct the first time, they can actually slow down and learn from their mistakes, rather than memorizing answers out of fear of failure. Iterating towards a solution rather than passing or failing takes a lot of the fear out of learning. It is also much more realistic in the workplace. I almost never have to urge a new grad to work more quickly. In fact, they usually come out of school feeling like they have to get the correct answer as quickly as possible, and that is counter productive. They rush, they are full of fear about getting the wrong answer, and that gets in the way of learning and productivity. It also slows everything down. When people rush and try to get the correct answer quickly, it creates extra work and rework, and it is incredibly disruptive. Iterating and learning as you iterate is a vital skill to learn, and it helps people feel like they can be human and make mistakes safely. Furthermore, many mistakes lead to innovative solutions, so they are a vital part of the process both in learning and in product development.

Curiosity and Research

Another area we try to foster is for self-directed learning. What do you find interesting? What do you want to learn about? What aspect or thread of what you have been working on do you want to explore? What topic has cropped up that you want to look into further? We then look for resources on the shelf or online. Sometimes these end up as multi-day projects if kiddo has a learning itch that he really needs to scratch. Sometimes a single video or article is enough to satisfy his curiousity.

The trick here is to encourage learning on whatever the topic might be, even if it seems unrelated. That can be a bit jarring when you are teaching a particular topic and that causes an unrelated learning urge. It’s hard to be flexible and let go of that lesson and instead follow the energy of the kiddo. The benefits are amazing though, learning becomes more interesting, and they start to take responsibility for their own education. They also get their own way, which is important to them. Interest in a topic is one of the most powerful learning motivations. As a home school parent, I feel a responsibility to encourage that behavior, since it will serve kiddo well throughout their school career, and as a lifelong learner.

Thankfully, there are a ton of resources available thanks to technology. You can watch world renowned experts on videos, you can take part in online workshops and classes, you can play related games, you can download materials, or order manipulatives and books online, delivered to your doorstep. You can watch reels on social media, you can follow hashtags, and watch livestreams of nature events or animals. It is mind boggling how much technology can be used for research and learning. Tech is your learning friend, if you use it that way.

Engagement over Mastery

I have become a big fan of modular learning, and that has influenced our homeschool approach. Kiddo has unique needs, and he thrives when there is a balance of structured and unstructured learning. Modular learning also fits how we learn as adults with on-the-job training, attending conferences and workshops, getting certifications, etc. Both of his parents have changed careers, and undertaken training online and in-person to facilitate that. We’ve taught him to treat technology as a learning tool in addition to an entertainment tool, and it fits his personality. We discovered Modulo App, and that has been a huge help for us as we plan out a course together with learning, and look for hands-on tools and ideas we can actually apply to learning.

While we really like Modulo App and have utilized it to help, there is one thing they highlight that I disagree with. They talk about a mastery approach to learning:

“In a mastery-based approach, learning is personalized, students learn at their own pace, sequentially, take as much time as they need to fully master one concept before moving on to the next concept in the sequence, and the educator takes responsibility for the outcomes. In 1-1 mastery-based learning, one tutor supports one student through this approach, customizing the learning process to fit their pace and unique learning modalities.”

This is an area that my experience has caused me to disagree with. In fact, I prefer repeated exposure rather than pushing to mastery. This is especially true in early elementary when developing literacy skills and math number sense can take years to master.

To be completely honest, I find Bloom overrated in general. We are also not a family who respects hierarchy or authority that much, and none of us like being told we can’t do something. My responsibility as kiddo’s learning coach looks like this: if he wants to learn differential equations at 8 years old, then it is my job to figure out how to explore the topic in terms that he understands. I make the differential equations relevant to him, explain at his current level, and then create activities that are within his current math skill, with just enough challenge to help learn. If it’s too much, we set it aside and try again. We despise gatekeeping around learning. We value trying and failing, trying again, trying a different approach, leaving it and coming back to it, etc.

In our experience, pushing to mastery too soon is another source of fear and anxiety, at least in our household. Instead of pushing for mastery, we push for engagement. A lot of learning theory overlooks the interest levels of the kiddo who is sitting there trying to do the work. It’s all well and good to use modern approaches with scientific underpinning, with relevant, fun, hands-on activities that are rich and in safe, supportive environments. If the kiddo isn’t interested in learning though, you aren’t going to get very far. However, we may start a lesson with a completely disinterested kiddo. In fact, this can happen more often than we might care to admit.

If kiddo isn’t interested in a topic at first, it is my job to help him. I do this by trying to make activities and lessons fun and relevant. I draw from his interests such as Minecraft, Pokemon, Bayblades and video games. I also try to get him moving and use manipulatives, or explore with software. I try to use humour and make things interesting. If I get it right, he transitions from disinterest or downright shutting down on me to some form of engagement. If he gets the gist of the lesson, and then makes it his own, then we are on the road to mastery. If I push for him to memorize facts or to repeat until he can show mastery, kiddo will shut down and we won’t make much progress. Or, he will memorize facts that help in the short term, but are quickly forgotten because he hasn’t understood the underlying reasons for what the lesson was. For example, memorizing words in a book make it appear that he is reading fluently, but moving to a new book he now struggles with, shows he hasn’t developed mastery yet. Or in math, he may move around a number line and get the correct arithmetic answers, but a few weeks later, he has forgotten how to do it because he wasn’t trying to solve a math problem, he was gaming a manipulative.

Instead of pushing for mastery, we push for engagement. A lot of learning theory overlooks the interest levels of the kiddo who is sitting there trying to do the work.

An exploration-based approach to learning, coupled with aspects of self-directed learning or unschooling means that kiddos are going to come up against learning lessons that are beyond their current capabilities. That’s fine, and that can be managed in various ways. If they are really interested and committed, often they will surprise you and grasp concepts that curriculum systems gatekeep for later years of school. Other times, they get exposure, they try, they realize they aren’t ready, and you file it away to try again later. Mastery appears in time, and that is something you watch for and encourage. After a while, mastery is the consistent observed behavior in a topic, but it also has all this extra richness around it that experimentation, fun and time passing can add to it.

Any kind of pressure, no matter how well meaning, is important to identify and push out. Instead of correct behavior and mastery, watching kids make things their own and grasp the underpinning theory is much more important to our learning. Even in cases where educators encourage children to “find their own way” or figure out their own way to solve problems can be a source of stress. Instead, it is something I watch for and encourage when I see it. When it doesn’t happen naturally, I provide a variety of approaches to solving a problem, and they develop preferences, and eventual mastery in several approaches. This takes time, and requires breaking up the materials, rather than focusing solely on a topic and not moving on until they have shown mastery. Furthermore, sometimes a topic doesn’t click at the time, and falls into place weeks, months, or even years later. That’s how we all learn, and how we all keep learning and find it interesting. “You learn something new every day” is often related to something that you didn’t understand in the past, but repeated exposure in different ways leads to eventual understanding.

Bottom line: when mastery appears, encourage it, but don’t enforce it. Engaged kiddos will learn a lot, even if it isn’t directly related to the task at hand. Kiddos who display mastery quickly may have memorized patterns and not grasp the underlying material. I prefer to follow the energy of the kiddo and see what happens over time.

Context and Comprehension

One other thing I use to change the game for him is context.

In math, “2 + 2 = 4” is only valid within the correct context. It isn’t immutable, no matter what the hardcore education people like to chirp on about. Things are only valid or invalid in their context. To break the anxiety and pressure cycle, sometimes we brainstorm around meaning of math facts. What if “+” meant something else? How would I explain this to an alien? Then I show kiddo when ” 2 + 2 = 4″ is false. If they are integers, it is correct, but if they are strings, “2 + 2 = 22”, and if they are floats, “2 + 2 = 4.0”. I have spent a lot of time on the symbology of math, and how we can challenge those ideas in fun or interesting ways. “Right” is only correct in the right context, and being able to turn that context switch on and off is extremely important. In the real world, understanding context is vital, because if you leap to a solution by just looking at the symbols, you usually get it wrong. Slowing down and getting context, asking clarifying questions, reading everything, etc is important. Once again though, to flip the script, I will ask for wrong answers only first, and see if we can devolve into silliness to get the brain going. It might take hours, days or weeks for this transition, if my experience has anything to show for it.

Understanding context is important, because correctness is completely context dependent. With math symbols in particular, computer programming is a domain where the symbols change. Since my kiddo wants to learn to code, we show him the differences. For example, “x” is the traditional symbol for multiplication, but in many programming languages, it is a “*”. The equals sign “=” is often an assignment operator, and is frequently changed to double equals “==” when programming. As a result, “1 x 1 = 1” isn’t going to work in many computer languages. Instead, it would look like “1 * 1 == 1”. While the meaning is the same, the symbology is different.

Context discussions are important for solving word problems in school, for developing critical thinking skills, and understanding the difference between facts and opinions. There is also a nice side effect: they take the sting out of being wrong. One fun exercise when kiddo is disappointed in getting the wrong answers, and after we review work and he figures out solutions to what he missed, we have philosophical discussions about what it means to be right and wrong. Under what context would his answers be correct? What if the symbols meant something different? What if we were on a backwards planet? What if we had a disability or a challenge that made things appear different to us than our teachers? What if it was a planet run by kids?

Instead of getting caught in a morass of moral relativism or confusing absurdly harmful opinions as valid as scientific fact, we explore the context around meaning. Ok, so you got most of your math questions wrong, and you learned what you missed, but now, can you think of how your approach might be correct? Under what circumstances would this not be wrong? Or, maybe you misinterpreted directions and wrote a position paper on the wrong topic. Your arguments were cogent, your writing was clear, but you missed an important detail. How do you learn from that? How can you re-use your existing work for something else?

Another side effect of these discussions is that it really pushes you as a teacher to understand the theory behind the learning. That also means that kiddo is trying to make sense of concepts as well. For example, you may understand how to multiply fractions, but do you know why it works? Can you explain what is happening in real terms? Context shifts force you as a learning coach and kiddo as a learning machine to start from first principles. Understanding context and meaning leads to much deeper comprehension, which leads to a better set of knowledge as a lifelong learner and problem solver.

Real World Examples

A lot of times in school we are encouraged to memorize facts and formulas and produce correct answers in a short period of time. This looks good on exams and on metrics regulatory bodies use to evaluate learning, but it doesn’t encourage comprehension or experimentation. “But Why???” is an extremely powerful learning tool. “Why do I have to learn this? When will I ever use this as an adult?” are great opportunities for us to explain why it’s important to have these skills. Many times we don’t know ourselves, so it’s a great chance to say: “I don’t really know. Let’s research and learn together!”

Thankfully with technology, we can get these answers, either through using our mobile devices or a PC. We can find real world experts, we can find lots of explanations, and we can find real world stories where people have used that one thing to do amazing things in their jobs, for research, and sometimes for all of humankind. Real world examples also help put context around learning, but more importantly, they can inspire us. We can find people who we can relate to, whether it is someone of a similar gender, ethnocultural background, or just someone who we like, their stories can inspire interest and a desire to learn more. These stories that connect us to people that connect us to our curricula and to our daily learning are perhaps some of the most powerful motivators of all. When you hear about their doubts and fears and what they did to overcome them, and how they make a topic come alive, it’s exciting for kiddo and adult learning coaches alike.

It’s not so scary when a cool person you found online overcame their fears and challenges and applied something you are trying to learn in interesting ways.

Adventures in Homeschooling: Fail Fast and FAFO

Fail Fast

In software development, there is a programming philosophy called “fail fast”. The idea is that you start by generating an immediate and visible failure, and then you add just enough code to fix that failure. This is a paradigm shift, since normally in software development you write code first, then test to see if it works. Both approaches work, but failing fast has the advantage of helping you be more proactive in developing reliable software, but it also has a side effect: confidence.

Here is an example, from a fail fast software development approach called Test-Driven Development. You want to write some code for a mobile gaming app, and you have your IDE (Interactive Development Environment) ready to go. You’ve sketched out some screen designs, and you want to work on initial game play by placing an object on the screen that can be interacted with. Instead of writing the code that starts drawing things on the screen, you write a test for that code. Then you run the test, and of course it fails, so now you start to write the program code to get that test to pass. It might take several quick attempts of writing program code for that test to pass. Next, you add some variation and elaborate on that simple test by adding more.

Once you are satisfied with your combination of program code and tests, you proceed with your program development. Again, write a new test first with no corresponding program code, run the test, watch it fail, then add code until it passes. After a while, you have a suite of tests that you can run when you change your code, to verify that you haven’t broken existing functionality. That suite of tests provides confidence that allow you to make simple changes, but it also makes you think more about writing code that is more reliable as you are writing it. In short, the computer provides you a level of safety before you commit a program to a build and deliver it for people to look at. It feels really weird at first, but your brain makes the paradigm shift after a while.


FAFO, or fucking around and finding out, is a popular term in online culture, but it also applies to learning. In fact, much of learning is about fucking around and finding out. Kids constantly do this. They try something, they observe the effects, and they learn and move on. Adults do this too, and not just when they engage in crappy online discourse. The scientific method, or hypotethico-deductive model is a formal, powerful, peer reviewed version of FAFO. FAFO, when it is safe, is a fantastic learning tool, and it comes completely naturally. As kiddos, we touch things, we taste things, we poke them with a stick, and we squeal and run away when things go awry. Trying, observing and adapting is crucial to learning. When you start adding knowledge and facts, FAFO gets squeezed out.

In childhood learning, we put a lot of pressure on kids to get things right. Instead of putting a worksheet in front of them, encouraging them to write out answers, then grading them on an answer key, how do we get them to fail fast and build their confidence? For me and my kiddo, using play and technology helps us fail fast, so we build confidence and explore in our learning, before committing to a correct answer. FAFO is a great learning tool, but it’s high risk when you use worksheets. You have to commit rather than explore and find out. That ability to explore wrong, right and indescribable answers before committing them to get graded is key.

…using play and technology helps us fail fast, so we build confidence and explore in our learning, before committing to a correct answer.FAFO is a great learning tool, but it’s high risk when you use worksheets. You have to commit rather than explore and find out.

Feeling Safe is Crucial

Failing fast in software development is possible when you have a safety net. FAFO is fun and a great learning approach when it is safe to do so. It turns out that other things like productivity, quality problem solving and providing feedback also require safety to be effective.

In the corporate world, there is a lot of talk and training about creating psychological safety in the workplace. In essence this means you create a culture and environment where people aren’t afraid to ask questions, make mistakes, or speak up when something is wrong. A psychologically safe workplace isn’t about enforced or toxic positivity, in fact, it is a place where problems can be confronted without punishment. Criticisms about product can be raised without also feeling forced to offer solutions. Outrageous ideas are welcomed and brainstormed together. Tough feedback, especially to leaders is welcomed. The people who need to hear the hard truths welcome hearing those hard things because it makes the product and the workplace better. The article What Is Psychological Safety at Work? How Leaders Can Build Psychologically Safe Workplaces articulates this well:

“Psychological safety at work doesn’t mean that everybody is nice to each other all the time. It means that people feel free to ‘brainstorm out loud,’ voice half-finished thoughts, openly challenge the status quo, share feedback, and work through disagreements together — knowing that leaders value honesty, candor, and truth-telling, and that team members will have one another’s backs.”

In my consulting work, I found that high performing teams had a high degree of psychological safety. They could try and fail without judgment, they could provide brutal, but important feedback without fear of reprisal, and they handled conflict well. I also noticed this in training sessions, especially with corporate clients. When I would set up in an office and participants in the company would start to trickle in, I could sense the fear almost right away. They were also afraid to take part in any of the group learning activities, because they were afraid of failing, and then being judged or punished for it.

In many companies, if management was around in the training room, people were extremely tentative. They didn’t want to answer questions or participate in the vital learning activities. If management left the room, they started to participate. I put a lot of work into my courses to make people feel safe to do whatever they needed to do to learn, as long as it was respectful of those around them. I didn’t always get it right, but I worked at it. Two instances stand out in particular.

In one instance, I had a room of about 60 employees with their managers sitting at the back. The development manager left early on along with several other senior managers. The QA manager though wanted to stay to learn for himself. At the first break of the morning he came up to me and said he felt his presence was interfering with participation levels, so he was going to leave. Sure enough, once the bosses were gone, people started to speak up, and they brought up problems they were having with their software development and asked how to apply coursework to their current situation. We had an extremely productive two days. My third day on-site was partially spent going through a highlight reel of the course with the manager. This was early in my training career and was extremely eye opening.

In another instance, I had a smaller team of about 15 people in a training session. When the development manager would come into the room, everyone went silent and would look at the floor. When they left, everyone would look over their shoulders to see if she was gone, and then they would participate again. She walked in again during a complicated systems problem solving activity and no one noticed. Instead of working as a group, they had asked to work on it individually to make it more challenging, and then they would compare their work as a group. This is a fantastic learning opportunity because you get a lot of perspectives. The right or correct answer with many systems thinking exercises is to generate different, yet valid perspectives. One of the shyest participants spoke up first, and mentioned that one of the prompt categories had been hard for her. It turned out she had misinterpreted the prompt, and wasn’t able to think of anything relevant. Usually when this happens, it leads to rich discussions about mental models, shared language and how different people or groups can interpret things differently. In fact, they may have completely different definitions for words that you use in a different context. The participant wasn’t “wrong”, and in fact, she had inadvertently brought us to our next discussion point, all through doing the work and feeling safe about it. Unfortunately, this didn’t happen. The manager who was standing at the back of the room suddenly spoke up, joking around and mocking the person for getting it wrong. She was instantly deflated and upset, and the tension ratcheted up with the entire group. The afternoon learning was completely ruined, no matter what I did to try to get them back on track.

When kiddos learn, we can put enormous levels of pressure on them, even by accident. When you are a parent homeschooling, this pressure increases. You want them to get the “right” answer, they want to please you, and you can give away a lot with your body language, your tone of voice, your approach, etc. Imagine this scenario. You work through some simple addition facts with small numbers. You carefully review the addition and equals symbols. You help them translate an equation into spoken language, “one plus one equals two”. You help them visualize it with some of their toys. You then have them review it with a fun online video. You then take out a math facts worksheet with 10 questions that have simple equations for them to solve. You read the directions on the worksheet, ask if they understand, and then you work through the first question together. You review, and they seem to get it. They know what is expected, they have the required background information, and they understand the concepts and have the skills to work through the problem. You turn them loose, and what happens? Are they feeling energetic and having fun with a challenge to show what they know? Or, are they freezing up and serious? As a parent learning coach, I’ve had both experiences. At first, we had a lot more of the freezing up and pressure than challenge and fun.

To help make this activity feel safer, I did away with the worksheet. I would take toys or math manipulatives, a plus sign and an equal sign and put them into an equation. I would take 2 Hotwheels cars, set them down on the table, then next add a plus sign. Then I would add 1 Hotwheel car. I had two Hotwheels representing the first addend, and then one car representing the next addend. I would add the printed out equals sign, and leave the sum empty. I asked kiddo to get Hotwheels to fill in the sum. After a bit of trepidation, he grabbed three Hotwheels to represent the sum. Next, I asked him to use his mini whiteboard to write out the equation in numbers. “2 + 1 = 3”. It took a few attempts, but in a day or two we had finished off the worksheet material, but in a way that allowed him to experiment before committing an answer. he could manipulate the Hotwheels or other manipulatives until they felt right, then write it on the whiteboard. Also, the whiteboard was easier to fix mistakes than writing down in pencil and then erasing. Also, I worked with him on how to check his work, so he could feel more confident before asking me to check his answers.

Experimenting with toys and math manipulatives are all well and good, but technology makes experimentation, failing fast and FAFO even more psychologically safe. I have long used virtual simulators, emulators and high volume test automation to experiment and learn about software systems. They are extremely powerful technology tools that allow you to explore and find out what happens to systems when they start to fail. You can then design and enhance your system to be much more robust, reliable and performant under real world use.

One of the first things I worked on to reduce risk in math work was to use technology to help, and make the activity virtual. I opened a slide deck, added in a plus and equal sign, and a bunch of small images at the top. I then asked him to create equations. I made text boxes where he could type in each addend and the sum, and he could add them up above the equation to experiment or check his work. He had a lot of fun with it, and would often ask to be alone to play around. Once he had written down some math facts, he would proudly show me his work on each slide he had created. When he made a mistake, I was very careful to ask him to review his work with me, and we would try to find a learning lesson if there was something to work on, or I would brush it off as a typo. After all, we all make typos!

Next, I used high volume automation using the programming language Ruby. Together, we wrote a function to add two numbers together. He came up with variable and function names, and the function would add the numbers and return the sum. Next, I added in a function that would loop from 0 to a number of his choosing and demonstrate the sum. Each addend would increase by 1, and with a bit of a delay added, he could watch the sums increase as the addends increased. We then repeated this with a subtraction example that would iterate down from a large number to 0.

Experimenting with toys and math manipulatives are all well and good, but technology makes experimentation, failing fast and FAFO even more psychologically safe. I have long used virtual simulators, emulators and high volume test automation to experiment and learn about software systems. They are extremely powerful technology tools that allow you to explore and find out what happens to systems when they start to fail. You can then design and enhance your system to be much more robust, reliable and performant under real world use.

If it works for adults who are solving incredible problems, then it is surely going to work for kiddos who need a safety net to fail fast, to FAFO and feel safe in making lots of mistakes and learning from them.

I found that our virtual work provided a lot of opportunity to fail fast, adjust quickly, and reduce the perceived risk of school work. Beyond that, we could use the tech to FAFO. What happens if you add in a character instead of a number? Well you get a type error. Ok, so what does that mean? We have to be explicit with the computer when programming and give it what it expects. But can a letter be a number? Well, sure.Then we talked about algebra and ended up working on one step algebra. We moved seamlessly from having trouble with simple arithmetic to basic algebra, all because kiddo felt safe to experiment and once his brain wasn’t processing anxiety and fear, we could move in whatever direction his curiousity took him. Technology is a wonderful place to safely play with exploration, but sadly, we seem to mostly try to replicate classroom experiments with virtual worksheets rather than tap into its power to enable and provide safety for judgment free failures and productive FAFO.

Adventures in Homeschool: Embracing Math Mistakes

One issue we were struggling with in home school was overcoming the fear of getting answers wrong in mathematics. Even at five years old, kiddo’s exposure to counting heavy math activities had provoked some anxiety. He could count to 30, he could identify numbers and do simple calculations while playing games, or around the house, but in a math learning context, he would get anxious and stop engaging.

At this point in homeschooling, I was using Natural Math activities from the book Moebius Noodles by Yelena McManaman and Maria Droujkova. There were fun activities such as symmetry and mirroring, creating functions, having fun making and playing with grids, and much more. The activities were fun, math time wasn’t prone to anxiety and conflict anymore, and we were progressing. We were still at the kindergarten level so I wasn’t overly concerned that we weren’t doing math fact work or determining calculations. However, I wanted to move beyond the form and function and start helping kiddo develop number sense.

Trouble was, whenever I tried to bring in math he had been doing in preschool, he got anxious. He felt pressure to get the right answer and it stopped being fun. We had conquered the “fun” aspect of math activities, but we needed to look more explicitly at numbers and their relationships to each other. We could go through the process of solving math facts, but now we needed to talk about the facts in a non-threatening way. In short, how can we banish the anxiety kiddo feels on always needing to provide the correct answer? I looked to web discussion forums for inspiration.

Cunningham’s law describes an online phenomenon about asking for help. In essence if you want to get help online, you don’t ask the question you want answered, instead, you make an obviously false statement and wait for refutations. If you ask: “How do I do…” you won’t get much engagement. People don’t seem to want to answer direct questions, especially if they have appeared on the forum before. However, if you confidently post a wrong answer, you will get many people pointing out that you are wrong, and providing examples to show you just how wrong you are. Soon you will get the answer to your “How do you do X”, you just had to ask it in a way that people would react to and feel compelled to engage with. The xkcd comic series has a cartoon describing this obligation.

Don’t Ask a Question. State an Incorrect Answer Instead.

When I was starting out as a public speaker at software development conferences, I had a lot of anxiety. Part of it was because it was new and public speaking is hard, but part of it is because the audiences in software development can be ruthless if you get something wrong. Heckling and heated arguments can occur when you get it right, let alone if you mess something up or if you have an incorrect interpretation. At the time, software consultant Brian Marick was very kind to me and offered encouragement and advice. One tip he had was to start off with a mistake in a talk, and get it out of the way. That way you could just focus on your content and not worry about making a mistake. You’d already made the mistake, and it wasn’t so bad after all, so now focus that nervous energy in a positive way.

I found this helpful, and with experience I learned to improvise and incorporate my mistakes into the talk. If I got a fact wrong and I was corrected, I thanked the person for taking the time to help me, and corrected my materials as best I could. Mistakes weren’t so bad, and in fact, they added a richness to my corporate training. Sometimes, this was due to me getting an important detail wrong. At the time I traveled so much I would forget what city I was in, or what company I was currently at.

I also used to use incorrect answers to warm up a shy group. If I had a group that was reluctant to engage with the activities in the training, I had a secret weapon. I’d deliberately pose and then answer a question with the wrong answer, and usually someone in the audience would blurt out that it was wrong. Or at least you could see them move from surprise to chuckles, once they figured out I was doing it on purpose. People would warm up and start adding in ideas about a better solution. It also helped with groups who didn’t know each other. If they were a bit reluctant or shy to collaborate, I would break the ice by suggesting incorrect solutions, then transition to correct examples.

There seems to be an innate need for many people to correct something that is wrong. If it worked with adult learners why not try this with kids?

In the book Moebius Noodles, they discussed teaching subitizing. This is something adults have developed through working through math over a number of years, but many of us weren’t explicitly taught. I liked the idea, but I had never heard of trying to teach it before. I started reading and watching videos about how to teach my kiddo how to subitize. Trouble was, if I held up fingers or a dice or pointed to a small group of toys and asked “How many?”, the old math anxiety would flare up. The fun would stop, and kiddo would be disappointed. I felt that we could easily work from 0-6, especially since we used dice in games and he was familiar with that number range. However, instead of doing it right, I was going to do it wrong and see what happened.

I started with body mirroring activities. We stood facing each other, and I bent one arm at the elbow and held my palm facing up. Kiddo mirrored me, watching intently. Next, I adjusted my hand so I was holding up three fingers. Kiddo mirrored me, watching quietly and intently. Then I blurted out: “I am holding up FIVE fingers!” He stared at me in shock. He didn’t say anything, so I said it again. “I am holding up FIVE fingers!” He gave me a puzzled look, so I repeated myself. “I am holding up FIVE fingers!” He responded this time: “No Daddy, you’re wrong.”

I repeated myself: “I am holding up FIVE fingers!” “No Dad, that isn’t right.” I asked him what was wrong with what I was saying. “It’s wrong, you are not holding up five fingers.” He looked concerned and wasn’t sure how to proceed. This time, I started using silly voices, making faces and hamming it up. “I am holding up FIVE fingers!” Once he realized I was being silly, he started to laugh, but kept telling me it was wrong. Finally, I asked him why it was wrong. “You’re holding up three fingers.” “Pardon?” “You’re holding up three fingers.” “Pardon?” “You’re holding up THREE fingers.” He was starting to giggle now. “What? How many?” “DAD! YOU ARE BEING SILLY. YOU’RE HOLDING UP THREE FINGERS!”

Aha! Finally! Math without fear!

I then asked him to do it. He started hamming it up and holding up random numbers of fingers and deliberately stating the wrong amount. He would ham it up until I guessed and corrected him, and then we would switch. After about 5 minutes, we were doing a basic subitizing exercise that was incorporated into our mirroring activity.

This was a huge breakthrough. We hadn’t had an experience like this in weeks/months. Now we could build on this.

Wrong Answers Only

In our daily work, I started to incorporate subitizing, simple arithmetic and counting. We would use manipulatives like mathlink cubes, Lego bricks, rocks, basically anything we could use to visualize. However, we had a rule. wrong answers only! I wanted to try to get the anxiety out, and model how math should feel. It should be challenging, but it should also be fun. It should be about discovery and exploration, and the mental math and memorization will come with doing, not by being judged on your accuracy.

I deliberately chose math problems that were below his current level, and then had him come up with the wrong answers only. I could tell that he really wanted to provide the right answer, but I would delay that and remind him that we were going for wrong answers only. In fact, the reward here was for the silliest answer. After a while, he would be practically vibrating to try to correct it, and then and only then would I ask him for the correct answer.

Here were some variations:

  • Try to make me laugh, or make yourself laugh with your answers.
  • Make them sillier and sillier.
  • If they want precision, then I have a rule that there needs to be 3 silly answers first, before doing the correct one.
  • If they are tired of doing wrong answers and want to do right answers, follow their energy and switch it up.

My goal here is reframing the learning. Instead of a winner takes all, high stakes math fact question, we explore and see what happens. Instead of getting a question wrong and fixing the answer, we embrace mistakes, and to try to banish fear. Part of this approach is to get kiddo used to the format of solving problems. Part of it is to overcome anxiety and panic when posed with a math question and being expected to get the right answer, every single time. If you can get the wrong answer and the wrong answer is the correct answer, then you have the capabilities to get the correct answer when you need to provide the right answer.

Switch the Context, Gently

I wanted to tap into the knowledge he had, and to get him to demonstrate it to us, but without any anxiety or fear. I worked hard to be matter of fact and not point something out and wreck the energy of the activity.

Once we were having fun answering with only incorrect or silly answers, it was obvious that he had the capabilities to answer correctly. Once he was tiring of silliness, or if he was starting to answer with the correct answer, I would silently shift. I might verbalize this if it felt confusing, or I might just go with his energy and watch him answer correctly. I didn’t praise him for the wrong answer, or the right answer, I reacted the same way no matter what he did. I was rewarding the approach and the effort, not the answer itself.

After a while, we could do subitizing without fear. I would hold up fingers, he would answer correctly. Then I would get him to do it with me. We would take turns with fingers, dice, toys, cereal pieces, or anything else that was a small number to count. To add some variation, I started holding up 1 finger on my right hand, and 2 on my left, slowly easing in to some basic arithmetic.

If he started to freeze up or show signs of anxiety, I would ask for “wrong answers only”. If he was really starting to get wound up, we would move and work out his emotions together, and return to mathy stuff later on, or the next day. After a while, he would ask to not do silly or wrong answers, and preferred to work at providing correct answers. To keep the positive energy going, I didn’t tell him if his answers were correct until he asked me because he was curious. I was careful not to reward him for being correct only, but to reward his efforts and the process we were doing. If he got one wrong, I built up his self esteem and let him know it was ok.

Finally, we were moving out of math anxiety, and were developing a solid base we could work from. Subitizing, counting activities and simple arithmetic could be completed without anxiety, fear or conflict. This was a major step forward.

Adventures in Homeschool: Revamping Preschool Math with Symmetry

In my previous posts, I wrote about issues we had with a traditional, North American approach to teaching and learning math basics. Utilizing popular approaches and activities weren’t working, so we had to try something new.

Natural Math was a lifeline for us to explore learning math with our kid. I liked the philosophy of opening up math, not putting in artificial age-based gatekeeping, that it de-emphasized counting based activities. I loved the focus on exploration, personalization of math and fun. This article, 5 Year-Olds Can Learn Calculus was an inspiration to us.

Reflection and Symmetry

One of the first activities we tried from Natural Math was body mirroring. I would stand and my son would stand opposite. I would move my right arm to a position, he would move his left arm to match me. I would extend my left leg, and he would match with his right leg. Then it was his turn. He would waggle fingers, kick a foot, or pull a funny face for me to match. Reflecting each other could easily devolve into silly giggling and fun, if someone got it wrong or did something funny

To add more variation, I also had him stand in front of a mirror and move himself, and watch carefully what happened. We would add more variation in with movement, such as moving to the side so only part of his body, or half his body was reflected. I would ask him to think like a scientist and carefully explain what he was observing. I was cautious with feedback, and I praised whatever he came up with. I also started modelling behaviour by doing it myself, and describing what I saw using different approaches. Then he would try and add more to his observations based on what he had seen me do.

My Gen Xer brain didn’t feel like this was really math, but at least he was enjoying it. I started to research reflection in mathematics to assuage my parent guilt, since I didn’t feel like I was doing a very good job in math learning.

After a few days of reflecting fun, I started to hold up a number of fingers for him to reflect as well. He would reflect different combinations of fingers on both hands with ease. I had to be careful though, if I called attention to it with: “How many fingers am I holding up”, he would get suspicious and stop having fun. I also ordered a small foldable mirror for him to play with, and once that arrived, I would put in a Lego character or a small toy, and show him the initial reflection, then fold one side in to increase the number of reflections.

Kiddo would play with that for extended periods of time, looking at things in the mirror, shifting the angle of the reflection to increase or decrease the numbers, and adding and subtracting items to add variation. It was also interesting to see what happened to an object placed in the centre, and how the object itself would get partially reflected. Reflecting half a Lego character would lead to us exploring symmetry. If you don’t get your Lego person exactly in the centre of the foldable mirror, it can reflect in unexpected ways.

Mom is an artist, and she suggested using small colorful and geometric objects to make patterns. Tangrams are fantastic items to use with a foldable mirror. He could make mandala-like reflections using tangram shapes and folding in the mirror. This led to conversations about infinite numbers, and to a topic that piqued his interest: fractals. We found videos on youtube discussing fractals, and we started to look for repeating patterns in nature. He would spot patterns in leaves, in rocks, in certain plants growing in the neighborhood or the river valley and shout out FRACTAL!

Since this was appealing to kiddo, I decided to try to tie fractals back to our reflection work, and found instructions on making a Sierpinski triangle. You draw out a large triangle on a piece of paper, find mid-points in each side of the triangle, and then draw a new triangle within the larger one. You repeat this process as many times as you can.

The Sierpinski triangle was a bit advanced for his learning at this point, and I realized we needed to look at symmetry more. Determining the line of symmetry in an object was intuitive from mirror play, but now we needed to be more explicit. I downloaded drawing and coloring worksheets to help learn more. I started with symmetry drawing exercises where a simple object would be drawn on half the paper, but at the line of symmetry, the rest of the paper would be blank and the child would need to draw it in. They would reflect the drawing in the other axes on the blank half. He found this a bit hard, so I started looking for exercises that were on a grid. The grid helped provide a guide, but the grid also had some hidden benefits. We were sneaking more math thinking we could build on later.

Counting away from the line of symmetry and then drawing a smaller part of the overall shape within that box requires more math thinking. There is counting, but now you are thinking in two dimensions. You need to keep track of rows and columns in a grid. There is counting involved, but the underpinning mathematics brings us to a matrix. Matrices lead us to arrays, and arrays lead us to different powerful abstractions for mathematics and programming. Cool!

Kiddo enjoyed working through the symmetry worksheets. We also found that the side that the drawing was on could have an effect. It was easier if the drawing was on the right side, with the left side blank, while a drawing on the left side with the blank right side left to fill in was a bit more difficult. The further away from the line of symmetry, the harder it was to get right. To get precision he was happy with counting, and keeping track of rows and columns. If he forgot, I coached him to write down the co-ordinates on his white board.

To add variation, especially when little hands get tired of drawing and coloring, we found worksheets that used the grid to make pixel-style art. He declared them to look like retro videogames or that they looked like Minecraft, and he would color in a block, rather than drawing with precision all the time. We also used bingo daubers to color in objects, as well as manipulatives like Mathlink cubes and color counting chips. These required less fine motor effort, but provided more time for variation and play.

After a few weeks, I noticed that our math time during the days was turning into a lot of fun. Instead of dreading it, or checking out when I put the math sign up to help with transitioning, he was starting to look forward to it. There was positive energy, questions, frustration with execution rather than with concepts, and he was becoming comfortable and fearless. Discussions would lead to math in real life, and he would spot symmetry in nature, or point out things around the house. Helping out with cooking and baking in the kitchen would lead to more topics for us to research and explore together.

Things were falling into place, now we needed to build on it.

Adventures in Homeschool: Revamping Preschool Math

While we were finding our way with homeschooling, our current approach to math wasn’t working. Kiddo was 5, going 6, and he had already learned a lot in preschool. He could count to 30, he could do simple arithmetic, and he could group items according to patterns. Trouble was, when I followed a lesson plan or printed off math materials, we had inconsistent results. Things started out ok, but kiddo would show signs of discomfort. He might avoid the activity by distracting, he might start the activity, then scribble all over the worksheet, or he might get upset and refuse to work on it. When we shifted to focusing on emotions and exercising to clear out the negativity, as soon as he returned to the worksheet, his mood would deteriorate. Obviously, there was something fundamentally wrong with the approach.

I came in to teaching my son predisposed with approaches that worked when I did corporate training. Some of the tools I used when teaching adults seemed appropriate for kiddos too:

  • Reward a problem solving approach rather than always getting the correct answer
  • Incorporate movement and collaboration in exercises and activities
  • Encourage productive struggle: let people figure out solutions on their own
  • Model behavior to demonstrate, then have students practice
  • Exploration, incorporating surprises or accidents, and having fun

When I started training, I was focused on knowledge and covering material, but people would get tired and bored with dense presentations, so over time I started to utilize exercises. I also got a sense of what worked well with groups and what didn’t work so well through trial and error. These were so ingrained, I found myself improvising and moving off of our daily lesson plan, when I followed the energy of my son.

I also had some unconscious biases from how I learned math as a kid:

  • Focus on correct answers rather than problem solving approaches
  • Memorizing “math facts”
  • Timed tests
  • Drills to review facts
  • Using worksheets

While I hated most of my math learning growing up, the repeated approach over twelve or thirteen years stuck with me more than I cared to admit. Furthermore, much of the math curricula and activities that I was following reinforced how I had been taught math. There were changes, such as topics such as subitizing and symmetry that were explicitly taught, rather than just picking them up as we did, but the format seemed very familiar to how I was taught. I found myself inadvertently putting pressure on my son to get the right answer on a worksheet in subtle ways. He would pick up on changes in body language, my breathing, etc. and would start to tighten up.

I decided to revamp our approach to math, and that would require some research, some hard work and retooling.

We decided to take a couple of weeks off from our homeschool kindergarten, while I researched and tried to retool. We downloaded some apps to try to help with literacy and math, and I watched to see what he liked and disliked. In the meantime I read books and searched the web for alternative approaches to teaching math to preschoolers. I didn’t come into this cold, I always knew I would need to support and enhance what he was learning in school, but I never expected to be leading the learning effort. I have taught a lot of adults how to program from my consulting and corporate training days, and there were some common problems that I had to help them overcome. Some of it was as simple as 0-based counting, and getting people to think more abstractly, rather than memorizing formulas or algorithms.

I had struggled in math and didn’t really come into my own until university, so I had a lot of thoughts about what I had missed out on in my education journey myself. I felt that my son needed to learn things I had struggled with later on, mostly because of exposure and memorizing previous “rules”. Once I was learning math in university, the approaches to learning were completely different, and I found approaches that worked well for me, but it was extremely difficult to keep up. I decided I wanted my son to have some advantages when it came to understanding:

  • zero-based counting
  • negative numbers
  • multiple dimensions (ie. arrays, grids, etc.)
  • variables (yes, letters can be numbers)
  • math can be fun.

When I was a kid, I felt this pattern when learning math. I would be taught something as a rule, only to have it change later on.

I always felt like it would have been better to teach me more of the picture, and that things were flexible, rather than absolute. For example, starting to count from 0 when looking at an array index or doing pointer math in programming was a lot of overhead at first. If I had been taught to look at 0 more often when I was younger, my brain could have spent more time on the hard parts. When I was younger, I hated how the transition to negative numbers, I felt betrayed. I was told that “2 – 3” wasn’t correct, and then all of a sudden, the rules changed. “2 – 3 == -1”. Now I had to start my math model all over. Another “rule” was that letters aren’t numbers, but then algebra came along, and that rule was cast aside. I would get extra help, go to the library and read, and find something that clicked for me, only to be told that what I actually wanted to learn was too advanced for this grade, or there wasn’t time in class. “You’ll learn that stuff later.”

This pattern repeated throughout my school career, gate keeping by age, and learning steeped in rote memorization and solving based on math facts. I suffered through timed drills, and I felt distant from the actual work. How would this apply to regular life?

It wasn’t until I was in university that math started to click for me and became fun. I even ended up in a career using applied math.

I also had a memory, from university. One of my favorite math professors was teaching his elementary aged children how to do basic linear algebra, calculus and other so-called advanced math topics. He railed against the gatekeeping we often do in elementary school curriculum. He also felt that most students weren’t taught how to think about math before they started post secondary education, and that he had to spend too much time expanding brains and getting people to move beyond memorization. The math that his kids were doing wasn’t difficult, it was just shown in a different context. His 7 year old was adding together two arrays, and the arithmetic was well within their skill level. The application of the arithmetic and keeping track of rows and columns was the challenge. However, kids love board games and can thrive with 2D arrays during play, so why not use that when learning math? You can teach abstractions and provide different contexts with basic math skills. Sadly, the book he had recommended for kids to learn more advanced topics was out of print, so I had to try to find other sources for us.

As a corporate trainer, I taught adults how to program, they were often struggling with off-by-one errors, or getting caught up in simple arithmetic because they weren’t used to starting with zero. For example, very basic programming errors could be caused by people looking at an array index, or loop counters and forgetting that they start with zero, rather than one, in many programming languages. The actual math thinking was kindergarten and first grade level, but there was often a mental block. Beyond that, looking at multi-dimensional arrays and simple algorithms or programming patterns could be extremely challenging.

It felt like a lot of people had to unlearn their approach to math first, then start learning how to actually apply the math to something in the real world. Since I had those same struggles, I could empathize and tailor my training work to help people who were having trouble learning how to program. I often thought of my old prof’s approach and wondered if there was something a bit off with how we teach math. Memorized facts don’t translate well when you are problem solving in the real world, other than to help provide a base to work from. Now, it was my responsibility to solve this problem for my son.

Finally, I found what I was looking for. Natural Math was an approach that made much more sense to me. In fact, it expanded on my thoughts of introducing him more math earlier, and emphasized fun, exploration and creativity. Unfortunately, there wasn’t a zero-prep lesson plan or worksheets I could buy and print out. There were books, lots of ideas, and different approaches and contexts I could use to create our own material.

After a couple of weeks of cramming, it was time to restart our homeschool kindergarten. We kept most of the lessons, but instead of a math worksheet or an activity with manipulatives like toys or duplo bricks, I would have him watch a video on a kindergarten math topic. I stopped using worksheets other than for topics he enjoyed to complete, such as filling in 2D graphs. He loved a particular worksheet style where he was asked to count objects, then fill in and color a bar graph based on the number of each object.

I watched him carefully, but I also had to watch myself. I could quickly ruin an otherwise positive learning experience. For example, if he made a small mistake in his graphing exercise, I would gently point out the mistake, and he would feel crushed. It would be something minor, such as him counting 5 red Duplo bricks, and then accidentally coloring in a bar graph for 6. I’d gently correct him, and the wind would go out of his sails, and a happy, smiling kiddo would look sad and start to withdraw.

The other part of my behavior I needed to adjust was to get over myself when it came to my reaction to his need to move and express himself. When he would make a connection in learning and was happy and proud of himself, he would jump up and down, flap his arms and spin. I felt that part of our homeschool work was to prepare him for learning in a classroom, so I would discourage the jumping and spinning. Once again, he would go from a happy kid who had just mastered a tricky learning problem and was full of joy to feeling shame and he would withdraw. I worked on my behavior, since what did I want him to learn? Did I want him to learn that he needed to be perfect in his math, or that he needed to master concepts and it was ok to get the wrong answer sometimes? Did I want him to sit still and stifle his emotions, or did I want him to experience joy and fun at a topic that can be challenging and many find intimidating? I decided I wanted to encourage the learning and the joy.

I decided to throw out the math resources we were using, or at least set them aside for a while and start something new. On the recommendation of the people behind Natural Math, I bought and read the book Moebius Noodles: Adventurous Math for the Playground Crowd. The hard part with Natural Math is that there are topics with examples, but there aren’t pre-free math resources you can download and start using. Instead, I read through the first chapter on symmetry, and tried the example they described in the live mirror section. To be honest, it didn’t really feel like math to me, but I was willing to try it out and see. One of the live mirror activities was to have the student stand facing you, and then you move your body, and they move to mirror it. For example, you stand with your arms at your sides, and lift your left arm and point it out from your body. They do the same thing, pretending to be your image in the mirror. For kiddo to get the hang of it, we also had him practice using a mirror first, then trying again with me.

While I didn’t feel like we were really doing math per se, the important outcome was my kiddo’s reaction. He LOVED it.

Over the next few days, we added complexity to the activity, using stuffies, toys, and other props. We tried things outside, and did more complicated movements. We even added in sequencing, where one person needed to follow 1-3 moves that the other did. We also watched videos of people dancing and doing other forms of copycat movements. The body movement and the focus on exploration, without any chance of failing to get the correct answer was a winning formula. Now we were on to something, but I needed to learn a lot more about this approach.

(to be continued…)

Introducing Adventures in Homeschooling

Today I’m going to introduce a new topic to this blog: homeschooling.

I’m a dad, and my son is elementary-aged. Together, we’ve had a bit of an unusual educational path, and people keep asking me to write and share what we’ve been up to. In addition to my software work, I am also my son’s learning coach. We use a blend of structured and unstructured learning, with some adult direction, some formal school interactions, and a lot of time and opportunity for self-directed learning.

To keep up with a kid who is an active learning machine requires that I keep learning too. I need to feed his learning appetite, to encourage and cheer him on, help set goals and milestones,remove impediments and protect him from politics. In short, it sounds a lot like what I do as a product manager working with software development teams, even if the implementation is different.

In March 2020, we–like everyone else–were suddenly pulled out of our routine and needed to find a way to help a four year-old (almost five year-old) learn at home. He had been in daycare and preschool, and was well prepared for kindergarten in the fall. While we weren’t worried about him falling behind, we needed him to keep learning and stay occupied while one of us worked from home. Since my health prevents me from full-time work, I took on the learning coach role, while my wife transitioned to full-time work from home and needed space and time to focus on her work.

We are fortunate because our kid has an insatiable desire to learn and is extremely driven. Since both his parents are techies, he sees devices as learning aids, as well as entertainment. He has a lot of patience when he wants to learn, and can focus on pouring his energy into a task when he puts his mind to it. At the time, he was frustrated because he couldn’t read, and he wanted to improve his music skills by working with me. We felt we would build on what he had been learning already, and branch out as he needed.

To start our home school, I researched and bought prep-free lesson plans for a month of kindergarten level activities. I read about how to get buy-in from your child by having them take an active role in homeschooling. We worked together on naming our school, we made a logo for it and I printed a poster for him. We talked about what he liked and didn’t like in school. We talked about learning goals, and setting up stations for learning in the house. I worked through the weekly overview of the lesson plans, and shared them with him. The first day we started by playing a learning song he chose to help us start the day. Then, we looked at the calendar and talked about today’s date, and shared our feelings.

At first, things went reasonably well. I found that 30 minutes of time in a lesson plan designed for a kindergarten class could take about five minutes for the two of us. Other times, if he was really into a topic, we might run long, throwing off our whole schedule. I didn’t want to fall behind, but I also felt that since we were essentially starting kindergarten materials early in the year (March instead of September), we could spread out the work. The hope was that in the fall he would return to in-person learning, and that anything we did at home would be preparation for that. However, I like plans and schedules, and it bothered me that we weren’t able to follow the plan. When a lesson ran short, kiddo suggested that we just take a break for the remainder of the time, then move to the next topic at the time in the plan. I decided to try, but quickly realized transitioning back to learning mode from break mode was tricky. It could be fraught with conflict.

On the other hand, if we stayed in learning mode for most of the morning, we were happier and felt more productive. Instead of breaks, I decided to revamp the lessons. We settled on a 15 minute format for lessons, rather than the 30-60 minutes in the lesson plan. It looked something like this:

  • Introduce the topic
  • Explain and teach the topic with a working example
  • Turn the topic over to the student
  • Once they are comfortable with the exercise and are finished with it, summarize and move on

One-on-one, this could take anywhere from five to fifteen minutes. It also seemed to work extremely well. Instead of free breaks in between topics, I could adjust the schedule, front-loading it for the morning, which matches kiddo’s energy. In the afternoons, I would catch up on software work, and, due to my health, I would also need to rest. Instead of leaving him to his own devices (which would often be non-stop YouTube kids, or working on a play project), I downloaded some educational apps for him to use. As his energy levels for learning waned, usually mid-afternoon, I left him completely unsupervised to do what he wanted. Surprisingly, he would obsess over YouTube kids for days on end, watching what parents would call “junk,” but then he would come up with learning goals and projects and all kinds of creative things to do on his own.

He would find an interest, ask to learn about it, and we would search out resources for him to consume, or help him set up art projects or experiments. Nice! We dialed it in, and figured out what worked for us. I used a modified schedule with a no-prep lesson plan that covered all the major topics, and we spent time bringing toys and books into his math and literacy work. When it seemed like he was just going to wile away the hours on something unproductive, he would get an idea and work to learn something new on his own.

Then one day, he literally flipped the table.

When it was time for learning, he refuses. We would argue, we would lash out at each other, and one day while working on some math exercises he had previously enjoyed, he tipped his craft table over. After that, each morning, and at every subject change in the schedule, instead of participating, he refused. He would sit and refuse to talk, participate or do anything.

After a few days of trying everything I could possibly think of, and consulting parenting books, online resources and chatting with other parents, I left him to his own devices for two weeks. In the meantime, I started to retool.

Feelings Matter for Learning

I knew I needed to approach things differently and get him to feel safe and comfortable learning again. The trouble is, a five year-old can rarely tell you what’s wrong with your approach or why they have big feelings. Furthermore, I am Gen X, and our learning approach was about being left to our own devices, lots of memorization in school, strict discipline and tough love. School was school, it wasn’t necessarily fun, but you did it to get where you needed to go. We rarely talked about feelings, and when we did, we often treated it as a big joke.

To figure out what would work for my son required a radical departure from what I thought learning should look like, and I didn’t have the option of buying and implementing zero-prep lesson plans anymore. I also had to spend a lot of time working on emotional regulation. First of all, I had to examine myself and my emotions, and I read a lot of Big Life Journal and Growth Mindset materials. I bought some packages with activities for kiddos, and instead of starting our typical schedule, I started with dealing with our emotions.

The first thing I changed was to start the day differently. We focused on emotional regulation first and got ourselves in the right mindset for learning. I found a couple of simple picture books about emotions, and we would start by reading them, then pointing to the color or the picture that best described the emotion we were feeling. If the emotion was negative, we would go outside and be active for 15 minutes. He’d blow off some steam, and nine times out of ten, start to feel positive. Linking his movement to his positive thoughts was an important observation that I return to, over and over.

When his emotions were positive, I would introduce some of the exercises from our lesson plan. But instead of trying to cover materials and make sure we got all the work done, I started to watch my son very closely. At what point would a positive emotion change, and what were we doing that caused that change? The first thing I noticed that could flip him from feeling good to starting to withdraw or feeling frustrated and angry was Math. He could go from smiling and chatting to quiet and withdrawn in an instant. If I could get him out of the situation and get him moving, we got back on track.

What was the trigger to go from positive to negative? At first, I thought it was just resistance to any sort of formal learning with a parent, which is normal. However, the negative reactions didn’t fit a pattern. They could come out of nowhere, and I realized that the feelings might have been brewing for minutes or hours before they would emerge. I needed to be much more aware and observe, and do “feelings temperature checks” often.

I noticed that once we went from theory to working through an example, any of the “school math” activities we worked on were affecting him negatively. For example, we were working on counting Hot Wheels cars, and then doing very simple arithmetic on a worksheet. He would start out happy, but while doing the math on the worksheet, his entire body would tense up. He’d go quiet and would be full of tension. Conversely, when he watched Jack Carson YouTube videos with math songs, he would move and dance and have fun. Clearly, I needed more of the latter, and less of the former in his learning. He would watch Numberblocks on TV and binge watch for hours, loving every minute of it. Then, when I tried to apply what he was learning from watching to a traditional math exercise, I wrecked it.

He was learning and really enjoying math, but not the way I was trying to teach it. I was taught math with memorization and figuring out equations and formulas, so I wasn’t sure how to approach it with my son.

Learning how to teach mathematics in a way that fit his energy and emotions was my next challenge.

(to be continued…)

I SLICED UP FUN Mobile Testing Infographic

Twelve years on since I created and shared the mobile testing mnemonic I SLICED UP FUN, I see that people are still using it and finding it valuable. I still use it myself on projects, so I decided to create an infographic to make it more shareable.

I call this a mnemonic because it is a memory aid to help me with my work. A catchy phrase helps me remember everything I need to think about to be thorough when testing mobile apps. Sometimes these are called heuristics, or listicles. Whatever you want to call it, it’s a helpful thinking framework to help quickly generate lots of useful testing ideas.

I SLICED UP FUN is a testing framework for mobile apps, but I use it for more than testing. As a product manager I use it in a generative or creative way as well, not only to help evaluate an existing app design, but to create something new.

If you haven’t used a thinking framework like this before, it’s quite simple to use. Read each section, and determine which ones apply to your product. If a section doesn’t apply, skip it and move to the next. Once you have a list that is applicable to your work, use each item in the list to generate ideas for that category. Once you have a few relevant ideas under that section, move to the next. Then review what you have, and see if there are gaps. Whenever you’re able, include other people to help you generate more and better ideas.

Once you have generated enough ideas, put them into action, whether it is testing, design, or other work you need to do.

You can download the infographic here:
ISLICEDUPFUN mobile testing infographic

Load Testing Your Web Infrastructure: Please Be Careful. Part 4

Earlier, we looked at different ways that load testing can go wrong, if you aren’t informed, or if you don’t know what you’re doing. In part 1, we talked about a well meaning person who inadvertently created meaningless tests. In part 2, we saw the disastrous effects of someone with a little knowledge creating a mess. In part 3, we read about what can happen to a network if you unleash load tests while other people are working. In this section, we will talk a bit about some of the underlying math we need to use with load and performance testing. (On second thought, “underlying” is a bit misleading as a term, it is actually foundational, but it’s also lots of fun. It’s fun, even for math phobics, as long as you get help from time-to-time.)

NOTE: I am simplifying the math descriptions here for brevity. If you are a stats expert, please don’t be offended by my glossing over the details. The point here is to provide a basic amount of information so people get the gist of it.

What? We Need Math?

It’s one thing to generate load and point out potential issues, but the real key to performance and load testing is an understanding of probability and statistics. A lot of problems are uncovered through basic statistical analysis, and reports on this testing are also used to help with forecasting, service commitments and purchase decisions. Communicating anything useful and actionable about performance requires stats and probability knowledge and skill. It’s important to highlight that generating load and successfully taxing a test system is the easy part of load and performance testing. The hard part, and the time consuming part is to figure out what the results data is telling us, or not telling us. This requires a working knowledge of statistics, including:

  • Averages
  • Means, Medians, Modes
  • Standard deviation
  • Confidence intervals
  • Distribution types: normal vs uniform
  • Statistical significance, equivalence, and outliers
  • Percentiles
  • Probability

It’s also important to have a good knowledge of elementary math:

  • Addition and Multiplication
  • Exponentiation
  • Combinatorics

You don’t need deep expertise in these concepts, but a working knowledge is important, as well as the ability to work with these concepts in popular productivity or math tools.

It’s one thing to manage the math, it is quite another to communicate what the math means to stakeholders clearly, honestly, and with context. It’s also important to be able to explain the limitations of what your math work has revealed.

While I’m not an expert in probability and statistics, I had worked at conferences and workshops with performance testing luminaries Scott Barber and Ben Simo. I once spent hours in a conference hotel lounge with Ben Simo as he dumped game pieces on the table and would ask me to observe and describe what I saw. Little did I know that this data visualization practice would help me track down a nasty performance bug months later. I also took online courses, attended other workshops and talks, and tried out various tools. Once I was comfortable with generating suitable levels of load, working with the numbers started to take precedence in my work.

Basic Math and Exponentiation

Performance and load testing requires dealing with large numbers, and calculating and observing the effects of addition and multiples. While this sounds simple, it can be deceptively complex.

At its simplest, generating load against a test server requires generating multiple simulated users, which in-turn requires counting and observing. For example, if you generate 10 simulated users with a testing tool, you need to observe your test environment and see what effect that has on it. Does the machine work harder? What do CPU usage, I/O and other measurable aspects look like? For most systems, ten is a small number and may not even register, so what happens if you simulate 100 users? Furthermore, can the network infrastructure you are using handle that much load, or will it limit traffic in unintended ways?

Once you are absolutely sure that yes, your 100 simulated users are exercising the test server more or less like 100 real users would exercise your production server, now you can start to add on more. What happens with the 101st user? Nothing much? Ok, let’s add more and observe. The trick here is to find the point where unintended behaviors start to occur when you add that nth user to the tests. The temptation is to think of this as a linear graph, where nth amount of load will add n amount of server utilization, but that isn’t how this tends to work. What often happens is the nth user causes a surge in server activity, which looks like a geometric graph, or a hockey stick shape effect. Adding that nth user causes I/O to go out of control, or CPU utilization to stay at 100%, or memory usage to get used up, etc. In other words, that nth test user causes the system to get overwhelmed, rather than increment resource usage the way all the previous ones did. This forces us to move from thinking about addition and multiplication, or simple product calculations, and start looking at exponentiation.

Exponentiation in simplest terms deals with the rapid increase of numbers. This can occur in distributed systems for a lot of different reasons. There can be a massive influx of users for unpredictable reasons, there can be massive increases in utilization of hardware components, there can be data that grows unbearably large quickly … the possibilities are numerous. In other words, something unexpected happens, and suddenly there are huge numbers that are impacting things, and we get called in because these rapid increases upset the status quo, making things worse. This is a complicated topic with lots of discrete math concepts, but it is fun and rewarding to study, as long as you aren’t learning during a production outage.

Even simple product based calculations can be tricky, especially when small numbers can lead to large numbers. Without some thought and analysis, this can lead to poor results. Our brains struggle with large numbers (hence the need to create computers in the first place), and our shorthand for dealing with them can get us in trouble.

How many servers do we need??!??!??!!

One project I worked on required a backend overhaul due to the addition of a suite of mobile apps. The mobile apps used the existing server infrastructure differently than the legacy suite of web apps, and there were some nasty load-related surprises. Trouble was, these surprises were major bugs that required architectural changes in the code base, as well as the server hardware. There was little appetite to address those issues due to cost, and politics, so they were deferred for a later release. In the short term, that meant that they had to severely curtail the estimates of simultaneous users per server with the addition of mobile app usage. (Note, when I say severe, I mean severe, as in a factor of 10 reduction of users.) The thinking was to get a couple of friendly existing customers to take on the mobile app product as beta testers, and then slowly roll on more organizations as the existing code base and infrastructure was updated. Trouble was, some of the sales people weren’t on board with this, because they wanted the potentially lucrative sales and commissions for that now, not months in the future. One salesperson returned from a trip with a friendly, major customer, who had signed up for an early release of our mobile app suite. There was great rejoicing. However …

One of the most important things I do when I take on performance and load testing projects is to read all the published claims about the system. That includes the README files, the release notes, website and other pubs, blog posts, and most importantly, any contracts with user and performance commitments and SLAs (service level agreements.) I asked for the contract that the sales people had signed with the customer, and I was horrified. They agreed to an enormous number of licensed users, starting modestly, but increasing at 3 month intervals over two years. The numbers didn’t look too bad at a glance, but when you factored in that they committed to doubling, tripling, quadrupling, etc over time, it was cause for concern. The lead architect and I spent a few minutes calculating what these commitments looked like in server requirements, and the numbers were insane. If we were to support that number of users without substantial work and massive performance increases, it would require thousands of web servers to support the commitment of one customer.

Getting to the bottom of this required a bit of digging.

It turned out that the lead sales person who had signed the agreement said he had approached QA for information about how many simultaneous users we could support on the test server. He then went to IT and asked how much more powerful the production server was. Since they said it was at least 10x more powerful, he took the QA quote, and multiplied it by 10. He then massaged the numbers to increase to the extreme level to sweeten the sales offer, assuming a massive increase in performance every six months for two years. Of course when he talked to QA and IT, he did not make it clear what he needed the numbers for. We had to explain that you can’t take raw numbers that a server can sustain for a short period of time before crashing, and then multiply it and assume some sort of “half Moore’s law” for the product.

In the end, legal and senior managers had to approach the customer and try to salvage the sale. They were able to renegotiate the contract SLA into something achievable and sensible. It wasn’t pretty, and the company lost money, but they thankfully didn’t lose the customer. It could have been a serious outcome though, with lawsuits and other potentially calamitous outcomes.

Calculating and Communicating Probability and Statistics

The real fun of performance and load testing for me is in the various ways we can use math to uncover important problems. It can also get a bit messy, since we aren’t dealing in absolutes, but in likelihoods. There is some experience involved in how to manage the uncertainty, and that comes with risk. Taking some calculated risks with the math you use can help your clients greatly reduce the risk in the operations of their systems. I used to really enjoy that uncertainty, using mathematical tools, observation and background knowledge to help inform recommendations, and seeing those ideas pay off in better customer service. The only downside is that when you have in-depth work in this area, you will yell at your computer screen when you see polling data, media articles or marketing campaigns that get it wrong either purposefully to manipulate, or due to a lack of research.

What metrics can we publish?

One system I was brought in to test was updating to support a significant higher number of mobile users. They needed to publish some of their user metrics, especially within contracts that required licenses. They wanted to provide a safe number of simultaneous users for customers who were hosting their solution themselves, so they would know what to expect and plan accordingly. This is straight forward, but from a statistics perspective, it adds a lot of complication and time to our work. It is one thing to find problems to fix, and to anticipate what you need for your own systems, it is another to make commitments about that to others. For example, if you have too much traffic on your own system, you can quietly add more capacity and no one needs to know. If a customer who hosts your solution is budgeting for servers, they need to have specifics. Also, if they end up with more traffic than they can handle, you might be on the hook, determining on what claims you have made in your SLA.

Company leadership understood what I needed and were willing to provide everything, including a safe test network. What I had to do was determine safe, but enticing metrics that marketing could use to publish in advertising, and sales could use in service level agreements for contracts. The key was, how many simultaneous users could they safely advertise, and commit to supporting legally? The way forward with this task involved a lot of simulation, and a lot of math.

I started by analyzing their legacy product and their website traffic metrics. Unfortunately, the data seemed to be off somehow. When I asked for more information, it turned out that the data I wanted was from two different sources. To make up for that, IT had been asked to add the two datasets together, and divide by two, providing a sort of average. Unfortunately, this isn’t the way to approach this kind of data. When you are dealing with two separate, but related sets of data, it is sometimes called bivariate data. The reason for this was a bit complicated, but imagine that you could get a dataset for web browsers only, and then a dataset for operating systems only. You can use some deduction on this data to get a better sense of the reality of the metrics. For example, if you are seeing lots of Safari browsers, then you know you are dealing with Apple devices only. But if you are seeing Chrome browsers, they will be Android devices, but can also be Apple and other operating system providers. The “averaged” data provided earlier skewed the data in unintended ways because it didn’t account for those proportions.

To cope with the bivariate data, I reviewed Chi-Square analysis from university statistics, and read up on how to analyze bivariate data accurately. I use spreadsheets a lot, so I found some youtube videos on built in analysis I could use there. Fortunately, while I was struggling with my calculations, a programmer who had worked with complex statistical systems was sent my way. He happily took over the task and used a more suitable approach. The numbers he generated looked much more realistic. With a bit of research we were able to find the proportions of mobile operating systems and web browsers, and our analysis revealed something similar in these metrics.

Phew. Our first math problem was out of the way. However, this had implications for our testing. We had to repeat certain tests to increase our confidence in our analysis. I’m simplifying for the sake of brevity here, but essentially, we needed to figure out a realistic sample size, and calculate our margin of error, or confidence interval. It got a bit complex, and meant we had to have a production snapshot available for a few days and did nothing but re-run subsets of our load tests on it, and analyzed results based on our prior calculations.

Next, we analyzed the new system that would support much more mobile traffic. What might change now that we had better mobile support? Would the proportions of OS/web browser remain the same, only increase in amounts, or would traffic behaviour change completely? Since most people like to use their mobile devices first, we felt that it could have a much larger impact than just increasing the same traffic as the legacy system. The behaviour and type of traffic could change significantly. This was a prediction, or a hypothesis, and we needed to research published metrics of mobile usage when web sites became more mobile friendly to help bolster that prediction.

While we were researching and adapting our tests to better reflect production data, I was extremely fortunate to be on-site during a system outage. I was able to view errors, request snapshots of server logs, server utilization and other metrics, and anything related to data. What are queues doing, are there problematic processes, tables filling up, etc. Also, we were able to gather hardware and network infrastructure information. After the initial problem solving to get the system back up, failure point analysis and bug reports, we were able to pour over the data to get a picture of the weak points in the existing system. This also required some math, since server utilization and other metrics have different formulas. One type of hardware might use one set of metrics, while another might use something that sounds similar, but uses different calculations. In other words, a “one” might be a great measure for one type, while another might use a percentage, like “97% utilization”. Furthermore, “97% utilization” might be a good metric for one service, but a red flag for server CPU usage. Furthermore, monitoring a web server vs monitoring an RDBMS vs network activity can be very different. Also, different applications can behave differently, utilizing different infrastructure and services depending on their unique needs and client load. Context and an understanding of what tools to use and what the metrics mean is vital.

We identified problem areas in the existing system, and then created conditions in the test environment to reproduce this at lighter levels of user load. Then, we used real mobile devices with different OS and web browser combinations and captured their traffic information so we could add those into our load tests. We then used simulated mobile clients to analyze the system and observed how and where the increased mobile clients would impact the servers. Next, we figured out how to artificially create some of these unique conditions in key areas of the system. For example, we created tools to eat up machine memory, or to cause database queries to slow down or even hang. We tried to determine how an influx of mobile users might use the system differently, and created tests based on typical user scenarios mobile users would be interested in. We also determined peaks, such as peak usage by number of simultaneous users, as well as peak usage with regards to system utilization. This is important, since a lot of simultaneous users reading a marketing release is easier to support than fewer users who are taxing the system using applications. From there, we got a good sense of what how the system behaved under heavier load vs. lighter load. Once we had a suite of tests that had a good mix of mobile and PC users, doing simple things and more complex things, we were able to simulate our projected system behavior, once it was released into the wild. We could also force conditions that could be problematic, so we could determine outcomes with various combinations of things going wrong on the back end. For example, what happens if an influx of mobile users all do the most taxing thing that could be done to the system, from a user workflow perspective? In other words, we were modeling expected server behavior based on both web and mobile application usage.

Finally, we worked on what areas we were going to measure. Management had asked for the greatest number of simultaneous users that the system would support, but this is a bit too vague. It is one thing to measure how many users can connect to the home page, versus how many users can use the supported apps, versus a combination of browsing, lightweight processing and apps that require heavy processing. Furthermore, while a server might be able to handle many users without crashing, if the performance is poor, people will get frustrated. Similarly, a server may handle a certain level of traffic for a period of time, and then stop performing adequately, either by slowing down considerably, hanging or crashing, etc. Or, a server may manage many multiple users, but it may become unreliable, also negatively impacting their user experience. To determine what to measure, we needed to utilize the following related testing approaches:

  • Load testing
  • Stress testing
  • Duration testing
  • Performance testing

Load testing is about generating a number of simulated users, and analyzing the system. Stress testing involves simulating enough traffic to push the server to its limits, or to failure, in order to learn limitations, what behavior to be aware of in production, etc. Duration testing involves load testing over time. Finally, performance testing is all about the measurement. It’s one thing to survive load, stress and testing over a duration, but qualitatively, how is the performance? What measures can we do to signify “good”, or “adequate”, or “poor” performance? We determined to measure average times of connections to the website, and the duration of completing the most common tasks in the mobile apps. That meant we did the typical web measure of simultaneous users and page load times, but we also timed how long it would take to do important things. That said, we needed to be wary of averaging these values too quickly, since outliers are important to find and identify the underlying cause. Once we had a reasonable sample size we performed calculations such as standard deviation in addition to spotting outliers and repeating conditions to cause them and verify when they were eliminated. For example, one issue we ran into was a nasty database table that required a lot of processing time to read, write, update, etc, and that could impact the load times at seemingly random points in user workflows. Once we found a fix, a subset of time delays on certain pages were eliminated.

Next, we analyzed mean, median and mode for each of our measurement points. Mode is one of my favorites for analysis, because it shows the frequency of a result, which can look different when graphed than a mean or median. A mode can show a cluster points at unexpected parts of a graph, which are a sign that there is a performance problem that needs to be addressed. Once averages of our data are calculated, based on sample sizes that are sufficient, I then use one of my secret weapons: percentiles. Percentiles can be used in several ways with performance testing. A percentile takes a portion of the results, which you can then analyze as a subset of your full set of data. For example, with the 90th percentile, you eliminate the top ten percent of your result set, and look at the remaining 90%. I have found a lot of performance issues in systems using percentiles to analyze and visualize data that weren’t apparent when using the full data set. This works because the top results can skew the overall results, pulling the graph in an area beyond the mode, for example. There are several ways you can use percentile to find patterns and problems that are shown in test data, but this is one I use a lot to troubleshoot. I often use the 80th, 85th and 90th percentiles in various ways to find unexpected results in the data. Those three work really well for me to find problems that get flattened out when using 100th. Percentiles are used in other ways in performance testing, but this is a potent analysis tool when you are finding problems.

Once the system was tuned, anomalies discovered and reduced, and the response times are fitting in a normal distribution that coincides with mean, median, mode, etc. then we are ready to measure and communicate metrics. First, we need to create a sample set of test results that is reasonably statistically significant. We don’t necessarily need to have a great deal of rigour with these calculations (such as statistical significance), but we need to run the tests enough times to have confidence in them. For example, running the tests once is not enough for a sample set of data. On your project, running them 100 times with the same build, the same equipment and conditions, etc. might be large enough. Or, you may need to run them a thousand times. In general, the larger the sample size, the better, but diminishing returns can kick in too. This requires some experience and judgment. Other projects may budget for the time and expense to do an auditable, full set of statistical calculations. I will use percentile here again, but rather than using it to look for problems, I am using it to assess the validity of the set of test results we are working with. If I find something surprising, then there is either a bug we didn’t encounter, a server misconfiguration, or a problem with the tool or test environment itself. Once we are happy with the sample set data, we can start capturing metrics and generating reports. (Reporting results could take up several blog posts to cover, so I will just touch on it.)

Determining server performance metrics that we want to commit to isn ‘t an exact science. Our test environment is rarely identical to a production environment, and no matter what we do to distribute simulated test users, etc, we aren’t completely emulating real world conditions. As a result of the statistical calculations, and analyzing the probabilities of events occurring, we tend to deal with percentages. “We guarantee a 99% up time” is a common one we see in marketing materials. They don’t say “100%, because there are so many factors beyond their control that might temporarily cause down time. Server up time is a pretty simple metric to measure and communicate, whereas performance is even less exact. For example, in testing, 90% of users may experience page load times of a certain average, or falling in a certain range, 90% of the time. Furthermore, the metrics we publish to brag about versus the numbers we are legally required ot meet might look very different. For example, we may find that a certain type of server configuration is adequate for performance targets, using a certain number of users. An aggressive approach might be to publicize one particular set of data that is attractive. We reached that level once, so we will tell the world we can do it. When it comes to SLAs though, we will likely be much more conservative. In some cases, an average is determined, and then some breathing room is built in those metrics by diminishing them, just in case of some events in production that weren’t apparent in test.

Communicating and reporting results requires skill and experience. Figuring out what is useful to measure, how to accurately analyze and interpet those measurements is part of the picture, but communicating what that means, what the limitations are, and providing advice on how to proceed is much more difficult. It’s one thing to do the math, and it’s altogether another to do something useful and helpful with it.

Lies, Damned Lies and Statistics

One of the great side effects of load and performance testing is how formerly intermittent bugs start to become repeatable. This is due to high volume test automation, one of the most powerful and useful test automation approaches you can use. While it is often unintended, adding load starts to cause problems to bubble up. This is so common, I always recommend teams schedule time around their load and performance testing efforts to deal with the inevitable issues that crop up. This is a good thing, because it helps improve the overall system and the end user experience with your software. In the short term though, it can be frustrating and might threaten schedules. These problems tend to require time and effort to fix, so while testers get excited, project managers start to get nervous.

One performance testing project I worked on had a particularly nasty “unrepeatable bug.” Once in a while, a tester using one of the web apps would experience a crash. This crash would also cause the test web server to hang, requiring a manual restart. No one was able to repeat it, so it was put into the state where bugs go to get forgotten, otherwise known as: “We’ll monitor it.” One day, the QA team installed a major new build. The team was getting ready to release a new version of the software with some new features and important bug fixes included. We started to run our automated tests, and testers began to work through their daily tasks. Suddenly, there was the familiar crash, and the required server restart. We had four test servers at the time, with one dedicated to our load and performance testing, with the other three available for other testing work. The testers moved on to a new server as the frozen one was restarted, and then the bug happened again, a tester saw a crash report, and the server froze up. Now there were two. Once again, a server froze up, and the testers were all on one test server. It crashed, and so did the load testing server. “That’s odd.” At one point, we had all four test servers requiring a restart at the same time, and this was causing serious productivity issues in QA, not to mention the implications for the new release. We raised the issue with the product and project managers, and started to analyze it.

The testers all kept track of what they were doing when they saw the bug, but we quickly set that aside. There was a factor in the system that wasn’t observable through the UI that was the likely culprit. We started to monitor the servers, turned up logging to get more information, and when a crash occurred, we tried to investigate every component of the web infrastructure on that server. We used low level load testing traffic on the each of servers to cause the bug to occur even more frequently. It took a couple of days, but we realized there was a strange race condition, where two services were utilized at exactly the same time. In the previous version of the software, this happened infrequently, but now, it was happening a lot. But, at least we had a repeatable case, and with the aid of our automated tests for load testing, we could repeat it on command, within five minutes. That gave developers the opportunity to run their debugging tools and track the issue down so they could fix it.

Trouble was, the fix was not an easy one, and was extremely political. To fix the problem required some major architectural rework, and re-opened a major debate on the development team. There had been bitter disagreement on a particular direction, and the one that was chosen was not popular. Now that the unpopular architectural decision was shown to be problematic, the issue blew up. There were heated arguments, lots of negative back channel chatter, polarization over possible solution ideas. All of this caused a lot of hurt feelings and resentment on the team. Some minor server setting tweaks were proposed, and each of them helped reduce the frequency of the bug somewhat, but didn’t reduce it enough. The team now had a choice: proceed with the release as-is, delay the release to try to find a temporary fix to reduce the occurrence more, or put the release on hold until the rework could be done to remove the problem for good. I was tasked with coming up with an impact assessment to help management determine a course of action. Here is what we observed, so I recorded it:

“Intermittently, a catastrophic bug causes a web server to crash, requiring a reboot. This means that once the bug occurs, the server is not available for users until it has been restarted. It doesn’t corrupt data, but it deletes the work that the user was currently working on, so they have to start over. The user will see a crash message, and once they refresh and connect to a new server, they have to log in again, and start over. In the meantime, there are fewer servers available, which means that at times, some users are unable to connect until someone else logs off. We found that on average, one in five users who connected to the server would come across this bug. This is a high probability issue, and it affects more than just the person who triggers the crash, the server is now unavailable for anyone until there is IT intervention. It costs time and money, not to mention the extreme frustration of the users who experience this. With self-hosted equipment, there is time required by IT to go and reboot the server, often several times a day. With cloud-hosted infrastructure, moving to new servers could cause expenses to increase significantly.”

Unfortunately, the people with political power did not want to fix the problem, they wanted to release. They took my 1 in 5 occurrence metrics and reframed it. While it wasn’t technically a lie, they greatly minimized the impact of the bug. This is what they told senior management:

“There is a severe bug that QA have found a repeatable case for, but it is going to hold up the release to fix it. The bug only happens 20 percent of the time!”

They also heavily implied that it was happening in the test environment more frequently because the QA team were abusing the system to find more bugs. Technically, we were using load testing tools to generate very light levels of load, but they didn’t say that. “You know how QA are, and they are also running load testing!!!” which made it sound like it would happen more frequently in test than in production. However, we were extremely worried about how often it could occur in production, with thousands of users, instead of the 15 testers and light load we were generating in the lab. Senior management decided to move ahead with the release as it was, and take a risk on the bug not occurring at all, or occurring infrequently. Why did they do this?

A 1 in 5 chance of something occurring is quite high. So is 20%, but twenty percent sounds smaller. If you use that figure without context, and your attitude is to make it seem small and insignificant, people will generally interpret it according to how you spin it. A 1 in 5 chance of the bug occurring in production, could mean that 200 people out of the first 1000 could experience this bug. It wasn’t uncommon for client sites to have dozens or even hundreds of simultaneous users, and our servers would peak at 1000 simultaneous users at times. If you think of 200 people seeing this crash, and then many people having to log in to a new server and start over, until license or server capacity was filled, with the system being unavailable for everyone after them, it starts to look more serious. However, the political players decided to just say “It has a 20% chance of occurring.”

The product management lead approached me and asked for a second opinion. I had to tread carefully because of the political implications of what they had been told, but I explained that even a 20% chance is sky high. For a bug like this, we could risk a 0.02% (zero point zero two percent) chance. Even a 2 percent chance would result in outages that would anger our customer base. For example, if you were gambling in Vegas, you’d take a 20% all day long. Those are wonderful odds if you are gaming. To hedge their bets, I advised that they create and rehearse a roll back strategy in case the new release was as bad as we expected it to be. Thankfully, the team followed that advice, because the release was a disaster. Every client site had no access at all by mid morning, which meant that our IT and customer support teams were busy 24 hours a day, dealing with extremely angry people. The release was rolled back, and the difficult architectural change was implemented, and the bug disappeared. It was weeks of effort, but if they had decided to wait on their release, they would have been much better off than unleashing something so unstable to the public. They lost a lot of money, they lost face publicly, and they lost some customers. They also lost months of time on their product roadmaps, since everything ground to a halt to address the customer anger and problems, and then efforts were split between support and fixing the problem.

The most expensive combination were the cloud based hosting services of the system, in some cases causing a huge increase in hosting bills. When you couple a frequently occurring server outage and a wish to fix the problem quickly with an extremely easy way to add more servers, you can quickly end up over your hosting limit and incur costs. As you might imagine, there were some extremely angry customers whose IT teams fell into the “just add more” trap to try to minimize the problem.

What went wrong? Someone decided to use metrics to try to spin a narrative that was counter to reality. This happens all the time in the world! It is almost always by people who want to minimize the problems highlighted by scientific rigour, or to try to maximize public support for unpopular policy. Or it is used by people trying to sell you something. The concept lies, damned lies and statistics explains how metrics can be used to spin a narrative. It’s important to question narratives, especially if they lack context. What can go wrong? Who wins and who loses when a particular course of action is taken? Are methodologies with weaknesses and strengths explained, or are they glossed over? Is the person presenting the data a relevant authority, or are they just a good talker? What happens if you scale up the numbers (if they are small), or scale down the numbers if they are large? Does the message change? These are all important questions to ask yourself when you are shown data that is supposed to convince you of something. The math lesson here is how you communicate metrics is important. Spin can blunt a serious issue and problem minimizers can win out of they are clever, albeit dishonest, communicators.

Thoughts on product development, management, design, mobile and other topics.