Reusing ActiveRecord scopes

You can use an ActiveRecord scope from one model to scope queries on another that joins it. This can be very convenient and keep your scopes DRY.

class Post < ActiveRecord::Base
  belongs_to :user
  scope :recent, lambda { order(:updated_at).last(10) }

class User < ActiveRecord::Base
  has_many :posts

It’s easy to get recent posts by saying User.posts.recent

But what if you want to fetch users who have recent posts?

users = User.joins(:posts).merge(Post.recent)

You can merge two scopes together and you end up with the conditions you would expect.


Note that you have to join :posts before you can merge a scope from Post.

Posted in Uncategorized | Leave a comment

Testing Rails Routes in the Console

Here’s a useful tip for testing rails routes in the console:
include ActionController::UrlWriter
default_url_options[:host] = 'hostname'

Then you can just type:



Posted in Uncategorized | Leave a comment

A Charming Dip Into HTML5 (and a bit of history, too)

I’ve only read a few pages of Mark Pilgrim’s Dive Into HTML5, and I already love it. The first thing that you’ll notice is that the pages are beautifully laid out with retro typographical elements. This gives the site a very warm and welcoming feel. Second, it begins with a history! This is really unusual in an industry that often treats anything that happened two years ago as irrelevant. This is more than just food for your curiosity, though. It’s an instructive story of how small decisions accumulate over time and how standards interact with implementors and consumers. Then come the technical points like the new semantics (which I love) and the various new HTML5 features. His explanations are clear and provide enough inline definitions for newbies to follow along, but also includes important details and outside links with information that even an expert may not know. Best of all, the prose is simple, supple, and amusing. This is a technical book you will actually enjoy reading. Go have a look!

Posted in Uncategorized | Leave a comment

Programming Skill and Dreyfus’ Stages of Expertise

In my last article, I posed an off-the-cuff model of skill development in order to illustrate a point about when we ought to improve our programming technique and when we ought to spend our time on other things. Today I began reading Hubert Dreyfus’ pocket-sized wonder On the Internet, and his description of skill development puts mine to shame.

Whereas I mentioned only familiarity, competence, and mastery with little regard to their specific content, Dreyfus gives a detailed account of the progress made by students. He uses this account to show the limitations of distance learning, but for our purposes, I’ll just summarize his stages of development:


A novice learns rules for performing certain easily understood actions in response to certain easily observable features of the environment.

Advanced Beginner

An advanced beginner has had some real-world experience and has begun to develop sensitivity to context in addition to the rules of the novice.


Competence comes when the student learns to sort their experience into relevant and non-relevant portions. This is necessary, because as experience increases, the number of recognizable aspects of a situation increases dramatically.

Moving beyond competency requires an emotional commitment by the student and a serious concern with the quality of their performance. It appears that the shift from a rule-based / rational mode of activity to an intuitive one requires a corresponding shift from a detached to an emotionally charged attitude of participation.


With proficiency, a student has internalized enough successes and failures that he is able to recognize situations immediately, but he must still deliberate in order to chosen an appropriate action.


An expert not only immediately recognizes each situation, but he intuitively knows the appropriate response. Experts are thus able to perform very smoothly, since no time is spent in deliberation. (Dreyfus’ “expertise” is roughly equivalent to how I used “competence” in the previous article.)


Mastery is the final and highest development of a given skill, and it is largely distinguished by an ability and willingness to go against established practices in search of increasingly better solutions. This willingness is usually the result of a strong dedication and passion for the material, which allows the master to persevere through failed attempts that could easily have been avoided had they been content to remain experts. Masters advance the state of the art.


If I were to update my recommendation using Dreyfus’ model, I would say that it is worth being an expert at anything you are doing professionally. If you are going to be a programmer, you might as well be an expert programmer. But you need to get clear on whether you’re pursuing mastery or not, because there’s no point in half-assing it. You’re not going to perform as well as a regular expert and you won’t get to the discipline-changing clarity of the master, either. That’s why it makes more sense to diversify if you’re not going to go for mastery one hundred percent.

