Jared Polis speaks on behalf of CS Education

YouTube Video

Microsoft’s top developers prefer old-school coding methods

While visual programming can be easier to learn and can help make developers more productive, it’s also “easier to delude yourself,” said Butler Lampson, a technical fellow at Microsoft. For instance, “no one can ever tell you what a UML diagram means.”

via Microsoft’s top developers prefer old-school coding methods.

An interesting article about a panel of Microsoft distinguished engineers mostly whumping on “visual programming,” which is never defined, and seems to mean everything from drawing buttons in GUI layout to drag-and-drop programming.  Maybe the engineers also said positive things about visual programming, but the author decided to only emphasize the negative.

Butler Lampson had the most enlightened comments (in the sense of being more balanced than most of the others).  The above does reflect what we see in the research literature.  It may be that visual programming is easier to get started with (see Hundhausen’s TOCHI article), but it’s no easier to understand or debug (as Petre, Green, and Moher showed in their studies).  Having taught UML for years, I do appreciate his comment that “no one can ever tell you what a UML diagram means.”  The interesting psychological question for me is, why do we “delude ourselves” (as Lampson puts it)?  Why do we believe that visual programming is a silver bullet?  Maybe because there is a better way there, but we haven’t found it yet?  Or is it an illusion?

 

 

Are some people suited for CS1, and others not?

The Psychology of Programming Interest Group (PPIG) has some of the best thinkers around who struggle to understand how people think about programming.  A recent thread asked the question whether programming could ever be “intuitive,” and how would one measure that.  A side thread started: Aren’t the low success rates in CS1 a sign of non-intuitiveness?  I replied to that thread, and am sharing it here (anonymized):
>> Clearly programming _isn’t_ intuitive for most people, but
>> people who are _now_ programmers often feel strongly that it is.
>> Why?  Is there something we can use to reduce the CS1 failure rate?
>
> You reduce the failure rate by not letting in the people who are there by
> mistake in the first place. How you detect these is a different issue. I can
> assure you I have spent hours on the phone as an admissions tutor trying to
> dissuade people from doing computing courses when they were adamant they
> wanted to do them and equally clearly entirely unsuited to them (and some of
> these were highly qualified too). People don’t take Physics courses if they
> have had no experience of physics (other than living in the world of course,
> though probably don’t realise that is physics), but they turn up in droves for
> computing courses with no experience.

Isn’t there an implication in your statement above that our ability
to teach computing is as good as it’s going to get, and thus, the only way
to raise the success rates is to reduce the number of people who fail with
our current methods?  Clearly, we (as in the community of those studying
computing education) do have the ability to teach computing to someone with
no experience, because those people whom you will welcome into CS1 do have
experience.  At some point, they didn’t.  What makes for a successful start?

What I find most interesting about the two hump hypothesis is that there are
some people who are highly successful at learning computing, even in the
first course.  Why is that?  What are hidden requirements of computing such
that some people succeed easily, while some do not?  (“Hidden” in that we do
not yet know how to detect them, and we clearly are not *teaching* those
skills, or we’d reliably track through pre-requisite courses.) I agree with
Raymond (Lister), that there is no reason to believe that there is a “geek gene.”
There are various cognitive capabilities that are candidates for the hidden
requirements for learning computing, like spatial reasoning (see [1]).

In 1961, Alan Perlis and C.P. Snow both argued that we should teach everyone
in academia how to program.  They pose an interesting challenge — how do we
teach computing (the parts that will be useful to them) to those who are
“unsuited” to it?  (See [2].)  Brad Myers and colleagues published a paper a
few years ago predicting that we’ll have about 3M professional software
developers in the US in 2012, and about 13M end-user programmers.  There are
many more people who could use what we have to teach about computing well,
and it would certainly be a boost to their productivity if they didn’t have
to invent it for themselves.  We’d have to invent methods to teach those
unsuited to being a professional software developer, though.

Mark

