Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Ryan Dahl on Software

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 and C99_FEATURES and 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.

As fucked as it may be, we don't have a whole lot of choices if we want to create and deliver software. I agree that the user experience is the most important thing, but we still have to use what we have to deliver that experience, whether it's ideal or not. That's life, you deal with shit even if you feel like you shouldn't have to.

I get the vibe from this rant that he thinks people who enjoy building software and understanding the complexity are naive. It sounds rather bitter to me overall. By that logic, we should just all hate the process of software development since it's not ideal. That's not the way I like to approach what I do.

Idealism is nice, but realism is still necessary.

It is a bitter rant. But I've seen similar rants elsewhere, from smart devs. Hard to pin down whether it's 'just' burnout or other issues, such as cultural influences. Software tends towards entropy, and, IMO, industry pulls it there faster due to it's insatiable demands for 'productivity.' But Dahl is right when he advocates for only the absolute minimum of complexity. I don't really want to understand your library, I want to plug it in, try it out, and move on.

Idealism is a double-edged sword: you can see how reality and how things should be. At the same time, you can try to reconcile the two, only to realize that it's a lot of work, there may be technical restrictions, and (worst of all), people may not be ready for it.

To the rant: If this game of software development was all about the user and nothing else then I wager a vast bulk of us would drift off, because for me at least it is the joy of puzzle solving and abstracting complexity that makes it all worth it. And yes, those abstractions may be leaky and those puzzles half-solved but it's still a fun process, or at least more fun than bending to the will of the deified user.

UX is very important, specially when you are getting paid to write code to solve real user needs; but most people don't become great devs by thinking only about the "client" needs, they get great by exploring new ways of doing the same thing, and by studying their fields deeply.

As @padolsey said, puzzle solving and abstractions is what motivates people; and these people are the ones who makes big leaps that change the course of the craft in ways that wouldn't be possible otherwise. Sometimes the process is more important than the short term result.

"Immeasurable harm is done by the assumption that only measurable outcomes matter." - https://twitter.com/DrJohnLTaylor/status/391560387755130881

We shouldn't focus too much just in one side of the spectrum; there must be a balance between UX, tech, complexity and fun.

@padolsey @millermedeiros You miss the point of the rant. In the author's opinion, software is here to solve problems for humans. That's it. Not to enjoy writing it, not to enjoy abstraction, nothing like this. You can disagree with that, of course, but it's not like the author missed that or didn't think about that aspect. He is 100% rejecting it.

devn commented Oct 31, 2013

  = You
  = Make
  = Some
  = Interesting
  = Points

m5rk commented Dec 2, 2013

Software is not the only field where this occurs. It's a human malady. In general, we tend to optimize the wrong things.

I just had a conversation with similar overtones with an investor of a startup I work for. There are two phenomenon that conflate to cause the type of frustration that Ryan appears to have experienced. The first is that people start writing clean code because it solves a problem internal to the act of software development -- that is, of the code becoming so messy no one can anticipate the side-effects of their edits anymore -- but inevitably this ends up becoming a goal in unto itself. The second phenomenon is that the writing of sloppy code, the use of deep abstraction, the build-up of technical debt...these things inevitably happen because the software industry as a whole benefits from it -- it keeps people employed. That said, it is very, very important to keep in mind that no one does this intentionally...it is a byproduct of the commoditization of software, and commoditization is an inevitable pattern in a free-market economy.

I used the word "inevitable" multiple times, for a reason: these phenomenon that I am calling out are capable of causing such deep frustration (and, ultimately, depression) because their causes lie far outside the power of one person to influence and they are virtually certain to happen. I have felt some of what Ryan seems to have felt, and I took a 10-year hiatus from development to repair myself. Now I'm back, and my assessment is that the center of gravity in the software world is HTML+CSS+Javascript+JSON -- and the center of that is node.js. That node.js's author has experienced the existential frustration of fighting against the inevitable degenerative patterns of our industry means that node.js has passed its infancy. And that gives me hope that I'm betting on the right horse.

@ghost

ghost commented Apr 25, 2014

