## Computational Thinking in Teaching and Learning (Re-post)

A modified version of this post appeared on the Techsmith Blog here and in their quarterly newsletter, the Learning lounge. I appreciate their interest in my perspective. I hope to continue this important discussion here with my readers.

The idea of computational thinking has radically changed my approach to teaching over the past few years. This term, first coined by Jeanette Wing, a professor of computer science at Carnegie Mellon University, refers to several key ideas of thinking that are essential to computer science. The paper clearly identifies the reality that there are some tasks that computers do extremely well, and others that are better suited to the human brain. Traditionally, computer scientists have worked to outsource the calculating, organizing, searching, and processing work for task X to a computer so that they can focus on the more complex, challenging, and engaging aspects of the same task. According to Wing, one of the most essential skills we should develop in students is sorting tasks into these two groups.

My classroom, at its best, is a place where maximum time is spent with students wrestling with an engaging task. They should be working together to develop both intuition and understanding for required content. I can read the smiles or frowns and know whether I should step in. I can use my skills to nudge students in the right direction when I think they need it. Knowing precisely when they need it can't easily be determined by an algorithm. For some students, this moment comes early on after encountering a new concept. Others require just one more minute of struggle before the idea clicks and it's in their brains for good. Knowing the difference comes from the very human experience of time in classrooms with learners.

This is the human side of teaching. It is easy to imitate and approximate using technology, but difficult to produce authentically. Ideally, we want to maximize these personal opportunities for learning, and minimize the obstacles. For me, the computer has been essential to doing both, specifically, identifying the characteristics of tasks that a computer does better. If a computer can perform a task better than me or my students alone, I'm willing to explore that potential.

The most consistent application of this principle has been in the reduction of what I call 'dead time'. I used to define this as time spent on tasks required for learning to be possible, but not actually a learning task itself. Displaying information on the board, collecting student answers, figuring out maximum and minimum guesses for an estimation problem - these take time. These sorts of tasks - displaying, collecting, processing - also happen to be the sort at which computers excel. I wrote a small web application that runs from my classroom computer that allows students to snap a picture of their work and upload it to my computer, anonymously if they choose. We can then browse student answers as a class and have discussions about what we see. The end result is equivalent to the idea of students writing their work on the board. The increased efficiency of sharing this work, archiving it, and freeing up class time to build richer activities on top of it makes it that much more valuable to let the computer step in.

I've also dabbled in making videos of direct instruction, but I have students watch and interact with them while they are in the classroom. During whole class instruction, I can't really keep track of what each student is and isn't writing down because I am typically in a static location in the classroom. With videos simultaneously going throughout the classroom, I can see what students write down, or what they might be breezing through too quickly. I get a much better sense of what students are not understanding because I can read their faces. I can ask individualized questions of students to assess comprehension. The computer distributes and displays what I've put together or curated for my students – one of its strengths. My own processing power and observation skills are free to scan the room and figure out what the next step should be.

Letting the computer manage calculation (another of its strengths) enables students to focus on the significance of calculations, not the details of the calculations themselves. This means that students can truly explore and gain intuition on a concept through use of software such as Geogebra or a spreadsheet before they are required to manage the calculations themselves. For students that struggle with arithmetic operations, this enables them to still make observations of mathematical objects, and observe how one quantity affects another. This involvement has the potential to inspire these same students to then make the connections that underlie their skill deficiencies.

Full disclosure though: I don't have a 100% success rate in doing this correctly. I've invested time in programming applications that required much more effort than an analog solution. For instance, I spent a week writing all of my class handouts in HTML because the web browser seemed like a solution that was more platform independent than a PDF. That ended when I realized the technology was getting in the way of my students making notes on paper, a process I respect for its role in helping students make their own learning tools. There are some tasks that work much more smoothly (or are just more fun) using paper and a marker.

