Unpacking Technical Decisions - Mountain West Ruby Conf 2014

Sarah Mei
Ministry of Velocity
@sarahmei
Unpacking Technical
Decisions
Hiya! I’m Sarah Mei, and I run a consulting company in San Francisco called the
Ministry of Velocity. I spend my days helping people refactor large Ruby and
JavaScript codebases.
!
I wasn’t supposed to be speaking at MWRC this year. I spoke last year, so I was on
the program committee this year, which meant I got to read all the talk proposals
people submitted during the CFP. I think we picked a good program, but we failed to
do one critical thing: designate backup speakers.
!
Soooooo here I am. Fortunately I did this talk last week, at Fluent, an O’Reilly
conference covering JavaScript, CSS, and HTML. Here’s a picture:

View Slide

People at Fluent
http://www.ﬂickr.com/photos/oreillyconf/8893292969
I think about Fluent as the conservative JS conference. And by the way, you can tell
it’s an O’Reilly conference because they sprung for the expensive “no-ﬂip” name
tags. :)
!
Anyway…Fluent is not the type of conference I normally do. I normally hang out with
Ruby folks. Totally different crowd. So I spent a lot of time in the hallways talking to
people — interrogating them, basically — asking them who they were and why they
were there. It was super interesting. The people I met fell into three categories:

View Slide

of PEOPLE AT FLUENT
•Back-end developers
•Visual & interaction designers
•Front end developers
1. Back-end developers, looking to learn more about front-end development,
because all the cool kids are “full stack” developers…
2.Visual and UX designers, coming at front-end development from the other
direction, and…
3.Front-end developers. Unsurprisingly, this was the largest group.
!
These are three groups of people with very different past experiences. And they
surprised me, because when I asked about speciﬁcally why they were there, they all
told me the same thing.
!
Here are some quotes I wrote down. See if any of them sound familiar.

View Slide

of PEOPLE AT FLUENT
“My group has started an ember
project, so I’m going to every
ember.js talk on the schedule.”

View Slide

of PEOPLE AT FLUENT
“My web app has an old jQuery
codebase and I need to ﬁgure out
what to do with it.”
One thing I learned at Fluent is that some people have a deep and abiding hatred for
jQuery.

View Slide

of PEOPLE AT FLUENT
“I want to learn about angular. I
think I can raise my rates.”
This is almost certainly true.

View Slide

of PEOPLE AT FLUENT
“We have an ancient backbone.js
setup that desperately needs a
rewrite…not sure in what.”
I think by ‘ancient’ here, she meant, like, 6 months old.
!
So, no matter what direction these folks were approaching front-end development
from, they all had the same burning question.

View Slide

What JavaScript
framework
should I use?
http://www.ﬂickr.com/photos/hakkiceylan/5043637183
What JavaScript framework should I be using? This is one the big open questions in
web app development right now. I suspect many of you reading this have some
version of that question on your mind.
!
It’s an open question because of this:

View Slide

Wooooaaaah! I mean, this is a great problem to have, because there are so many
options! But unfortunately…there are so many options. And even though it seems
like, these days, we do have some front-runners emerging, it’s still early. I mean,
Ionic (upper left hand corner), just got a million dollars in funding, like, last week.
It’s early days, I’d say, and it’s very confusing.
!
Every technical community that’s evolving has something like this. They’re questions
that lots of people are wondering about, lots of people are talking about, and lots of
people have strong opinions about that they really, really, REALLY want to tell you
about.
!
For example, if you’re a Rails developer, you have another open question right now,
and that is…

View Slide

What data store
should I use?
http://www.flickr.com/photos/hakkiceylan/5043637183
…“which datastore should I be using?” PostgreSQL, MongoDB, Cassandra, Redis,
Riak…so many options. When you’re a developer with a specific project in mind,
looking at either of these questions, it’s hard to tell what the right answer is.
!
The internet has a ton of information about this stuff, but unfortunately…the internet
has a ton of information about this stuff, and it’s really hard to sift through and find
the things that are really useful. Fun fact: if you google “how to pick a JavaScript
framework,” as of last week, there are two pages of results from the last six months.

