In my previous post on using OneNote with students, I wrote about the need to choose students to be responsible for each day's notes. This needed to be deliberately planned and fair to students. Here were my requirements:
- Over the course of a quarter or semester, students had to be picked around the same number of times.
- I needed groups of two or more students for redundancy.
- If a student was picked for a given week, there should be some time before being picked again. If repetition of a given student did occur, cycling through the class was a requirement before that student could reappear.
After a while playing around with this, I came up with the code below. Feel free to play with the code. It's embedded in this post through the nifty tools from http://trinket.io..
Here's a walkthrough of the algorithm: fill a list with the student names, and then shuffle the list. Create groups of the desired size until there aren't enough to create a full group. Make a new copy of the student list, shuffle it, and then remove the students that remain from the first list. Finally, tack those remaining students at the beginning of the second list. Repeat until you have the number of groups that you are looking for, and then print out the list.
I can see a number of other applications for something like this. My hope is that you take some time to adapt it to your needs, and then circle back here to share what you used it to do.
A conversation with Dan Anderson(@dandersod) this morning has pushed me to revisit a coding for teachers concept that I've nudged forward before, but haven't made happen to my liking yet. There's an amazing variety of coding materials and tutorials out there, but few that I've seen take the approach of helping teachers build immediately useful tools to improve their workflow.
To be done right, this must acknowledge the fact that this valid sentiment is out there:
@cheesemonkeysf: @dandersod @emwdx @dcox21 But are you prepared for… the "coding-impaired"?
As any person that has dabbled in programming knows, there's always a non-trivial period of frustration and bug hunting that comes with writing code. This discomfort is a part of learning any new skill, of course. It's also easy to say that you aren't a code person, just as someone can say that he or she isn't a math person. What pushes us (and our students) through this label to learn anyway?
- Minimal hand-waving about how it 'just works'
- Experiences that demonstrate the power of a growth mindset
- Concrete ideas first, abstraction later
- Building the need for better tools
- Maybe the most important: having the right people at your side
I want to work to make this happen. Consider this a pile of rocks marking the beginning of that trail.
How do we start? I see this as an opportunity to use computational thinking as a way to improve what we do in the classroom. This project should be built on improving workflow, with the design constraint that it needs to be accessible and as useful as possible. I also want to use a range of languages and structures - block programming, spreadsheet, Automator, everything is fair game.
I want to first crowdsource a list of tools that would be useful to learn to build. Let's not limit ourselves to things that are easy at this point - let's see what the community wants first. I've posted a document here:
What Do You Want To Learn To Build?
Go there and share your ideas. I don't want to wait any longer to start talking about what this could be.