[1] Is spatial ability the “Geek Gene”? Why we use algoviz, and why that may
be a bad idea.

[2] “Teaching Computing to Everyone,” May 2009 CACM.

Being Thankful for Luck

One of the main themes in Malcolm Gladwell’s Outliers is that much of a person’s success in life is due to factors outside of his or her control, like the month or year of birth.  Yes, hard work is critical, but other factors play a significant role. Since here in the United States we are celebrating Thanksgiving this weekend, I was thinking about the luck that gave me a leg up. Not everyone gets to be a professor at a top CS department — how’d I luck out?

In 1979, I was a high school junior, and a computer store opened up not three blocks from my house.  I was already mad for computers, having already taken classes in Basic, Fortran, and Cobol.  So, I went to ask for a job.  I wanted a job programming computers.  I got a job folding envelopes and taking out the trash.  But heck, I got a job in a computer store not 10 minutes from my house! I had access to computer magazines and books, to all kinds of oddball machines (from Altairs and Imsai’s, to Exidy Sorcerers and Pertec 2000’s), and to people who knew about how these things worked.  I worked my way into small programming jobs, then into helping repair computers (though I’m still awful with a soldering iron), and into the store’s other business, writing custom software.

What a wonderful job that was!  During the summer of 1979, I worked 45 hours a week, and then spent all night reading everything I could get my hands on about computing.  I easily spent thousands of hours learning about computing through that job over the two years I was there.  I learned 6502, 6800, and 8080/Z-80 assembler language.  I learned about TTL and CMOS chips.  I was humiliated when I got critiqued about how I wrote code for the first time, and still came back for more.  I booted our CP/M hard disk system (with a massive 10 Mb disk!) by loading the JMP instruction and address via switches on the front panel.  I felt that I really had an understanding of how the computer worked, from the chips to the high level language.

When I went to Wayne State University, I got a job as an undergraduate in a robotics lab. I got the job because I could help build the milling machine system they were building in Applesoft Basic, and I knew 6800 machine language to help with the 6802 boards that the grad students worked on–both skills from my job at the computer store.  The director of that lab recommended me to his friend, a recruiter from Bell Labs.  When I went to a summer internship in 1982 in New Jersey, I met kids who were planning on going to graduate school, which I had never thought that much about.  I took a class in UNIX Shell where the instructor happened to mention Smalltalk.  When I looked up Smalltalk, I found “Personal Dynamic Media,” and decided that I wanted to work in education and computing.

Yes, I work hard, but I also recognize that things totally beyond my control — like a computer store opening nearby that needed its trash taken out — has had a huge influence in my life.  For that, I am grateful.  As an educator, I think about those students who don’t get those kinds of breaks, and how we can help them to be successful. Maybe we “create our own luck.”  Maybe we can also create it for others.

The role of debate in learning

“With my undergraduates, the hardest thing to teach them to do is make an argument, support that argument with evidence and bend and move and evolve,” said Susan Herbst, a professor of public policy at Georgia Tech. “Debate is an accelerated way to teach students to do that.”

via High school debate: We all need a lesson in it — chicagotribune.com.

I am actually teaching two educational technology classes this semester, one for undergraduates and one for graduates.  They happen to meet in the same room at the same time, which means it’s basically one, large, large-variance course.  I have undergraduates in Computer Science and Computational Media; and MS students in Computer Science, Digital Media, and HCI; and even some PhD students.  I’m teaching this class around argumentation.

• In Phase 1 of the class, I gave them a proposition, had them read papers about that proposition, then they wrote me a paper making an argument. The proposition was: “Computing creates an opportunity to program, and learning to program creates an opportunity to learn other things better.”  We read Seymour Papert and Alan Kay, Sharon Carver and Elliot Soloway.
• In Phase II, I gave them propositions and papers, and they picked proposition (in teams) then presented it and wrote a paper with the argument.
• In Phase III (right now), they invented the proposition and I helped them with the papers.  They’re presenting for the rest of the term, then owe me a paper at the end.  One group last Thursday defended “The choice of computer language used in CS1 courses has no great impact on the ability of computer science majors to perform in follow-on computer science courses” and another team defended “Instructional video materials can be used to teach declarative and procedural knowledge about computer science, creating expanded opportunities for learning with limited technological investment.”

