“Everybody Wants to Rule the World”, too much of its time

I really dislike “Everybody Wants to Rule the World” by Tears for Fears because it’s a perfectly written song that sounds exactly like the year it was recorded, 1985. Five years earlier, it would have sounded mildly seventies-ish and been great. Five years later and it would have had a little more grit and sound very late eighties.

What I’m saying is, if I could un-invent certain musical sounds, the bass on that track would appear on the list.

Hype curve superpositions

It seems, these days, that technologies can exist in multiple phases of the hype curve, simultaneously. Two data points I read this weekend:

  • Node, which I personally place somewhere between “trough of disallusionment” and “plateau of productivity”, is in the “exceptional exuberance” phase for the author of Monolithic Node.js
  • Ruby, which I personally place in the “plateau of productivity” phase is in the “trough of disallusionment” for the author of The Ruby Community: The Next Version

In short, I strongly disagree with both of these opinions. But I think that’s not the useful datapoint here. The takeaway is that both viewpoints can exist simultaneously, in their own context, and not be entirely wrong.

Raising all boats

It’s easy to complain about PHP. For instance, why didn’t they choose ☃ as their namespace resolution operator?! As a developer with lofty opinions, I’m not a big fan of PHP. To me, it’s an argument against allowing accretion to determine the design of a system. I don’t think it’s controversial to call the PHP language, core library, and ecosystem “inconsistent” and “a matter of curious histories”. A language feature here, a library function there, year over year, and you’ve got a “quaint” design. Yes, those are scare-quotes.

Whenever I feel a big rant about PHP shortcomings approaching, I try remember a few important facets of its success:

  • PHP made programming web applications accessible to lot of people for whom writing CGIs with Perl, Python or Java servlets was overwhelming. Myself included!
  • You still can’t beat the simplicity of PHP’s deployment model: acquire commodity web hosting, upload source files, and done.
  • Due to its accessibility and ease of deployment, a whole new kind of person started building stuff with code. Jason Kottke called part of this Liberal Arts 2.0. Less mathy programming, more craftsy.

Fast forward to today. PHP is still doing fine, though lots of people switched to Ruby or Python many moons ago, depending on personality type. And lots of those have since moved on to other things. The technology hype curve is an overlapping, ongoing thing.

Of those that switched, many ended up with JavaScript, in the guise of browser-side frameworks or server-side Node (and its ilk). I think there’s a huge opportunity here. JS is not without flaws, like PHP. But its sort of backed into really broad reach. Embedded, games, applications, mobile, probably more that I don’t even know about. That could make it compelling for an even less math-y demographic of people building stuff with computers.

And yet, there is no single JS community. There’s browser people, there’s server people. The future may hold mobile, gaming, and device people. That creates dissonance and some uphill battles.

But maybe that’s the really cool part. The JavaScript communities will have to slog uphill a bit to make accessible the previously intimidating domains of mobile apps, games, and embedded software. And that could raise the boat for people who aren’t building web apps but could be building software.

Functions about nothing

The tricky thing about decomposing code into abstractions is you end up with “functions about nothing”. You’ve probably seen on of these: a method or function with really vague names glommed into a utility or enumerations junk drawer. It’s probably innocuous, but as you’re reading code, it takes you out of your flow and forces you to think in the abstract instead of the concrete.

It’s easy to guess how these things happen. Successive refactoring iterations end up pulling business logic into a pile of predicates and side-effects and separate pile of abstractions. We feel pretty good ourselves at the end of the refactoring and write a fancy blog post about it!

The rub is when we come back to read the code later. Its easy to find the abstraction first and get side-tracked by figuring out why it exists, the context in which it was created, and when we might use it again. This is better than predicates and side-effects interwoven. But it’s still a problem.

I don’t have a salve for this. I just wanted to put the phrase “functions about nothing” on the internet. [SLAP BASS OUTRO RIFF PLAYS HERE]

Missing the big picture for the iterations


Driving in Italy is totally unlike driving in America. For one thing, there are very often no lane markers. Occasionally a 1.5 lane road is shared by two cars moving in opposite directions. Even if there were lane markers, it’s doubtful Italian drivers would heed them. Italian traffic flows like water, always looking for shortcuts, ways to squeeze through, and running around temporary obstacles. For an American, driving in a big Italian city is a white-knuckle affair.

My conjecture is that the unspoken rule of Italian drivers is “never break stride”. Ease in and out of lanes, blend in at traffic circles. There’s almost a body language to Italian driving by which you can tell when someone is going to merge into your lane, when a motorbike may swerve in front of you, or when a tiny delivery van is going to blow past you on a two-lane road.


Start with the result. I find myself mired in optimizing for short-term results that I can incrementally build upon. This is a fine tactic, especially when getting started. It’s a nice way to show progress quickly and keep making progress when rhythm matters.

But, it’s a tactic. To make a musical analogy, it’s how you write a song, not how you write a whole album. At some point I need a strategy, a bigger idea. I need a result in mind.


I love to tinker with new technology. The grass is always greener with new langauges, libraries, tools, etc. I’ve learned a lot this way, and kept up with the times. I’ve got lots of surface-level experience with lots of things. But increasingly I want more experience with deeply accomplishing or understanding something.