View Slide

http://www.ﬂickr.com/photos/57340921@N03/6663307997
Unfortunately, as a collection, those articles are about as helpful as this collection of
parking signs. So look at that and tell me whether or not you can park there at noon
on a Tuesday. (I’m not waiting.)
!
I mean, of course, that they give you confusing and seemingly contradictory
information. That seemed to be the case even at Fluent. One talk would say ember is
great for [X], and then in the same room in the next time slot was a talk about
angular that said angular is clearly superior for [X]. Data binding, or whatever. Your
job is to synthesize all this data into a decision.
!
No pressure! But…it’s important, because the cost of being wrong is high. It’s not
just “might you get a $30 ticket?” If you pick a JS framework that isn’t suited to your
project, it can be disastrous, depending on when you ﬁnd out.

View Slide

http://www.ﬂickr.com/photos/cgpgrey/4887121259
How far down the road are you going to go, before you realize that there’s no more
road?
!
These decisions are big, and they are scary. And we want to be able to get better at
them. Unfortunately, we don’t make these decisions very often. And one of the most
effective ways for our human brains to learn is by repetition. I’m sure you’ve heard
that before.
!
Because in our programming pop culture, there’s a particular meme…

View Slide

http://www.ﬂickr.com/photos/celestinechua/9687401410
…this one. Here’s an “inspirational” image from the internets.
!
The meme is that it takes 10,000 hours of practice to get great at something, like
playing an instrument or programming, or…whatever this person is doing. It makes
me a little angry, actually, every time I see it. Not because of that horrendous drop
shadow on the text, though it is pretty bad. It makes me angry because it’s such an
over-simpliﬁcation of how people learn a skill.
!
This meme is persistent partially because it has a kernel of truth in it, which is that
repetition is a very powerful way for human beings to learn. The key, though, is not
just the time spent - it’s how you spend that time. You can spend 10k hours on
something, but if you’re not doing it right, those hours are wasted. To really learn by
repetition, you have to do the action…

View Slide

…analyze the outcome, and then repeat the action, changing it a little bit — this is the important
part — changing it to see if that changes the outcome. Even once you think you’ve got it, even once
you think you’ve can do that cursive letter L, you need to keep experimenting. Keep trying new
things. That’s where the learning actually happens.
!
As a side note, my daughter’s in third grade, and they don’t teach cursive any more. At all. She
doesn’t do these worksheets that I remember doing. Makes me feel old. She has, however, known
how to operate an iPad since she was 2. So…I guess I’m hoping that’s a more useful skill than
cursive in this new world.
!
But in any case, repetition is a powerful way for us to get better at something like large-scale
technical decision making. If only we did it as often as Noah is doing his cursive letter L. If only we
could wait 10 years, or 15 years, to accumulate enough experience with this type of thing.
!
Well - we can’t do that. At least not right now.

View Slide

But we can make an end run around this limitation by analyzing the decisions we do
make all the time, and bringing that information back to the framework choice.

View Slide

of
Libraries from Github
Frameworks
Languages
Decision Frequency
THE DECISION PYRAMID
Every day
Rarely
Everyday code decisions
We can do this because our decision making happens at different scales, and
different frequencies. Language and framework choices are the most infrequently
made decisions. But, there are a few things we do more frequently, such as decide
whether to use some random code you found on Github.
!
And even more frequently than that are the technical decisions we make every day —
things like “where does this code go? what should I call this variable? should I write a
test now?”

View Slide

http://www.ﬂickr.com/photos/columodwyer/11200346004
But even at the smallest, most frequent level, the process we use to make these
decisions is pretty opaque. Ask a programmer why they named a variable that way,
or why they put that function where they put it, and often all they can tell you is
“well, ah, it just seemed like the right thing to do?” Sometimes you get an answer like
“experience.” “Intuition.” “Gut feeling.”
!
When I ask a programmer why they like ember over angular, or the other way around,
I often get very similar opaque responses. “It feels more natural,” is one that I hear a
lot. I’ve heard it said about both ember and angular, by the way.
!
I wanted to investigate what goes into that feeling.

View Slide

