Disclaimer: I'm older than average. I can't help feeling nostalgic for the good old days before our thing went mainstream.
Price of success I suppose, but now we have proclamations like "The world belongs to people who code. Those who don't understand will be left behind". Another example in a daily stream of hyperbolic mass media reports, reminding us yet again that 'software is eating the world'.
I have to say I preferred when the whole thing was regarded more as an exciting hobby - mostly by and for those who took the time to study the craft - than a world dominating force. This article may have value, but in those days you knew you were free of the grand statements. Money backs this new world, not code.
>"The world belongs to people who code. Those who don't understand will be left behind".
What a bizarre claim to make. Building houses is a necessary occupation in all societies. Are those of us who are ignorant or simply unwilling to learn the myriad skills needed herein 'being left behind'?
The claim seems to be that some aspects all possible jobs (even building houses) will require at least understanding the premise and possibilities of programming.
There will be more and more jobs that require the basic skills of coding and less and less jobs that require the basic skills of house building. That is what is meant by "left behind". Obviously the best house builders will always have jobs, but the mediocre ones who once were good enough to get basic jobs on most building sites will be in less and less demand.
It's like being an Apple user from the early days when most computer programmers thought having a GUi or user interface standards was for wimps. Now every other person at Starbucks has a Mac or iPhone, and even Linux users claim to care about usability. What happened to my exclusive club?
and the Mathematical Recreations by Robert Kurosaka. Or Chaos Manor (Jerry Pournelle). But to the parent's point, I remember also wanting "world-dominance" even then ;)
I think it's an absolutely amazing piece. I know, I'm on HN, I'm not allowed to appreciate anything, but hear me out.
A lot of people here seem to be criticizing it because it has something they don't think fits everyone: austenallred thinks most people won't like its brief explanation of classes, others seem to delight in picking out things they think most people wouldn't understand and writing snarky comments about them. But "fitting everyone" would be impossible due to the gigantic range of people reading the article. This article brought together everyone: old and young, the suits and the programmers, PHP script-kiddies and artisanal Haskell sculptors into one mass of enchanted readers.
The people I know that read this have almost nothing in common: wannabe teenage intellectuals, middle managers, a kind, witty man in his 70s, spouses of programmers, people learning to code. As another commenter said, this article is something new: an article as an event. [0] An article as art. [1] But instead of dividing people, as may be expected (news events all too often separate crowds into opposing mobs; modern art separates people faster than oil and water) it brought them all together to talk about code.
> 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?"
WIC seemed to me more like a self indulgent brain dump than a work of art or a useful piece of information. First of all, it treats code as being somehow uniquely impenetrable as a value proposition - when we have plenty of similar examples such as any kind of creative art (why is one script worth $100M and another $0 and how can you reliably create one and not the other?) or highly refined mass produced good (e.g. Silicon chips or soda cans) or valuable insight (e.g. Progress in physics can be very expensive and yet be represented as a few scribbles on a page).
You don't need to reduce a computer to a clock with benefits to explain code any more than you need to explain how a typewriter works to explain writing.
A typewriter is an optional tool for producing a written work. With programming the computer is a necessary object required for converting the intentions of a programmer into both information about the world and actions within it. I think it's fundamental to understanding code to grasp a meaningful model of what a computer is and how it turns key presses into code on the screen and in a file, how it turns the code in that file into a sequence of simple instructions and finally what those instructions do.
This article did a good job of that as well as many other aspects of software development.
A keyboard is just as optional as a typewriter. When I first learned to program the device I learned on did not have a keyboard in the sense described; many people have learned to program by, e.g. Flipping switches on a panel.
The first computer-like things (e.g. Jacquard looms) were programmed by physical objects — indeed one of the first gadgets I learned to program used punchcards you punched manually with a pencil.
The digression into keyboards exemplifies the "self indulgent brain dump" issue I am complaining about. It reminds me of "Mathematics made difficult" except that the book in question was humorous and not pretending to make its subject more accessible.
This article is great for a reasonably knowledgeable programmer to read and think "oh yes, this really nails what a complex and subtle and deep thing programming is, how astonishing it is that when I type a key so much magic happens to even make it appear on a screen, let alone be saved somewhere for posterity, and how amazingly clever I am for understanding all this stuff... mostly". What it completely fails to do is explain programming, or "code" to anyone else. And wasn't that the point?
One part of the podcast that stuck with me was the idea of an article as an event. It really was quite a while ago people talked about a text as an event. I mean, like a new book or something.
I guess Buzzfeed (and the like, which is everyone nowadays) is sort of trying to pay for their real journalism with "aww"-clicks and "omg!"-clicks, it wouldn't surprise me if cool articles like this became more of a commonplace thing.
Lots of websites have been attempting to turn their long online feature articles into events. This goes back at least to when New York Times did Snowfall, and probably earlier. I assume that's why Paul Ford got the job on this one.
But they don't appear every day. Or maybe they do, but not always as successfully?
I agree that another success means that we'll probably see more attempts.
Maybe it started life as separate files that were assembled, and is now only being edited ad hoc after the first public commit [1]? Maybe...but there's no reason why the repo couldn't contain the component pieces (by that, I mean the individual sections of the page), and rebuild them via grunt. In fact, that would make it far easier to do ad-hoc fixes...as fixing HTML by hand is always a pain in the ass...nevermind working within a 3,000+ line file.
I guess I'm just "annoyed" because mitigating the problems of working with large, raw HTML -- and other parts of the textfile-to-publishing process -- is one of those things that is so wonderfully the domain of the programmer. For non-programming journalists, there's just no concept of being able to create a one-command deterministic "build" of a story...so separating the story into multiple files is very impractical...because it means you have to reassemble them by copying-pasting when it's publication time. Also, since the average writer tends to work in Word or some other proprietary document format (I've spent a lot of my web production career translating .docx files to HTML to be pasted into a Wordpress body field)...jumping into different files is not as easy as it is when you're working with Markdown and Sublime Text. Also, much harder to do a article-wide search-and-replace across multiple .docx files.
After learning Markdown (specifically, Kramdown) and static content systems like Jekyll and Middleman...I honestly could not be paid to go into a job where I had to build/publish content a non-automated process...e.g. a rich text editor, whether Word or WordPress. Being able to produce good writing means, well, first being a good writer, of course...but it's far easier to focus on being a good writer when the production process is made frictionless.
> You expect your staff to speak in plain language.
> This policy has served you well in many facets of
> operations, but it hasn’t worked at all when it
> comes to overseeing software development.
I totally agree you should aim for a lay understanding of things outside your specialty. Programming is technical, but so are business, law, accounting, and medicine. I feel like explaining tech to non-tech people is something I'm really good at, and I see how hard it is for other programmers. I suspect that if our profession can learn to communicate better it will profit us all---but then on the other hand I don't see my own ability making me rich. Maybe I just haven't figured out how to make the most of it.
And this statement makes me mad:
> All of the computer code that keeps the website
> running must be replaced. At one time, it was
> very valuable and was keeping the company
> running, but the new CTO thinks it’s garbage.
A project manager said to me once that he'd never heard one programmer praise another's code. It's always "This is crap!" Another thing I think I'm good at is coming on to a new project and adopting the style, patterns, and architecture without wanting to reinvent everything. It takes patience to read and understand, and not start too quickly to write. I feel like that behavior sets me apart from even other good programmers, but I don't know how to take advantage of it.
Great read for someone on the business side of the coding community. Very in depth and relevant to those with no coding experience and experts at the same time, curious to see how this sparks coverage on coding and its application to those who haven't ventured into it yet
Wow, that's meta. I find the original article truly a piece of art. It explains code to laypersons but in a way that's also interesting for seasoned programmers. Being able to bridge that gap requires more than just knowing what code is.
I am an "early" programmer. I'm on Chapter 7 of Hartl's Rails Tutorial, took a step back to learn Ruby early on and continued. This was all supplementing my knowledge of HTML, CSS and some basic JS.
I recently decided to start the "From NAND to Tetris" Coursera course which led me to starting Petzold's "Code" and then this article comes along.
There are people like my wife who have zero knowledge of coding, and likely won't ever care enough about it to make it through this article (I tried, she didn't get very far). They just have no interest, and I can respect that.
However for people like myself, I've realized that the more layers of the onion I peel back, the more intrigued I become. When I think about it, I was fascinated by fantasy-based magic systems when I was younger. I'm talking things like D&D, Mage: The Ascension, etc. Then I read "The Wiz Biz" by Rick Cook and realized that I was sucked in at the end when he realized how he could harness the basic "first principles" of this fantasy magic system to build abstractions that allowed for modern day coding principles.
My mind was blown, but I didn't realize just how much at the time.
Harry Potter interested me from the standpoint of "wow, I'd love to learn magic in an academic environment--how cool would that be?" And then I found myself hooked on the Magicians Trilogy by Lev Grossman which got as deep as I'd ever seen a book get on some of the mechanics of the actual magic system.
Finally, I put two and two together and realized that what appealed to me about all of this was the gradual understanding/building of a complex system based on its simple component parts, and the deep knowledge that was needed to master it. Then I realized that this was why I'm currently geeking out on going under the hood of modern day abstractions and working up from First Principles.
Again, I'm an "early" programmer. I don't fully grok half the crap I read. But I've realized that learning software development on my own is about as close as I'll ever get to working real, modern day magic. Clarke's 3rd law "Any sufficiently advanced technology is indistinguishable from magic." is very much top of mind lately. The fact that I can twiddle my fingers on a couple buttons and conjure up pictures, video, any information I want, etc. is pure magic.
There are many people out there like me who are amazed by the raw scope of how far we've come, and this article did an amazing job at reminding me of that, even though I may not have been the target audience, and that is why I enjoyed it immensely.
Some people are scared and overwhelmed by complexity, while others seek to understand it and tear it apart. I firmly believe the latter would have much more interest in this article than the former.
So now, about What Is Code, not about the commentary on it:
I got into this article today not knowing it was ~40k words. I was tired by the time I got to the silly certificate at the bottom, but I stayed intrigued the whole way. It was well paced and had a fascinating amount of depth.
I admire the authors' ability to write unapologetically from his own perspective. The sheer scope of this piece was a delight to dive into.
So same here. Not the target audience and enjoyed it immensely.
Business has been trying to do that for 50 years, but it doesn't really work because the scope of software systems too broad and varied. In a way software is an anti-commodity in its diversity. As much as "real" engineers rightfully decry software as easy and less rigorous than physical engineering disciplines, at the same time, the potential scope of software is greater than physics itself—it is math incarnate. The only way to commodify programmers would be to willingly limit software's scope to some established domain that is well understood by the powers that be.
I don't see one article, no matter how brilliant, providing the tools make any meaningful progress on that little management wet dream.
I learned how to write functions and subroutines a long time before learning algebra. The way that functions were taught in my math class were so confusing. Eventually I realized they were the same as what I learned coding.
Iḿ a non-coder and I felt light I already knew all he said in the piece. I guess it's useful for some CEOs, now they kinda understand what their employees are talking about.
Price of success I suppose, but now we have proclamations like "The world belongs to people who code. Those who don't understand will be left behind". Another example in a daily stream of hyperbolic mass media reports, reminding us yet again that 'software is eating the world'.
I have to say I preferred when the whole thing was regarded more as an exciting hobby - mostly by and for those who took the time to study the craft - than a world dominating force. This article may have value, but in those days you knew you were free of the grand statements. Money backs this new world, not code.