Ben Scofield

Raise your hand if you have a job description – a paragraph or eight that describe your role and responsibilities in your current position.Now, raise your hand if you have a specific set of goals for what you are supposed to accomplish today, this week, this month, and this quarter.

I’m betting that there’s little, if any, overlap between those two groups.

I used to be in the job description camp, and I was pretty effective. I built stuff, went to meetings, talked to people, got stuff done… I think I did a good job of matching the description. For the last eight months or so, however, I’ve been in the second camp. In lieu of a formal job description, I have specific, measurable goals to accomplish in any given time period. As a result, I can tell you exactly how I’m doing at any given point, and where I need to focus my efforts to get more done.

For freelancers, of course, this is probably an obvious change – when you work for (and substantially by) yourself, your job description is “get everything done,” which means you have to fall back on goals. For employees, however, changing your mindset from a vague prose passage to a set of concrete goals can be a massive shift. It can dramatically improve your effectiveness at your current job – or it could show that you should’ve been doing something different all along.

I had a thought the other day… I wonder if the demise of correspondence via letters has resulted in a reduction in significant thought. Here’s the idea:

When long-form letter writing was the predominant means of long-distance communication, you had some astounding exchanges (Descartes’ correspondence with pretty much everyone, for instance). Many great thinkers first detailed their theories in these long letters, and I wonder if the form itself made that more likely. Think about it – when you’re corresponding via letter, longer messages are more efficient (whereas the opposite is true today, with email, IM, and tweets). Longer messages mean more time writing, and more time writing means more time thinking through what you want to say. As a result, then, writing long letters may have helped people think through their ideas more fully before making them public.

If that’s the case, then it very well might be the case that today’s preponderance of short-form communication makes it much less likely that anyone will release a complex idea fully-formed – but the greater frequency (and reach) of their interactions with other people may overcome that deficit. Could it be that letter-writing was waterfall, and email, IM, and Twitter are agile?

(And might this post play into that precise analogy, being far from presenting a fully-formed theory itself?)

So, after some difficulties getting the planes to fly on time, I finally made it home from CodeMash late last night. Despite only being there for a short time (and being intensely jealous of everyone who was able to stay for the full event), I had a great time.

I did notice a couple of differences between CodeMash and the Ruby/open source conferences I normally attend, however. First, the gender balance was, while still skewed, was much closer than I’m used to. I remember hearing somewhere that there were more women in enterprise computing (.Net and Java) than in the more fringe technologies, and I guess I’ve got anecdotal evidence to back that up, now.

Also, the sponsorship atmosphere was very different – in fact, it felt more like the Startup Crawl than it did the Expo Hall at RailsConf. Sponsor booths had video games, coding problems, and a ton of giveaways (both raffles and freebies), and their staff were a bit more assertive.

My talk (an updated version of the one I gave at RubyConf) went over well, I think – no ratings on SpeakerRate yet, but (like all technical conferences) there were substantial problems with the wifi, so I’m hoping that people will rate it once they return home. I did fail in one significant way, however: I didn’t consider my audience as carefully as I should have. The needs of an audience of .Net, Java, and related technologists are somewhat different than those of a room full of Rubyists. I got a question on Neo4j’s licensing, for instance, that hasn’t come up in any of the half-dozen or more times I’ve talked about it previously.

I don’t think that this problem affected the presentation itself, but it’s certainly something I should have done for the question period.

The first RubyConf talk I gave was entitled Cleanliness Is Next to Domain-Specificity; in it, I spoke about DSLs, and gave an example of how you might want to create one (I also spent some time talking about regional variation in Little Bunny Foo Foo, but that’s neither here nor there). At the time, I said that the best way to design a DSL was to write out what you wanted it to look like, and then write the code that made that functional.

I’ve since become convinced that this process is in fact the best way to design any code, not just DSLs. API? Write out how you want to call it, then write the code that responds to those calls. Routing in a web app? Write out the URLs you want people to hit, then create the code and routes that will make those work. A web page? Design the page, build it out into HTML, and then write the code that makes it live. Each of these is an example of design-first development.

You may be wondering if I’m abandoning the lean/agile fold for waterfall with this idea. Happily, I’m not. If you think about it, this is how TDD (or BDD) works: you write a test or spec that runs some code (in the process, designing how you’ll interact with the code), and then you write the code that makes it pass. The sort of design I’m talking out isn’t fossilized in spec documents, but is actually executable when you finish writing the code to make it work.

The key to all of this is realizing that design happens at a number of different levels. In the examples above, I described design the level of writing code (DSL), of integrating with systems (API), of browser interaction (routing), and of user interface (web page).

I think that more and more people are realizing the power of this approach at various levels, but I’m convinced that recognizing each of those levels as an instance of using design-first development may provide better insights into the process overall.

It’s a new year, and it’s about time for a hard truth: practice, when done properly, isn’t fun.

I’d love to be able to tell you that it is – that the transcendent joy you get when you practice a skill gives you the best feeling in the world – but that’s not true, and if you pursue that end you’re going to misuse your practice time.

The father of the analysis of practice is Anders Ericsson; his 1993 paper on deliberate practice is a must-read for anyone interested in mastery. In that paper, he distinguishes three different sorts of activity:

• Work is the execution of a skill for an external reward (for instance, a paycheck)
• Play is the execution of a skill for an internal reward (because it makes you happy)
• Deliberate practice is the execution of a skill specifically to improve at that skill

Those distinctions alone leave open the possibility that practice could be fun, but when you start to dig into the depths of activities that are specifically designed to help you improve a particular skill, it turns out that they share very little with the general activities you see in play (or in work, for that matter).

Daniel Coyle provides an example of this in The Talent Code. He describes a video of a schoolgirl practicing the clarinet. She’s an average player, but during one six-minute section of the video, she practices deliberately, and improves markedly as a result. Watching the session, however, you’d be hard-pressed to understand why this particular bit was important, because it certainly doesn’t look like she’s enjoying herself – where later in the session she’s playing through tunes, here she’s constantly stopping and starting. It doesn’t sound like music, or what we naively think of as practice, but it’s the best thing she could be doing.

The point is that the actions that produce the most improvement aren’t closely related to the more common performances of a skill. In a martial art, you may practice a single turn hundreds or thousands of times in order to perfect a tiny piece of a long form. The practice itself isn’t fun, which means we have to trick ourselves into enjoying it by considering the future rewards.

Aside for developers: one consequence of this finding is that side-projects don’t cut it as practice. If you want to improve in your technology and you think you’ll do it in the course of building some application that you have a need for, you’re heading down the wrong path. What eventually happens is that the external reward (of having some tool that you want to use) will inevitably overtake the skill-improvement aspects of the process, and, while you’ll end up with something useful, you won’t have improved as a developer nearly as much as if you’d spent that time practicing more effectively.