When Things Go Wrong: We Learn

This week the students in TSA (Technology Student Association) raised some money by running the concession stand at our high school basketball game.  It's fun to spend time with the students outside

of class, and also to see our athletes compete. There is time to talk about their interests and plans for the future.  It was also encouraging for me to hear that at least one other of the AP CSA students is at least considering a major in Computer Science.  I'm not quite sure why, but I always count it as a win when I hear of a student deciding to pursue a major in CS which I enjoyed and hope that these students find a rewarding career programming, as I did.  It was a good week...until Thursday when I was reminded again that we all (teachers included) have many opportunities to learn from mistakes and none of us has all of the answers.

When Things Go Wrong

On Thursday, students had a studio day and were finishing off their final labs and reviewing for the

upcoming test on ArrayList, references, and OOP.  One of the students was stuck on a lab trying to load elements into an ArrayList.  The loop he had written looked for an item in an empty list.  If the item was not found, it would be created and added to the list.  If the item was found, the counter in the item was increased.  However, since the list was empty the loop checking for the item was never executed.  I pointed this out and we decided to add an if statement before the loop and check for an empty list and then add the first item.  Problem solved!

Then we ran the code and received a ConcurrentModificationException.  I was stumped.  This was a single threaded program, multithreaded programming was not something we would be covering, so the error made no sense.  We looked at the Javadoc for the error and saw that this exception could also occur if an item in a List is changed while iterating through the List.  OK, that explained the error but not how to fix it.

We Learn

After struggling with the error for some time, I finally went back to my desk and looked at the

solution for the lab.  I had not noticed the get...() method immediately below the load...() method.  The get() method was already implemented and just waiting to be used.  After updating the code, it worked fine.  We spent some time reasoning through why the solution worked and the original code could potentially cause problems -- changing a list item while iterating through the same list could essentially pull the rug out from under yourself.

This proved to be a great learning experience for all of use.

1. We learned about the list iteration and changing list items.
2. We learned about the ConcurrentModificationException
3. My students learned that even when you have been coding for a long time, you can still run into things that stump you.
4. And I learned that although I like not looking at the solutions to the labs provided with my AP CSA curriculum, I had best do this from now on!

There is an important lesson for me -- wanting to always have the answer is not always the best way for students to learn.  A struggle is good!

Competition: Collaboration and Edge Cases

Last week I took a day off mid-week.  I had a doctor's appointment and thought that was a pretty good reason to take a day off since I have been fortunate and not been sick all year.  It's amazing how a day off can improve your outlook, give you some extra rest and let you catch up on things that have gone undone with the busy-ness of the start of a new semester.  It is also great when you come back and see a large number of Google classroom assignments were turned in.  Students made good use of the time!  The only problem was a small ding to my ego when students tell me how great the substitute was and to be sure and get the same person again.  But it is affirming knowing that students can get work done on their own without the prodding, encouragement, and reminders that I provide daily.

Competition as Collaboration

This week we firmed up our teams for the upcoming programming competition season.  Our school is sending teams to three programming competitions this year:  HP Code Wars, Colorado School of Mines programming competition and Lockheed Martin Code Quest.  The students seemed excited about it, I had considered assigning teams but decided to let the students choose their own teams.  It was interesting to watch as they discussed who would be best on a team and jockeyed for positions.  The competitions all appear to require 2-3 students per team.  And the competition is a time for students to hone their collaboration skills.

One of my favorite times as a teacher of the AP Computer Science class is after a lesson when the programming labs have been assigned.  I assign a set of 3-5 programming labs with each topic and grade these by checking off student solutions as I look at them with the students (one of the benefits of having a small class size).  I encourage the students to work together to reason through the problems and come up with solutions.  The typical scenario that I see is students diving in individually or with one other person on the problems.  Then after working for a little while, they begin to get up and walk over to another person or group to discuss what they are doing and hear what another person or pair is doing.  One thing that helps is that this group of students have been together for many years and take many classes together -- they get along well and make a high functioning team that complements each other.

This collaboration is such a valuable skill.  And I do see the programming competition as another time to learn and develop this skill.  In 26 years of working in the IT industry, I never worked individually, it was always on a team.  I have worked on small teams and large teams that were divided into sub-teams.  Some teams were local and others were remote.  Communication, collaboration, and a team that enjoys being together were keys to the high functioning teams that I was a part of.

Competition and Edge Cases

Another benefit that I see coming from the competitions, is developing in students more complete thinking about edge cases.  It seems that most or all of the problems of the competition provide a simple test case that will verify that your code works for a default scenario without any exceptions or error cases -- the "happy path".  Then the judging inputs will test out various edge cases.  This causes students to start to think about and anticipate the exceptions and to make sure that their code works in all cases.

Now that it is the second semester of AP CSA, the coding problems are becoming more challenging and it is easy to create a program that works for some but not all test cases for a programming lab.  Designing these test cases can be challenging for young coders (and old coders!), and the idea of a test-driven design is important as I looked at some of the TDD research around this a couple of weeks ago.

I am not a competitive person by nature, so the whole idea of going to a competition to beat other teams is not particularly high on my list of things I want to instill in the students.  However, I am excited to see them develop better collaboration skills and thinking around edge cases.  I hope we are able to complete lots of the challenges in the competitions!

Image from pexels.com

Learn, Practice, Improve

Last night I went to our school's performance of "Little Shop of Horrors".  It was so fun to see some of my students in a different light.  I was also impressed by the performance and the talent of these

students -- I have some very gifted students!  As teachers, we see students in the classroom on a daily basis with their struggles and successes with the material we teach.  Last night was a great opportunity to see students shine in a different way.  They took a lot of time after school and on weekends to learn their lines and the music, practice over and over, and improve until they have a performance to be proud of.  And those themes of learning, practicing, and improving is the topic for the week,  But I am reminded that we are all so much more than what we see in the classroom.