Driving in Italy was extremely jarring for me at first. It closely resembled chaos. Eventually, I got used to it, at small and medium scales. (But never drive in Rome/Milan). Now, I sort of miss driving in Italy, at least the good parts. I miss the freedom to overtake other drivers without having to swerve through lanes, and I miss not stopping at traffic signals any time there’s an intersection.

Maybe this is a reminder, for me, that getting out of my routine (American driving) isn’t so bad. Worth the initial shock. Maybe my routines, my tactics, my tool/library/langauge novelty seeking, were helping me along as much as constraining me.

Maybe the big picture result, not the iteration, is the thing and how you get there (highly ordered American driving or seemingly unordered Italian driving) is of less consequence.

Aliens through the eyes of boys

On screening Aliens for a slumber party of 11 year old boys:

“I like the way this looks,” one said. “It’s futuristic but it’s old school. It’s almost steampunk.” “This is like Team Fortress 2,” another remarked. “Dude, shut up, this was made like 20 years before Team Fortress 2,” said the kid next to him. “This is, like, every science fiction movie ever made,” another said, as Ripley operated the power loader for the first time.

I love works of culture that bisect their genre. There were symphonies before Beethoven, and symphonies after Beethoven. There were comedies before Animal House and comedies after Animal House. For action and sci-fi action movies, there were movies before Die Hard and Aliens, and there are movies after.

In all of these cases, the pieces after are a wholly better ballgame because the piece bisecting the genre changed it so completely.

It’s not your fault if your tools confuse you

I. Pet Peeve #43: Complaining About Frameworks

The whole point of a framework is that you trade one or more axes of freedom in how you structure your program so that you can move faster writing the meaningful (unique) part of that program. To wit, the first definition I learned of a framework goes something like:

A framework is a library that takes over the main() function of your program and provides a higher-level entry point for calling your code.

Most programs would have a boring main() anyway, so this is a great tradeoff in most cases.

And yet:

  • Some programs aren’t boring.
  • Some programs demand more control.
  • Some developers crave choice and accept the burden of picking each library and choosing how to wire them together.
  • There’s a bit of a hero complex about rolling your own framework from libraries.

Where we end up is that I notice people complaining about frameworks. I think most of these are proxy complaints about someone else choosing a framework they have to live with. To their credit, some complainers are actively trying to make a better thing too. Kudos to them. To the idle complainers: cut it out.

2. I complain about a framework

RSpec and minitest are both frameworks in the sense that your entry point is a special class with special methods. RSpec is more frameworky in that you don’t actually write classes or methods. You use a language-y DSL to define test cases that share some aspect of scope. You can go pretty crazy in this manner. Or you can not go crazy, RSpec accomodates either style.

Lately I’ve been wrestling with test cases written using at least three kinds of RSpec scope and it’s driving me a little crazy. They look something like this:

describe "POST /something" do
  before do
    @thingy = somethings(:alices)
    post :something, thingy: thingy
  it { expects(assigns[:something].attributes).to eq(@thingy) }
  it { is_expected.to render(:created) }
  it { is_expected.to respond_with(:json) }

If scoping is about answering the question “what methods are available to me on this line of code”, this code seems to have four kinds of scope:

  1. Inside the describe block, we can call RSpec methods
  2. Inside the before block we can call RSpec expectations and rspec-rails controller methods (but that is implicit!)
  3. Inside the it blocks we can call RSpec expectations
  4. When we call is_expected, we can reference…I’m not sure at all

It is at this point I try and take my own medicine and make a constructive observation rather than yelling “this sucks and someone should feel bad about it!” into the wind (i.e. Twitter).

3. What’s an RSpec for?

I didn’t like RSpec at first (circa 2008), then I really liked it (circa 2010), and now I’m sort of ambivalent. The question of what RSpec exists to solve has evolved too. At first it was “hey, BDD!” and then it was a less underscore-y way to build tests and now I think it’s a tool for writing tests in a style that some prefer and some don’t. In short, the Ruby community is figuring this out and kind of storming through the awkward parts.

That awkward part is how I think my example test came to be so unclear. Without doing a deep archaeological dig on the code, I’m guessing this code had three phases:

  1. Originally written according to the RSpec vogue at the time, which was to use it one-liners as forcing function on the constraint that tests should have only one assertion (Which in retrospect I think is a rule about the functionality of the method under test and not a guideline about how to write tests. This isn’t the first time developers have adhered to the letter of the rule and missed the spirit entirely).
  2. Use the amazingly great transpec tool to translate RSpec 2.x style to RSpec 3.x style without having to spend months carefully transitioning a large test suite from one API to another. Mostly this works out great, but you get some awkward translation, like the is_expected part.
  3. Use the newer RSpec 3.x style expect syntax for assertions, introducing two ways to say the same thing with the intended long-term benefit of using the clearer expect style everywhere.

I don’t blame RSpec for any of these phases. You can easily swap out the names of libraries and concepts for any other language or library and find a similar story buried in any chunk of code that’s been around for more than a year and worked on by more than one person. It’s a thing that happens to code. I’m not even sure people should feel bad about it. Mindful of cleaning it up over time, yes. Throw it all in the bin and start over, no.