http://www.ﬂickr.com/photos/tulanesally/3638658173
What data do we collect? How do we organize it? What do we do with it?

View Slide

of
Decision Frequency
THE DECISION PYRAMID
Every day
Rarely
Everyday code decisions
Libraries from Github
Frameworks
Languages
Higher risk,
lower frequency
Lower risk,
higher frequency
We want to get insights into these higher-risk, lower-frequency decisions, like
choosing a framework. So we’re going to look at the decisions one level up.
!
Because it turns out, I know a lot of people who evaluate libraries off Github all the
time. I asked a bunch of my colleagues to introspect for me, and describe how they
evaluate a gem that they’re considering using in their project. And it turns out that
they all start in the same place. They go to Github and they look at the README.

View Slide

Interface
This is a README that slightly predates Github. :) It’s a README from 1936, covering
how to operate the telephone.
!
When people come to a README, they’re looking for the features, the functionality,
and the usage of the code. Basically they’re looking at the interface of the gem —
what does it do and how do you use it? This information is easy to ﬁnd because it’s
usually in bullet points right there: “to operate,” “to answer,” “to clear,” “to make
calls.”
!
Let’s consider a real evaluation and see how it goes. Let’s say you’re trying to pick a
gem to make HTTP requests.

View Slide

http://www.ﬂickr.com/photos/dirtyf/2191026054
Now we all know that making http requests is how you construct the tubes that make
the internets. We want to use the tubes, so we need a gem to make http requests.

View Slide

of THE INTERFACE
HTTPARTY
FARADAY
https://github.com/lostisland/faraday
https://github.com/jnunemaker/httparty
A google search turns up two contenders from Ruby land, the ﬁrst called “Httparty”
— which I’m actually not sure how to pronounce — and a second called “Faraday.” So
assuming you don’t dismiss Httparty out of hand because you don’t want to keep
saying it, you look at the README for each project, skip to the usage section, and
this is what you’d ﬁnd:
!
You don’t need to actually read all this code — I’ll point out the interesting bits.

View Slide

of THE INTERFACE
HTTPARTY
FARADAY
1
2
3
4
Httparty has static methods [1], or you can include its HTTP call methods into your
own object [2].
!
Faraday takes a different approach, and gives you a connection object [3] that you
use to make the calls [4].
!
Both interfaces will work. Both will let you make any type of HTTP call you want. So
looking at the README, by itself, is not enough for you make a decision — just like a
bullet list of the features of a framework aren’t enough to tell you if it’s worth using
on your team.
!
So what else do we think about? Here’s what I got from interviewing a bunch of folks:

View Slide

of
•Read README (Github)
•Frequency/recency of commits (Github)
•Number & age of issues (Github)
•Comments on issues & pull requests (Github)
•Number & recency of tutorials/blog posts (Google)
•Relative popularity to similar gems (Ruby Toolbox)
•Date of last release (Rubygems)
•Number & answer status of Stack Overflow questions
•Opinions of work colleagues
•Opinions on Twitter
•Hacker News/Reddit discussions
•Opinions of outside developers (email, IM, etc.)
•Recency & completeness of official documentation
•Availability of books
•Mentions on screencasts/podcasts
•Evaluate code directly (Github)
•Evaluate the tests (Github)
•Drop it in and see what happens
•Build a sample app around it
EVALUATION TECHNIQUES
When Ruby developers are evaluating two similar gems, these are the things they do.
!
This is a long list. I had to move the font size way down to get it to fit. And it’s not
exhaustive. I could put more.
!
I want to point out a few interesting features it has.

View Slide

of
1
2
2
The first is that different people rank these differently. I always poke around on
Github first to establish that is has a reasonable interface and activity, and then I ask
my co-workers for input. But one of the people I talked with works at a company
displaying ignorance is not really a good thing, so he never asks his co-workers. He
goes straight for documentation and tutorials after he does the initial foray into
Github.
!
So that’s the first thing.

View Slide

of
The second is that no one does all of these for any given evaluation. Generally,
though, the riskier a decision is, the more of them we do.

View Slide