I value my student’s time. I value their thoughts. I want to spend as much class time as is possible building a community that values them as well. Where technology gets in the way of this, or adds too much friction to the process, I set it aside. I sit with students and tell stories. I push them to see how unique it is to be in a room for no other reason but to learn from each other. When I can write a program to randomize groups or roll a pair of dice a thousand times to prove a point about probability, I do so.

Knowing which choice is better is the one I wish I could write an algorithm to solve. That would take a lot of the fun out of figuring it out for myself.

## Sensors First - Progress Report

I wrote previously about my plans to change how I teach programming to my LEGO robotics students. By including sensor use as a starting point, my hope is to equip students with the experience to know when sensors can do a better job than simply aiming the robot toward the target and hoping for the best.

Yesterday was my first open ended challenge after beginning this approach. Students needed to build and program their robots to retrieve the loops located at the ends of the black line paths. The time available for them to do so was kept short. As one more way to advantage sensors over a trial and error approach, I told them that I might tell them to start their robot anywhere along the line, and that they could only pick up their robot once while retrieving the two loops.

I really didn't need that final requirement. Students quickly figured out how to adapt the line following tricks I taught them to this task. In a forty minute period, all of the teams made progress and were able to make contact with the loop using a collection mechanism.

The most satisfying result? Not a single group spent significant time aiming their robot. They clearly didn't feel the need, which is a step in the right direction.

Filed under programming, robotics, teaching stories

## Standards Based Grading(SBG) and The SUMPRODUCT Command

I could be very late to the party finding this out. If so, excuse my excitement.

I gave a multiple choice test for my IB Physics course last week. Since I am using standards based grading (SBG), I wanted a quick way to see how students did on each standard. I made a manually coded spreadsheet eight years or so ago to do this. It involved multiple columns comparing answers, multiple logical expressions, and then a final column that could be tallied for one standard. Multiply that by the total number of standards...you get the drill.

I was about to start piecing together an updated one together using that same exhausting methodology when I asked myself that same question that always gets me going: is there a better way?

Of course there is. There pretty much always is, folks.

For those of you that don't know, the SUMPRODUCT command in Excel does exactly what I was looking for here. It allows you to add together quantities in one range that match a set of criteria in another. Check out the example below:

The column labeled 'Response Code' contains the formula '=1*(B6=E6)', which tests to see if the answer is correct. I wanted to add together the cells in F6 to F25 that were correct (Response Code = 1) and had the same standard as the cell in H6. The command in cell I6 is '=SUMPRODUCT((F6:F25)*(E6:E25=H6))'. This command is equivalent to the sum F6*(E6=H6) + F7*(E7=H6)+F8*(E8=H6)+...and so on.

If I had known about this before, I would've been doing this in some way for all of my classes in some way since moving to standards based grading. I've evaluated students for SBG after unit exams in the past by looking at a student's paper, and then one-by-one looking at questions related to each standard and evaluating them. The problem has been in communicating my rationale to students.

This doesn't solve the problem for the really great problems that are combinations of different standards, but for students that need a bit more to go on, I think this is a nice tool that (now) doesn't require much clerical work on my part. I gave a print out of this page (with column F hidden) to each student today.

Here is a sample spreadsheet with the formulas all built in so you can see how it works. Let me know what you think.
Exam Results Calculator

1 Comment

Filed under computational-thinking, physics, programming

## Revising my thinking: Force Tables

I've avoided force tables as a lab in the past. This is primarily because when I first started teaching physics and saw some collecting dust in the lab equipment room, the activities that were written for them seemed so formulaic that I was bored by them. I didn't know then what I might do to make it more interesting.

In making an activity using them today, I actually played around with them a bit. They are a bit tricky to set up, but once you have the weights balanced, it's oddly satisfying to see the ring in the center floating there:

The theme of my lesson planning is a search for this type of gold: how can we play with this?

I've done activities involving 'find the unknown mass' before, and the force table offered an efficient way in to doing this.

I asked students to figure out the mass of the weight circled in blue. I asked them to decide what information they needed to do so, and they requested the other two masses, which I provided.

