I have this weird conceptual tick where it bugs me when the term “coding” is used to mean things that aren’t coding. I’ve been trying to figure out where it comes from: am I just being a pedantic engineer, or is there actually something here?
I think I’ve figured it out, at least partially. Let me use two examples: cooking and legos. (These aren’t perfect analogies, but hopefully they’ll help illustrate my point.)
Lego Webmaking: Build a lego house. Grab a whole bucket of legos and create the tallest structure you can without it falling over. Understand how pieces snap and unsnap together. Recreate famous photos in Lego form.
Lego Coding: Write those Builder’s Guides that come with lego kits and show you how to build things. Learn how to put together easy-to-follow steps.
Cooking Webmaking: Make an omelet with whatever leftovers are in your fridge. Stir fry some veggies and meat and serve over rice. Nomnomnom.
Cooking coding: Write recipe books. Figure out if you wanna divide the sections by ingredient (“Chicken”, “Beef”) or meal occasion (“Brunch”, “Appetizer”) or locale (“Italian”, “Indian”), etc.
Webmaking is not just the amateur version of coding. They are different skills. Coders spend all day thinking about things (like how you want to divide the sections of a recipe book for easy recipe-retrieval later) that have no baring on webmaking (cooking an omelet).
So why do I care?
Creating new awesome coders is a goal that companies should (and rightly do) think about. I totally support this goal — we have a lack of software engineers, especially represented amongst certain minorities, and this is probably indicative of some deep fundamental issues that should get resolved.
But I’m not convinced that coding is a skill that everyone should know, the way that I think that everyone should know how to search for information on the web. Here’s some examples of skills that you need to be a good coder, that rank pretty far down on my “everyone should know” list:
- Big O complexity
- Data structures
- Managing program complexity using abstraction
- Testing and testability
- etc.
I think that your average citizen should learn how to manage program complexity using abstraction just after they’ve learned about scarification in stone fruits, feline tastebuds, and the lyrics to every Animaniacs song. (I can already see the lineup of angry engineers gathering pitchforks and heading to my door at this statement.)
I don’t want to create a generation of people who know how to write recipe books. I want to create a generation of people who reach into their fridge, pull out random ingredients, and know how to make themselves an omelet. Eating at home lowers your cancer risk. And though we need great recipe book authors in order to make it easier for everyone else to learn how to cook at home, we don’t need them all to be recipe book authors themselves.
Michelle,
Those are really intriguing analogies, and I completely agree with your primary point that crafting web pages is not a form of coding.
I think your list of skills to be a good coder are really the skills needed to be a good software engineer. And I agree with you that software engineering skills are not part of web literacy or web making.
However, I have a strong intuition (that I can’t explain articulately) that learning to do some simple programming is a valuable because it forces a kind of rigorous step-by-step sequential thinking that people might otherwise not be exposed to. I think that we should teach kids a bit of programming, not as a job skill or to give them a head-start on becoming software engineers, but because it is a critical thinking skill! (And I look forward to hearing with Cathy Davidson has to say Wednesday about algorithmic thinking: http://lanyrd.com/2012/CathyDavidson/ )
I don’t have a pitchfork, and I agree that big O notation can be left for college-level algorithms class. But abstraction is a fundamental part of technological society. When students learn about the scientific method in school, I think they should learn about abtraction (and testing, too) as part of the “engineering method”. And the easiest way to teach abstraction might, in fact, be by writing some programs.
As for data structures…I’ll just say that there are some interesting analogies between software data structures and the “thinking maps” (http://www.mapthemind.com/thinkingmaps/thinkingmaps.html) that have started to appear in my kids elementary school.
Interestingly, I’d choose to teach different aspects of computer science/software engineering than David, probably for different reasons.
Big O and data structures should probably be taught. Not in an advanced way, not in depth with all the theory, but for instance, some data structures are very intuitive:
Probably everyone already know what a list is. It’s quite easy to teach what trees are: comments on a blog form a tree (assuming it’s possible to responds to a particular comment). This is data structure and yet still something people can understand quite easily.
For Big O, it’s not important to teach people how to calculate the complexity of any algorithm, but it’s important to give them an insight of what “linear” and “quadratic” (or at least “bigger than linear”) are so that when they use the same algorithm with bigger data, they are able to understand what part of their program is to blame.
Very soon, I’ll be involved in a “web data journalism” project-thingy with some data visualization. There will certainly be some massive amounts of data sometimes, so writing giving an insight of what algorithm is ok and which may be dangerous performance-wise will be important to convey to the journalist students (who are not computer scientists).
The term ‘making’ means absolutely nothing to me. I’ve been seeing it in Planet Mozilla and I still do not know what it means.
Whether I write simple markup, markup with CSS or markup, CSS and JS, I consider it coding.
@pd & @B.J. Herbison
Regarding the difference between making and coding, consider a blog, a Youtube channel or websites like paper.li (see example at http://paper.li/FuzzyFox0 ). In all these cases, people (anyone!) can “make” without “coding” and this is a very important distinction.
While “coding” requires years of practice, I have seen people successfully “webmaking” by just “transfering” their writing skills to the web medium.
The verbs “make” and “code” seem too similar to me to be a useful distinction. If someone says “I’m going to make a web page” and someone else says “I’m going to code a web page” I wouldn’t notice a distinction.
The distinction you seem to be making is how much knowledge and planning go into something.
It’s good for everyone to be able to cook an omelet, or to make a web page to present an idea they have. That’s reasonable.
But to produce consistently omelets, having the omelets come out the same even when ingredient quality varies, to know how to substitute ingredients well, to know what flavors go well together, to consider overall nutrition and health–that requires lots of practice, and information you can’t get from just practicing. Similarly, if you go beyond a simple text web page and go into fancier designs, interactivity, storing information, you need to do more than just practice simple web pages.
Cookbooks make many recipes accessible to many people, but for many people it’s too much trouble to pull out a cookbook, by the ingredients and follow the directions. To let more people do more on the web we need good tools (easier to use than a cookbook) that guide them through the process, taking care of complex steps and preventing them from accidentally trying something they don’t have the skill to pull off. (If they want to learn more, that’s great, but tell them in advance “you will need to learn if you want to do this”.)
(I’m also not happy with your analogies. Building a lego creation and creating a manual are different domains, not different aspects of the same domain.)
pd: “making” is borrowed (I believe) from “makers”: the do-it-yourself hobbyists who like to tinker and make things and believe that they are the vanguard of a “maker movement” See O’Reilly’s Make magazine, for example.
(And speaking of Make magazine, Michelle, I wonder if we could pick Dale Dougherty’s brain or get him to come talk at a mofo event or something. As creator of the first commercial website and publisher of Make, he might have interesting things to say about webmakers…)
I suppose the fundamental distinction you’re drawing with “make” vs. “code” is hobbyist vs. professsional. You don’t have to go to culinary school to make a good omlette, and you don’t have to go to journalism school to publish news and opinion on a blog, but you do have to be passionate (i.e. a hobbyist) about food or blogging to do those things well.
Mozilla isn’t in the business of training software engineers or professional web designers. But we do believe that web literate citizens — who can participate in and extend (“make”) the web in a non-professional capacity — will create a better web and a better world.
I like the term “make” or “makers’. When Dale Dougherty talked at the Mozilla Learning, Freedom and the Web unconference two years back, he talked about how for his magazine, Make, they came to that term because it was gender as well as discipline neutral. I think THAT is important when choosing words to describe the large amount of different projects that someone could be involved with on the web.
I think that your definition here of “coding” is right on- and actually it is often something that I deal with, when people talk about “coding a website” that is only html and css. However, when I read about lego or cooking coding, I can’t help but want to add design thinking into the conversation. So often when people think of code, they think of the recipes to accomplish something, however, as we know a crucial skill is taking pause and designing a solution – whether that be designing the what is going to be built with the lego kit or the table of contents in the recipe book.