My first temptation is to say that using it one-liners is a smell. They are nice to scan through but tricky to write and trickier still to change. But I can see where a series of well-intentioned code changes compresses many structurally similar test cases down to nearly-declarative (nearly!) one-liners without much duplicate typing. I can imagine a high-functioning team writing their own matchers, carefully using one-liners, and succeeding. So this one is a word of warning and not a smell.

The real smell, I think, is that its really easy to have very different scopes adjacent to each other in an RSpec test file. Further, not all scope-introducing constructs look the same! describe/context introduce one kind of scope, it introdues another kind of scope, let/subject/before introduce three similar but different kinds of scope, and expects/is_expected look the same but have different scopes as well.

Even smellier is that I’m making this list from an empirical understanding and not by examining the implementation or experimenting with reduced test cases.

What are you gonna do about it?

I’m probably going to leave that code alone. Wait for a muse to strike at the same time I need to make wholesale changes.

People who use RSpec should feel fine about themselves. People who contributed to RSpec should feel great about themselves. People who struggle with figuring out scope in RSpec should take solace that the best of us find this stuff confusing and frustrating at times. Developers not in one of these camps should take my advice, globals are bad but a bunch of weird scoping is not great either. Everyone else can smile and nod.

Organize your Gemfile by function and coupling

Most Gemfiles I see are either unordered (just throw new gems in, wherever!) or alphabetically ordered. A while back, I reordered the Sifter Gemfile, ordering by difficulty of removing the dependency and grouping by functional area. Thus organized, it came out a bit like this:

  • Framework: Rails, Rack, the mysql2 driver, JSON, Rake. We will basically use these forever.
  • Gems for our vendors: Postmark, Braintree, Skylight, Bugsnag. We’ll use these as long as we’re using their respective service.
  • Partner integratons: GitHub, OmniAuth, etc. Most of these aren’t maintained by the partner, and we’d have to drop the integration to drop the gem.
  • Extensions: jquery-rails, delayed-job, will_paginate, etc. We could stop using these if we cared a lot, but we’re pretty committed to them.
  • File uploading: carrierwave, fog, wand, rmagick. We’d have to overhaul our file attachment support if we wanted to remove these.
  • Sphinx support: thinking-sphinx and ts-delayed-delta. We’d have to overhaul our search to remove these.
  • Admin: bootstrap, etc. Things we could easily remove next time we overhaul our admin, which isn’t really a big deal if we decide to.
  • Gems for building assets: jquery-ui-rails, therubyracer, execjs, coffee-rails, sass, compass, etc. We’d have to remove uses of the underlying tool (CoffeeScript, SCSS, etc.) if we wanted to drop one of these.
  • Development gems: pry, ffaker, byebug, better_errors, spring, rack-mini-profiler. We can switch these out if we want.
  • Testing gems: rspec-rails, capybara, etc. Again, if we change tools we can change these.
  • Deployment: capistrano. This could go in the framework section, seems unlikely we’d overhaul our deploy scripts away from Capistrano.

This organization makes it easy to know where to add a new dependency. More importantly, we can better understand how much we depend on a gem and the level of effort to remove it if we need to.

Programming advice for a younger me

How to get better at programming without even programming:

  1. Accept, in your heart and mind, that the languages, libraries, and tools that you use to write programs may not be good for other people, other teams, or other problems.
  2. Search for deeper understanding of approaches to programming that seem strange or incorrect to you. Don’t look for wrongness in what someone else is doing or what you’re thinking.
  3. You will come across scenarios that challenge principles 1) and 2). When you do, say what you can to help but err on the side of not making things worse; let go of what you can’t control.

Bonus: be a kind person.

Leadership, pick a size

Like fast food or coffee at Starbucks, maybe team leadership comes in three sizes.

Extra large leadership. “This is what you’re doing. Make it happen, let me know when it’s done.” The old school, top-down approach. This is what I thought all management was like many moons ago. In my experience this is only useful when people need to think only about what they’re doing, not why they’re doing it or how they do it. Leadership sets the work, lays out the exact process for doing that work, and closely monitors the work as its done. See also: Taylorism.

Large leadership. “Here are some things that need doing. Do one of them, keep me posted.” This is where I think cohesive teams of knowledge workers should aim to be. Leadership lays out the tasks to be done, makes the work to do clear, and gets out of the way. Luckily this is a lot more frequent lately, but probably not so much in part-time labor. Leadership still monitors the flow of work, but not overtly as in Taylorism.

Medium leadership. “Do what you think is most important. Let me know how to remove obstacles.” I suspect most leaders really want to get here, but are constrained, imagined or in reality, by some organizational detail. It’s definitely where I want to be in leadership style. High trust in the team, high trust in the leadership. Lots of unicorn dust.

Oddly enough, I think some teams and projects require large leadership and some require medium leadership. Some people want a little structure to their work, some projects require well-defined milestones to rally around. Other people can effectively guide themselves to useful outcomes, other projects are less about the milestone and more about the journey.