Category Archives: programming

Coding or programming?

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.

Learning to Code: Are block or text-based languages best?

Learning to code with Snap!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:

  • There are many, many different kinds of languages used in the real world.
  • Today’s languages will not be tomorrow’s languages.
  • Just because a language is used by software developers doesn’t make it a developmentally appropriate language for learning to code.
  • There is lots of coding done in the real world outside of software development. Every area, from history to biology to music production has languages that are specific to the field.
  • Last but not least, the experience of coding is about acquiring mental models of computing that meet your personal needs and interests, not about getting a job in the future. (Or at least that should be true.)

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.

Negotiating the future

“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

“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).

Biology or code? Both.
Biology or programming? Both.

When you see this, ask yourself — how long can we teach science and math as if time stopped centuries ago?

Classroom supplies of the (near) future
Classroom supplies of the (near) future


How to teach coding

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

Did “Hour of Code” work? One school’s experience

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