« October 2009 | Main | December 2009 »

November 30, 2009

The Take Two Approach

I was talking to a gentleman the other day who has a successful mentorship program in his line of business. I was amazed at the simplicity of his model. It started many years back when a few young fellows started coming to him with questions about what he does and how he does it. And simply by sharing the basics of his job, these men became more interested and started asking more and more questions. It finally dawned on this older gentleman that this seemed to be working out pretty well for equipping people to do the job at hand. So he developed a system of looking for people with promise and then taking two of them under his wing at one time, even if they did not overtly have the interest or background at the beginning of the relationship. But the real key was that he each pair that he was training and mentoring to make it their mission to do the same thing for two other people, thus exponentially growing the pool of applicants to work in the field.

So I got to thinking. What if the equity issues in computing were addressed in this way? People who feel passionate about the underrepresented populations could reach out and form a personal mentoring relationship with a couple of individuals, mentoring these people and supporting their explorations of computer science and then, in turn, those individuals could choose another two and so the process would be repeated over and over again? Sure, some of this happens unintentionally already. But what I am talking about here is a real focused effort- built on relationships, not internships.

I hope that maybe you will just give this suggestion a whirl. Find a couple students in your schools who you think might have potential and invite them to give computer science a try. Build a relationship with them so that they feel they can ask questions, even though they may not know anything about computer science. And let's just see where this puts us in 10 years.

Mindy Hart
CSTA Board of Directors

Posted by cstephenson at 12:41 PM | Comments (1)

November 28, 2009

Down and Dirty Programming

I read John Harrison's recent blog asking the question whether students are good problem solvers or mimics and it made me consider my latest school experiment.

Each term our principal polls the faculty to ask for elective offerings for the upcoming term. Since it is meant to be more relaxed than an academic period for students, I decided to offer an elective I called Down and Dirty Programming, specifically to prepare students to compete in programming contests. I am often unable to field a junior team because I use Scheme in my class and most contests are limited to Java, C++, and VB. I know there is much debate on the pros and cons of programming competitions themselves, however, my belief is that my students love to compete and going to an event that promotes CS and gets them pumped up is a good thing. But that's a topic for another blog.

I warned the five students (four males and one female) who signed up that the course would work very differently from my normal CS class. All good programming practices would go out the window. They grinned at the thought: no documentation needed, no design recipe! They wouldn't learn OOP, they would focus on solving problems quickly, and might get dirty doing it. I warned that it would be largely self-directed. I would give minimal instruction of basic programming concepts, enough to get them going on some practice problems, and later we would work on competition strategies.

I was curious to compare how learning occurred in the elective and in my regular Computer Science class. All five students are in my regular class too, as all juniors are required to take CS. Three of the five students had never programmed before, other than the few weeks of Scheme they have had so far this year. I gave them very brief introductions to conditionals, looping, and arrays and a short set of problems on each. The other two students had some Java experience so I set them off to do practice problems on the USACO training website.

How are students solving problems? There is an immense amount of googling for sample code and copying/pasting of code snippets to accomplish minor tasks like opening and closing a file. So, is that mimicking or is it problem solving? Since competition problems are often so unique, complex, and unrelated to real life, students have never come across problems quite like these and they must apply several different concepts to solve them. They are not mimicking, they are gathering from a set of tools to put together a solution. They must come up with the algorithm that solves the problem.

The class is incredibly collaborative, with the more seasoned programmers eagerly helping the others. The newbies compete to see who solves a problem first. However, I don't think there is necessarily a higher level of collaboration than in the regular class. The atmosphere is more relaxed than in the regular class. There is no stress on what the grade will be or whether they will complete the problem by the end of class. They are just enjoying the learning process.

The big difference between the elective and the regular CS class is the lack of directed guidance. Labs in the regular CS class are directed, methodically leading students through each concept, building upon each skill. The learning in the elective is very ad hoc, depending on what the student needs to know to accomplish a given problem. Which is the better method? Which method applies more to real-life and to how the students are going to learn new skills in the future? I am still questioning this myself and wondering what others think. I am also reflecting upon what I may bring back to my regular classes from this experience.

Karen Lang
CSTA Board of Directors

Posted by cstephenson at 01:51 PM | Comments (1)

November 25, 2009

Happy Holidays

The end of the year brings upon us the celebrations that come with the holidays. This year, we have extra reason to celebrate with an added holiday.