of
And the last thing is that this list changes as the community that generated it
changes. For example, before Rails came along, a lot of discussion about Ruby
libraries took place on the official English-language Ruby mailing list. But today, I
don’t think it would occur to any of us to post to the official English-language Ruby
mailing list when we’re trying to choose an HTTP gem. The Python community, on
the other hand, relies heavily on email lists.
!
All three of those things are pointing out that the way we collect and use this data is
pretty complicated. But the most interesting thing about this list, actually, is that
most of it isn’t technical data at all. It’s social data. It’s information about the people
around a project — the maintainers and users.

View Slide

of
Interface
README,
use gem
There is some technical data - let’s pull that out ﬁrst. This is what everyone starts off
with. They look directly at the features & functionality of the gem. Not the internals -
the external interface. We’ll put that stuff over here.

View Slide

of
Activity
Commits, issues, PRs,
releases, docs
Interface
README,
use gem
OK. Now, these things are information about the activity of a project. How often is it
updated, how likely am I to get help from the maintainer or get a pull request
merged? We’ll pull these out over here.

View Slide

of EVALUATION TECHNIQUES
Popularity
SO, HN, Google
Interface
README,
use gem
Activity
releases, docs
OK — most of this stuff that’s left is information about the project's popularity
among other developers. How easy will it be to ﬁnd help when I run into a problem?
Can I hire someone who is already familiar with it? How likely is it that someone else
has already ﬁxed a bug by the time I encounter it?
!
We’ll pull that stuff out over here, and now we’re left with a couple of outliers. What
are these?

View Slide

Popularity
SO, HN, Google
Interface
README,
use gem
Activity
releases, docs
Reading the code, and reading the tests. They don’t really ﬁt in any of the groups we
have so far. Interface, activity, and popularity are all pretty straightforward. There are
well-known sources of data for this information. But what we have left is a little
fuzzier.
!
It’s really about how familiar things feel to you. Is this code idiomatic Ruby? Does the
maintainer share my test strategy? How much does the code match up with what I
would write if I were going to roll my own? How much does this code feel like other
code I’ve seen?

View Slide

Popularity
SO, HN, Google
Interface
README,
use gem
Activity
releases, docs
Accessibility
Look at code
Let’s call this accessibility. So there’s our last group. These are the four categories of
data that we consider when we’re making a decision. Once I got to this point, writing
this talk, I sort of squinted the circles for a while, and I realized that you could
actually group them further in two different ways.

View Slide

http://dashes.com/anil/images/jobs-iphone-quadrants.jpg
Now, stay with me here, we’re about to make quadrants! Apparently they’re a thing.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
So, here we go. First off, you can draw one line here. The two categories on the top -
accessibility and interface - are both about you. Interface is about whether the code
can actually do what you need it to do for your project, and accessibility is whether
your team feels comfortable with the metaphors the project uses.
!
On the bottom, popularity and activity are about the people and the project outside
of your team. So we have a divide, here, between internal categories and external
categories.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
Then there’s another line you can draw here. On the left side, accessibility and popularity both have to do with
the people around a project. Accessibility is whether or not your people can use it. Popularity is whether other
people are using it.
!
Then on the right side, interface and activity are both information about the project itself. The interface, as we
said, is whether the project does everything you need. And activity, while it’s generated by people, is ultimately
about the project. It’s about whether you can bet on bug ﬁxes & improvements down the line.
!
So there you go. There’s my four-quadrant system for making difficult technical decisions. I was showing this talk
to this friend and we got to this part and he was like “This is awesome, because you’re a consultant now. And
consultants are supposed to have a system they’re selling. Now you’ve got one and it even has the right number
of quadrants!!!11one”
!
And I looked at him and I thought, you know, if I’m going to own this, it has to have a suuuuper narcissistic title.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
The Mei
System
So here we go. “The Mei System.” Now if this really makes you want to throw lots of
money at me…uh, let me know? But otherwise I think I’m just going to stick to my
pair programming consulting approach.
!
So we’ve got quadrants! Cool. But maybe isn’t super useful yet. All we’ve done is
capture the practices that people actually do into categories.

View Slide

