On Sunday, June 30th, “Computer Science vol. 2 in English: Debugging” was held in Fukuoka Growth Next.
This is the 9th installment of the class (we did 6 in 2018 and 2 in 2019). This is a special class since all teachers, supporting staff, and kids from Seattle, Kumamoto, Fukuoka, gathered together in one place. 36 kids and 38 volunteer staff participated. With parents and observers, we had more than 100 people at the venue. We also live streamed using Zoom and had 20-30 people joining online from different parts of Japan. They spent 2 hours using only English. Good job!
The videos were uploaded to Our CS in English Youtube channel and here is Youtube playlist.
Also, we created a class blog as well to show students activity. This is an upgraded version of last year’s class.
Kenji Imasaki who leads the CS in English project
Laurie Griffiths, a leading teacher in Fukuoka
Ricky Chai, an Amazon Engineer in Tokyo
Teaching Staff
Main Theme
We developed the class material with the goal of enabling students to learn and experience how IT companies deal with resolving bugs. The following slide summarizes the general flow:
In this class, we worked on bug finding, bug reporting, bug triaging and bug fixing (debugging).
Out of these, the most difficult concept/process is bug triaging. Thus, we spent the most time on it and explained it in Japanese as well for extra clarification for the Japanese students.
Icebreaker
English and Programming
First, we used Wooclap to ask students how familiar they are with English and Programming. Here is the result:
The result was very surprising and we were happy to see it. Of course, we tried to use a lot of pictures and plain English for students who do not speak English well. We hope they enjoyed the class too.
We also asked how they are feeling at the beginning of the class using the Wooclap word cloud feature. With word cloud feature, you can input your opinion and/or you can like others opinion.
Show and Tell
Next, we did “Show and Tell” for students. “Show and Tell” is done in many schools in the US. We did it in the group first and later Anjyu came up to the stage and showed it to other students.
Assignments
We prepared and assigned two assignments ahead of class as practice for the students. They were simple error spotting games with a little twist. We used the What’s Wrong with these pictures? / David Coulson drawing for the class with permission.
Error classification by types
For the first assignment, students were asked to circle errors by type as shown in the following activity
Error classification activity 1 (you can click the image to use this activity in your Seesaw class)
Error classification by incorrectness/unrealisticness
For the second assignment, students were asked to identify and circle three big errors in terms of degree of incorrectness/unrealisticness. This is another way of classifying errors. We told students these might be subjective; but, that it’s OK. Often times, not everyone agrees on how severe a certain bug is.
Error classification activity 2 (you can click the image to use this activity in your Seesaw class)
Introduction
Why do we call a computer error a bug?
After talking about the homework, we dived into the reason why a program error is called a bug. We explained that it was because of a moth that flew into a computer and caused an issue, and thus Grace Hopper named the computer error a “bug”. Grace Hopper is one of the first pioneers in computer programming and we have an annual event called the Grace Hopper conference to celebrate women in computing.
Buggy software
We showed several examples of buggy software(meaning software with a lot of bugs). One of the examples we showed was Super Mario. Sometimes game developers take advantage of them to sneak in easter eggs for its players.
Bug types
In general, computer bugs can be classified into
- Functional bugs
- Security bugs
- Performance bugs
- Stress/load bugs
In a similar way as we did in assignment 1, we can classify the bugs based on these. This classification is used in the bug triage process that will be explained later.
Division by zero is functional bug example. The following slide visually represents it:
Bug severity
Next, we moved on to the severity of bugs (from 1 being the most severe to 5 being the least severe). We used examples from the homework and also talked about bugs that were found in real software. For example, you cannot launch an app (functional bug) or your credential is stolen (security bug). Most likely, these bugs should have severity 1.
Bug life cycle
Again, here is the bug life cycle that can be seen at IT companies. We will explain each step.
Finding bugs
We told students that these are examples of techniques to find bugs:
- Pay attention to details
- Try edge/boundary cases
- Do something very fast (for example, mouse clicking)
Reporting Bug
Finding a bug is not enough since you have to tell others that you found a bug. So, reporting is important.
We showed an example of a bug report using the homework drawing.
In general, the bug report mainly consists of:
- Reporter’s name
- Summary/Title
- URL
- Screenshot
- Platform
- Browser
- Steps to reproduce
- Actual Result
- Expected Result
- Severity
- Logs
- Software versions (some of the bugs start happening from a particular version)
We worked on a Seesaw activity to submit bug reports.
Here is an example student submission by Angelica
Great work, Angelica
We also asked students to look at a real website and file a bug report using google forms using the following activity.
We have a total of 15 bug submissions in the spreadsheet. You may want to triage those that will run in the next step.
We took brief break.
Bug Triage
After a short break, we moved on to the next step in the bug life cycle, bug triage. The word triage (French) refers to the process of determining the priority of patients’ treatments based on the severity of their condition in the ER. The bug triage process is similar; but, it deals with bugs instead of patients. It also looks at clustered customer feedback and bugs found internally.
To explain it, we pretend, we are in a hospital. Ricky is a doctor, and the following patients come: Laurie has a cut on his finger, Kenji has a broken leg, and Akane has itchy skin. Which patient should Ricky treat first?
Again, we used examples from the homework to show the process.
As shown in the slide, the important steps in bug triaging are:
- Combine duplicate bug reports into one -> (De-duping)
- Add/modify severity and sort them from 1 to 5
- 1 being most severe, 5 being least severe
- Rewrite the bug title/description so it is easier to understand the problem and solve
Then, we moved on to the Seesaw activity. In this Seesaw activity, you have become a project manager of a game company where you bug triage.
This is one of our students, Hikaru’s, answer:
Good job, Hikaru. You sorted out bugs and de-dupped bugs.
Bugfix (Debugging)
Next, we moved on to debugging. Here we used Code.org’s paper and graph programming
The first task was to understand graph paper programming. It is very easy since it only has 5 operations.
5 operations – from code.org website
The following is a simple example:
Follow the program
In this section, students were asked to draw the resulting graph from the given sequences..
Here are the Seesaw Activities (Activity 1, Activity 2, Activity 3, Activity 4).
This was done utilizing Seesaw’s new drawing feature.
Make your program
Using Seesaw, we gave students 3 figures and asked them to come up with a sequence of operations that would result in the given figures.
Here are the Seesaw activities (Activity 1, Activity 2, Activity 3)
Debug the program
Now given a program and a graph, your job is to find the bug in the program.
Here are the Seesaw activities (Activity 1, Activity 2, Activity 3)
A common error made was that many students wrote a new correct program from scratch rather than fixing the bug to make it correct. Finding the root cause of a bug is often just as important as fixing the bug! An example is shown below:
^ This program was not fixed efficiently because the student wrote a whole new program to get the correct behavior
^This program was fixed efficiently because the student fixed the one step that was wrong (the bug).
Another example is :
We may change the student’s template format in the next class to let students fix the bug (rather than writing their own program).
Great work!
Kahoot
As always, we have Kahoot time.
Here are the Kahoot final results.
We were surprised by the results. They did a pretty good job!
We gave out prizes (Starbucks water bottles) for the top 3 students.
Closing statement
We congratulate students on working hard for activities and we hope they will continue learning CS, preferably in English. No matter what, though, we hope this class gave students the opportunity to start learning CS.
Class Evaluation
Here are the class evaluation results. In general, kids and parents are satisfied with the results
Kids comments
Good
- Kahoot Quiz was so much fun
- I do not understand English; but, the teaching assistant helped me to understand
- The teachers and mentors at our table were really helpful and nice.
- I enjoyed graph paper programming
- I enjoyed solving question with mentor
Improvement
- We need easier quiz question
- Please increase the number of games
- I wish the quiz questions are in Japanese
- I wish we have a translator
Comments
- A little bit difficult
- I made friends
- I really enjoyed it
- The content we did was fun!!
- I enjoyed it and I would like to come again
- I want to pair up with the same mentor next time.
Parents comments
Motivation to join
- Kids like programming
- Learn technology in different language setting and observe kid’s reaction
- Interested in English event and computer
- Familiarize with English and Programming
- Let kids join English class
Comments about class
- We go to Coder Dojo and I understand the goal and philosophy. Our expectation is met. I’m thankful for a lot of volunteers. I worry about the current Japanese education system based on exams. I hope mentors encourage kids to self-learn and solve problems by themselves. Please continue the class. Thank you.
- Thank you for teaching a lot of stuff that cannot be taught by us. My son enjoyed it very much. Thank you for giving such an opportunity.
- It might be difficult for our kid but he enjoyed it. It was a little bit too long. So he lost concentration. This is a rare opportunity and we experienced it.
- With this class, you can learn English and Programming. Please continue.
- I had an opportunity to talk with other parents with similar opinions. We got good influence from the team. Kids guessed the answer if he does not understand or was taught by helpers.
- IT might be difficult but it is good we are in one location since we feel better. I like snack time during the break. We also liked satellite room.