The author has inadvertantly stumbled upon a part of hacker culture with wide-ranging implications, that is almost never discussed—and that is that people expect that you publish code because you want it to be changed, and not simply read. This stems from a deeply-rooted tradition in programming of not reading a codebase until you have a problem with it that you must fix. People don't "read for pleasure" in the programming world; they don't even read to learn—have you ever had a school assignment that charged you with reading more than 1KSLOC? The only reason, as a programmer, I will ever "cd src/", is that I am on a mission to fix a problem. Therefore, publishing code but reserving the right to derivative works, looks a bit like gloating, or showing off—"look what I did! Look how smart I am! It's no benefit to you... but look!"
This makes perfect sense in the art world (and writing is a form of art), as you never really "derive" from a piece of art; instead, you first look at the mechanisms by which it communicated its message to add those techniques to your repitoire of skills, and then re-use those skills on your own works. That makes perfect sense in an artistic medium, where any single stroke or word or note may be chosen from an infinitude of options—but programming requires formal grammar—a finite set of ways of expressing each concept—and thus there is relatively little merit in studying the technique by which a single problem was solved.
On a separate note, for the first few paragraphs he seems to be completely unaware of the medium of fan-fiction—which is about as core to "the culture of online fiction" as you can find.
And it is surprising how much you can learn from reading code, the most humbling thing I learned from reading other people's code is that I'm not nearly as good a programmer as I thought I was.
I haven't read a program yet that didn't teach me something.
Reading programs is hard work though, it can tire you out pretty quickly, especially in the stage before things start clicking in to place and you can start to predict what's coming next based on the parts that you've already grokked.
I'm definitely not saying it's not a good idea to read code—it's just something that almost nobody does, because, as you've said, it's very hard work; much harder than having the "story of the code" told to you in a book or a blog post.
It's also work no one knows you did; unlike reading a book or a blog post, you can't really reference or quote a codebase to prove you know what you're talking about, because you can't expect the people you're talking to to have read the same exact lines.
It's probably related to the way I learned about tech, I relentlessly pulled stuff apart until I understood how it worked. I never really grew out of that I guess.
Getting good at reading code helps with debugging. I like teams where every commit is reviewed by somebody else -- keeps you honest, you learn new tricks and you reduce bus factor
People don't "read for pleasure" in the programming world; they don't even read To learn—have you ever had a school assignment that charged you with reading more than 1KSLOC? The only reason, as a programmer, I will ever "cd src/", is that I am on a mission to fix a problem.
Seriously? As a programmer, the problem I'm often on a mission to fix in /src is that I haven't learned enough.
Yes: you are in a minority within a minority. Of the programmers who read to further their education after school is done with (an already-small number), most will be complacent to read books, or blogs, or at the most journal articles. The number who dive into a foreign codebase—that is, one they have no association with and don't rely on for anything—without the expectation of eventually contributing something (i.e. In OSS) is vanishingly small.
Random rails and jquery plugins tend to be terribly documented and frequently make easy to fix design errors. I read code all the time -- if I am committing it to the repo, I want to be sure I know how it works. For "black box" things I usually won't delve that deep, but if it really needs to integrate, I usually end up reading it sooner or later.
My only regret is not pushing more changes back upstream
I'm with you on this one. I like to understand how things work and how other people approach certain problems. You can find new tricks to add to your bag. Which is also why I like to reinvent the wheel. Waste of time? Maybe, if you don't want to learn anything.
I often find that I can't properly "read" code without a mindset of wanting to change something about it. Of course, I sometimes invent a trivial "something" when I really want to understand a piece of code.
It's interesting that you mention fan-fiction. I imagine the reason people overlook forking" fiction stems from the fact you're consuming the story, remixing it and spitting out something new. On the other hand, forking code is more like tacking on a paragraph here or there.
Also, while you did touch on the hacker culture I think that's the most important factor. As hackers we're practically born to tinker. When we tinker with hardware ,say a remote controlled car, no one confronts us and asks "Hey, man, why are you tinkering with that car?" More often than not you'll get people saying "Hey, that's really cool!"
Furthmore, it's easier to take a get tangible changes from tinkering with a program than with a piece of literature. You can't miss the impact of gravity on gameplay in a game like HATETRIS but very few people will pick up on the significance of a new piece of text in the middle of a novel.
I really like how jsankey put it when he said "If you put something out there, you should be flattered that people take enough interest to tinker with it."
> ... people expect that you publish code because you want it to be changed, and not simply read.
Browser-interpreted code makes this quite a fuzzy issue. What are the rules with running tools like GreaseMonkey? Is there a legal or moral line that shouldn't be crossed with tools like GM?
As an aside, I wonder if there is any gender bias in the "publish code"-->"you want it changed" conclusion. I've observe that females tend to state problems in order to find empathy, and males tend to state problems in order to find solutions (of course, this is a gross simplification). Mixing these two types when a problem presents itself can sometimes result in conflict. Perhaps the same tendencies in people sometimes conflict over code (i.e., some present code to look at and admire, others see it as an opportunity for improvement).
I would say "publishing" must always be a distinct step, and that there has to have been a conscious effort of some sort on the part of the programmer to put the code up separately from its existence within a program. However, even if some people disagree with that, I don't think it could be argued that obfuscated code was to be considered "published"—which could actually be a good argument for code obfuscators.