http://www.ﬂickr.com/photos/drift-words/99645
Categories are useful. These ones in the picture look pretty useful I think. But they
really only become powerful when we apply them to the higher-risk problems. So
let’s look at how to apply these categories to higher-risk problems.
!
Er, maybe not these categories. Although, that also seems like it would be an
interesting talk. (Which framework goes in “Fish”?)

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
These categories. Let’s start with interface. At the framework level, as at the lower
level, it’s pretty straightforward. The interface of a framework is what’s in the
angular README, the ember README, and the intro tutorials. It’s the bullet lists of
features that make up most blog posts and conference talks (*cough*) about picking
a framework.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
Next — activity. This is also largely the same as at the smaller scale. You can get this
by looking at the Github project, looking at the release schedule, and looking at the
docs.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
Next — popularity. Also largely the same as at the small scale. Stack overﬂow
content, percentage of Hacker News arguments, number of recent blog posts.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
Finally — accessibility. This one is a little bit different. Once again, it’s kind of the
interesting one. Because in the JavaScript framework landscape that we have today,
there are multiple frameworks with sufficient interfaces, sufficient popularity, and
sufficient activity.

View Slide

…

View Slide

Right? This is where we are. Backbone, angular and ember. All three of these will do
what your application needs. They’re all reasonably popular. They’re all reasonably
active. Accessibility is how we distinguish these frameworks from each other. To
make this more concrete, I want to show you what an accessibility judgement looks
like at the small scale, and then at the large scale.

View Slide

of THE INTERFACE
HTTPARTY
FARADAY
Add http call
functionality
to your object
Keep http
functionality in a
separate object
So let’s go back to our HTTP library example. Both of these libraries have a sufficient
interface. They’re both actively maintained, and are both heavily used. But using
them feels different.
!
If you come from a procedural background, the upper approach will feel better. It will
feel more convenient. More natural.
!
But if you’ve done a lot of object-oriented programming, single responsibility
principle and all that, then the lower approach feels better. More natural. That’s what
accessibility is all about. Do you identify with the style of the code?
!
That’s even more important when you’re talking about frameworks, because
frameworks affect the code you write way more than an HTTP gem does.

View Slide

http://www.ﬂickr.com/photos/betchaboy/6325132427
But it’s not always easy to untangle the makeup of an accessibility judgement at the
framework level. Gems are relatively simple; frameworks are much more complex.
But let’s try. Now that we’ve seen accessibility in the small scale, let’s look at it in the
larger scale.
!
I want to start with a little history of how Java and JavaScript have historically gotten
along.

View Slide

http://cdn.arstechnica.net/wp-content/uploads/2011/10/dart-sharks-4e95fbf-intro.jpg
Which is not very well. For a long time, Java web framework land was a very sad place
to be if you were JavaScript.

View Slide

http://www.ﬂickr.com/photos/kawaii77/31896862
The state of the art, for a while, was something called “Java Server Faces.” I have
never actually seen Java Server Faces, you can’t ﬁnd them anywhere on my resume,
and please never talk to me about them again. o_0
!
Java Server Faces are packaged front-end widgets, usually with a really old version of
jQuery thrown in. And to put one on your page, you just put a little directive into
your code and it will spew JavaScript into your page. It hooks up automatically to
your backend, and you get JavaScript functionality in your pages without having to
write any JavaScript. This is considered a feature.

View Slide

http://www.ﬂickr.com/photos/3059349393/3801594313
Over the years, the Java community has put a lot of effort into avoiding JavaScript
entirely. Other efforts included GWT, google web toolkit. Write Java, compile down to
JavaScript, what could possibly go wrong?  
!
There are more modern approaches, too, like Dart. These are basically all efforts to
allow Java developers — of which there are millions — to write JavaScript without
actually having to learn it.
!
However! These days things are looking up.

View Slide

There is a new contender: Angular.js. Written by Java developers, and featuring a
dependency injection structure eerily similar to those found in modern Java backend
web frameworks.
!
Hmm.
!
So if you come from the Java backend world, or the .NET backend world, where
dependency injection frameworks are standard practice, then Angular will feel
familiar. Accessible. Natural. Angular is a huge step forward for the Java world. It’s
actual JavaScript — that’s great! — with a structure layered on top to make it less
risky for them to adopt it. They can do JavaScript, without having to learn an entirely
new development paradigm.

