Add one or more graphics to the top of the paper

[briandk]

Or even just a billeted list of points:

1. We don't know enough about what happens in early stage software design.
2. And what little we do know has focused on experts: professional software engineers working in industry. Which is a problem because:
3. If there's a path of development for novices to become expert software designers, we haven't fully characterized the end points.
4. What we know about novices is far less than what little we know about experts. We have almost no data comparable to those in Petre's book to characterize how novices design software.

[briandk]

This paper tries to redress that balance by:

1. Focusing on novices designing software,
2. Engaging in the kind of data collection that would allow us to compare practices across contexts (see Hall and Stevens on work v. school)
3. Revealing how if we just study the output of a students' summarize assignment, we miss consequential opportunities for formative assessment and instructional intervention.

[briandk]

Include a table of some of the other participants to illustrate the dimensional spanning that arose:

• Isaac on what kind of activity gets missed if you just look at snapshots
• Natalie on the kinds of sexism she experienced, as well as her 'retaliatory code' that fought back against the design requirements
• Dana on question banks as an example of coping with a broken system that doesn't invite authentic design opportunities
• Lionel on top-down design and white boarding as a way of programming, including the cascade of what satisfices and pseudocode

[briandk]

Look into fieldwork/anthropology references that document theme emergence and spanning a space