Students worked quickly using their knowledge of forces and equations of equilibrium. They figured out pretty quickly that the angles between the threads were approximately equal, a fact I didn't notice until I looked from above:

Their predicted answer of 290.9 grams was impressively close to the actual answer of 292.2 grams. We discussed that the assumption that the angles were the same might contribute for the error.

On the whole, this was a fun way to put to use a piece of equipment that I've kept out of my classroom for largely silly reasons. I think I'll definitely add this to the playlist for future units on equilibrium.

Filed under physics, teaching stories, Uncategorized

## Revising My Thinking: Repetition

Traveling with students has always been one of the most rewarding parts of the teaching job. Seeing students out of their normal classroom setting draws out their character much more than content alone can. One particular experience on a trip last week forced me to rethink aspects of my classroom as I never could have predicted it would.

On our second day of the trip, students experienced the lives of Chinese farmers. For breakfast, we paced a series of stalls cookies of sizzling noodles, Chinese pancakes, and tea eggs - students could spend no more than ten Yuan on their breakfast. After leaving the market and driving for an hour, we arrived at a village surrounded by tea hills. Here, the farmer experience began. The students were divided into three groups and set out to compete for first, second, and third place in a series of tasks; their place determined how much the group would be paid in order to purchase dinner that night.

Students tilled the ground with hand tools to plant vegetables, with a seasoned farmer showing them what to do, and then judging them on their efforts. The farmer's wife gave a dumpling making lesson, and then had students make their lunch of dumplings according to her example. The third task involved collecting corn from a nearby field and putting it into a woven sack. Teams were judged by both quantity and quality. Many students tossed out corn that had shriveled kernels and silk from beetle larvae around the stalks. Students at this point guarded their yellow post-it notes (where the guide recorded their earnings) carefully, chasing them down when they flew away in the wind.

In the final task, students were to earn money by assembling plastic pens. For every one hundred pens put together, the group would earn 1 Yuan, or about 16 cents. Our guide said we would work on this for three hours. I prepared her for the likelihood that the students might not last that long. Such a simple task would surely result in disinterest, especially in a group that was already distressed by our insistence that their mobile devices stay put away for the majority of the day. To myself, I questioned whether an investment of three hours into the task was really necessary to get students to appreciate the meaning of a day of hard work or to understand the required input of human energy to create a cheap plastic item. They were already exhibiting signs of fatigue before this, and a repetitive task like this couldn't make things any better, right?

The first pattern I noticed was that students quickly saw the need for cooperation. Each student felt the inefficiency of building one complete pen, one at a time. Without any input from adults, the students organized themselves into an assembly line. They helped each other with the tricks they discovered to shave off seconds of the process. They defined their own vocabulary for the different parts and stages of assembly. Out of the tedium, they saw a need for innovation, and then proceeded to find better ways on their own. While they worked, they sang songs, told jokes, and made the most of the fact that they could socialize while they worked.

The students were brutally honest with our guide about the value of the work they were doing. They expressed disbelief that they couldn't be paid more for their time. The guide responded by reminding the students of the real costs of things: 17 Yuan for a chicken, 2 Yuan for bottles of clean water at dinner. The students responded by asking for the price of the pens at the market ("0.8 yuan each" said our guide) and said that without the people working, the pens wouldn't be made. By the end, students had assembled 3,880 pens, and had smiles on their faces even at that point.

The other outcome of this activity was that each student was permitted to keep one pen as a keepsake of the day. For a group of students that routinely leaves things everywhere, these pens were guarded and treasured as closely as their mobile devices. A couple of them were so attached that they insisted on bringing their pens with them for pre-dinner free time at the creek.

There were so many lessons that came out of the repetitive nature of this task. As I said, I underestimated the level to which students would be engaged by this activity. They took pride in their work. They tested their pens carefully before counting and bundling them together with a rubber band. They took time to understand what they were doing in order to find better ways.

I routinely look for students to have similar discoveries in my class. There is repetition. There is a need for careful reflection on the quality of an answer or clarity of explanation.

I do, however, try to hasten this process because I underestimate the value of repetition during my class period. I've argued before that class time should be spent making the most of the social aspect of the classroom for learning. Repetitive drills don't tend to make the cut by that standard. This is, after all,one of the points I frequently make about the role of computers and computational thinking. I do introduce students to tedious processes, but usually cut out the middle part of students feeling that tedium themselves, because I figure they get it without needing to actually experience it. I do this to save time, but I now think I might be spoiling the punchline of every lesson in which I take this approach.

After seeing the students themselves invent and create on their own and as a group (and with no adult intervention), I now feel the need to rethink this. Perhaps I'm undervaluing the social aspect of repetitive tasks and their potential for building student buy-in. Maybe class time with meaningful repetition is valuable if it results in the community seeking what I have to share from my mathematical bag of tricks. Maybe the students don't fully believe that my methods are worth their time because I tell them what they should feel instead of let them feel it themselves.

Perhaps I'm also reading too much into what I observed on the trip. I am , however, quite surprised how off the mark I was in predicting the level of engagement and enjoyment the students would have in spending three hours assembling pens. I'm willing to admit my intuition could also be off on the rest.

Filed under reflection, teaching philosophy

## Sensors First - A Changed Approach

I presented to some FIRST LEGO League teachers on the programming software for the LEGO Mindstorms EV3 last week. My goal was to present the basics of programming in the system so that these teachers could coach their students through the process of building a program.

The majority of programs that students create are the end product of a lot of iteration. Students generally go through this process to build a program to do a given task:

1. Make an estimate (or measurement) of how far the motors must rotate in order to move the robot to a given location.
2. Program the motors to run for this distance.
3. Run the program to see how close the robot gets to the desired location.
4. Adjust the number in Step 1. Repeat until the robot ends up in the right location.

Once the program gets the robot to the right location, this process is repeated for the next task that the robot must perform. I've also occasionally suggested a mathematical approach to calculate these distances, but the reality is that students would rather just try again and again until the robot program works. It's a great way to introduce students to the idea of programming as a sequence of instructions, as well as familiarity with the idea that getting a program right on the first try is a rarity. It's how I've instructed students for years - a low bar for entry given that this requires a simple program, and a high ceiling since the rest of programming instructions are extensions of this concept.

I now believe, however, that another common complaint that coaches (including me) have had about student programs is a direct consequence of this approach. Most programs (excluding those students with a lot of experience) require the robot to be aimed correctly at the beginning of the program. As a result, students spend substantial time aiming their robot, believing that this effort will result in a successful run. While repeatability is something that we emphasize with students (I have a five in a row success rule before calling a mission program completed) it's the method that is more at fault here.

The usual approach in this situation is to suggest that students use sensors in the program to help with repeatability. The reason they don't do so isn't that they don't know how to use sensors. It is that the aim and shoot method is, or seems, good enough. It is so much easier in the student's mind to continue the simpler approach than invest in a new method. It's like when I've asked my math students to add the numbers from 1 to 30, for example. Despite the fact that they have learned how to quickly calculate arithmetic series before, many of them pick up their calculators and enter the numbers into a sum, one at a time, and then hit enter. The human tendency is to stick to those patterns and ideas that are familiar until there is truly a need to expand beyond them. We stick with what works for us.

One of my main points to the teachers in my presentation was that I'm making a subtle change to how I coach my students through this process. I'm calling it 'sensors first'.

The tasks I give my students in the beginning to learn programming are going to require sensors in order to complete. Instead of telling students to program their robot to drive a given distance and stop, I'll ask them to drive their robot forward until a sensor on their robot sees a red line. I'll also require that I start the robot anywhere I want in the test of their program.

It's a subtle difference, and requires no difference in the programming. In the EV3 software, here's what it looks like in both cases, using wheels to control the distance, and a sensor:

What am I hoping will be different?

