> Tyrangiel says the piece is worth reading, not only because of the herculean efforts behind programming the page, but because it truly does bridge the gap between laypeople and programmers.
I'd like to see the proof in the pudding...in the original piece, Ford described how it was commissioned by the Bloomberg Businessweek editor who asked Ford, “Can you tell me what code is?”
It'd be interesting to hear from the editor -- after spending weeks (months?) editing all 38,000 words of Ford's piece -- can he/she now tell _everyone else_ what code is? I liked the piece (though I didn't finish all of it and skimmed a few parts)...but a lot of it struck me as reading that was very interesting/amusing because I was already a coder...I'm interested in what non-coders learned from it.
My impression reading the "code" parts of it was, "There's no way in hell I would understand this if I weren't a coder." You'd understand the culture, sure, but if you've never programmed would you grok this paragraph?
> So what if, whaaaat if, we made a little box called Customer (call it a “class,” as in the taxonomical sense, like a Customer is a subclass of the species human, which is a subclass of mammal, etc.), and we put the data and methods relating to customers into that box. (And by box, it’s literally just “public class Customer {}” and anything inside the {} relates to that particular class.)
It's a solid effort, but for someone who isn't technical, jumping from,"ok we have a thing called a class" to "and that's object oriented programming!" is just not something you can do in one paragraph, no matter how well it's written.
The piece uses this bewildering-for-the-lay-person language sparingly, and I think it's intended to be bewildering. It seemed to me to be meant to confuse you at times, to then later make it clearer, or to provide an escape hatch, if the reader so desired to give it a try. It's meant to give an impression of, an emotional connection to, what it means to be a programmer. To be a programmer is to take on understanding that bewildering language. It's not just some magic that we can do because we "get" computers. It was hard work that got us here.
I agree with both of you. I think the piece is brilliantly done, and the writing is just jaw-droppingly good. But I said to myself, about half-way through reading it: there's just no way a non-coder is going to "get it".
But then, how much better a job could anyone do to explain it to a non-coder? Past a certain point, you either dive in, or you don't.
I think it's brilliant too - possibly the first ever piece of genuine digital journalism.
And I think it's worth making a distinction between two aims - understanding a little about code and the culture around it, and learning how to write professional code.
Obviously you're not going to do the latter in 38,000 words.
I think WIC is great--very enjoyable--and agree with this article that its presentation is basically a work of art, but it fails to explain "this is what code is," especially for the layperson.
Before reading this article I reflexively sent it to my wife, thinking that WIC will clarify what it is I do for a living. WIC does that remarkably in explaining what it is like to be a programmer. It tackles the business side of things, the current trends, and some history. But it is much less successful, when it comes to explaining the code.
An example of where it fails in explaining code to the layperson is the part about compiling C code in the command line. Yes, a layperson could follow this step by step, but I think if they did they wouldn't be able to put it in a larger context. Ok, it is compiled but what does that mean? How does that compare to other languages? These are questions that are left unanswered for laypeople, so it is just confusing and unrewarding.
For me as a professional dev, I enjoyed that part, especially because I could relate to it: it is like finding a basic tutorial on line, starting from scratch and following it line by line, something I do all the time. WIC is an excellent insider piece that really captures the zeitgeist of programming. The question should be reframed. If you really want to know "What is code?" you should read Petzold's Code. Any layperson could read it. You would have to work but it rewards. What is Code is better at answering "What does it mean to be a coder right now?
> An example of where it fails in explaining code to the layperson is the part about compiling C code in the command line. Yes, a layperson could follow this step by step, but I think if they did they wouldn't be able to put it in a larger context. Ok, it is compiled but what does that mean? How does that compare to other languages? These are questions that are left unanswered for laypeople, so it is just confusing and unrewarding.
I'm not sure this is a drawback to the article. Compiled vs. interpreted and etc. etc. is a huge set of things to explain and would muddle the point. Most laypeople probably aren't interested in the hypertechnical details--do you read an article on what it's like to do mathematics and come out wondering why they didn't go into more depth explaining why functions over complex manifolds have interesting properties? Is it not enough to say "Ok, continuous functions over complex manifolds are interesting compared to the functions you learned in high school (like y=x^2+x+1) because they are restricted to certain behaviors, which makes them easy to predict"?
In the end, the human story of "What does Jim at the end of the hall do all day, anyways?" or "What do the people who make my phones/car/computer/life work do, anyways?" or etc. is a lot more compelling and interesting than teaching the minutiae of 'code' as an abstract idea in an article, so I doubt a nontechnical layperson leaves unsatisfied with the explanations in the article. I don't look for technical explanations in articles on chemistry or biology, either, since I know I don't have the background to learn about them in what is well under a short book's worth of material--I'm not sure why anyone else would, either.
Right. I think we are actually making similar points. What I was trying to say in my example of the C code compilation is that it doesn't really tell you what code is, but rather this is what it's like to write code, or rather the human story--as you described it.
Paul Ford and his editor Josh Tyrangiel went on Charlie Rose's show last week to talk about the essay, and you can get some sense of Tyrangiel's acquisition of the topic:
Well, a really interesting evaluation would be to develop a pre-test/post-test for some learning objectives about what it means to understand code, and then have this be the presentation of an instructional unit. You could measure this fairly empirically and simply. Of course, you'll end up having the question - "does this teach better than something else?"
I'd like to see the proof in the pudding...in the original piece, Ford described how it was commissioned by the Bloomberg Businessweek editor who asked Ford, “Can you tell me what code is?”
It'd be interesting to hear from the editor -- after spending weeks (months?) editing all 38,000 words of Ford's piece -- can he/she now tell _everyone else_ what code is? I liked the piece (though I didn't finish all of it and skimmed a few parts)...but a lot of it struck me as reading that was very interesting/amusing because I was already a coder...I'm interested in what non-coders learned from it.