Ryan Dahl, the creator of Node.js, wrote this short rant:
I hate almost all software. It's unnecessary and complicated at almost every layer. At best I can congratulate someone for quickly and simply solving a problem on top of the shit that they are given. The only software that I like is one that I can easily understand and solves my problems. The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved.
In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with. The complexity was not contained. Instead I deal with DBus and /usr/lib and Boost and ioctls and SMF and signals and volatile variables and prototypal inheritance andC99_FEATURESand dpkg and autoconf.
Those of us who build on top of these systems are adding to the complexity. Not only do you have to understand $LD_LIBRARY_PATH to make your system work but now you have to understand $NODE_PATH too - there's my little addition to the complexity you must now know! The users - the one who just want to see a webpage - don't care. They don't care how we organize /usr, they don't care about zombie processes, they don't care about bash tab completion, they don't care if zlib is dynamically linked or statically linked to Node. There will come a point where the accumulated complexity of our existing systems is greater than the complexity of creating a new one. When that happens all of this shit will be trashed. We can flush boost and glib and autoconf down the toilet and never think of them again.
Those of you who still find it enjoyable to learn the details of, say, a programming language - being able to happily recite off if NaN equals or does not equal null - you just don't yet understand how utterly fucked the whole thing is. If you think it would be cute to align all of the equals signs in your code, if you spend time configuring your window manager or editor, if put unicode check marks in your test runner, if you add unnecessary hierarchies in your code directories, if you are doing anything beyond just solving the problem - you don't understand how fucked the whole thing is. No one gives a fuck about the glib object model.
The only thing that matters in software is the experience of the user.
I can guess most of the context behind Ryan's frustrations, but I don't know all of it. However, I'm drawn to his frustrations and believe I've suffered a parallel frustration. His closing line keeps me coming back to reread the passage. "The only thing that matters in software is the experience of the user."
Now, to a product or business guy, or to an average person, they might think that Ryan is talking about "UX." Responsive layouts, appropriate palettes, subtle typography, just the correct number of clicks from Point A to Point B. Yes, that stuff matters, but FUCK NO, that is not what Ryan's talking about.
Here's what I think he means.
When I was in investment banking and management consulting, I grew frustrated because of the nature of the job. I dealt with tedious complexities to make a living. Nothing was particularly challenging about the job except for the tediousness. I felt unfulfilled, so I pursued my interest in programming so I could become a builder instead of a sorter of tedious minutiae.
For a while after that, I was the programmer that Ryan ridicules. I was, and sometimes still am, the programmer who thinks it's cute to align my equal signs, customize my window manager and editor, etc. Shortly after my honeymoon phase with programming ended, I started seeing the complexities in my craft as annoying, unnecessary, and the result of other people putting together hacks instead of solutions. The landscape of wonder that WAS programming became the landscape of tediousness that IS programming.
Here's what's tedious about being a programmer. You are hired to build specific software. In your spare time, you want to build specific software. This software is the End Result. You don't care about anything else.
To reach the End Result, before you even begin writing your own code, you must know how your tools work. And if they don't work, you need to fix them. Your tools have their own tools to work, which in turn might be broken and have their own tools to work. What a mess!
When your tools and environments are finally ready, you're ready to start building. But then you see that your tools don't exactly work well together. So you start bending the tools to work in ways in which they weren't designed to be used. While you misuse your tools, you add to the difficulty of completing your End Result. But you keep going with misused tools, because the alternative is to built a better tool yourself, for which you surely don't have the bandwidth.
And there! That's it. You finally finished and achieved your End Result. You take a few steps back and think about your software. The End Result correctly foos some bars as it should, but man, you had to deal with so much more complexity than it deserved! The amount of complexity that you're willing to deal with should be proportional to the size of your problem. Otherwise, the problem's not worth solving. And THIS is what's tedious about being a programmer.
Like Dillon the Banker and Dillon the Consultant, Dillon the Programmer deals with too much complexity to build software which only foos some bars. That's just frustrating. Why do I have to do so much work to make my tools work and fit, when all I wanted to do was foo my bars??
And this is why, from my point of view, Ryan says that the only thing in software that matters is the experience of the users. Software is supposed to remove complexity. But in the act of creating software using other software, we're creating more. And why is that happening? Ryan seems to think it's because software tends to not do a good job solving the problems it was designed to solve. I would agree. I don't want to waste time with tools that don't work the way they should. I want my tools to just work, so I can build my End Result and start fooing some bars.
When any developer writes software, that software should be extremely easy for other developers to use and build more software with it. To me, that's why nothing matters more than the user's experience when it comes to software. The users are other developers. Developers should not be wasting most their time dealing with pointless complexity.
Here's the punchline. This is our job. Dealing with this terribly tedious and endless complexity is our job. As much as I might hate a crucial piece of software, it's my job to wrap my mind around the complexity and fix it so that I can use it. I'm lucky that I have the ability to do that. Yes, the more you learn, the more you realize how fucked up current software is, to Ryan's point. But the fact that you realize how fucked up everything is means that you have the power to make it better.
Being a programmer can really, really fucking suck sometimes, and I don't envy people like Ryan who have seen and lived in the worst of it. But man, I still love being a programmer.
It’s hard to believe that Node.js is four years old. On one hand, we ask ourselves where did that time go. On the other, it seems like Node.js has been around longer that it actually has. The eternal contradiction!
Created by Ryan Dahl with growth sponsorship coming from Joyent, Node.js has come so far, and the community surrounding it has grown so much. It is fascinating to watch the diversity of projects using Node.js. We’ve been watching and appreciating this both locally and globally at NodeFly. And we’ve been proud to take part in it as well.
NodeFly’s muse for Node.js arrived when we were releasing our server and application services monitoring service. We realized that we needed something to monitor ourselves. There wasn’t something out there that met our needs. Solution: we decided to build it. And now we are happy to keep building it, incorporating feedback from the node.js community. The cycle continues. Ah, node.js.
And since Node.js is the star of the show, let’s go back in time to October 5, 2011 to hear Node.js creator Ryan Dahl discuss its history.
Ryan Dahl talks about the history of Node.js and why he created it. This was filmed at the Phoenix meet up group Phx Tag Soup.
http://tagsoup.github.com