Thank you for providing this text (from a google+ post). I remember... he basically said this (also) in a video (must be somewhere online). If anybody finds it please leave it in the comments!

@teknomath: Nice comment, the worst thing is that YOU can almost do nothing about it and that's it and it will happen the same way on every IT project. Probably awareness (of the problem, which leads to depression :) may help. I live in Germany and not the US or the valley and I think things are worse here. We almost don't have cool IT (the startups I see here are not really cool, I am so sorry), so we have just enterprise IT and the problems are very strong within enterprises (see "the expert in a marketing meeting"). I have studied computer science and I can't just switch (to e.g. being a doctor) since this would take much time (6 to 8 years ;). So I am stuck. People tell me how bad people's live is in whatever country, but you know what... it's not that we flush down all this software soon. It's also my live which is ... it actually is... it just is... in the trash can. There are other factors: My specialization requires me to move somewhere where they use my "product" (IBM Message Broker) and the government tells woman "to live their own live" and so my wife just won't move with me to the new location ... and there are all terms for it... it's called "contracting" and "a project" ("you won't stay long there") and "consulting" and I call it: "a live in the trash can". And ofc "love it, change it or leave it"... ofc, BUT... it is the same everywhere. It's human nature. It repeats everywhere. And people with a different job will just say "oh I do this and that and you do software". Yeah challenges (I didn't know they are intrinsically unsolvable). I thought it's about a (subject) matter and not human psychology and ultimately... human failure

And we are all happy, right? I am not allowed to be unhappy (to raise critique). Everything is so great. Everyone loves everybody and we live in the greatest times ever. And in any doubt, we must "sharpen" our understanding of our roles (the roles we have on the project)

And psychologists, they can't help you. They just make money out of your misery ("hey I am a psychologists it's my job and you know... I mean you decided to do software"). What is the first/second highest cause of death among people aged 20 to 40. It's suicide. And each and every one of them means that our society has failed. I am alive because I see other's die ("ah, they must have had problems too").

Thank you if you don't delete my post but leave it for other's to read

I'll just leave this right here... Joel Spolsky in 2000, "Things You Should Never Do, Part 1."

http://www.joelonsoftware.com/articles/fog0000000069.html

Ryan's sentiment doesn't reflect reality. Joel's understanding is a much better representation of the real nature of software development.

You cannot both make a programmer's life simple and easy, and make the user's life simple and easy. Those two things are inversely proportional to each other. If you want to solve more problems for an end-user, the programmer has to do more work. If these two things were not inversely proportional, a programmer could make the user's life easier by simply not doing any work!

Look, fundamentally, computers are hard. They're weird, esoteric machines that aren't like anything humans are naturally familiar with. Just think about the fact that a computer executes millions upon millions of instructions every second. Now imagine the number of instructions you execute to bake a cake. Those are many orders of magnitude different from each other. There are weird natures between the human scale and the computer scale that are dealt with through all of the things that Ryan is complaining about. If you eliminate those, what are you going to do, write your own libs? Write your own compiler? Write your own assembler code? Good luck getting a simple hello world application written, let alone a web server, a browser, or an operating system.

The idea that Unix is a house of cards that, at some point will be more easily replaced than understood is foolishly wrong.

Computers are hard. Programming is hard. You're not doing yourself any favors by sitting there bitching about it. You need to knuckle down, dive in, and start dealing with that complexity on your user's behalf. Isn't that what they're paying you for? The more you founder and delay, the longer it's going to take to achieve some real, valuable outcome for an end user.

hansman commented Aug 20, 2017

"This is a common pattern that has been repeated in many well-established sciences: not just medicine, but physics, mathematics, chemistry, and others. The fields start out monolithic, with just a few deep ideas. Early experts can master all those ideas. But as time passes that monolithic character changes. We discover many deep new ideas, too many for any one person to really master. As a result, the social structure of the field re-organizes and divides around those ideas. Instead of a monolith, we have fields within fields within fields, a complex, recursive, self-referential social structure, whose organization mirrors the connections between our deepest insights. And so the structure of our knowledge shapes the social organization of science. But that social shape in turn constrains and helps determine what we can discover. This is the scientific analogue of Conway's law."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment