Professional site of Sylvia Libow Martinez
2020 Florida Workshops
Feb 10, 2020 Fort Lauderdale, FL
Feb 12, 2020 Jacksonville, FL
Join me and Gary Stager as we host one-day workshops on coding, making, and physical computing in Florida.
This workshop will focus on the amazing opportunities for students to code and make across the curriculum using new micro-controllers like the BBC micro:bit. Even better, every participant will go home with a micro:bit of their very own!
We are excited to announce that a newly revised and expanded edition of Invent to Learn: Making, Tinkering, and Engineering in the Classroom has just been released.
It’s been five years since Gary Stager and I published the first edition of Invent to Learn. In that time, schools around the world have embraced making, makerspaces, and more authentic STEM/STEAM experiences for all children. It’s been fun to be a part of this worldwide phenomenon!
The brand new second edition includes a lot of new material reflecting how much has changed in a few short years. There are many new microcontrollers to choose from, and many more that are better for school use. The fabrication chapter has been updated to reflect how the design process has been streamlined by hardware and software progress. There is an entirely new section on laser cutters and CNC machines.
Programming options have expanded as well with software appropriate for students as young as four years old. Finally, there are some fantastic and accessible environments for programming microcontrollers. When we published the first edition, we were positive that a good block-based programming language for Arduino was just around the corner. Although new software environments emerged, they lacked the polish and stability required to make a difference in classrooms. Now things are different.
There is more research about the positive impact of fabrication, robotics, and coding to share. All of the suggested resources have been updated and expanded. The online resources here on inventtolearn.com are even more extensive.
The additions and updates to the book go beyond mentions of new technology and fixing broken URLs. There are new examples from educators around the world who have embraced making in their classrooms. There is more context provided for the connections between project-based learning and making. We attempt to be clearer about the real reason that making matters—not to build a special room or purchase equipment, but to make schools a better place for ALL students and teachers to learn.
The second edition is now available in paperback, hardcover, and Kindle on the Amazon website and other online retailers. For volume sales, using a PO, or international sales, please contact sales@cmkpress.com.
I spent some time working through the first bunch of “coding” tutorials in Swift Playground from Apple. It’s slow, wordy, and arbitrary about how it introduces concepts. Just one example – the tutorial lets you turn left, but not right, because it wants you to make a “right turn” function out of three left turns. That’s weird and bossy. It’s immediately annoying that it takes 3 times as long to turn right as to turn left. What if I didn’t want to do it that way? Do they think I can’t handle a right? Oh, they just want to force me to realize that you can group multiple commands. And if I don’t get it, they over-explain it with lots of words. LOTS. OF. WORDS. Thanks Swift – coding is all about doing what you are told instead of figuring things out with flexible tools!
There are a lot of quirks in how you add and edit the commands–clunky is a kind description.
It reminded me of Lightbot, a cute puzzle app. Except Lightbot is more fun and is at least 10 years old. They couldn’t do better than that? LightBot says it’s “a puzzle game based on coding” and “teaches you programming logic.” At least they are honest!
We don’t pretend that solving crossword puzzles teaches writing. (Well hopefully not.) The same applies to coding.
The way to learn to code is by coding, not doing logic puzzles.
Gary Stager and Sylvia Martinez contributed a chapter to Creating the Coding Generation in Primary Schools: A Practical Guide for Cross-Curricular Teaching, edited by Steve Humble and just released from Routledge.
The chapter is called: Ten Considerations for Teaching Coding to Children
There is a sneak peek available online here via Google Preview (Look for Chapter 3)
In recent years, it’s become popular to call the act of programming computers “coding.” Some people claim that there are differences, that there are no differences, that it depends on the level of the language used, or that coding implies informality and therefore is less thoughtful or skilled than programming. Wikipedia seems to be trying to parse that difference in its definition of computer programming.
My personal experience being in software development over the time this vocabulary shift happened is that both the act and the terms slowly merged. When I started programing (back in the stone age) HTML and websites did not exist. My job title was software engineer and my job was programming computers. The term “coding” simply didn’t exist.
Programing a computer meant designing algorithms and creating the machine instructions that would react to the real world, do complex math or data manipulation, and output results. This applied to programming jet navigation software or programming games. (And I did both!)
After the web and HTML appeared, people were hired in technical positions to make websites. HTML is a markup language, not a programming language. HTML “marks up” the text, just like a human editor does, and controls how text is displayed, like making certain words bold. Way back when, it was pretty simple and making websites was called scripting or coding.
You programmed computers—you coded websites. I can’t say that in EVERY job in every industry this was true, but in my world at that time this was a big distinction in hiring, job descriptions, and pay.
As time went on, websites and the languages used to create them became more complex. Websites are no longer passive, simple text manipulation. The line between the network and computer became less distinct, and the functions, tools, and practices merged.
There was never one day when people said, OK, coding now equals programming, it just happened. Coding or programming? Whatever you choose, it’s a vocabulary shift that is here to stay.
Many people assume that graphical, or block-based interfaces for programming are a “baby step” in learning to code. Not true! This article, written by a software developer helps dispel that myth and explains why graphical programming languages are “real” programming.
From: TechAge – Graphical vs Text-Based Coding for Kids. Read the whole article! But here’s the summary:
Graphical vs textual isn’t really that important an issue.
It’s whether a particular language allows your child to do what they want to do in a way that’s efficient and enjoyable for them.
Start with what they want to make and find a good language for that which is suited to their expertise level and the way they think.
It’s a myth that adults don’t use graphical languages. They do.
This is a good article to share with parents who are pushing back on learning to code with Scratch and arguing for “real” programming languages like C++.
I’m in favor of this functional argument for learning to code. The best language is the one that does the job. If the job is to “mess around” with some of the big ideas of programming, then graphical languages do that well. The argument that we should teach children “real” programming languages used in the “real” world of work falls flat when you consider:
For more information about a variety of graphical, or block-based programming languages that support learning to code, see The Invent To Learn Guide to Block Programming.
“IF YOU FOLLOW the ongoing creation of self-driving cars, then you probably know about the classic thought experiment called the Trolley Problem. A trolley is barreling toward five people tied to the tracks ahead. You can switch the trolly to another track—where only one person is tied down. What do you do? Or, more to the point, what does a self-driving car do?
Even the people building the cars aren’t sure. In fact, this conundrum is far more complex than even the pundits realize.” – from Self-Driving Cars Will Teach Themselves to Save Lives—But Also Take Them (by Cade Metz, Wired)
Yes, this is a conundrum – but the real dilemmas that will arise from self-driving cars and other “smart” machines will not be the rare life-or-death ones. They will be the smaller, every day, every millisecond decisions. They will be 99.9999% mundane and hardly noticeable — until they aren’t. Since all these machines will be networked, not only will they make decisions, they will communicate, and therefore negotiate with others.
Imagine an ambulance is making its way through traffic. Drivers know to pull over and make way. Self-driving cars will have to as well. That’s a decision to override normal behavior based on social convention and law. But what if you have a pregnant passenger who has just gone into labor? Should it matter that the ambulance you make way for has a patient with a much less critical condition? Should there be some way to assess priority?
What if the siren is from a police car that carries an officer just impatient to get to lunch? (It happens!) Should these vehicles negotiate for their own rights to move ahead of others? Traffic signals could also be in this negotiation. They could change or stay green a little longer depending on ranked requests from the network of vehicles in the vicinity. Should every car have an emergency setting that allows it the same precedence as an ambulance? Should emergencies have ratings that would create ranked priorities in traffic? These decisions are going to be made, it’s a matter of when, not if. It’s up to us as a society to think about and decide on these issues.
And what about paying for priority? People pay to use express lanes and we don’t consider that unfair. Is it the same social calculus to have a negotiated price that would get you home 5 minutes faster by changing the traffic signals just a bit, or having other self-driving cars that didn’t pay move slightly to the right as you glide by? It would hardly be noticeable if your car decided to change lanes or slow down by 5%. You might assume it was avoiding a jam or taking a better route, when instead your car just lost a negotiation with a better financed machine. But once you give up the wheel and get used to the car deciding these things, will you know?
Would you let your house adjust the temperature to serve the social good of using less energy in a heat wave? Smart thermostats already do that. How much different would it be to bid for the privilege of using the air conditioner when you really really want it? “I’ll pay up to $20 extra to have A/C tonight.” If it’s a zero sum game, that means that some other person won’t get their A/C that night. So — is it a way to raise more money for public utilities or the opening battle in an invisible, machine-negotiated class war?
So back to the trolley problem. Are five people more important than one? Only if people are equal. That’s going to be programmable, a set value in the complex algorithm that controls the trolley (or car, or traffic light, or…). But as machines learn, it would be as obvious to assign more complex and variable values to humans as chess playing machines assign values to the different chess pieces. So the calculation of who to put in danger would be based not on a calculation of five people vs. one person, but how much each of those people are “worth” to the system that’s doing the decision making. Who (or what) will create that valuation? Will it be based on age, net worth, Instagram followers, number of Tony Awards, or what? If one of those trolley-bound people had the means to pay or some other status that gave them extra worth-points in the calculation, who will decide if that’s fair, just, or human?
We shouldn’t leave that to the machines.
“Bio is the new digital” – Nicholas Negroponte, MIT Media Lab founder
When Nicholas Negroponte predicts the future, you listen (A 30 year history of the future). Now he says that biology is where digital was at the dawn of computers, and that synthetic biology and programmable organic materials are following the same pattern, with costs dropping and capabilities increasing even faster than Moore’s Law.
Watch this amazing 10 minute video from Joi Ito, the current director of the MIT Media Lab.
People ask me why the maker movement in the classroom is so focused on electronics, fabrication, and coding. The answer is simple — that’s what’s available now. More is on the way, and it’s happening quickly. Bio-hacking, organic sensors, and programmable bacteria will be in K-12 schools sooner than you think (and already are in some cases).
When you see this, ask yourself — how long can we teach science and math as if time stopped centuries ago?
Or how NOT to teach coding.
I get a lot of email asking me to look at various computer programming lesson plans and curriculum. “Is it good? Should I use this?” people ask. Some people want me to endorse something, “We’ve created something the kids will love! It’s so maker!”
So let me share one secret, the very first thing I do when I click the link of whatever comes next in the email. I look at the first thing, the very first thing the kids are supposed to do. If lesson number one is bits, bytes, and binary arithmetic, I’m done.
Yes it’s that simple. (You may find it amusing that my decision-making process is so binary.) But it’s what poker players call a “tell.” It shows that they’ve resorted to the “building blocks” theory of learning. It shows that they’ve looked at lots of other programming lessons and that’s where everyone else starts. It ignores constructionist learning theory that the experience is the place to start.
In our book, Invent To Learn: Making, Tinkering, and Engineering in the Classroom, we begin every chapter with a quote. One of my favorites is:
If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. – Antoine de Saint-Exupery
Whether you think the recent “Hour of Code” is a mindless PR stunt, a shameless data grab, a fake solution to a non-crisis, or an awesome way to introduce lots of folks to programming who would otherwise not be is up to you!
However, no matter your stance towards the scheme, there is no doubt that it actually made something happen in lots of schools around the world. What happens next, though, is what really matters.
With that in mind, it’s really helpful when people share in-depth reflections of what worked, and what could be done better next time (since hopefully there will be a next time.) This reflection (Hour of Code: Observations from a Middle School Classroom) is from Philip Guo, who volunteered at The Meadowbrook School, a private middle school outside of Boston, as part of the Hour of Code initiative.
Philip reflected on pair programming, how error messages helped debugging (or didn’t), the different languages used, differences between adults and youth, reflections on participation based on gender and race, and numerous other interesting musings. This article is a MUST READ if you wonder how coding can be taught as a “regular” subject.
And hopefully it will also be a model for others who ran “Hour of Code” sessions, programs, and classes with kids. We need your thoughts and ideas!
Gary and I just lead a day long workshop for teachers at The Meadowbrook School and they are ready and eager to incorporate programming and making throughout the curriculum. It’s wonderful that they are so willing to share their experiences with everyone!
Please read – Hour of Code: Observations from a Middle School Classroom