My reason for this structure is that I’m trying to avoid graduate students coming to qualifying exams unable to argue a position. Since we’re a research institution, all students should learn a critical research skill — how we make an argument based on research literature.  Even for the undergraduates, it’s worthwhile for them to learn in terms of argument, evidence, and story.

The presentations have been so-so.  They sometimes work really hard to involve the audience and present interesting material.  However, in so doing, they often miss the argument.  The argument comes through better in the papers.

All the papers have been readable, but few really present an argument.  My undergraduates don’t write to an audience.  They all spend way too much time setting up their story and making flowery claims about the importance of education and of their proposition — things that make it easy to hit the 10-12 page expected length but don’t really speak to me or their classmates as an informed audience.  Surprising to me, only my Masters students from our Digital Media program really know how to make an argument. They are really careful in their analysis, defining their terms, and making their claims. Even PhD students skip basic steps like defining terms.  One recent team completely ignored half their proposition.

I’m not really surprised.  I spend much of my writing time with my PhD students trying to teach them to write to a story and to defend their argument.  I know that my advisor, Elliot Soloway, spent a lot of effort helping me to tell stories in my papers.  I’ll bet most advisors do.  So while I might wish for better from our undergraduates, I don’t expect more than I’m seeing with regards to writing and argumentation ability. The article referenced above is making a stronger point — that debate is a critical skill, and we should teach it earlier. I think that Susan Herbst’s comment above is particularly critical for our graduate students.  They must know how to make an argument, to engage in debate, to tell a story with evidence.

The role that debate (as Susan refers to it — making an argument, using evidence, telling a story) plays in learning is important in computing education, too, in the sense of the blue-collar vs. white-collar distinction made in the last blog post.  It’s not clear how much you learn about computer science just by programming.  It’s clear that you can learn a lot of computer science by programming, if you bring a lot of knowledge to the task in the first place.  If you don’t know what you’re doing, if you don’t understand grammar and the notional machine, you work to correct bugs with random walks of semi-colons.  If you know what you’re doing, a new bug can become an exploration that leads to new learning.  In my experience, learning from the activity of constructing and designing only really works when there is a base of knowledge to begin with.  It’s hard to start from programming.

The base of knowledge to learn from construction and design is akin to the elaborated knowledge necessary to engage in a debate.  Then, when you have a bug, it’s a challenge to your understanding, and you have to “bend and move and evolve.”  How do we develop that elaborated knowledge in computer science students?  We lecture at them and have them read a book.  Is that enough?  Does reading a book teach you to have the knowledge of a debater?  What is the analogy of debate for computer science students? How do we help computer science students develop rich understanding, like that developed through debate?

Are You a Blue Collar or White Collar Developer? — Datamation.com

Interesting piece (particularly the comment stream) related to a theme in this blog — that students want a job, and how do we teach them about things they ought to know about even if they don’t recognize that they need it.

“You see, I didn’t want to waste my time having to learn about philosophy and political science. I just cared about writing code. Period. All that other stuff would have been worthless… in my humble opinion.”

via Are You a Blue Collar or White Collar Developer? — Datamation.com.

iList: An intelligent tutor for linked lists

Davide Fossati is working with me as a CIFellow.  He’s releasing his dissertation work for others to use:

iList is an Intelligent Tutoring System that can help you learn linked lists. It allows you to work on linked lists problems within an interactive, user friendly environment. However, iList is more than just a graphical environment: iList carefully monitors your progress and gives you helpful feedback while you are working towards a solution. The system does so by using sophisticated artificial intelligence technology. If you want to learn more about the science behind iList, you will find plenty of information in the papers referenced in the documentation section.

