Tag Archives: computer science

The problem is NOT the computer

We were checking in to board the plane, and the woman at the check-in desk told me our seat assignments. “That’s not right!” I said. “We’re a family of three, traveling with a child. You cannot give us three separate seats.” The woman apologized, but said that the plane was full and she could not give us three seats – or even two seats – together. I argued and became insistent that we be given seats together, and she brought in her manager. The manager was able to do some rearranging and gave us two seats together for one parent and the child, and another seat nearby. I thanked her for accommodating us and said that the airline policy should be that families – especially with children – should always be seated together. That’s when she said it:

“The computer assigns the seats. That’s the problem.”

Before steam started coming out of my ears, I swallowed hard, counted to 10 (in binary) and then calmly and patiently explained to the woman that the problem was not the computer.

Perhaps nothing reveals the great need for Computer Science to be taught to every student in school than this very common misunderstanding. People in every job and every walk of life use computers every day. And many of them fail to understand fundamentally how computers work.

Computers do not do things magically, and they don’t operate on their own (yet). Computers do exactly what they are told by human beings, and how they accomplish those tasks is also controlled by human beings. That is called programming.

In this case, the airline (or their programmers) instructed the computer (their servers) to assign seats to passengers once they book a ticket (or when they check in or whenever). Seemingly, those instructions (program) prioritized business travelers, frequent flyers, people who checked-in early, etc. There seemed to be no provisions within the program for families or children.

The solution to the problem is very simple: adjust the program to ensure that children traveling with families are always given seats next to their parents (or at least one parent). Sure, this might interfere with frequent flyers choosing their ideal seats, but the program can be written to maximize the choices for prioritized customers without sacrificing at least two adjacent seats for every child traveling with family.

The problem does not come from the computer. The computer is only doing what it has been told to do by the airline’s programmers. The problem comes from the programmers not being told to prioritize children by the airline.

Too often people blame “the computer” when things do not go well. It’s more than just “blaming the messenger” – it shows that people really do not properly understand how computers work. It’s a mystery to them, so they can blame computers for mistakes .(And also presumably to praise computers for serendipitous good fortune – “Congratulations! The computer has selected you to be upgraded!”) If people truly understood that computers were programmed by human beings to produce the results they come up with, then they would not only be better able to explain problems but also feel empowered to fix those problems. Imagine the manager’s response if she had really understood the way computers work: “I’m sorry for the trouble. The computer system has obviously been programmed poorly to not take into account children traveling with their families. I will make a recommendation to my superiors that the program be revised so this problem doesn’t happen again.”

Aside: I know I’m whining a bit about my own situation. However, I’ve been on airplanes where air hostesses were scrambling to rearrange passengers after boarding to try to unite families who had been separated by “the computer.” It’s a problem that affects many airline customers as well as many airline employees. I could write about the dismissive treatment of passengers by airlines, but I’ll have to wait until I can do so calmly!

 

photo credit: andreas160578 from Pixabay (CC0/public domain)

Anuther kase four programing

Can you see the error in this code?
Can you spot the error in this code?

As I go from student to student, helping them debug their program, it strikes me that there’s a very simple reason why teaching programming is a help for all students. So many of them have simple typographic errors: three n’s in “running,” leaving out the n in “column,” etc. I give them some hints (often simply saying “spelling error!” suffices) and they stare at the screen intensely until, with a smile, they find the mistake. That’s when I tell them: they’re going to be so good at proofreading their work in all their classes!

There’s probably a good research question there: do students who learn to successfully program apply their proofreading and error checking skills in English and other classes? It’s something I’m going to track with my current students …meanwhile, I’ll just continue to help them develop careful spell-checking and proofreading skills.

Building games on a Saturday morning

The sixth grader stares intently at the screen, working the mouse and entering numbers on the keyboard. As the work progresses, a huge grin spreads across his face. He then pokes his friend, sitting next to him. “Hey!” he says, “Look what I can do!!”

On Saturday, about two dozen students, parents and teachers came to school to learn how to program. As part of the annual Computer Science Education Week which promotes the learning of Computer Science skills including programming, ICS held what may become the first of many Beginners’ Game Code-A-Thons. Using gaming as a hook, and emphasizing fun over strict programming protocols, two three-hour workshops were held to get younger students building games using the drag & drop block programming environment of Scratch and start older students learning Java code with the easy interface of Greenfoot. The goal was to learn enough of the program to build a game. Participants were given an opportunity to explore the program and see sample games and simulations. They were then walked through the creation of a simple game, and then given time to build their own games.