Learn, Practice, Improve

We have learned the basics of Python in Exploring Computer Science -- input(), print(), int(), float(), explored the math module and I was very pleased with the speed that we were moving through the material and hopeful that this year we would be able to get further in the language than last year.  My typical approach to learning is to code together with the students and talk about the concepts and the code as we write a program that has lots of starter comments and we fill in the code as our notes.

The practice part of each unit is to complete a set of step by step instructions included with snakify.org and then either complete projects in Snakify or complete projects that I have come up with for the students.  These projects are all the same and students can and are encouraged to work together.  After listening to @teachingpython podcast by Sean Tibor (@smtibor) and Kelly Paredes (@kellypared), I have started to do 5-minute challenges to start each day with a 3-5 line program that the students need to write and then we review together.

Finally, each student completes some type of independent project that lets them be a bit creative but also shows that they can complete an assignment using these basic concepts.

How much practice is enough

I was ready to quiz over the basic material and move on.  Then on Friday, I had the students complete a 5-minute challenge of a four line program which included importing the math module, ask the user to enter a radius, calculate the circumference of a circle and display a message with the result.  With one of the two sections of ECS, I spent over 15 minutes on the 5-minute challenge.  Thank you @teachingpython!  These 5-minute challenges are a valuable formative assessment, and very quickly told me that I need to have some more review before we move on.

I am creating some additional review programs for the students to complete.  But it does go to show me the importance of these formative assessments and that from year to year and even from one section to another additional practice may be required.  And just like the Little Shop of Horrors, once the students have learned, and practiced they can improve their skills and perhaps learn something new that may become a new interest just like theater!

Image from pexels.com

Code Testing as a Teaching Method ... and THE EGG

On Friday, the students in Exploring Computer Science were working on a "Studio Day" (a term I borrowed from our art teachers to replace work day), I was circulating through the classroom, helping students with questions, encouraging those that needed a little push, and reminding some students to get back to work and

No these are not the eggs that broke the internet!

crank some code.  As I approached one group of students, a picture of an egg flashed from the screen and the code was back.  I encouraged the group and moved on.  I thought that was an odd thing to have on the screen -- usually, it is cars, clothes/shoes, or makeup that are more popular than me and not an egg!

Over the weekend I learned about the egg that broke the internet, and how a picture of an egg became more popular and had more likes on Instagram than a picture from Kylie Jenner.  I enjoy seeing what is popular with students and why.  Voting up a picture of an egg seems to be one of those things that students do, just to have fun.  But I also think it shows them that they can have power with their vote, and I hope that their enthusiasm with voting in Instagram to change things carries through to adulthood and that they value the importance of their vote and the power it has.  No, this blog is not turning political -- that vote can be left, right or center -- but our votes do have power!  And in the end, a very important purpose of the school system is to educate our citizens.

Code Testing:  Education Research

On Friday, I had a conference call with the Career and Technical Education (CTE) Advisory Committee for our software engineering program at Pinnacle.  We had a new member join, so I had everyone introduce themselves and as I again heard Anita Wall introduce her role at IBM working with companies and their Software Quality and Assessment, it reminded me about the importance of testing and that this was an area that I was not emphasizing with my AP Computer Science A students.  So I did a little digging over the weekend.  I read an interesting education research article by a set of professors (Edwards, Shams, Cogwell, and Senkbeil) from Virginia Tech University:  Running Student Tests Against Each Others' Code: New Life for an Old "Gimmick".   And a second article by Edwards, Using Test-Driven Development in the Classroom.

The article discussed the importance of making sure that students write test cases for the code they write and that these test cases have good/complete code coverage.  The article begins by suggesting that students test their code with the test cases that all other students have written.  This is a powerful idea in that all students get to look at each others' code as well as the test cases that others have written.  It not only expands their thinking about the code, but it also expands their thinking about what makes a good test case.

The authors also discussed the value of using a tool such as Web-CAT to show students what the code coverage of their test cases is.  The tool can be used for grading but it can also be used to show students how well their test cases actually test their code.  That is a bit more than I need, so I plan to take a little time to show the students EclEmma and what a code coverage tool looks like.  The authors also discussed the difficulties doing something like testing other students code with their Runner classes if students do not use the same method signatures or if solutions are only partially implemented and do not compile.

Implementing the Research in the Classroom

I am using the A+ Curriculum for the APCS A class and am very happy with it.  With all of the Java classes my students write for their assignments, there is always a set of starter code for the class and a separate Runner for executing and testing the class.  Some of the assignments specify a complete set of test cases that must be included in the runner and other assignments only provide one test case and direct students to add more test cases.

The next unit we start digging into what reference variables are, although we have been using them for quite some time.  We will look at reference variables and arrays of references.  The code students will be writing is becoming more complex and looking at what constitutes a good unit test of the code becomes increasingly important.  I plan to initially have students work with partners and have each student write the code and a set of tests for the code.  Then they can exchange classes and test each others' code.  Because there is a set of starter code for each assignment in A+.  And the start code includes class declarations and method signatures, students will have the same starting point.  Unless they go in and change method signatures (which does happen sometimes), all students should be able to test each others' code.

Along with that, I will have students setup EclEmma to have them look at code coverage.  The discussion that needs to accompany it will be the difference between code coverage (each line of code is executed) and testing edge cases (what happens with an array of zero elements, one element, repeating elements, etc.).  While testing and code coverage don't seem to be topics that are heavily covered in the AP curriculum, it does seem worthwhile to expose students to these practices.  Testing is a good thing -- even if it is not as popular as THE EGG.

Photo from pexels.com