The week of December 7, 2009 has been declared as Computer Science Education Week. Celebrations for this week, honoring computer science education have been planned across the country. CSTA's parent organization, ACM, is preparing a Web site to provide classroom teachers with resources to use in their school's celebration. You might want to check out the "20 Things You Can Do as a Classroom Teacher" to help with your celebration. This list was compiled by John Harrison at the recent CSTA Board of Director's meeting and contains easy classroom activities that any teacher could use to promote the Computer Science Education Week.

What activities are planned at your school for this celebration? What are your ideas for activities that other classroom teachers might use to help them with their celebrations?

Let us hear from you and your great ideas.

Dave Burkhart
CSTA Board of Directors

Posted by cstephenson at 05:15 PM | Comments (1)

November 24, 2009

Real Code is Messy

Reading John Harrison's blog of November 3 got me thinking about what I am trying to teach my students in my third-semester (university) course about the development of large software systems. They seem to have a good handle on the nuts and bolts of software. Down in the weeds, one statement at a time, they do ok. It's the bigger picture that is harder to explain. I have a cartoon clipped from the newspaper years ago of a guy in a lab coat pacing back and forth in his office. In the last frame of the cartoon, "Writing," he says, "is nature's way of showing you how fuzzy your thinking is."

A large part of the business of writing software is getting one's thoughts organized, and then transforming into software those organized thoughts about the management of the information at hand. Human beings are fallible organisms, so their software objects need to be made as simple as possible to minimize the chance that mistakes will be made. We encapsulate information into instances of objects so that all the data handling for a certain "thing" is done in one place, and no code except the local code in the object can manhandle that data. Just as a naval officer expects commands to be repeated back to verify that they have been understood, we expect software modules to report both success and failure, and we organize software so that we trust no part to be "obviously correct" unless we have tested it and found it correct.

But with programs, it is indeed hard in a school setting to give students real problems. The sorts of things that can be dealt with in a class setting are naturally going to be smaller, less complicated, and designed so that most students can actually finish them. Real code is not usually like this. It's big, it's messy, and (unfortunately) it can often be as unorganized and unmaintainable as we try to teach students not to be.

Perhaps the answer is that we must bring students to the edge of failure by having them read and understand some large programs that are well written, and having them read and understand some programs that are not so well written. We hope that they will learn how to write by reading literature. We can't expect them to write software to solve large problems, but perhaps they will learn about solving problems with software by seeing how it's done and analyzing that code. If they see how others have reduced the fuzziness in their thinking as they organize software to solve a problem, perhaps they will learn how to do it themselves.

Duncan Buell
CSTA Board of Directors

Posted by cstephenson at 12:06 PM | Comments (0)

November 14, 2009

Just What is Computer Science?

Just what is computer science? Is it a science course? Is it a math course? Is it a business course?

These questions pop up more frequently now that states are requiring four years of science and math. In Texas, the AP CS A course counts as a math and is offered by both the math and business departments but this has raised questions about who can teach AP CS A. In Georgia, AP CS A is offered in the business department. Several years ago there was a move to allow only business teachers to teach it, but I asked that all certified teachers be allowed to teach it, and this was approved.

When Georgia started requiring four years of math and science, some of the faculty at Georgia Tech asked that AP CS A be allowed to count as a math or science. As of fall 2008 it was approved that AP CS A could count as a science course. However, this fall the Georgia Board of Regents removed it from the list of approved science courses, but they had not done a formal review of the course. Georgia Tech asked for a formal review of the AP CS A course and we just learned that the Board of Regents will allow the AP CS A course to count as a math or a science course!

But what is computer science, really? Some people claim that it isn't a science, even though the title includes the word science, since it isn't a study of the natural world like biology, chemistry, or physics. But inheritance, which is one of the central ideas in object-oriented programming, was first formally used in the scientific classification of plants. And, these days all of the natural sciences are becoming more and more dependent on computing. One famous biologist has said, "that biology is becoming a branch of computer science".

Some say computer science is a branch of applied math. And certainly many of the people who created and programmed early computers were mathematicians. And, many mathematicians now depend on computers in their work. Computing does include many mathematical concepts, but it also covers many other concepts such as how to design and build computer systems.

Some say it is a type of engineering. My master's degree from the University of Michigan was from the computer science and engineering department. Certainly the creation and testing of software systems includes engineering concepts. But, again computer science isn't just engineering.