View Slide

http://www.flickr.com/photos/theknowlesgallery/4714085113
Conversely, for those of us who don’t come from Java or .NET, the dependency
injection in Angular will feel disorienting, at first. That makes adoption riskier,
because we’ll have to take on the cognitive load of understanding the framework in
addition to trying to actually get shit done.
!
Now of course there’s a learning curve on any JavaScript framework, for any team.
But finding a framework that fits the way you already think makes adoption less
risky. And that’s what accessibility measures, at its core. It’s a measure of how steep
the learning curve is likely to be for your team.
!

View Slide

Now of course Angular isn’t your only option. There’s Ember.js, with a mascot that I
think we’ve decided is a hamster. It’s not quite as creepy as the Go gopher. I don’t
know if you’ve seen the mascot for Go, the programming language.

View Slide

http://www.gophercon.com/img/logo.png
This may be the creepiest conference logo I have ever seen. Uh…I’m sure the
conference will be great though!
!
Anyway. Back to our friendly hamster.

View Slide

Ember.js - built by Rails developers, and featuring at the center of all ember applications, a
router! A router is a piece of code that takes in a request and decides what code to run as a
result. That is eerily similar to what’s at the center of all Rails applications.
!
Hmm.
!
This concept, that the incoming routes determine what code gets called, comes from REST. So, if
you come from a web framework that matured in the RESTful era, such as Rails or Django,
Ember.js is going to feel very accessible. It’ll feel easy. Natural.
!
On the other hand, if you come from Java or .NET or another web framework that matured before
REST was a popular thing, then you are used to having much more control over what exactly
happens to a request. So, Ember may feel a little…

View Slide

http://www.ﬂickr.com/photos/deanspic/4960440218
…overly constraining.

View Slide

And ﬁnally we have Backbone.js — the old-school choice. Backbone was graduated
out of a Rails app in the 2008-2009 timeframe. I know it’s hard to think back that
far, but that was before the idea of single-page apps was a thing. There were one or
two people doing things with like cappuccino over in a corner, but really most people
thought about JavaScript as something that decorated server-rendered pages.
!
So you’d render a view, assemble some JavaScript, shove them down a pipe to a
client, and once they got there, the JavaScript would add a veneer of interactivity over
the markup.
!
And if that’s how you still think about “web applications,” then Backbone will feel
natural. Easy. Straightforward. Maybe not convenient, at times, but certainly
understandable.

View Slide

On the other hand, if you’re one of those kids today who think about a “web
application” as a bunch of JavaScript that runs in a browser, creates some markup,
and goes out to the internet to get data once in a while, then Backbone feels
completely wrong.
!
So for this framework, the accessibility judgement ﬂows from the type of projects
you’ve done, rather than the technologies you’ve done them in. And that’s
interesting!
!

View Slide

http://www.ﬂickr.com/photos/gsfc/4690804595
What we’re seeing is that accessibility judgements come from many different sources
when we’re talking about frameworks, because of the extra complexity over a simple
gem.
!
One source is the technology stacks you’ve worked with. Another source is the type
of projects you’ve done. It’s also affected by who you’ve worked with, the industries
you’ve worked in, and so on.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
And for any given decision, accessibility is the most difficult of these to ﬁgure out.

View Slide

http://www.ﬂickr.com/photos/wyscan/22754672
It’s not like the Angular guys have a bullet point in their README that’s like “by Java
developers, for Java developers!”
!
Everyone who’s building a framework thinks they’re building it for everyone. And
they’re all wrong.

View Slide