• Students will look to the challenges I give them with the design requirement built in that aim-and-shoot isn't an option that will result in success. If they start off thinking that way, they might always think how a sensor could be used to make the initial position of the robot irrelevant. FLL games always have a number of printed features on the mat that can be used to help with this sort of task.
• When I do give tasks where the students can start the robot wherever they choose, students will (hopefully) think first whether or not the starting position should matter or not. In cases where it doesn't, then they might decide to still use a sensor to guide them (hopefully for a reason), or drop down to a distance based approach when it makes sense to do so. This means students will be routinely thinking what tool will best do the job, rather than trying to use one tool to do everything.
• This philosophy might even prompt a more general need for ways to reduce the uncertainty and compound error effect associated with an aim and shoot approach. Using the side of the table as a way to guide straight line driving is a common and simple approach.

These sorts of problem solving approaches are exactly the way successful engineering design cycle works. Solutions should be found that maximize the effectiveness of a design while minimizing costs. I'm hoping this small change to the way I teach my students this year gets them spending more time using the tools built into the robot well, rather than trying to make a robot with high variability (caster wheels, anyone?) do the same thing two times in a row.

Filed under computational-thinking, robotics, teaching philosophy

## Ultrasonic Sensors & Graph Matching: Play, then learn

In my physics class this morning, the plan was to have students work through a packet of descriptions of constant velocity motion. Each description was either a position vs. time graph, a velocity vs. time graph, or a motion map. Students would then sketch the corresponding velocity/position graphs, and then actually act out these scenarios in front of an ultrasonic detector. With a live graph showing them what their position vs. time graphs were as they moved, mayhem invariably would result.

I had a last minute change to my plan this morning. Following the ideal set out by one of my favorite books as a kid and my favorite museum (the Exploratorium), I asked 'how can we play with this?'

I had the sensor ready to go at the start of class. I told a student to walk back and forth in front of it while data was collected. I didn't have to give any other instruction - they saw how their movement resulted in a graph.

I then put two post-it notes on the screen and told another student to make the graph hit them both:

This was probably the first time since the first day of school that the class was all smiles.

After they had this figured out, I gave them another task: hit the post-it notes, but also make the graph go along a string taped to the wall:

This took a bit more time for developing intuition, but they got this down.

It was only at this point when I introduced the packet of scenarios. They went right to work and sped their way through, helping each other when differences arose.

My usual assessment activity for this has always been that I could call each student up to generate a specific graph. Since they don't know who I'm going to call until the last minute, they ideally would work to understand how to generate each graph in front of the detector so that they were ready in case I called them up.

A student this morning said point blank that this plan did not sound fun at all. When I thought about it a bit more, I realized it was a fear based activity. The student instead suggested that I call each of them up, and give a number for a graph that needed to be generated, and the rest of the class could guess which one it was.

Clearly a superior idea. We proceeded to run the activity this way, and it was a blast.

I'm not sure why I haven't done this activity this way in the past. It's obviously superior to almost anything else for a number of reasons.

• The activity starts with no numbers, just intuition and feedback. It's fun seeing your own movement be simultaneously measured and displayed in front of you. The need to communicate about the process is where the vocabulary and numerical measurement comes in - that's a perfect place for a teacher to step in once students are digging the activity.
• The idea of setting an origin and detailing the meaning for increasing or decreasing position values isn't necessary here. Students figure out quickly how these relate to their own movement without any intervention on my part.
• Any activity that gets teenagers out of their seats and moving around during the first block of the day (and does so in a way that also directly serves the learning goals of a lesson) is going to be vastly superior to pretty much everything.

A great way to open a rainy Wednesday in Hangzhou, by any measure.

Filed under physics, teaching stories

## Uncertainty about Uncertainty in IB Science

I have a student that is taking both IB Physics with me and IB Chemistry with another science teacher. The first units in both courses have touched on managing uncertainty in data and calculations, so she has had the pleasure (horror) of seeing how we both handle it. For the most part, our references and procedures have been the same.