Certainly computers are used in business. One reason that Wall-mart has succeeded is that it gathers sales information from all of its stores every night and uses this data to improve operations and lower costs. Nearly all businesses are dependent on computers.

I think that the real truth is that there are connections between computer science and many fields such as science, math, psychology, engineering, and business.

What do you think?

Barb Ericson
CSTA Board of Directors

Posted by cstephenson at 12:58 PM | Comments (1)

November 12, 2009

What is Computational Thinking

In the March 2006 issue of the Communications of the ACM, Jeannette Wing generated a significant response with her article on Computational Thinking. One of the significant impacts of this article was placing the phrase "Computational Thinking" into the common language (at least of academics). Reading through the article, it seems to me that Wing never directly defines this term. Having heard her give a couple of talks on her article, however, I have seen her give an actual definition of Computational Thinking. Paraphrasing from her slides, Wing has defined Computational Thinking as the process of abstraction. (Wing provides several engineering aspects of the term, but I think that "the process of abstraction" is what Wing intends Computational Thinking to be.)

As a computer scientist, this was an acceptable definition for me. While having lunch the other day with an engineer and a biologist, I shared this definition with them. Both of them hated this definition, feeling that it was too "computer science-y" of a definition, and not one off of which they could work.

Since Computational Thinking in K-12 should probably apply to other STEM (Science, Technology, Engineering, and Mathematics) disciplines, and probably to all other disciplines, any reasonable definition of Computational Thinking needs to appeal to faculty in other disciplines. I haven't yet come up with a satisfactory external definition of Computational Thinking, and wanted to get others' thoughts of a definition, one that will at least appeal to biologists, and engineers (and hopefully teachers in other disciplines as well)....

Steve Cooper
CSTA Vice-President

Posted by cstephenson at 11:31 AM | Comments (2)

November 10, 2009

Email Netiquette

Can you remember life without email and texting?

BITD B4 the EMSG, we talked, in person or on the phone, and wrote in a language that was readable. Now, most of our communication is done via email and texting. This sometimes includes a new vocabulary and a new dictionary [7, 8].

Communicating on a personal level and communicating on a professional level are two different animals. Many of us use email for professional communications, which stresses the importance of knowing proper email etiquette. I'm sure many of us have, at least once, pressed that SEND button too quickly or received an email that we had to ponder over trying to make sense of its meaning or intent. Email can be very easy to misinterpret. According to research done by Nicholas Epley (University of Chicago) and Justin Kruger (New York University) and published in the Journal of Personality and Social Psychology, there's only a 50% chance of correctly ascertaining the tone in an email message but people think they have correctly interpreted the tone 90% of the time.

People often think the tone or emotion in their messages is obvious because they hear the tone they intend in their head as they write. At the same time, those reading messages unconsciously interpret them based on their current mood, stereotypes and expectations. [5]

I found the following Tips for Writing Emails helpful (and sometimes amusing). How many of these "tips" hit home with you (either as the sender or the recipient)?