http://www.ﬂickr.com/photos/seattlemunicipalarchives/2713475713
What they’re actually doing is turning the way they think into code.
!
So…how do you see that? Besides, I suppose, coming here and reading my rant. Well,
as fun as it is to talk about it, you probably don’t actually need to know what their
biases are when you’re making a decision. You’ll be able to feel how well they line up
with yours. Notice the amount of ease, or unease, you feel when you use a
framework.
!
And remember that even once you’re explicitly thinking about accessibility, it may
not always be the most important factor in your decision.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
Sometimes, you have a team that is overtaxed and you need a way to adopt a new
technology that is as close as possible to what they already know. But other times,
your team is ready and willing to be pushed further.
!
Sometimes you want popularity because you know you’ll need to hire 5 people and
the timeframe is short. But other times you pick something totally unpopular & new
because it has that one feature that you need for your project.
!
When you’re making a decision, just make sure you’re actually considering all four
quadrants.

View Slide

of OH, HACKER NEWS…
https://twitter.com/steveklabnik/status/444147360856551424
I want to close with something I saw on Hacker News last week. Steve Klabnik reads
Hacker News so I don’t have to. (Thank you, Steve.)
!
The context for this tweet is a blog post about Nimrod, an obscure programming
language. And one of the commenters on Hacker News talks about all the great
features it has, how great its interface is, and then he says, “The only reason Nimrod
isn’t popular is that people don’t evaluate things logically.” And he was clearly very
frustrated.
!
I actually really sympathize with his point of view.

View Slide

Popularity
Interface
Activity
Accessibility
Internal
External
Project
People
Because I thought that way when I was a new programmer. The decisions that other
people make really do look mysterious if you think that the interface is all there is to
consider when you’re evaluating a technology.
!
Nimrod is failing to catch on. But not because people are illogical.

View Slide

“A change in perspective is
worth 80 IQ points.”
Alan Kay
http://www.ﬂickr.com/photos/alexschwab/9205086243
It’s failing to catch on because their logic extends further than that guy can see…
from down there.
!
So, ok ﬁne, you can’t repeat the language or framework decision often enough to
learn from repetition. But you can take these categories and let them expand your
vista when you’re thinking about large-scale technical decisions.
!
As a very wise man once said, “a change in perspective is worth 80 IQ points.” Alan
Kay just invented object-oriented programming, that’s all.
!
And I’d say with the things we’re thinking about - a change in perspective is worth
80 IQ points, and also 5 years of experience.
!

View Slide

of
Sarah Mei
[email protected]
@sarahmei
Thank you very much. This is my consulting company, and, of course, I’m writing a
book.

View Slide

http://practicalrailsbook.com
I’m trying to make sure no one can ever tell me and Sandi Metz apart (two-syllable
ﬁrst name starting with S, one-syllable last name starting with M).
!
So we are writing a book together. Of course she’s the marquee name. It’s about
refactoring large rails apps. Go check it out at
http://practicalrailsbook.com if that is relevant to your interests.
!
Thanks!

View Slide

Most photo credits are inline. Others:
• Slides 1 & 2: http://www.ﬂickr.com/photos/loop_oh/4621885147/
• Slide 62: http://www.ministryofvelocity.com/
• Slide 63: http://practicalrailsbook.com
!
ALL THE LOGOS
• Ember logo (slides 5, 10, 40, 48, and 50): http://emberjs.com/
• jQuery logo (slide 6): http://jquery.org/
• Angular logo (slides 7, 10, 40, 46): http://angularjs.org/
• Backbone logo (slides 8, 10, 40, 52, 53): http://backbonejs.org/
• Other logos from slides 10 and 40:
• Ionic: http://ionicframework.com/
• can.js: http://canjs.com/
• Rendr: http://github.com/rendrjs/rendr
• Enyo: http://enyojs.com/
• Rikulo: http://rikulo.org/
• Flight: http://twitter.github.io/ﬂight/
• Polymer: http://www.polymer-project.org/
• Meteor: http://www.meteor.com/
• BladeRunner: http://www.caplin.com/developer/component/bladerunner
• React: http://facebook.github.io/react/
• Evening Starlight: http://friendshipismagicfanon.wikia.com/wiki/Evening_Starlight

View Slide

Unpacking Technical Decisions - Mountain West Ruby Conf 2014

Unpacking Technical Decisions - Mountain West Ruby Conf 2014

sarahmei

More Decks by sarahmei

Other Decks in Programming

Featured

Transcript