Codeulate. » coding

Don’t get blocked

Ben Orenstein — Tue, 27 Sep 2011 03:35:19 +0000

Every day at our stand-up, each person shares what they did the day before, what they plan to do today, and, critically, whether or not they’re blocked.

Blocked is a crappy place to be. It means you’re trying to get something done but can’t. Current velocity: zero.

I’ve noticed something about programmers I admire: they’re extremely good at not getting blocked.

Some time ago I spent three days trying to get a feature working. I was blocked, and bad. Finally, I took a break and went to work on something else. The next day at standup, a colleague mentioned implementing that same feature, and then then going on to do two more tasks with the other half of his day. Incredulous, I asked him how he solved the problem I’d run into. He happily admitted he hadn’t. He’d run into that problem, spent a half hour on it, and then changed direction.

Me: got blocked, pounded on the barrier. Great programmer: got blocked, tried something else that worked and moved on.

Like most programmers, I have an strong desire to solve problems. Put some broken code in front of me and I’ll wrestle with it ’til it works. There’s lots to do but I’ve got to start by fixing this problem.

The best programmers I know have a different mantra: don’t get blocked. They’re focused on moving things forward, not getting bogged down making everything perfect. They’ll duck and weave, leaping over obstacles or tunneling beneath them. They like problems too, but they like something else even more: shipping.

Don’t get blocked.

Programmer Resumes are Deprecated

Ben Orenstein — Tue, 14 Jun 2011 05:24:22 +0000

First, some exciting news: after a thorough (but enjoyable!) interview process, I’ve accepted a position at thoughtbot in Boston and will begin in a few weeks. I can’t wait to get started.

The interviews themselves will make great fodder for future posts, but I realized a startling fact the other day: I never once sent anyone at thoughtbot a resume.

Moreover, I was never asked about schools, degrees, nor much about my past experience. My “resume” took the form of links to this blog, some open source contributions, and access to a couple private github repos of Rails apps I’d built.

This experience confirms an idea that I’m glad to see gaining ground lately: resumes are deprecated. Code is king. Oh, and connections help a lot too.

A year ago I wrote that it was possible to land a Rails job with no experience, provided you had a portfolio application, some code on Github, and attended Ruby meetups to network. Some people were skeptical, but it was exactly those things that got me my first Rails job. Now, years later, the same set of things got me in the door at thoughtbot: code, more code, and the recommendation of thoughtbotter Dan Croak, who I got to know during the ’09 Rails Rumble (yet more coding!)

I’m starting to think this really is the secret sauce for professional programming success, regardless of experience level. Get some code out there for people to see, and get yourself out there to meet awesome programmers you might want to work with someday. Leave the bullshitty bullet points to the MBAs.

Don’t Use Rails’ Scaffolded Controllers

Ben Orenstein — Sat, 13 Nov 2010 05:04:28 +0000

Fellow Rails Developers, the state of the art has moved on, and you should no longer be using the controllers generated by Rails’ scaffold command (or ‘rails g resource foo’).

These controllers are all the same. Repetition like that can and should be eliminated.

Instead, you should use something like Inherited Resources.

Here’s what a controller generated by Rails looks like:

class UsersController < ApplicationController
# GET /users
# GET /users.xml
def index
@users = User.all

respond_to do |format|
format.html # index.html.erb
format.xml { render :xml => @users }
end
end

# GET /users/1
# GET /users/1.xml
def show
@user = User.find(params[:id])

respond_to do |format|
format.html # show.html.erb
format.xml { render :xml => @user }
end
end

# GET /users/new
# GET /users/new.xml
def new
@user = User.new

respond_to do |format|
format.html # new.html.erb
format.xml { render :xml => @user }
end
end

# GET /users/1/edit
def edit
@user = User.find(params[:id])
end

# POST /users
# POST /users.xml
def create
@user = User.new(params[:user])

respond_to do |format|
if @user.save
format.html { redirect_to(@user, :notice => 'User was successfully created.') }
format.xml { render :xml => @user, :status => :created, :location => @user }
else
format.html { render :action => "new" }
format.xml { render :xml => @user.errors, :status => :unprocessable_entity }
end
end
end

# PUT /users/1
# PUT /users/1.xml
def update
@user = User.find(params[:id])