1. The subject line: The subject line is the only thing you're sure the recipient will read. "Re: re: re:" is not helpful in this regard. But neither is "Project Update." Be as specific and clear in the subject as every other part of the email [3].
2. Say it up front. What is the purpose of your email? Say it in the first line. Can the reader tell from the subject line and first sentence what you are writing about? If not, why are you insisting that they guess? [1].
3. Call to action. The number one thing that separates a memo, report, or PowerPoint from a novel is a call to action. Does your email ask the reader to do anything? If not, why are you sending it [1]?
4. Assume nothing. Let the reader know what thinking has gone on behind the scenes. And when following up, don't assume everyone remembers everything you've said. If you've got any worries that an acronym, term, or reference is going to elicit a confused moment, just explain it. Are you hiding anything from the reader unintentionally or assuming that your audience has prior information [1]? If so, clarify and explain.
5. Do the thinking. How many times have you gotten an email that says, What are your thoughts? followed by a forwarded chain of messages. That's the writer saying, I can't be bothered to explain my reasoning or what I want you to focus on. When you write, make sure you've explained what you're thinking and what you want the reader to spend time on [1].
6. Share your train of thought. If I know why you emailed me 37 spreadsheets and asked for me to combine them by Tuesday, it allows me to be part of the process rather than feel like a cog being dumped on [4].
7. Delete redundancies. Say it once. That's enough. If you're repetitive, the reader will stop reading and start skimming (Like you probably just did.)[2].
8. Use numbers and specifics instead of adverbs and adjectives. Johnnie is currently way behind schedule on major assignments, is not as clear as Johnnie's science project is 3 weeks late [2].
9. Delete off-topic material. The best emails say one thing and say it clearly. One-subject emails also make it easier for the recipient to file the message once they've taken action, something anyone who uses Outlook to manage tasks appreciates [2].
10. Delete anything written in the heat of emotion. Will this sentence show them who's been right about the project since the beginning? Yes? Cut it [2].
11. DON'T SHOUT IN EMAIL!!! don't mumble in email, either. Avoid writing your message using all upper case or all lower case [6].
12. Shorten. Remember the reader struggling to digest your message on the run. A BlackBerry or an iPhone gets about 40 words per screen. What looks short on your desktop monitor is an epic epistle on their mobile device [2].
13. Give it a day. With time, what seemed so urgent may no longer need to be said. And one less email is something everyone will thank you for [2].
14. Toss useless words. "In fact," "personally," "I think," "actually," "literally" and their like are almost always empty of meaning [3].
15. Don't BCC. Remember that no matter how you send it, email is as private as a postcard slapped to the water cooler. If someone needs to know something secretly, call them and whisper [3].
16. Format. Use bolded headings, bullet points, and numbered lists to allow the reader to scan for your main points [3].
17. Use Paragraphs. Similarly, use blank lines to separate paragraphs. You do use paragraphs, right [3]?
18. Use Spell check. Have it? Use it.
19. Look at your email address. What does it say about you? Are you a sexydude@wherever.com? or mrknowitall@wherever.edu? First initial, last name might be a better option [6].
20. Save the txt abbreviations for your friends.
Remember, you could always use the phone or snail mail. Enjoy your *$ and HAG1!

[1] 4 Tips for Writing Better Email
[2] How to Revise an Email so the People Will read It
[3] How To Revise an Email Revised
[4] Is Your Email Businesslike or Brusque?
[5] The Secret Cause of Flame Wars
[6] Email Etiquette: Why is it Important
[7] E-Mail Etiquette
[8] NetLingo List of Internet Acronyms & Text Message Jargon

* first phrase in this blog: Back in the days before the email messageā€¦
* last sentence: Enjoy your Starbucks and have a good one!

Fran Trees
CSTA Chapter Liaison

Posted by cstephenson at 02:02 PM | Comments (1)

November 05, 2009

Computer Science in Practice

Seen in the stairwell of the Purdue Student Health Center...


Robb Cutler
CSTA Past President

Posted by cstephenson at 12:28 PM | Comments (0)

November 03, 2009

Are Your Students Good Problem Solvers, or Good Mimics?

Recently the topic of Computational Thinking has risen to the forefront of discussions of what our students should learn. Ignoring the facts that computational thinking has different meanings to each of us, I think the root of the discussion focuses on our students' abilities to apply their problem solving skills to realistic problems that may or may not have identified solutions. Can your students do this? I'm not sure that many of mine can.

Many of us learn by mimicking the behavior we want to master. I learned how to play baseball by copying the throwing and batting motions my coach demonstrated until I could reliably throw the ball to a stationary teammate or hit the ball off a batting tee. But I didn't become a good baseball player until I could apply these skills in a game situation where either my target or I were in motion or I faced a real pitcher who was reluctant to throw every pitch down the center of the plate. It took real experience to master these skills and become a baseball problem solver.

Our students learn to program (a basic computer science problem solving skill) by mimicking the programs that we write to demonstrate key concepts. How do they make the transition to problem solvers? Where is their game experience? Why should we expect most of them to be more than mimics who can only solve the types of problems we have demonstrated if we never give them real problems?

These are questions we need to address. If you are tackling these issues in your classroom, then you are on the front lines of computational thinking. Share your ideas. How do you get your students to make the transition? How do you know they are on the right path? Unlike the baseball player, we don't have the luxury of tracking their batting average, fielding percentage or ERA. What are the metrics that we can identify to help measure success? How do we bring our students into the 21st century using knowledge and skills we gained in the 20th century? These questions may not have obvious answers, but they need to be asked. Help me ask them.

John Harrison
CSTA Board of Directors

Posted by cstephenson at 01:35 PM | Comments (1)