Given that politicians can have such an influence on policy that impacts computing educators, it seems important that we try to influence their actions.  The ACM recognizes this and has several sub-organizations that work on public policy.  But as an individual computing educator, it’s interesting to think about what we can do to influence policy makers.  The answer to that question will likely differ by country, but it seems like it’s worth the time and effort.

The responses led me to think about my attitude toward failure.  While it can be discouraging and disheartening to fail at something, it’s also inevitable.  It is only the most gifted of people who doesn’t experience failure on a regular basis, and those who push themselves experience it more often.  Personally, I see failure as feedback.  It’s a sign that you were doing wasn’t quite right and that you need to try something different.  The only part of failure that reflects on me as a person is my reaction to it.

Since this experience had come about in a work context, I also thought about failure and computing.  It occurred to me that my attitude about failure is particularly helpful in someone who wants to work in a computing-related field.  Problem solving, and the inevitable failure associated with it, is core to computing.  People who are successful in computing are people who handle failure on a regular basis: the program crashes, the network goes down, the algorithm has a problem, the machine dies.  Handling these situations requires a certain acceptance of failure as a natural part of the process.

But my experience teaching has let me see that students don’t tend to develop this attitude about failure until at least midway through their programs.  Students in early classes, typically programming classes, often personalize failure in ways that may not be helpful.  Yes, a student who repeatedly fails at coding probably isn’t going to be a developer, but some amount of failure is part of the process of coding and therefore part of the process of learning to code.  When I teaching CS1/2 I try to convey that failure is natural, as a way of letting the students see that they shouldn’t take their failure personally.  I’m not sure how effective I am at this.

Speaking of effectiveness, all of this led me to consider what the literature has to say about failure and computing education.  In my search I ran across two interesting articles.  In the first, Tony Clear writes about failure in the context of a capstone course, which is a situation on the opposite end of a degree program from CS1/2.  In the second, Klara Benda, Amy Bruckman, and Mark Guzdial examine failure in online courses.  There failure means lack of retention, and I particularly enjoyed their summary of the literature on retention.  It also surprised me how few articles in computing education were displayed in the ACM Digital Library when the keyword failure is provided.  It was a much more common term in the broader computing literature, which is somewhat ironic.

When I returned I read the article Viewpoint: Computer code frees us to think in new ways by Tom Armitage in the BBC.  In it he very eloquently argues that programming is as much about design as engineering, writing:

A great deal of it is much more like sculpture. Data, technology, code, as a slab of clay, to be manipulated, explored, felt between your fingers, and slowly turned into something substantive.

It’s practically the opposite of engineering. It’s an artistic discipline: beginning with sketching and exploring, and then building on those sketches slowly through iteration, watching a final structure emerge.

He then goes on to argue that everyone needs to know more than just computer literacy, because computers and code are like prostheses for people.  As he says:

The magic of these prostheses – the magic that lies at the heart of true innovation – is not necessarily just doing things faster. It is giving us the ability to think new thoughts.

The convergence of these two things in my life got me thinking about people who aren’t computer scientists, or even identify as programmers, but nevertheless would like to program.  Mark Guzdial has written extensively about this, most recently here, so I won’t rehash a lot of the ideas.  But what strikes me this time is that it’s not just computer scientists who are suggesting that learning to program is worthwhile.  Political scientists, like my sister, recognize that programming would open up new worlds for them, and they want to be a part of it.  I find that to be interesting, since real change only happens when people are ready and embrace it.  The innovation that would arise from social scientists (and artists and others) learning to program makes me excited for the future.

Yesterday I made a rare trip downtown for a work-related meeting.  Normally December is a time spent with quietly writing away in my home office since our quarter system does not have regular classes between Thanksgiving and the start of the new year.  But a technology company in Chicago is interested in recruiting students from the College of Computing and Digital Media at DePaul, and the staff member who handles employer relations likes to have a subject-matter expert with her.  I left the meeting with a lot of new information, but two pieces stand out to me: 1. Employers are desperate to hire computer science graduates and 2. technology companies are most interested in people who blend into the (somewhat unique) culture of their workplace.

I then spent today reading most of the latest issue of ACM Inroads, for a paper I’m writing on diversity in gaming.  There are many fascinating articles in that issue, but one theme stood out to me.  Computer scientists have put, and continue to put, a lot of energy into improving diversity in the field.  From college-level initiatives like those at Harvey Mudd College, to NSF-funded programs to improve access to computing among the disabled, to a transformation of the high-school curriculum, computer scientists are deeply interested in seeing women and underrepresented minorities participate at higher numbers.  The hope, of course, is that these projects and programs will succeed, resulting in a transformation of computing into a field where gender parity is within reach.  In that process and with that goal, I think that computer science is serving as a model for other technology-focused disciplines.

The interaction I had with the employer-relations staff member after our visit yesterday made me wonder if technology companies are ready for this change, should it actually occur.  She and I started discussing the need that technology companies have for employees to fit their culture, and how their culture can be very different from other industries.  In response she told me a story about a visit she paid to a large technology company based on the West Coast (that will remain anonymous for reasons about to become obvious).  A representative for this company emphasized that adapting to the culture was important, causing the DePaul staff member to ask how the representative would describe the culture.  The response: The average employee age was 26 and the culture was like a “frat house”.  (Note that this company has been around for at least 8 years, so this is not a small start-up).  I rolled my eyes when I learned this and commented that I certainly would not be recommending the company to any of my female students.  She countered that this company was particularly interested in hiring female graduates.  We noted that the lack of reflection on this situation was intriguing.

