My feelings on Ruby have a tendency to oscillate between evangelical adoration and pure, unadulterated disgust. Now, I haven’t really experienced this before with a language, so naturally I find myself curious as to why this seemingly uncontrolled hysteresis of perspective happens. Well, today it hit me — I legitimately feel both ways, simultaneously, about Ruby. This is possible because, as with all human endeavors, there exists two parts to a programming language: reality (the language itself); and perception (the idioms, practices, and community that surround Ruby).

Ruby, as a language, is beautiful. Left to its own devices, Ruby is syntactically rich and expressive. Now, a lot of programmers like to dismiss high-level languages like Ruby or Python because they aren’t C. And you know what? They have a point. Ruby is not C. And while I could very well implement a complete web application using only C code, frankly…No. If Ruby’s way of doing things is too saccharine for you, there are literally hundreds of other options.

One of the things I especially appreciate about Ruby, thought, is that it allows you to create domain-specific languages by using a few sugary-but-still-neat syntactical tricks that let your Ruby code resemble markup. Again, lots of people will balk and vomit when hearing that, and the point I’m about to follow this with tends encourage that reaction. When you need readable, approachable code (and when you know the rules), nothing I’ve seen yet can really beat Ruby. Ruby makes hard problems feel easy. When you have a large application with a lot of moving parts, or one that integrates very heavily into a lot of other systems, you come to appreciate the little physiological tricks Ruby plays on you. But, of course, there’s a bad side to this as well.

Ruby Makes Easy Problems Too Easy

The fact that Ruby can let you express complex logic in a very elegant, succinct, clear way (and in the best of cases, all three) is wonderful. However, when you get into this mindset that everything should be easy and fit into 5 lines of code, it warps your thinking. I have found myself falling into this trap on occasion, where I’m clearly on the wrong side of the 80/20 rule, trying to optimize code for how emotionally satisfying it is to read rather than how well it performs. The trick here is to be self-reflective. Realize that this is a thing that you might do, and also know that there’s nothing wrong with doing it. You have a right to want beautiful things. But there’s also a point when you need to stop jerking around and get back to work.

Agile Might Be Too Agile

The term “agile programming” came about in the early 2000’s as a neat, pre-packaged, sellable, trainable, consultable, exportable, outsourceable way of doing what Unix programmers had already been doing for 30 years. Agile promises structure, rapid development cycles, quality code via small teams — everything forward-thinking or pennywise-and-dollar-foolish companies like to hear. The idea that you can have a team capable enough and a language flexible enough to deliver “rapid” prototypes is appealing. And to be honest, in a lot of cases I can’t really dispute the reality of it. Agile, when not taken too seriously, does have benefits over more traditional monolithic project management schemes for projects, especially web projects. This idea is by no means new. But beyond that, the assumption that your team is capable enough to handle these ideas is likely just plain wrong.

Ted Dziuba has a wonderful article that touches on Agile as a methodology and on methodologies as a whole. But for my purposes here, I want to make another point. I feel like Agile, and the flagship languages like Ruby that champion it, have set the bar a little too low. Ruby is easy. The barrier to entry is almost nothing. Install a package, read an “…in 10 Minutes” walkthrough, watch a screencast, and build a cookbook app. That’s a far cry from the months of theory, backstory, and practice it takes to write similarly entry-level code in C/C++/Java. It’s a whole new world out there. It’s one where non-coders can become coders quickly, cheaply, and with reasonably usable results. But, this also tends to make people learn only enough to be dangerous, but not nearly enough to be good.

I believe that there is value in the barrier to entry for programming and computer science being high. Barriers, as a rule, are good at one thing: keeping stuff out. Not all stuff, just stuff that doesn’t want it enough, or stuff that doesn’t have what it takes to make the cut. Forty years ago the only people who used computers were the ones who built them. And not for nothing, but a lot of those people did a damned good job. They had nothing to work with, and from nothing came some excellent code. Ken Thompson and Dennis Ritchie; the MIT, Berkeley, and Stanford folks, among so many others, spent a great deal of time solving problems the average first year CompSci college student will never know existed. I, myself, only know about it through independent research. I got curious, and felt it was important to know what I don’t know. Books like Raymond’s The Art of Unix Programming, IMHO, have just as much to say about programming today as the Agile Manifesto.

Do I Hate Productivity?

Certainly not. I’ll admit, if I am destined to become famous (or infamous), and as a result there has been some Temporal Studies class from the future taking notes on my early years, the natural conclusion is that I’m full of shit and can’t actually complete anything. But the more exposure I get to this industry, and the more kinds of people I work with, the more I’m convinced that this is all just one big crapshoot. Unless you actually go to a Top Tier engineering school (I did not, nor will I assume even that would be sufficient), your technology education is probably going to be missing something. Again, this is why the most important thing I think an engineer can learn is to know what you don’t know. Endeavor to figure out what it is that you are fuzzy on, vaguely clear about, or just flat-out ignorant of. Then get your ass out there and learn those things. Hit some books, hop on Freenode, go to a meetup, and learn yourself but good on these things. Ultimately, beyond whatever dicking around I do in my spare time, beyond what project I think is So Damned Important™ at the time, my biggest ongoing task in life will be to find things I don’t know and know the shit out of them. Ruby happened to be one such flight of fancy. However, during this flight I’ve seen a LOT of people who don’t know what they are doing shipping out hella lots of code. I just don’t see that as often with C; because despite all the evangelism surrounding Ruby and the Agile tiger, learning C is the real religious experience. Ruby let me ship a technically functional web app inside of 2 weeks that one time. C continues to make me work for it.