respond_to do |format|
if @user.update_attributes(params[:user])
format.html { redirect_to(@user, :notice => 'User was successfully updated.') }
format.xml { head :ok }
else
format.html { render :action => "edit" }
format.xml { render :xml => @user.errors, :status => :unprocessable_entity }
end
end
end

# DELETE /users/1
# DELETE /users/1.xml
def destroy
@user = User.find(params[:id])
@user.destroy

respond_to do |format|
format.html { redirect_to(users_url) }
format.xml { head :ok }
end
end
end

Here’s that SAME controller using Inherited Resources:

class UsersController < InheritedResources::Base
end

That’s right, just by inheriting from InheritedResources::Base you all the standard REST actions for free.

If you need to, you can override any of the default actions:

class UsersController < InheritedResources::Base
def new
# do different stuff for new
end
end

It even has a nice DSL for customizations you’re likely to need. Here’s how to change just the redirect for the destroy action:

class UsersController < InheritedResources::Base
def destroy
destroy!{ root_url }
end
end

The best thing is, once you’ve got that duplicated code out of there, you don’t need to test it! Inherited Resources already has its own tests for the standard actions, so you only need test the things you explicitly change.

A few months ago, I refactored an app to use Inherited Resources instead of the generated controllers. And by ‘refactored’, I mean ‘deleted pages and pages of controller and test code’. I ‘git rm’d almost all our functional tests and damn that felt good.

You gotta get in on this! The README is solid, so you should have little trouble getting started.

How Unit Testing Could Have Saved Lives

Ben Orenstein — Fri, 16 Jan 2009 19:35:07 +0000

A recent article in The Independent describes a fascinating study. Researchers found that forcing surgeons in a London hospital to implement a single new procedure caused the death rate after surgery to fall 47 percent. Complications likewise fell by 36 percent.

These are enormous numbers:

Donald Berwick, the president of the US Institute for Healthcare Improvement, said of the innovation: “I cannot recall a clinical care innovation in the past 30 years that has shown results of [this] magnitude.”

The change? The surgeons were required to run through a simple checklist before and after every procedure.

Now, this checklist [pdf] is not lengthy. In fact, it’s less than twenty questions. Even more strikingly, the questions are not complicated: before administering anesthesia, has the patient confirmed his identity? Does the patient have any known allergies? Have we confirmed that this is the right foot? I’d wager that the most common reaction of people seeing this checklist is “you mean these things weren’t being asked already?”

The thing is, these questions were already being asked. The difference is that they weren’t being asked in systematic way. Members of a surgical team assume that these obvious things have been checked because they’re so obvious. “Of course this is the right patient.” “Of course we asked if he’s allergic to the anesthetic.” “Of course we marked the right limb for amputation.”

The problem is, these things are sometimes done incorrectly, or missed entirely. Not often, not usually; just sometimes. Forcing doctors and nurses to use the checklist caught these “sometimes” problems, and dramatically improved patient safety in the process.

From this study, we can draw the following conclusions:

Even obvious errors are easy to commit, and once committed, can have terrible consequences.
Those who overlook these problems can be highly-trained and intelligent people. It appears that you cannot out-train or out-brain our human tendency to err from time to time.
Instituting a rigorous system to check for errors lowers their occurrence dramatically, compared to existing processes that check for them informally.

Laid out this way, these statements are probably starting to look familiar, because they are exactly like the arguments for using unit tests in programming. As a software developer, I look at this list and think we knew this stuff already! We knew it, and we came up with a way of mitigating the problems caused by our own flawed humanity.

The errors that this checklist catches are the kind that kill people. Thousands of people, every year. If we, as an industry, had somehow conveyed the efficacy of systemic testing with the medical field, this checklist might have been implemented sooner, and lives could have been saved.

The fact that ideas like this don’t flow across fields is not surprising. Industry-specific myopia reflects our human tendency to form into groups and distrust outsiders. Despite this, I do believe it’s worth struggling against. Perhaps the field of architecture could provide useful insights into the construction of software (perhaps it already has). Maybe the next big idea in architecture will be inpsired by chemistry, or biology. Maybe the next time I open my editor I should think “first, do no harm.”

It certainly couldn’t hurt.

Damn Useful: When You Forget to type Sudo

Ben Orenstein — Tue, 09 Dec 2008 16:12:20 +0000

(This post is part of a series. To read more tips and to learn about the philosophy behind these posts, check out the parent post.)

You know you’ve done this way too many times:

ben@lispclub ~ $ apt-get install blahblahblah
E: Could not open lock file /var/lib/dpkg/lock – open (13 Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Bah.

You forgot to type sudo first.

So what do you do? Hit up arrow, swing back to the beginning of the line, type sudo–ARGGH…THE WASTED SECONDS!

Do this instead: sudo !!

In bash, !! means “repeat the last command I entered.” Bash substitutes your apt-get command after the sudo, and you finally get to install blahblahblah 0.0.13. Note that this isn’t specific to sudo. If you do an ls, and then wish you’d grepped the results for foo, type !! | grep foo.

How to remember it:

Imagine an angry father yelling for his son. “Sudo!!” Sudo runs down from his room, sees the command he was supposed to be in front of, and executes it immediately.

Damn Useful Tips

Ben Orenstein — Tue, 09 Dec 2008 16:11:57 +0000

This post is the first in a series called Damn Useful. The posts will be a number of tips on the tools we use most frequently as programmers, particularly the shell and editor. Because of my own preferences, I’ll focus on bash, vim, and unix tools like grep, screen, and others.

Here are some guidelines on what to expect:

1. One tip per post.

I’m a sucker for productivity tips. I’ve read dozens of articles with titles like “25 _____ Tips for Fun and Profit!” I usually take away at most one useful tidbit from these articles. A lot of good stuff gets lost in the tidal wave of new information. This posts in this series will be short: one tip each. I’ll focus on just one idea and move on.

2. I’ll provide mnemonics or imagery to aid recall.

Can you name the nine planets in our solar system? How about the order of arithmetic operations?

If you can, I bet you access a mnemonic you’ve learned for this purpose. I use My Video Eye May Just Show Us Nine Planets, and Please Excuse My Dear Aunt Sally for these two.

I’m never, EVER going to forget the names of the planets. That mnemonic is in my brain for good. I want the things you learn through this series to be the same way. As such, I’ll try hard to come up with memorable mnemonics for them. Sometimes mnemonics don’t make sense, and I’ll instead provide an image to think about that will hopefully stick in your mind.

3. The tips will involve tools programmers tend to use daily.

The value of a tip is proportional the number of times a day you can use it. These tips will probably only be worth a few seconds each on their own, so I want to be sure there’s a big fat multiplier next to each one. I’ll be focusing on the heavy hitters in the programming world.

The Posts:

When You Forget to type Sudo

On the fundamentals of programming

Ben Orenstein — Fri, 14 Dec 2007 18:01:02 +0000

Let’s start with a story.

I am a volleyball fanatic. I enjoy the game in a way that borders on obsession. Lately I play three times a week for hours at a time. Now, my position is known as middle hitter. As you might have guessed, I’m the guy who stands in the middle of the court and tries to pound the ball through the other team’s floor.

A few months ago, I was going through an athletic crisis. Despite many hours of play I still wasn’t that good at hitting. In fact, I kinda sucked at it. My other skills were decent, but when it came to spiking the heck out of the ball, something wasn’t right. I just wasn’t getting the power other people were and I didn’t know why. I experimented constantly: different arm swings, changing my hand shape, snapping my wrist. Nothing worked. Sad and ashamed, I enrolled in a clinic hoping to cure my hitting dysfunction.

On the first night, the coach ordered us into a hitting drill. No problem. I’m focused, I’m ready; I’m going to crush this ball. I went up for my approach and, well–tapped–the ball over the net. Not impressive. I tried again but with similar results. Discreetly, the coach pulled me aside:

“Did you know you’re taking an extra little hop before you jump?”

“I am?”

“You are. It’s taking away all your momentum so your jump is all wrong. Get rid of that and try again.”

On my next attempt, the set was perfect: high and tight, and I smacked it the same way you’d high-five your grandmother. But that time, I felt the extra hop I was taking. Suddenly it was so obviously there.

I lined up once more. I took three strong steps, leapt in the air, and pounded down the best shot of my life. WHAM! I was elated. The problem I had with hitting was simple: I was deficient in the fundamentals. Everything I’d been tweaking was the minor stuff. Fundamentals are the rock-solid road bed you build on. I’d been rearranging the mile markers on a strip of sand.

The point here is important: mastery of any complex skill requires mastery of its fundamentals. I think this idea just might tell us why there are so many bad programmers out there. And I also think it tells us it’s our fault.

How does one acquire the fundamentals of programming?

I don’t think the answer lies in obtaining a computer science degree. I once interviewed a recent MIT graduate who’d majored in computer science. She was articulate, had a strong GPA, and couldn’t write the pseudocode to sort an array. Really. This is actually a familiar phenomenon. A CS degree tells you how, theoretically, you might spike a volleyball, but that doesn’t mean graduates have ever actually hit one. Of course computer science isn’t really about programming, it’s not even about computers. Now, there are lots of strong coders with CS backgrounds, but that strength is almost always acquired through their own work–they are self-taught.

Academia isn’t much help, so we’re going to have to become deadly code-ninjas on our own. Fortunately, there is a wizened master who can point us in the right direction: Peter Norvig, whose essay “Teach Yourself Programming in Ten Years” wins my personal Nobel for Programming Literature. It’s probably the best advice out there on the subject, and we’d all do well to follow his recommendations. However, despite the fact that Peter is so smart his brain has its own gravitational pull, I think his essay glosses over an important point.

Let’s look at the main thrust of Norvig’s advice:

Program. The best kind of learning is learning by doing. To put it more technically, “the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve.” (p. 366) and “the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors.”

This is clearly good advice. Surely that MIT graduate could have written me that algorithm if she’d, you know, written code before. But check out the quotation Norvig cites. Where exactly does one find well-defined programming tasks of an appropriate difficulty level? How about informative feedback and corrections of errors?

Well?

It turns out that there’s a shortage of things like this for programmers. Especially new ones. This is a serious problem, and it is this I blame for the huge numbers of coders who lack the fundamental skills of our craft. Worse, this is our own fault: only people already skilled in an activity can devise effective training for newcomers. Even worser: when you lack skills in the fundamentals you almost never know it. I had no idea why I couldn’t spike a volleyball.

So how do we fix this? We do what all great thinkers do: steal a great idea from somewhere else and reuse it. So here’s my solution, shamelessly grabbed from a different, but related area of my life:

To become a better programmer, one should practice like a musician.

Bear with me…

A beautiful piano sonata is the product of thousands of perfectly executed notes. If even one note is misplayed you have cacophony. However, the consideration of individual notes never enters my mind while playing. Instead, I’m thinking about making the phrases flow together, the winsome arc of the melody, or keeping the steady beat of the bass line. It is these things that create music from mere notes. I’m able to think of these things because my mind is free from worrying about playing individual keys, and my mind is free because of my mastery of the fundamentals. The study of classical piano (and every other musical endeavor) devotes ample time to performing exercises. There are perhaps hundreds of books full of them. Compared to a real piece of music they are simple and repetitive, but each exercise isolates and drills a vital skill. This focused practice makes such skills automatic–I can play a very fast run of notes smoothly and accurately because I’ve quite literally practiced it thousands of times. I no longer need to think about it. Because of this, I am a better pianist.

The application of these ideas to programming should be clear. When I’m focusing on the overall musicality of a piece, I’m operating at a higher level of abstraction. Individual details have faded away, and I’m able to focus on making something beautiful. The same skill is required for creating beautiful programs. If you must spend brain cycles struggling with minute implementation details you have no hope for making your solution elegant.

So let’s take this musical idea and alter it slightly. After all, when it comes to programming exercises, coverage is more important than repetition. Not remembering how your language retrieves values from a hash is far less damaging than not knowing hashes exist in the first place.

Fortunately, I can already point to an excellent example of these sort of problems. I believe newcomers would learn more about programming per unit time by working through Ninety-nine Prolog Problems than almost anything else. (Replace Prolog with your language of choice). With the ability to check your answers and also post questions on a wiki, we’ve even covered the “correction of errors” and “informative feedback” requirements mentioned above. Also excellent is The Python Challenge, a series of riddles with programmatic solutions that get progressively harder over time. The site is massively popular and makes people better programmers. Truly, this is a phenomenal start, but there’s much more to be done.

So how about it guys? What are the first fifty programs someone should write to break out of that painful newcomer phase? What topics would they definitely have to cover? Later, what programs must one write to reach hacking virtuosity? I also like to think about this a different way: what problems would you be embarrassed to tell your coworkers you can’t solve?

I think these questions are important, and they just might help improve the overall quality of programmers out there. If you accept programming as an art, why don’t we treat it like one? Let’s start practicing like musicians, and maybe we can create something beautiful.