Nadia and Helen learn from Brendan

Turnout was not in huge numbers, but there was a decent cross-section of students and teachers from elementary school to high school. Several parent-child teams came in with both learning together and from each other.

Helen, the ES Art teacher was asking how to change the background to her Scratch program. “Can I show you?” her 3rd grade daughter, Nadia, asked. A big grin came over Helen’s face. “Oh, yes please!”

Seeing teachers become the taught was one of the many exciting aspects of the day. In the Greenfoot session, that aspect was completely on display. Adults – teachers, parents and the HS Principal – outnumbered students learning the system. They were eager learners, with various purposes – to learn programming, to build a game, to see what the fuss was about. The leaders of the session often found it challenging dealing with the diverse group. Particularly as they were students. Josh (9th grade) and Stephan (10th grade) ran the session with minimal input from me. As they worked to explain things clearly and keep things moving at a pace that suited most if not all, showing things in front and moving around to assist their students, both boys gained new insights into learning. Josh looked over at me at one point and said simply, “Mr Iglar, teaching is hard.” I looked at the principal and suggested we do more of this kind of event.

Was it worthwhile? You bet. Participants all enjoyed the sessions and expressed their appreciation of the students who led the workshops. Many were most appreciative of the fun prospect of building their own games, while a few were particularly interested in developing their ability to program in general.

Will we do it again? Definitely!

Instant Gratification: The Joys of Coding

I got up at 6 a.m. on Sunday morning to do some coding. I know some might think it sad, but it was a delightful hour.

I’m learning to program in Python through the Coursera course taught by a team of professors from Rice University. I know some Python, but I’m no programmer. The tasks are fairly easy but I find myself learning a lot: not just about the Python language, but also about online courses, how I learn, and the benefits of learning to program.

my stopwatch game

This morning I was finishing up a mini-project that was due at 8 a.m. It’s not a complicated program: a timer that you can turn on and off, with a game element of scoring points every time you stop it exactly on the second. Nothing Earth-shaking – I won’t be selling it as an app anytime soon! – but the process was very rewarding and illuminating.

I’d been working on the program for a couple of hours the other day, and had some frustrations. It kept blowing up on me, no matter what I did. I’d code something, run it and then the thing would wind up with a huge series of the same error message and lock up the system. I knew there was something going on with the timer in the program, but I couldn’t figure out what. I had started saving locally every version of the program, and having to open new windows (it’s a browser-based environment) and reload the code to work on it.

I then got more methodical in what I was doing and had more success without it blowing up. Eventually I got it about 75% working and shut down for the evening. This morning I got up and loaded up what I had saved, and the realization of what I had been doing wrong came to me clear as a bell: I’d been closing a window the program was drawing without resetting the program. That lock-up and series of error messages was the program shouting at me that I was doing things backwards. It’s amazing how a simple insight can come after walking away from a problem and clearing your mind. You come back fresh and look at things anew.

Now treating the interface properly, I was able to complete the other elements of the program, test them, and get everything running in proper order. The program runs, keeps score and works properly. (As long as you don’t close the pop-up window!) I submitted my assignment, feeling quite pleased.

Over my first cup of coffee of the morning, I reflected on it. I really do feel quite proud and happy about this simple little program. It’s quite amazing. The program itself is nothing to write about (you’re welcome to try it out) but I’m pleased as punch with it. Why?

I guess it’s that I faced difficulties and had to think my way through them. Something wouldn’t work right, and I’d have to figure it out. Apart from the interface blow-ups, there was the aspect of the timer counter that had to be tweaked (how do you get the minutes digit out of a counter that is in milliseconds?), figuring out how to ensure that the score wouldn’t be affected by mis-clicks, tweaking the visual interface, etc. Each time I encountered one of those I had to think it through: understand what was happening and what I had to do to change it to make it work correctly. I would change something, test it, change it again, test again – repeat until it was right.

And that process of code – test – tweak gives the same kind of feedback as you get from an addictive game: instant. You know when it’s right and you know when you’ve done something wrong. You’re rewarded with success for doing things right, and you get a failure when you do something wrong. No penalties – no bad grade – just instant feedback that it wasn’t right and you won’t get the reward until you do it correctly. Sure, it’s a bit of a Sysiphean task but so are all games – play Angry Birds for a while, why don’t you?

So I stuck at it until it worked right. And it does. I didn’t get a grade or even a score, but I got it right. And I did it myself. Can you tell I’m beaming as I write this?

Boy, this coffee tastes good this morning! OK, what’s next?