The other wonderful thing about Dreyfus’ model is that it allows us to understand why so many people get stuck at competence and never reach expertise, no matter how long they spend programming. They don’t have the emotional involvement required to get there. To become an expert, you need an aesthetic sensitivity to your subject matter. You need to appreciate the beautiful and the good and despise the ugly and the rotten.

That’s why you can often tell a person’s skill or potential based on their reactions to code of varying quality. If they respond with disgust to hacky garbage and wondrous admiration to some little pearl, they may not be masters, but you know they’re on the right track.

Posted in Uncategorized | Tagged , , , | 6 Comments

Improve your Life, not your Craft: Why Programmers Shouldn’t Study Programming

There are many times when programmers should study programming, such as when they are first starting out, or in the process of solving some especially difficult problem. For certain developers, however, improving one’s programming skills seems to be a kind of go-to solution for dissatisfaction with life and career. I think that’s an error.

This is a follow-up to my earlier post on Organizational Variety, or Why Startups Should Hire Developers with Broad Experience.

Choose Mastery or Get Off the Treadmill

Last week, Seth Godin wrote a post called The Myth of Preparation in which he described three phases of skill development (or levels of polish depending on whether you’re talking about a person or a product). At first, quality increases rapidly with time, but then it levels off and progress becomes gradual. He calls these phases beginner, novice, and expert, but I have a different interpretation. The stages I’m interested in are familiarity, competency, and mastery. At every level, the increase in time required is exponential. Become a master is a worthy task, but it has to be a vocation because the investment required is huge. Competency, on the other hand, just takes a few years of dedicated effort. Once you’ve reached competency, the gains from, say, learning a new programming language or testing out the Latest Cool Thing are pretty low. You should already be getting enough of that at work. This is the time to get off the competency treadmill and head into the jungle.

Do Something Scary

The “jungle” is the place where you start over. Studying programming is easy. Pursuing your buried desire requires more. It’s usually a bit scary because:

  1. You have to become a beginner again.
  2. You might do something you’ve always wanted to, which also means you might fail at something you always hoped for.

The first is just a bit of ego bruising. The second is more difficult, but if you keep going, the satisfaction is worth the doubts. The experience of failure, when it comes, is almost never as bad as the anticipation.

Cultivate Your Business, Not Your Code

Whether or not you’re pursuing long-lost dreams, you are probably at least concerned with your professional success. In a software career, there are many factors that affect success, technical prowess only being one of them. For many developers, however, programming is the only one that’s really been explored. Here are a two more that merit investigation:

The first is communication, which I mentioned in the previous article. If something helps you understand project requirements, helps you promote yourself, improves your social life, and enables a new activity, such as writing, it’s probably worth your time!

Another is business, and in particular, entrepreneurship. This is as much of a commitment to enter the jungle as it is a self-made course in wilderness survival.

In December, Giles Bowkett posted a video describing reasons that it’s better to spend one’s time improving business savvy (and launching businesses) than on perfecting programming talents. He put the choice in rather dramatic terms as a decision whether to build your own business and become independent or to descend into a “Dilbert Hell” of cubicle oppression. I don’t think that every programming job is a Dilbert Hell. A lot of them are pretty cushy. But if you want to spend your time in that beginner’s rapid-learning state and less on the competency treadmill, starting your own business(es) might be a good way to go.


Once you have taken up a new skill or started your own business, you will develop new models of thought and new domains of knowledge. Once you’ve achieved multiple competencies, you can start synthesizing them and producing novel products targeted to the niche at their intersection. By diversifying your skills, you actually become more specialized with regard to their combination. For example:

  • You love food so you became a chef as well as a programmer? Great, now you are specially positioned to create all kinds of products for chefs: iPhone apps, community sites, technology training, etc.
  • You started a company? Now you understand the needs of small businesses. Startups for startups are a genre that Paul Graham has specifically announced he’d like to fund.

