it’s tough being an open source messiah

Either I’m spending more time on tech and tech-related sites or there’s been a brief preponderance of articles about coding, learning how to code, and coders themselves. One of them in particular caught my eye since it not only touched on the quest of those determined to teach more people how to code, but the human aspects of coding as well. Programmers, as odd as it may seem, are human after all, we have feelings, or so I’m told, and the occasional creative rut and depressive episode or the periodic fruitful period during which we’re busy churning out line after line of code.

And to cover the ups and downs of a programmer, a Slate columnist tried to focus on _why, a famous but emotionally frail big shot of the Ruby community. Now, I don’t work with Ruby, not because I have something against it but because most of my projects do just fine in C# and I’m very much at home with its pseudo-functional features like delegates and lambda expressions, so most of the trials and tribulations of the Ruby community are simply not on my radar. When it came to the _why saga, there wasn’t a whole lot that caught my eye either, especially his big quest to help more people start coding with Ruby.

We’ve seen several attempts to get more people to learn programming with flattery and by trying to get them excited about code when they’re young, but neither of those approaches focused on one of the big reasons why a lot of open source activists really want to get more people coding. They don’t really care about boosting one’s rhetorical and mathematical abilities but using one’s coding skills to create, modify, and invent.

Since a great deal of coding today is being done in cubicles and serves to manage corporate paperwork, there’s a not too inaccurate view of professional programming turning into seemingly endless drudgery. Working with a lot of open source projects allows coders to express their creativity, sort of how a copywriter has to work on fairly routine and formulaic press releases and white papers by day, then goes home to write sci-fi novels. It was in the spirit of that desire to harness their inner creative that he formulated his manifesto about coding…

For nearly all of us, code, the language that controls these objects and in a way controls our world, is mysterious and indecipherable. Back in the old days, you could hack a Commodore 64 without too much trouble. But just try to get a sense of the millions of lines of code controlling a Windows computer, or the Google search engine, or your Android or iPhone. For starters, the user interface and legally enforced sanctity of the code will prevent you from even seeing it. Even if you managed to take a look at it, the code would be so complex you would struggle to understand it, let alone be able to manipulate it. For that reason, _why explained in the “Little Coder’s Predicament” — and over and over again at conferences and panels — too few people were learning to code.

But this is a rather bad comparison isn’t it? Sure you could modify your Commodore 64 because there wasn’t a whole lot to it by our modern standards. It didn’t run an operating system with 10,000 drivers and using over half a billion lines of code. Interestingly enough, you still can take a look into a lot of compiled code by using a de-compiler and modify it by editing either the intermediate language or the assembly you’ll get, then plugging your changes back into the de-compiler and re-compiling the altered code. Of course a lot of people really will not want you doing that because you can do some really, really evil things with that ability.

This is an easy way to put in a backdoor into a system or hide a sinister bit of malware into code that’s not being actively scanned by an antivirus system. If the original programmers were really sloppy, this is how you find backdoors they put in during testing and grant complete control over a system. But if you really had the best intentions in mind for your decompiled version of Windows 7, just try rewriting the 550 million lines of x86 assembly. Actually, just try to organize it into blocks and find where one ends and the other begins. We’ll check back in two years.

And while you’re reverse engineering all that code, keep in mind that it’s doing things that the Commodore 64 users couldn’t even imagine a computer would do and all the files it could handle, analyze, and modify for you without requiring you to know anything more than how to type and use a mouse or a touchpad. The phones in our hands are a thousand times faster can be connected to millions of other devices from computers to other phones on demand, moving data from one end of the world to another within seconds. When the C64 was in its heyday, only the boldest futurists even thought of anything remotely like we have today.

And true, with all its might, today’s digital realm adds a lot of complexity to code and it is intimidating for many to even venture into it. But as noted before, they don’t have to code to use computers and while the biggest reason to modify your C64 was to do something you couldn’t do before, we have millions of software packages that will do what you need for you if you’re an average user. Why would people want to code if they can either buy what they need off the shelf or have the money to enlist trained professionals to do it for them unless they have a deep interest in how things work and just really, really want to try programming themselves to see how they like it?

And just like any creative work, programming can certainly get to you. This is what happened to _why and as a result, he killed his online persona, erasing his GitHub repository, Twitter account, and blogs right after being outed for seemingly no reason whatsoever. Of course this raises the question of why one would go so far as to maintain anonymity to the degree _why did and there are some Ruby architects and developers who have a rather mundane but all too plausible explanation for why an emotionally fragile coder would go dark…

Vanderburg puts it simply: “_why’s code was sloppy. He was an amazing thinker, but not as good when it came to execution. So, he saw a lot of people take his ideas, and then build them out into more sustainable or workable projects.” Klabnik, who now works on Hackety Hack, said much the same. “_why’s programming just really is not very good,” he said, adding, “That doesn’t mean he wasn’t brilliant.” Over and over, _why would build something, and something better would quickly supplant it, either a variation on _why’s work or a new approach.

In other words, he was more of an idea guy and less of a coder who hacked together proof of concept kind of projects and had them modified by others, and according to his tweets, wasn’t all that happy with the fact that his projects were being rewritten again and again. But that’s not necessarily a bad thing. Obviously you’ll want to put out great code but you run into problems with every open-ended exploratory project like _why’s. Not sure exactly what users want and how they’ll use the utilities you build means constant refactoring (or what normal people would call editing) until the scope is finally solidified and the exact functions are better fleshed out.

It’s not as if one can’t be influential by throwing out good ideas and letting others help you flesh them out but you have to keep in mind that nothing you write will last forever. Programmers and architects contribute new ways of doing things, new patterns, and new approaches. Those are our lasting contributions. Code is really just a temporary thing. And it would be really sad to confirm that someone who generated a lot of good ideas which he evangelized with an addictive zeal withdrew from his community because he didn’t yet move beyond code, the blunt instrument that demonstrated his ideas, and embrace his role as an idea man.