via digitaltutor.net – About iList.

Yes, this for me is the kind of educational material that I was thinking about in my last blog post — the kind of thing that we might offer to students needing extra help. This is something that goes beyond reading the book some more, spending more time interpreting error messages, or trying to randomly place semi-colons in your code until it compiles.

What would a CS School of One look like?

Each day, students in the School of One are given a unique lesson plan — a “daily playlist” — tailored to their learning style and rate of progress that includes a mix of virtual tutoring, in-class instruction and educational video games.

via The School of One – The 50 Best Inventions of 2009 – TIME.

If one wanted to do this for an introductory computer science course, what would we do?  What variables do we have available to tailor computing instruction to the individual student?  For example, do we know anything about learning styles for CS?

Here’s a particular version of that question that says something about the state of computing education: How do you help the student needing remediation?  If you have a student not doing well, what options do you have to help that student learn and catch up?

My sense is: Not many.  Most of our instructional repertoire in introductory computer science consists of material that students read (textbooks, PowerPoint slides), lecture sessions, and having students practice in front of an IDE.  What other options do we have?

• Tutoring sessions, particularly with peer-led team learning, could be added to support students who are falling behind.  Essentially, the variable here is “More teacher time.”
• Changing the pace, though the answer for remediation isn’t obvious.  Would you give the students more time per programming assignment?  Fewer assignments? Smaller programming assignments?  More but smaller?  Since we know that lower-performing students take more time per assignment, it’s not clear if it’s more help to give them more time, or make the assignments smaller (easier?), but maybe more of them to provide more practice.
• We could provide students with visualizations, but most of the results I’ve seen suggest that visualizations help the high-ability students to learn more, but they actually hurt low-ability students.
• We have a set of tools that we know are easier to get started with (e.g., Scratch, Alice, Etoys), but they may not be much help once a student has started with a more traditional course and language (Python, Java, C++) and now needs help.  I guess that, if a student was struggling with (say) IF statements in C++, you might use IF statements in Alice to help teach the concept. However, the overhead of learning Alice mid-course might be greater than the benefit, and might really frustrate the student (e.g., “I’m trying to understand C++! Why does learning Alice help me with that?!?”).
• There are some tools like JEROO and iList that look like the languages that students are study and have helped students.  We could use more tools like these.

In other disciplines, there are remediation options. For disciplines from English to Chemistry, there are Cliff notes, study guides, educational software, and instructional videos.  Some of these exist for CS, but there’s not much.  For most subjects, you can always fall back on re-learning the prerequisites. For example, if you’re having trouble with high school mathematics, there are lots of K-8 mathematics materials that one can fall back on.  We don’t have that bench strength that other disciplines enjoy.  CS instruction in high schools doesn’t look that different from CS instruction in colleges, in terms of materials and methods used.

I think that this is another example of how our educational practices in CS are aimed at the top half of the students.  The problem is that if you aim for the top half, you lose the bottom half.  However, if we aimed for the bottom half, everyone would learn, even if the top half were not as challenged.  Yes, we’d prefer to challenge everyone.  But thinking about a CS School of One has me thinking about how we would change how we teach to address the bottom half of students.

How would you know if you’re broadening participation?

Yesterday’s meeting of BPC Alliance investigators might fall under the category of “hard fun.”  Certainly “hard learning.”  The BPC Alliances were originally funded for three years, and then could apply for a two year extension (9 alliances have passed this hurdle), and next can possibly go for a five year extension.  The bar for the five year extension is going to be very high.  Jan Cuny wanted us to realize just how high it’s going to be, so she organized “mock review panels” where we critiqued each others’ 2-year extension proposals.  Each PI presented the proposal for 10 minutes, then there was a critique where the PI could not rebut or respond to questions from other PI’s as well as other experts, then the PI was sent out of the room for the hard discussion that you might not want to do to the PI’s face.  It was fascinating and I learned a lot, but it wasn’t a lot of fun.

