Today’s SQL Saturdays post is aimed at the teachers, librarians, and tutors of our community. A few weeks ago, my employer held a “bring your kids to work” day themed “Work in Progress.” The day was broken up into intervals that included exercise and snack breaks, even a walk through our beautiful little mini-park. The thrust of the exercise, though, was to walk the 8-12 year old children through mock interviews and mock-job training. Volunteers were picked to read through the children’s resumes and interview them. A co-worker and I were picked to do on-the-job training for a group of 5 kids. The goal, I was told, would be to explain my day job and teach the kids how to do it.
I admit to being a little panicked. I’ve rarely been able to explain database administration to an adult in a way that makes sense to them. Trying to teach kids in 30 minutes how to do what I do seemed impossible. Then fellow SSCer Stefan Krzywicki suggested I do a bit of flowcharting, because lots of kids enjoy drawing. With that idea, I was off and running. After a quick kid-friendly explanation of database administration, we “programmed” burgers, pizza, and even one girl’s gymnastics class routine.
Supplies needed:
Several large sheets of paper
Lots of colored markers or pencils
Dollup of Patience
There are 5 basic shapes I used : The terminator oval, the process rectangle, the decision diamond, the preparation hexagon, and the arrow-shaped precedence constraint. (All documents are attached to this post). Rather than confuse the kids with the more complicated terminology, I called them “Start or End,” “Prep Work,” “Job,” “What’s Next,” and “The Question.”I initially started off with a PBJ (peanut butter and jelly sandwich), but the kids didn’t like PBJs. When I asked them for suggestions everyone agreed they liked burgers. So I used that to illustrate the flowchart process. We start in the kitchen. Our prep work consists of laying out the ingredients and heating the pan. Burger assembly is broken down into multiple jobs. Questions are asked about what we want on the burger, with each question leading to a yes or no decision. If the answer is yes, we do the task, then we move on to the next question. If the answer is no, we move on to the next question. We end our process by eating the burger. Here’s what the final workflow looks like.
I could have made this a lot more complicated with the number of condiments and the additional process of adding seasonings and asking how the burger should be cooked, but that’s not the point of this exercise. The point is getting them to think of something they do every day as a program that can be broken down into multiple steps and multiple decision-making points. After the burger example, the kids got their own paper and choice of markers so they could program pizzas and ice cream sundaes (I gave them the option of programming whatever food they wanted and this is what they chose). I stood over their shoulders, answered their questions, and made suggestions when they hesitated. What kind of toppings? Do you want the cheese on the pizza first or the pepperoni before the cheese? Do you have to make the ice cream first or did you get it from the store?
It’s important to let the kids make the choices about what they want to do with their programming. Telling them “it doesn’t work that way” or “you’re doing it in the wrong order” doesn’t help them. Asking them a question about the order, though, lets them think about the ramifications of their choices. “Do you want to add the ice cream to the bowl before the chocolate syrup?” is a better way of guiding them, and if they want syrup under the ice cream, let them have it in that order. I like syrup on all sides of my ice cream, so I’m not one to judge. @=)
Reminder: Kids will not always stick to the actual flowchart shapes. That is absolutely OK. The shapes aren’t important. What is important is teaching kids how to break things down into individual logical units and learn how to order those units. So encourage the creativity. And when they’re finished, let them decorate their flowchart with pictures. My group drew pictures of their completed pizzas and sundaes and one kid even drew himself eating said pizza.
After we finished that project, one girl was so excited that she wanted to do it again, but didn’t know what to draw. When I asked her what activities she enjoyed the most, she said gymnastics class. So I walked her through her routine. We started at home, the prep work was gathering her gymnastics supplies, then she drew her tasks (getting dressed, getting in the car, walking into class, warming up). We had a decision point where she decide which of three gymnastics practices she would do next (tumbling, flips, or ribbon work), and another decision point that depending on whether or not she was on a team and had to do a team practice. This chart was more complicated than the food chart because it had multiple branches, each with their own terminators. Every terminator was “home,” but her new chart looked more like a real programming workflow because home didn’t happen at the same point every time.
After we were done, the kids signed and rolled up their flowcharts to take them home. They had a great time programming their favorite things. Who knows, this experience may have influence a new generation of database administrators and programmers.
Oh, and as far as the kid-friendly explanation of database administration goes, here’s how I spun it. “You know all those treasures, coins, and equipment you can earn in a video game? Each game has a limited number. A database stores that information. My job is keeping track of what is in your inventory and how many of each item is still available in the game.”
To which the response was “What games do you work on?” ah-hem. Apparently I explained my job a little too well. They were very excited to meet a “game designer.” For the record, though, I have actually programmed games. Text-based MUSHes, though. Not video games. It’s the same difference, right?