Now I understand many technology companies are encouraging of and enthusiastic about the goal of broadening diversity in computer science.  But I think it takes more than a diversity initiative, which I know that the company described above has, to make the workplace welcoming.  It particularly remains unclear to me whether technology companies are ready to deal with the changes that would come from a pipeline that begins to approach gender parity.  On the other hand, technology companies are nothing if not adaptable, so maybe they would surprise me.

I have a possible reason, one that has little to do with the interest of computing educators in computing education research.  I think it has to do with funding.  My institution, DePaul University, is relatively generous in their travel funding.  As long as I am in some way presenting at a conference, DePaul will pay my expenses.  Part of the generosity comes from the fact that “presenting” includes papers but also panel presentations, posters, and other contributions.  However, if I wish to attend a conference in which I am making no direct contribution, I must pay for it myself.  I do not believe that DePaul is unusual in the stipulation that I contribute in some way in order for expenses to be paid.  If anything DePaul is more generous than other institutions, something supported by a study a colleague and I did of institutional support for computing faculty.

What does this have to do with ICER?  Typically before someone can begin publishing in a research area, they need to attend conferences and/or workshops in that area.  He or she need to understand the research approaches, questions, and culture of the community.  However, this is not necessarily the case for the SIGCSE Symposium or ITiCSE.  There are multiple entries into that community, including posters, birds-of-a-feather sessions, and working groups, that do not require extensive previous knowledge for participation.  Someone can then attend the Symposium or ITiCSE, learn more, and be successful in larger and more complex projects and submissions.  It is not clear that this is the case for ICER.  Lightning talks come the closest to the previously mentioned items at the other conferences, but a look at the titles for the talks at ICER 2012 suggest a level of sophistication that the average computing educator may not feel ready to tackle.  This is compounded by the hint of snobbery that some computing education researchers convey when discussing contributions by their less research-oriented colleagues.

While I believe I have part of the answer to Raymond Lister’s “why,” I do not suggest to have the solution.  How is it that ICER can make it possible for computing educators with funding restrictions to attend the workshop?  Not being a part of that community (yet?), I cannot answer that question.  But perhaps Dr. Lister and others who are part of the ICER community can find a solution, assuming as I am from his article, that he and others are interested in drawing more computing educators into their fold.

We are now entering a new era for developing an exciting relationship between the print version of ACM Inroads, the new Inroads website, and the e-version of the publication. ACM designed the website as a hub for computing educators worldwide to share their experiences and expertise.

The web site is an extension of the print and the newly launched Digital Edition.  Here, readers have a forum to discuss and debate ideas and opinions on articles presented in the magazine.

The blog associated with this website should generate much discussion regarding the articles in ACM Inroads. We expect to find excerpts from published essays that incorporate some recent online reader comments. We expect bloggers to write valuable posts and disseminate useful information toward advancing computing education. The anticipated interactions and clarifications of blog posts and other site content should create an opportunity for continuous discussion. For bloggers, this is a rare opportunity to reach a global audience. Over time, these blogs should form different, and hopefully extensive, categories of discussion and should prove a valuable reference point for teachers, students, and professionals.

I take this opportunity to clarify some apparent misconceptions of ACM Inroads as follows.

• ACM Inroads is a magazine. It is not an ACM journal; nor is it a newsletter. ACM Inroads is one of eight magazines published by the Association. For example, Communications of the ACM, the flagship publication of ACM, is another such magazine.
• ACM Inroads publishes articles, not research papers.  As a magazine, articles should be concise, interesting, informative, yet substantive. Authors should write articles in a more informal, general-interest style with an appropriate number of colorful diagrams, images, and figures. If you are not yet a subscriber to the magazine, the articles and columns featured on the homepage are open to the public, and are great examples of the editorial available in each issue.
• ACM Inroads is a computing education publication. Its focus includes all areas of computing such as information systems, computer engineering, computer science, information technology, software engineering, and other related fields.  Its focus is not just computer science. The magazine encourages and seeks education-related articles from all computing areas.
• ACM Inroads submissions undergo a strict review process via Scholar One’s Manuscript Central.  Most articles such as Bits & Bytes, Standard, and Comprehensive types must pass a double blind, formal peer review scrutiny before publication.
• ACM Inroads is an ACM publication; it is not a SIG publication. The magazine is under the jurisdiction of the ACM Publications Board even though the publication derived its roots from the SIGCSE community. SIGCSE helps support the publication and it provides the magazine as a benefit to its members.

Please form discussions within the context presented above.

I take this opportunity to introduce to you Amber Settle, Blog Administrator and Administrator of the ACM Inroads website, who will be the contact person for Inroads bloggers.  We are very appreciative that Amber has taken the lead in this area.

In summary, I welcome you to the ACM Inroads website and its associated blog. Amber and I look forward to exciting comments and discussions from a global audience. We encourage potential bloggers to set the direction on a myriad of topics related to computing education in a manner that only the flexibility of an interactive website can offer. This initial post, therefore, officially launches the beginning of a productive relationship between the magazine and its online outlets for expression.

John Impagliazzo

Editor-in-Chief, ACM Inroads

acminroads@gmail.com