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:
Go there and share your ideas. I don't want to wait any longer to start talking about what this could be.