Communications of the ACM

Philip Guo offers programmers 'Opportunistic Programming' tips that typically are not shared in school.

Franklin Chen

I agree that programming as it exists in the real world is not taught and that this is a problem. I think this is a symptom of a larger problem: yes, programming is not computer science, just as building robots is not linear algebra, calculus, or physics. Problem is, we expect people who build robots to have had a decade of education, before arriving in college at all, to have mastered some basic math and science. But computer science, the "nuts and bolts" of programming, is not taught K-12. If all the low-level stuff of algorithms, data structures, and so forth could be taken for granted, then there could be an entire discipline revolving around programming that students could begin working on upon arrival in college. Imagine the difficulty of coming up with an undergrad curriculum for would-be physicists and roboticists if students arrived in college without knowing how to add. That's we face today in anything involving computation.

Anonymous

You're forgetting one thing - in the real-world you also have a purpose, a goal for what you are trying to create or a problem you are trying to solve. You also have a wealth of background and tacit knowledge about the constraints and affordances of programming. If you just had students mimic the actions of how programming is done in the real world, they would be doing it without understanding the reason for it.

Search for "problem-based learning" for more information on types of approaches in education that have students work on real-world, messy problems.

Anonymous

This style of programming goes by the name "code quilting". Part of the difficulty with moving this workflow method into the classroom is that it requires schools to redefine "cheating."

William Billingsley

We've had a course running for a couple of years now that seeks to addresses these issues, as well as the inherently collaborative nature of software engineering. We've published papers on it both at ICSE in 2012 and at the ACM's ITiCSE conference this year.

It's a second year course that in its first two iterations had approximately 70 students working on a common code-base: tinkering, extending, integrating their work, etc. This year we have 170 students. And we're on a path towards opening the course to the world.

(This also means that rather than have students work on small greenfield exercises, they're working on a project that in terms of numbers-of-programmers is possibly larger than some of them will work on in their first post-degree jobs.)

It's a follow-on to a more introductory programming course -- we expect students to come in to our course knowing the basic syntax of the language.

Billingsley, W. & Steel, J. 2013. A comparison of two iterations of a software studio course based on continuous integration. ACM conference on Innovation and technology in computer science education (ITICSE). 213-218

S, J.G & Billingsley, W. 2012 Using continuous integration of code and content to teach software engineering with limited resources. International Conference on Software Engineering (ICSE). 1175-1184

Gail Murphy

The ubiquity of a wide variety of frameworks and libraries and the growth of resources such as stackoverflow has changed the way in which a lot of software is developed. At UBC, we have been bringing this changing approach into our second year curriculum in Computer Science. We have been immersing students into Java by showing them how to read and take apart existing Java code. We spend time in lecture showing how to navigate through code, refactor code, and test hypotheses about how the code might work. By the end of the course, the students augment an existing Android application by integrating new features based on widespread web services, such as the Yelp API. With this approach, we have been able to achieve several of the steps you outline. This approach assumes more of a top-down learning style where students are able to operate without understanding all of the details of the software they write. We are continually trying to introduce new approaches into the course to balance out the needs of those with a more bottom-up learning style that would like to understand the ramifications of every statement they write. There are challenges in not only making the new style of software development more systematic and explainable to others but in also meeting the needs of the variety of learners one finds in a large classroom. Thanks for raising this important issue!