I'm helping Software Carpentry think through its strategy and curriculum for a blended learning model of teaching software engineering to scientists. As I recently noted, I'm making some shifts in my work so that I can focus more on some of these questions surrounding how do we create learning environments for non-programmers to learn programming. Fair warning: what follows is a bit of a brain dump…

Discipline, Part 1 (n. a field of study)

My academic background is in literature and folklore, so no surprise, I spend a lot of time closely watching the developments in the "digital humanities" and thinking how can we help bridge what has long been viewed as two utterly separate (and perhaps even oppositional) disciplinary fields -- the humanities and computer science. Stanley Fish's handwringing aside, those bridges can be built in a number of ways and to a number of ends: helping train scholars in new tools (and, as such, in new methodologies); learning to work with technologists; coming to terms with the ways in which storage, processing, interactivity, data, and so on might enhance teaching, research, and their dissemination.

The relationship between the humanities and technology may be fraught (again, cue Stanley Fish and a weak joke about "Is there a .txt is this class? or something), and I suppose we can trace that to the various graduation requirements for humanities majors: unless students pursue the tech education themselves, they're unlikely -- or at least not required -- to come across it in the course of their degrees. You take a math class. You take a science class. And boom, you're done, allowing you to steer clear of those scary STEM-y part of campus.

But what about folks whose disciplines are science? Perhaps it's easy to assume that they 1) have had more technology instruction, 2) have a stronger background in math and engineering, and 3) have a greater need (and therefore drive) to use computer tools in the course of their work. Indeed, as Northwestern University English professor Martin Mueller writes in a recent essay on the digital humanities (and Stanley Fish), DH "is different in most other disciplines. There are no self-proclaimed digital biologists, chemists, or economists, but for many practitioners in those disciplines digital tools and methods have become essential parts of their engagement with the primary data in their fields — leaving aside the matter of writing and publishing research results, which is going digital in all fields, including the humanities, albeit at different rates."

But I'm not sure that's true. I'm not sure we can say be so assured that scientists are de facto "digital" or even technical -- as tool-users let alone as tool-builders. In fact, according to a survey conducted by Software Carpentry back in 2008, 96% of the scientists who responded described themselves as "self-taught" when it came to their software engineering skills. And while the survey wasn't able to ascertain how effective or skilled these scientists were, it did uncover some anecdotal evidence that the answer may be "not very."

Discipline, Part 2 (n. training that corrects, molds, or perfects the mental faculties or moral character)

When we talk about informal learning -- like the steps that the scientists mentioned above have taken to teach themselves a sufficient amount programming -- we often assume that these are very motivated learners. In other words, if you know that you need to use a particular tool in order to move a project forward (whether it's HTML or Hadoop), you'll likely be more driven to learn.

But is that initial impetus (the motivation, the need) sufficient? Do our assumptions about motivation color our assumptions about discipline? That is, do we err on the side of the casual lessons and loosely-structured learning plans and goals? How much learning is sufficient -- just enough to muddle through?

And do we tend to view the informal learner as an isolated learner? Sure, that person can go to online forums and Q&A sites for help (e.g. Stack Overflow). Is the informal learning constructing their knowledge on their own? If so (and/or if we think that's so), how can we engage them with others? (And I can't help but return to this question of academic disciplinarity: what happens when these social learning environments cross disciplines -- particularly when there are gulfs (real or perceived) between the "how" and the "what" they know?)

Do we need CS-the-discipline? Or do we need programming-in-practice? (Is there a difference?)

Discipline, Part 3 (n. orderly or prescribed conduct or pattern of behavior)

Software Carpentry offers a two-day boot camp, followed by a six-week online course (with the expectation of between 2-5 hours per week of work on the part of students). The curriculum is listed here, and includes a fairly broad survey through the basics of the Unix shell, a brush-up on programming concepts*, through to data structures, databases, and development techniques and practices. Some of the instruction is done in a face-to-face setting, but much of it occurs in the online, follow-up lessons.

What to do during that two-day bootcamp and what to save for the follow-up, online lessons is an important question here. Also, what do participants already know (particularly with regards to their programming chops*)? What do participants need to know (in other words, what problems are they solving)? How is the learning scaffolded, particularly with participants' different goals and with their coming from a variety of academic backgrounds ("science" after all is a very, very generic term)? In the move from face-to-face to online, how do make sure there's enough "there there" -- not just the right content, but the right format and, of course, an environment where learners are both supported yet encouraged to be self-driven (cough, disciplined, cough)? After all, ideally the Software Carpentry training won't just "solve their programming problems" by equipping them with new skills (or honing pre-existing ones), but it will enable them to apply that problem-solving and design-thinking forwards and backwards in their work.

More questions: Do students work together (on- and offline)? If so, how? If they are solving their own problems (based on their own projects and disciplines), how does Software Carpentry meet those needs -- practically, philosophically? While there's a lot of thought that's gone into thinking about the format for the lessons, it seems to assume direct instruction rather than peer-to-peer learning.

Learning (Software Engineering), Undisciplined

How does "end user software engineering" different than "professional software engineering"? And how do we teach for the former, not just for the latter -- an un-disciplined computer science, if you will?

* For a subsequent post( or posts): how do we help folks who do not have a good understanding of basic programming skills reach this point so that they're ready for Software Carpentry and similar sorts of programs? That leads to another question (of course -- this write-up has way more questions than answers, eh): what are some other examples of blended learning to teach programming (either "professional software engineering" or "end user software engineering")?