Enrich Your Life

The most important reason, however, to do something different is that it will enrich your life. The world is wide, full of fantastic things. The internet is a poor way to experience most of them. Having a powerful second focus in your life is a great reminder of everything we don’t know. For me, that’s highly encouraging.

Posted in Uncategorized | Tagged , , | 2 Comments

Organizational Variety, or Why Startups Should Hire Developers with Broad Experience

The law of requisite variety has fascinated me since I first learned about it several years ago in a course on cybernetics and design. The law is rigorously defined in W. Ross Ashby‘s Introduction to Cybernetics, but for our purposes we may loosely say that the more variety a system has, the more options it has in a given situation — and the more options it has, the more capable it is of obtaining a desired state of affairs. As Ashby points out, this offers a way of understanding the survival value of certain apparently useless characteristics of complex organisms:

This point of view enables us to resolve what might at first seem a paradox—that the higher organisms have sensitive skins, responsive nervous systems, and often an instinct that impels them, in play or curiosity, to bring more variety to the system than is immediately necessary. (212)

Organisms “bring in” variety by experiencing variety and internalizing it (aka learning from it). The more variety they acquire, the better able they are to maintain the parameters that allow them to survive. Thus, in the shifting conditions of life, it is important to acquire more variety than is immediately necessary by experiencing a diversity of stimuli and situations.

The same goes for organizations. The more variety a company has, the better able it is to cope with changing conditions. Companies already understand this this principle in a simple way with respect to investments and products, where it’s known as “diversifying”. So why is it that when I glance at the job boards, even for forward-thinking groups like the Rails community, that non-technical qualifications are almost never mentioned?

The ability to communicate well, for instance, is something that makes almost any person more effective. Effective communication implies verbal sensitivity. With regard to variety-acquisition, verbal sensitivity functions much the same way as skin sensitivity does for all higher organisms. The more carefully a person listens, the more variety he will acquire through conversation.

Likewise, excellence in any area is evidence that a person has the capability to do great things. If those great things are in an unrelated domain and in addition to programming expertise, that should be a very good sign for a hiring manager. It indicates broad intelligence and exposure to experiences which will have produced a greater variety in the individual, and thus a greater flexibility of thought and action.

Several years ago, I applied for a job at a startup that had a unanimous hiring policy: the whole team had to agree or the person wasn’t hired. I got turned down, despite the fact that the founder liked me, because one of the developers thought I had insufficient “passion for web development”. My response is that web development is exactly the wrong thing to be passionate about. It’s the wrong level of detail, especially for a startup. Development is what you practice so that you can create awesome products, or, for the more ambitious, so that you can change the world. Technical excellence is a prerequisite, not the end itself.

That’s why I always cringe when I read ads looking for “ruby rockstars” and the like. What they’re really saying is “we want people for whom the most important thing is the how, not the what”. A corollary is “we want people whom we can use to achieve our fixed ends, not people with whom to discuss and discover ends”. For startups, business models can change from week to week. Thus the ability to think about ends and not merely implementations is of the utmost importance. Hiring a “ruby rockstar” is a bit like hiring an editor who is a “grammar rockstar” instead of one who is actually thinking about the topic and critiquing the ideas.

To return to the story, why is it such a poor idea to hire by consensus? Because it guarantees monoculture. It limits the variety of employees to the most recognizable and common sort. It decrease the variety of the organization and hence reduces its ability to produce desired outcomes.

“But what if I just want my employees to do what they are told?” Go ahead, hire those people. You just removed all of the reflective intelligence from your organization. Next time you ask for something stupid, you can be sure you’re going to get it.

Posted in Uncategorized | Tagged , , , , | 1 Comment

Hello world!

My name is Nick Urban. I’m a web developer with a penchant for philosophy. I love the startup world for its energy and innovation, but I think it can be rather shortsighted at times. I’m starting this blog as a place to stash technical tips, and more importantly, to express my thoughts about this crazy business of ours.

Posted in Uncategorized | Leave a comment