Today we worked on propagating error through the calculation $\Delta x = \frac{1}{2}at^2$ with uncertainties given for acceleration and time. The procedure I've been following (which follows from my experiences in college and my IB textbooks) is to determine relative error like this:

$\frac{\delta x}{\Delta x} = \frac{\Delta a}{a} + 2 \cdot \frac{\Delta t}{t}$

In chemistry, they are apparently multiplying uncertainty by 0.5 since it is a constant multiplying quantities with uncertainty. On a quick search, I found this site from the Columbia University physics department that seems to agree with this approach.

My student is struggling to know exactly what she should do in each case. I told her that everything I've seen from the IB resources I have in physics supports my approach. The direct application of the formula suggests that an exact number (like 1/2) has zero uncertainty, so it shouldn't be involved in the calculation of relative error. That said, the different books I've used to plan my lessons agree with each other to around 95%. There is uncertainty about uncertainty within the textbooks discussing how to manage uncertainty. Theory of knowledge teachers would love the fact that teachers of a generally objective field (such as science) have to occasionally acknowledge to our students that textbooks don't tell the entire story.

The reality is that there are a number of ways to handle uncertainty out in the world. Professionals do not always agree on the best approach - this conversation on the Physics Stack Exchange has a number of options and the mathematical basis behind them. For students that are used to having one correct answer, this is a major change in philosophy.

Thus far in my teaching career, I haven't delved this deeply into uncertainty. The AP Physics curriculum doesn't require a deep treatment of the concepts and roughly ignores significant figures as well. I talked about some of the issues with uncertainty with students, but I never felt it was necessary to get our hands really dirty with it because it wasn't being assessed. We also learned error analysis in my experimental design courses in college, and it was part of the discussion there, but it was never the class discussion. It's really interesting to think about these issues with students, but it's also really difficult.

It seems that the questions that have resulted both from class and for my own understanding are exactly the style of conflict that the IB organization hopes will result from its programs. The way this student throws her hands up in the air and asks 'so what do I do' and managing the frustration that results is the same difficulty that we as adults face in resolving daily problems that are real, and complex.

The philosophy that I shared with the students was to be aware of these issues, but not to fear them. It should be part of the conversation, but not its entirety, especially at the level of students that are new to physics. I'm confident that some of the discomfort will melt away as we do more experimentation and explore physics models that tend to describe the world with some level of accuracy. The frustration will yield to the fact that managing uncertainty is an important element of describing how our universe works.

Filed under physics, teaching philosophy

## Graduated Assessment & Web Design

I decided to try teaching programming this year as a class, specifically HTML, CSS, and Javascript. My hope is to get students to the point that they can put together a basic Meteor app by the end of the year, along with a good set of skills for building web pages from scratch.

My assessment scheme for the class is through a series of projects. Some are small, some are bigger and more open ended. I noticed during class on Tuesday that students are cutting corners by copying HTML from files we used in earlier classes. I admittedly do this all the time, but I pay the price for doing so in time spent cleaning up fragments of code that I really could have written from scratch in less time. In the general series of trying to teach good habits, I decided to give a graduated assignment that went through the series of HTML concepts we have learned over the past two weeks.

The requirement is that students need to make one HTML file for each of the ten steps in this file. They have to start from a blank HTML template that has nothing more than the basic head and body elements. I also had students write out the code for the first three steps by hand.

The effect today in class was a clear measurement of where each student stands in understanding how to piece together HTML from scratch. I collected the folders of files from students at the end of class and can see precisely where their difficulties are. Some of this comes from just knowing what step they were on at the end of class, but I also had some good conversations with students throughout the period today. My class, thankfully, was pretty honest in showing what they do and don't understand how to do. While there has been some code sharing in the class before, they seemed to appreciate this opportunity to step their way through the progression of what we've learned so far.

I think there's an analogue in math and science here - I've given leveled practice sheets before in various mathematics topics. The willingness to push through misunderstanding and admit difficulties seems to be a lot more substantial in a programming context.