One of the key questions for the day was, “How would you know if you’re broadening participation in computing?”  What would you look for?  What should be in the evaluation?  The evaluators presented in the morning and highlighted the five indicators that they think are key:

• Participation: Who’s in the pipeline?
• Motivation: Are the people in the pipeline motivated to move on?
• Advancement: Do we see people moving from stage-to-stage?  For example, do we get kids into high school CS, then taking undergrad CS, then going on to careers or grad school in computing?
• Organizational capacity: Can we handle more people?  Do we have the teachers and schools to handle growth?
• Alliances: Are the stages working together to make advancement happen?

These five are not the ones that the evaluators are declaring the “Common Core Indicators,” the ones that everyone in BPC will be required to gather.  Instead, they are highlighting just three: People, Organizational Capacity, and Alliances.  They decided that Motivation and Advancement are part of the other indicators.

Teachers are an interesting case here.  If you think about training teachers, they’re part of the pipeline — they have to get started, and then improve, and then reach the point where they can teach harder classes like AP CS.  However, teachers are also part of organizational capacity.  They can be measured under either indicator.

Probably the most interesting nugget that I learned yesterday was that we don’t have a lack of African-American men in computing! We’ve thought for years that African-American men were not going into computer science, because the Taulbee report showed so very few of them.  Then the WGBH image study came out showing that African-American male students really liked computing.  Well, then, where are they?  Turns out that they’re mostly going to the community colleges, and to the DeVry and Phoenix kinds of places.  They show up in the IPEDS study.  The Taulbee report only surveys PhD-granting institutions, where the African-American men aren’t.  So, the problem is a little more complex and nuanced than what we realized — there are a lot of African-American men in computing, but they’re not going into the educational paths that lead them into the leadership positions.  We have lots, but they’re not getting the high-paying jobs.  It’s still a problem, just a more complex problem.

Are we a bunch of (particularly) grumpy old men?

Yesterday I was in DC for a meeting of NSF Broadening Participation in Computing Alliance investigators.  It was a really useful and challenging meeting, where we had to go around the room and critique each others’ last proposals (!).  The goal was to improve how we’re thinking about our efforts and how we’re expressing them.  I’ll have more to say about the meeting in a moment, but first, I wanted to highlight a meme that was going around the room yesterday.

We computer science faculty have a bad rep!  Over and over yesterday, in one-on-one meetings and in group discussions, the notion that computer science faculty are a particularly grumpy and curmudgeonly group kept coming up.  Some examples:

• “Our <different kind of computing> faculty are willing to try all kinds of things to attract students and do outreach, but our Computer Science faculty insist that they will only do Scheme!  They’re just a bunch of curmudgeons!”
• A specialist in working with disabled students said that her colleagues ask her why she decided to work with computing students.  “Why did I decide to work with the most difficult and grumpy faculty on all of campus?”
• Another PI describing her efforts to inculcate change in her computer science department, “But we can’t even get the faculty to learn about new things! They’re happy with UNIX and want everyone to just do that!”

So my experience is that there is a significant percentage of more senior faculty of all disciplines are fairly set in their ways and are rather “grumpy” about change.  Maybe I fall in that category now, so I’m blinded to the claim I heard yesterday — that computer science senior faculty are particularly resistant to change and grumpy about it.

Before Barb Owens or others call me on it — of course, there are senior CS women faculty, too.  But it is the case that CS faculty of decades past have been male, so the characterization of “grumpy old men” is not inaccurate.  And it might be that the male faculty are even grumpier than the female faculty.

I can imagine how the claim that CS faculty are particularly grumpy could be true.  Computer science is a young discipline.  Senior faculty today spent their whole careers defining and defending their turf — “This is computer science, and that isn’t.”  At the same time, computer science has had dramatic change: From computer time being more expensive than human time, to the reverse; from memory being dear, to memory being plentiful; from sequential processing being the assumption, to today’s world where parallel processors are all that we can see going forward.  How often does a discipline change so many of its base assumptions in the lifetime of a faculty member?  Change is hard for anyone, and particularly so when you’ve spent your career making arguments that are weakened or changed by time.

