Was she was being sloppy in her use of "tinker"? It is worrisome whether the answer is "Yes" or "No".
If YES: One of the big lessons from programming computers is the utter importance of the precision of language, a skill that can carry over from programming to other communication forms. Sloppy usage indicates that the example curriculums that the committee is using didn't incorporate these values.
If NO: "Tinkering" would be shortchanging the students: Research on using programming in education of young children goes back to the 1960s (Seymour Papert and the Logo programming languages) and reportedly demonstrated ability their ability to do much more.(foot#2)
Similarly, I hope that the usage the term "computer science" is simply puffery and not an indication that the committee doesn't understand the meaning. There is a rough hierarchy, with the lowest level being "computer usage", that is, awareness of the basic conventions, terminology ... (the culture) presumed by designers of computer hardware and software. The next level is "coding", that is, the knowledge of at least one programming language and the ability to write trivial programs (tens of lines of code). Above this is "programming" which involves more sophisticated design dealing with issues such as correctness, maintainability, interaction of subsystems. The disparaging term "code monkey" indicates the difference: The code monkey just keeps modifying and fixing code until he gets something that seems to work on his test data, that is, he engages in high-energy tinkering.(foot#3) Programming has many sub-specialties, but involves applying the results of computer science, and does not involve advancing the field. To enhance this differentiation, programmers are often called "software engineers", but actual engineers (rightly) object.(foot#4) Of course there are gray areas between these categories, and the work of many practitioners slips back and forth between the categories.
The current dynamics in many college computer science departments results in some of their graduates qualifying only as coders, and sometimes only mediocre ones. The problem is widespread enough that many companies have taken to having candidates for programming jobs write a small program to see if they actually have an adequate skill level. Aside: Some companies are abusive in this regard, but that is an unwelcome tangent.
I realize that we live in an age of inflated descriptions, but imagine if kindergartners play catch was labeled as "Introduction to Astrophysics" (develop intuitions about the effects of gravity on the motion of spherical objects). The role of education is not just to increase what you know, but give you a better sense of what you don't know. Inflated descriptions are harmful to students because the students can be deceived into thinking that they know more than they do.
----Problems with high school programming classes----
In the early 1980s, Intro to Programming college courses were seeing increasing numbers of students who had done some coding in high school. The CS Department I was in (Oregon State) explored whether there should be a separate track or sections for such students. What we found was that those students tended to do worse in the course (strong negative correlation). It seemed that those students had picked up bad habits in their high school work and were very resistant to unlearning them.
The programming course I taught grew in two years from an enrollment of 50 (just before I arrived) to 400 with a waiting list. From what the students told me, part of the reason was that they could easily tell which professors and teaching assistants had experience with nontrivial programming. I challenged them to go down the list, and they were quite accurate.
The combination of these two should serve as a cautionary note to question whether there are adequate teaching resources to achieve the goals of a coding or programming course, not just to avoid wasting the students' time, but to avoid teaching them the wrong things. And one of the worse habits I have seen is a programming style that could be characterized as tinkering.
----Computer Science for All----
When the Obama Administration announced its "Computer Science for All" program in early 2016, I took a look at the (College Board) AP courses and the PAUSD course catalog. What I saw was troubling.
I first looked at the new (College Board) AP course "Computer Science Principles" that was to launch in Fall 2016. My reaction to the syllabus and the example exam questions was "This is a course I wouldn't want to teach" and one that I would probably recommend against taking. Many of the topics were ones that are typically taught at the Junior and Senior level in college. From my experience teaching them, I didn't see where there would be enough time given to the various topics to provide the students with enough exposure and details to be useful beyond recognizing the basic terminology and the existence of the topic. In a teach-to-the-test approach, it is unlikely that time would be spent giving the students a sense of true breadth of those topics. While the claims made for what the course should cover are clearly wildly extravagant, I didn't see a way to cut the syllabus down enough to make it practical. (foot#5)
Note: The established course AP Computer Science A focuses on learning to code in an object-oriented language (Java) and seems to be reasonably structured.
I next looked at the catalog for Gunn HS (2016-2017) and the year-long course "Introduction to Functional and Object-Oriented Programming" (#8634)(foot#6) is listed as expecting only 1-1.5 hours per week to be spent on homework. I am skeptical that this is enough time for the typical student would learn the material. Yes, writing tiny programs similar to the examples in the text book could be done, but this is equivalent to regurgitation and doesn't provide real learning. I have seen such students being unable (unprepared?) to step up to slightly larger programs. I am aware of the legitimate concerns about homework burden. It is also a problem at the college level: For many students, the immediate feedback they get from programming assignments can draw them in to repeatedly doing "just make it a little bit better", and thereby leading them to neglect their other courses. Crafting assignments that are difficult enough without being excessive--or worse, only busy-work--is one of the crucial and difficult skills of teaching.
----PAUSD Curriculum Design----
I didn't find the notes of previous meetings of the Curriculum Design Advisory Committee to be illuminating, but that may be partly due to the documents being discussed not being available online. My impression is that the committee is overly focused on the details--the specific skills to be taught--and don't have a high-enough strategic vision. This is mildly incongruous because one of the key skills/big ideas being taught in programming is to abstract away from low-level implementation, that is, the current goals should be treated as means to much larger goals.
So what are some of the important skills that can, and should, be taught as part of this curriculum? Note: I know much too little about primary and secondary education to venture what can be taught when and how.
Rigor: Precision of language, complete instructions, accurate instructions. Testing/validation/verification. Due diligence.
Caution/Paranoia with your own programs is a motivation for rigor: You typically don't have an opportunity to fix errors as they occur, for example, because they occur so fast, because there are so many of them, or because someone else is running the application.
Caution/Paranoia with programs you are using. Be prepared for them to produce erroneous results or outright fail, and that the former can be the more dangerous situation.
Perspective of others: When dealing with other people, it is too easy to blame them for misunderstandings, both misinterpretations and doing what you said instead of what you meant. Shifting the blame to the computer doesn't work, although many have tried. Debugging of computer programming offers abundant opportunities to shift between your perspective--what you want done--and the computer's--what it understands you having told it to do.(foot#7)
Design and documentation: Computer systems and applications offer abundant examples of bad design and bad documentation. Use the opportunities of the students' frustrations with this to have them think about what was wrong, why and how it might be done better.(foot#8)
Atypical cases: With computers, the improbable --say one-in-a-million-- can happen several times a minute. Foster an attitude of needing to think beyond the typical situations to the full range of situations that might occur and then how to handle them.(foot#9)
Economics is often defined as the study of allocation of limited resources. In programming (beyond coding), you are routinely making certain categories of these decisions, for example, a tradeoff between having the program be more efficient or making it easier to modify. For example, producing a model of the real world that adequately represents what you are interested in. For example, at advanced levels, students learn that algorithms that work well on small scale problems may be horribly expensive for larger scale ones, and vice versa. Having control of the choices and seeing the results can be a much more effective introduction than reading about it, and can provide the intuitions for when students get to traditional economics teaching.
Clarity of expression: When I was a graduate student teaching assistant (TA) for Programming 2 I had a housemate who was a TA for English Composition. He was not the typical English TA: His attitudes about effective communication had been strongly shaped by his experiences as a lead helicopter pilot during the Vietnam War. My complaints about my students' programs were mirrored by his about his students' compositions. I have observed that students quite readily critique each other's programs, but are very reluctant to do the same to their compositions.
These are some ideas to get people thinking along similar lines. Note including ideas such as the above are difficult to incorporate into a curriculum because of the focus on what gets taught when ("In week 5, X will be covered") and how it will be tested (predominantly multiple-choice or short-answer).
Warning for those who might want to become involved: I have found the PAUSD community (staff and parents) tends to be highly insular, both in not seeing the value of including outsiders and in having a culture and jargon that impedes participation (this is a general problem, not just the PAUSD's).
The Committee's webpage has not been updated to include meeting times, but according to the PA Weekly story the next meeting is Monday March 13 (today) starting at 4:30pm.
----Footnotes----
1. Committee explores K-12 computer science curriculum, Palo Alto Online, 2017-03-09. In the 2017-03-10 hardcopy edition, it is on page 10 as "School district seeks to make computer-science ed mainstream".
2. Disclaimer: I do not have any expertise in this area. I took a class taught by Papert in 1973 and had various friends and colleagues in the area of Artificial Intelligence in Education.
3. An allusion to the "Infinite monkey theorem". I like the retort "We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true." (Robert Wilensky, Professor of Computer Science, UC Berkeley)
4. "Why Computer Programmers Should Stop Calling Themselves Engineers" - The Atlantic, 2015-11.
5. AP Computer Science Principles, containing links to course overview, details and description.
6. This year-long course was previously two single-semester courses meant to be taken in sequence (#8632 & #8633): 2015-16 catalog which listed an expectation of 2 hours/week spent on homework.
7. When I was an undergraduate working on a project, one of my teammates couldn't find a bug in his program. Even when I took him step-by-step through what was happening, he was unwilling to accept that what he saw could possibly be happening.
8. Examples of exploiting bad documentation:
1. Many applications use ambiguous terms, assuming that you know which definition they intended. Hint: The safe answer is "None of the commonly accepted definitions--they are using their own special version".
Aside: Computer industry saying: "Everyone is committed to the importance of standards. Why else would they have so many of their very own?"
2. Vacuous definitions such as defining a "tinker" (N) as "one who tinkers" with no definition of the verb.
9. Attempts to apply Artificial Intelligence to legislation and case law has highlighted the many contradictions, ambiguities and omissions that routinely occur. This happens even with new laws where considerable effort was expended to avoid these problems. A classic example from the 1980 is the work of Segot et al at Imperial College London on the British Nationality Act.
----
An abbreviated index by topic and chronologically is available.
----Boilerplate on Commenting----
The Guidelines for comments on this blog are different from those on Town Square Forums. I am attempting to foster more civility and substantive comments by deleting violations of the guidelines.
I am particularly strict about misrepresenting what others have said (me or other commenters). If I judge your comment as likely to provoke a response of "That is not what was said", do not be surprised to have it deleted. My primary goal is to avoid unnecessary and undesirable back-and-forth, but such misrepresentations also indicate that the author is unwilling/unable to participate in a meaningful, respectful conversation on the topic.
If you behave like a Troll, do not waste your time protesting when you get treated like one.