Here's the full exercise:
day5-Step Instructions

Filed under programming, teaching stories

By my last week in the states this summer, I had made it to San Francisco. Before getting to the hard work of eating sourdough and tinkering my way through the Exploratorium, I made two stops that were really special.

The first was a chance to meet the Desmos team at their office, arranged by Dan Meyer, who was planning to be at the office. I walked into the office while the team, not two days from the successful release of their newest activity Central Park, was on a conference call discussing the next project. As my time with them went on, I periodically felt a wave of giddiness at the fact that I was sitting with some of the people responsible for making Desmos what it is.

The four people that I met there, two thirds of the entire team, had their hands in making a difference in hundreds (if not thousands) of classrooms around the world. Jason shared that his changes to some code had resulted in a substantial increase in the code speed. Jenny showed her prototypes for a beautiful new user interface. Eric repeatedly referred to the guiding principles of Desmos as they made decisions about moving forward. The careful, deliberate work done by this group of passionate people is the reason Desmos is able to create the collaborative learning experiences for which they are known.

At one point, David Reiman, one of the team members and a former teacher himself, asked me what they could do for me. Honestly, all I could muster was that it was an honor to learn from them and see their workflow. They put a lot of energy into making sure their tools are useful for reaching objectives in the classroom, not for the sake of merely being used in the general category of technology. I really appreciate Dan, Eric, Eli, and the rest of the team for arranging to spend time with me.

The next day involved a visit to Meteor headquarters for their monthly Devshop. This is a meeting that gets Meteor coders and entrepreneurs in one room with the goal of everyone helping each other. It was impressive to meet in person some people that I had really seen only as Twitter handles. They were all incredibly genuine, humble people that worked really hard on work that mattered to them. I gave a lightning talk on coding for the classroom (posted here on YouTube) and using code to make my life as a teacher easier. Mine was one of a series of such talks. They were streamed live on the internet, but it seemed much more intimate in the actual room. Each person had three minutes to talk about an idea that mattered to them. It was also a treat that people that came up to me to chat afterwards - some of them teachers themselves - to talk about teaching, coding, and the challenges of teaching effectively with technology.

The theme that struck me after both days, a theme that I think resonates strongly with the beauty of the existence of the Math-Twitter-Blog-o-sphere, is not just that individuals (and teams) are doing interesting, thought-provoking work. That has been true for a long time.

The people at Desmos and Meteor are designing tools that enable others to not just explore their ideas, but develop, build, and share them. Just as these tools are created iteratively (Meteor released version 0.9 today) they encourage others to make the most of what is out there to put ideas in front of an audience and make them better over time. That audience might be a classroom of students. It might be an audience craving a useful online tool that targets their unique niche. Everyone at these companies (and in classrooms) is hoping that the next idea they try is one that gets more people excited than the last. Teachers work in a similar vein hoping that their next idea for tweaking a lesson gets more students engaged and making connections than the last.

I've spent the past three academic years interacting with people through this blog, Twitter, and other online channels. I've shared ideas here and have gotten feedback on them from a number of different perspectives. All of us are working hard. We have ideas and share them because ideas sprout new ideas. This process is addictive. We all have our pet projects and obsessions, and need to be brought back to reality from time to time about what will really work most effectively. We listen to each other and value the conversations that happen.

As this year is getting underway, I'm going to work to keep something in mind this year. We all have governing principles that help us decide what work to tackle at a given point in time. We often wait to share ideas until they are fully formed, but that's not really when we need the most feedback. I hope to share more ideas when they are raw and still forming. Bad days, especially when they are still smarting from an unsuccessful lesson, are revealing. It's in these situations that we stand to grow the most. What makes innovative companies like Meteor and Desmos successful isn't that they have the best ideas from the beginning. It's that they know how to cultivate ideas from beginning to end, and aren't afraid to make mistakes along the way. They acknowledge that there are lots of starts and stops and hiccups before ending up on the idea that will make a difference to people.

Have a great school year, everybody!