Now, I don’t know that it’s true that CS faculty are particularly “grumpy.” Maybe it is.  The real point of the BPC discussions was that our resistance to change is counter-productive.  We need students who don’t look like us.  There are too few students who look and act like us to provide the computing labor and insights that our society needs.  We have to break out of our assumptions and the methods that have served us well up until now.  That’s hard, but we have to get past the “grumpiness.”

Latest: GaDoEd says Science Yes, Math No

We just got word that the Georgia Department of Education will count AP CS as a science credit towards high school graduation, but not as a math. The University System of Georgia, however, will count AP CS as either a math or science towards admissions requirements. No word on why the difference, or even how the decision was made, but at least we’re no worse off than we were — and maybe even a bit better.

More farmers for the fields: More computing ed experiments!

I’ve been thinking for several days about Doug Holton’s blog post about the critiques of cognitive load theory.  The critiques are well taken.  I find the “intrinsic, extraneous, and germane” kinds of cognitive load confusing and not particularly useful.  Cognitive load is clearly a hard thing to measure.  Doug’s critique that it’s “unfalsifiable” is important.  It’s an important goal to figure out how to measure these factors and to develop good experimental evidence.

However, the critique doesn’t change my mind about the need to explore reducing cognitive load in computing education.  There are lots of ideas in education that are problematic and hard-to-measure. Yesterday, in my educational technology class, we read papers by Alan Collins.  I challenged the class to wonder, “How would you test cognitive apprenticeship?”  What evidence do we have that cognitive apprenticeship is a good method? Is it falsifiable? Measurable?

I built my dissertation work around cognitive apprenticeship and constructionism, and I still think that these are promising educational ideas.  The available evidence convinces me that these are ideas worth exploring, even if we still have problems measuring these things or developing clinical trials that demonstrate  the value of these ideas.   The reality is that we need many more experiments.  I look around and see very few computing  education efforts exploring education ideas like worked examples, cognitive load theory, and the modality effect. TeachScheme does a good job with respect to issues of cognitive load (e.g., in their directions to students on how to analyze data and then how to write code for processing that data, thus allowing students to focus on one aspect of learning at a time), but that’s just one experiment.  Where are others?

In Alan Kay’s foreword to the “White” Squeak book, he wrote:

In fact, Squeak is primed to be the engine of its own replacement…We not only give permission for you to do this, we urge you to try! Why? Because our field is still a long way from a reasonable state, and we cannot allow bad defacto standards (mostly controlled by vendors) to hold back progress.

Alan is right — we need people trying to do better than other projects, building on others’ works, trying good ideas with different languages and different approaches. We need a lot more experiments.  We need more farmers tilling the fields.

Are we doing so very well at computing education that we should just replicate the same practices everywhere?  It’s a problem that so many classes look nearly the same, that a small number of textbooks cover the vast majority of courses, and that we have so few languages used in intro courses.  We should be trying out all the good ideas that we can.  Yes, cognitive load theory is problematic, but the evidence is strong enough that I think we ought to try that, too.  Let’s get more good ideas out there.

 

Can direct manipulation lower the barriers to computer programming and promote transfer of training?

Chris Hundhausen has a really important paper in the latest issue of ACM TOCHI: Can direct manipulation lower the barriers to computer programming and promote transfer of training?.

We’ve known for a couple decades now that programmers read and understand visual programs no better than textual programs — Thomas Green, Marian Petre, and Tom Moher settled that question a long time ago.  However, everybody experiences that starting with a visual programming language is easier than a textual language.  But does it transfer?  If you want students to eventually program in text, does starting out with Alice or Squeak or Etoys hurt? Given Chris found: “We found that the direct manipulation interface promoted significantly better initial programming outcomes, positive transfer to the textual interface, and significant differences in programming processes. Our results show that direct manipulation interfaces can provide novices with a ‘way in’ to traditional textual programming.”  I think that this is big news for computing educators.

