Software Carpentry

I’m trying to be systematic about re-designing the core curriculum of Software Carpentry. So far, I’ve identified 11 common questions:

Read more…

Based on the feedback we’ve received so far (both as comments and by email), it looks like we should take development methodologies (i.e., agile development) out of the core curriculum and replace it with two hours on:

1. Nothing: there’s already too much in the core.
2. Spreadsheets: because many scientists use them badly.
3. NumPy and/or Pandas: because many of them are crunching matrices/doing stats.
4. Visualization: which in practice would mean the basics of matplotlib.
5. Image manipulation: because it’s fun as well as useful, and lets us talk about binary vs. text data.

I am quite arbitrarily limiting options to those five. Please cast your vote (one vote, not three out of five) in comments. We’d be grateful if you could include a brief explanation as well.

Once again, Cameron Neylon explains things much better than I ever could:

“The impact factor of a journal is a better predictor of the chances of a paper being retracted than…of the number of citations.”

One of the things we need to do in the next six months along with running boot camps and updating our online content is to create some sort of badging to recognize people’s skills and contributions. As we said in the proposal to the Sloan Foundation, “A badge program will provide near-term incentives for both learning and mentoring; a framework to support viral, peer-driven engagement with the program; and facilitate recognition by partner institutions and potential employers.”

Read more…

I’ve been thinking some more about what the foundation and core of Software Carpentry actually are (and not just because Jon Pipitone keeps pestering me to do so). My last attempt had a foundation of seven principles and dozen topics in the core. I think I can slim that down even further; in fact, I think three big principles form the foundation of computational thinking:

Read more…

We just wrapped up the first boot camp of 2012 at the Space Telescope Science Institute. 14 scientists with a wide variety of computational backgrounds spent two days learning about testing, version control, program structure, the basics of Python, and the psychology of learning and programming. We’re following up with 6 weeks of online material, partly because that’s what fits everyone’s schedules, and partly to see whether a blended approach works better than either strategy on its own.

And on a completely different topic, this diagram from the Discover magazine web site sums up every scientist-vs-journalist debate ever:

I’ve been teaching scientists to program since 1998 (or 1986, if you want to start with my first lunch-and-learn for grad students in physics at the University of Edinburgh). Technology has advanced by leaps and bounds in that time, but I don’t think it’s any easier than it used to be to get basic software skills into people’s heads. What makes it hard?

Read more…

We’ve just added a single-page description of the two-day boot camps we’re planning to run in the next six months. In brief, their aim is to ensure that people have a few core skills, so that they can tackle our online material productively, and to help them get past startup hurdles such as software installation. If you have questions, comments, or suggestions, please add them to that page; if you’d us to help you organize and run a boot camp, please get in touch.

We are very pleased to announce that the Sloan Foundation has generously agreed to fund six months of work by Software Carpentry and the Mozilla Foundation. The proposal we submitted, which outlines what we’re going to try to do, is included below—it’s a lot of work, but we’re very excited to have the opportunity to move Software Carpentry forward. Details are below the fold…

Read more…

A couple of days ago, I posted replies to some of the comments that people had made on my posts about Software Carpentry’s future. To recap, I want SC to:

1. offer learning materials so that people can work through them on their own;
2. be a repository where people can evolve those materials;
3. coordinate people who are organizing live workshops, offering technical support [1], etc.; and
4. coordinate a distributed research program to evaluate Software Carpentry’s effectiveness.

Read more…