Teaching better by teaching less

I wonder if this idea would help computing education, too.  If students aren’t getting it, maybe you should redouble your efforts on a smaller set of goals and learning objectives?

Middle school students in every racial, ethnic and income group show greater mastery of mathematics — including algebraic reasoning, statistics and geometry — than they did three years ago.

Educators attribute much of the progress to Oregon’s embracing a national recommendation to drastically scale back the number of math topics covered in each grade.

via More Oregon students are getting math | Oregon Education – OregonLive.com.

Funding Projects not People

In Alan Kay’s comment to a recent blog post, he mentioned again that ARPA in the 60’s and 70’s  “funded people, not projects.”  I’ve been meaning to post a (unfortunately, whiny) blog entry about that phrase, and his comment has goaded me into it.

The current way we fund research is broken.  I know that there are researchers who are doing really well under the current system and will disagree.  I personally have been blessed with several large grants recently, so I can certainly be accused of ingratitude with these comments.  I just keep running into roadblocks that don’t make much sense to me, that seem to me to be a result of our national policy of funding projects, and not people.  Some examples:

• Graduate students often take more than 3 years to finish their PhD.  NSF grants are almost always 3 years long.  There is intense pressure to have graduate students fully funded, or to dismiss them from the program.  “If they’re doing good work, you should be able to get them funded.”  So what do you do when a student is doing good work, has 9-12 months to finish, and runs out of his NSF grant?  Do you apply for another NSF grant?  That’s great for his last year, but how do you fulfill your commitments on the proposal for the extra two years after he graduates?
• The whole idea of matching students to NSF proposals is a mismatch of expectations and realities.  I have a project where we wrote in a new PhD student before she arrived.  It rarely works out that smoothly that we offer a student admission, write a proposal to do what we’ve agreed to work on, then you get the funding as she walks in the door — but in this case, it worked.  However, new PhD students don’t really know what they’re going to do, and this one has now realized that her skills and interests are taking her in a different direction.  That’s great for her, and I bet she’ll do great work. But now how do we fulfill our commitments to our grant?
• I’ve complained before that the US doesn’t fund computing education research.  One of my colleagues just got an NSF BPC proposal rejected, in part (one of the criticisms in the panel review) because there was “too much research.”
• I have a CIFellow working with me, a post-doc.  He would like to apply for funding to let him continue his post-doc for an additional year beyond the year funded.  Georgia Tech won’t allow him to be the PI of such a grant, so I agreed to be the nominal PI while he wrote the grant and did the work.  Turns out that new policies don’t let me.  Georgia Tech won’t let me submit a proposal where none of my time is funded.  Okay, let’s throw a day or two of me on the grant.  Nope, that won’t work either.  I currently have NSF grants where my funded time adds up to two months, and NSF (at least in Education and in CS) won’t fund more than two months (summer or academic year) of any faculty’s salary.  Until my current grants expire, I effectively cannot submit any more NSF proposals, even as just a co-PI or nominal PI.

A lot of this craziness comes from funding being based on individual projects, not on funding people and programs.  However, to be honest, I don’t currently see a way to get it changed.  The increased emphasis on accountability and having measurable benefits requires funding to be associated with the outcomes of a particular project.  If we funded people and programs, instead of projects, how would you decide who to fund?  Even many schools formerly focused solely on teaching are trying to break into research, to help shore up sagging revenue lines.  If we only funded people with proven track records, how do new people break in?  If the new folks have a great idea for a project, shouldn’t we fund that project?

I don’t have a solution to offer. It just seems to me that there’s a disconnect between the demands of research and graduate work, and the realities of funding and accountability rules.

Okay, I’ll stop whining now. (For this post, anyway.)