More on practice

In a great post by Jeff Atwood.

Ada Byron was Homeschooled

Continuing this discussion from Geeknews and greatjustice.

The post at geeknews doesn't make much of a statement except in the title, but since this is a generally inflammatory topic, they've earned a pile of readership from that alone. And to prove I'm not the guy with the degree trumpeting the wonders of elitism, I went to a second-place state college. Even that was a better education than I could've managed on my own, but then it doesn't take MIT to do that.

I've been a vocal supporter of bootstrapping your way into other careers for a couple years now, but recently have changed my mind. I think the question of degree vs. hard knocks goes deeper than the "value of an education" or "real-world experience". Those are great things, but what will really turn a journeyman to a master is deliberate practice (PDF).

According to Ericsson, et. al., to really be deliberate practice, not just any task will do:

The most cited condition [for optimal improvement] concerns the subjects' motivation to attend to the task and exert effort to improve their performance. In addition, the design of the task should take into account the preexisting knowledge of the learners so that the task can be correctly understood after a brief period of instruction. The subjects should receive immediate informative feedback and knowledge of results of their performance. The subjects should repeatedly perform the same or similar tasks.

This probably sounds obvious, but take a step back. What they're asserting is that learning is doing. It is a task. You can sit on your ass reading CS articles on Wikipedia for 4 years and never learn how to write a program. You could even read through MIT's "Structure and Interpretation of Computer Programs" course material for free and not learn a damn thing about Scheme.

Whether you're learning from Wikipedia, a professor, a colleague, or a book, you're not going to start learning till you care about the subject and start stretching. A great programmer is one that is not afraid to do just that, and at the end of the day it doesn't matter whether he went to college or not. He will be great because he wanted to be and was not afraid to do what it takes to get there: intentional, deliberate, ongoing practice.

This practice of learning has been around much longer than universities. The system of apprenticeship survived for thousands of years. Any good tutor can create the above conditions for their student, but at the end of the day it is the student that must put the work in, not just the reading. Or the student can put that work in even without a tutor, though it will take much more effort.

So when hiring, look for the curious, unafraid, diligent one. Don't let a degree fool you into thinking that, just because they had the opportunity to learn, they did anything but read.

Further reading: A Reg Braithwaite post in a similar vein.

On Elegance

Lately I've been working on a new media serving backend for Treemo. We've outgrown the features on our existing setup, and since the vast majority of our hits are content downloads, it's time to optimize those.

One thing that we've discovered needs changing is the URL structure for our content. Most large content-focused sites like Flickr, Fotolog, or Imageshack use an unguessable portion of the URL to enforce visibility restrictions. This allows easy connection to a CDN, as you can simply pass out those URLs to a hosting service secure in the knowledge that they will only be presented to the appropriate people. Livejournal is an exception, they do authorization and byteserving on their balancers. We copied this setup initially, but as is the case with many Livejournal tools, we found we had to really go whole hog copying the rest of their setup (in this case, perlbal) to make it useful. So we're changing our approach.

Obviously changing your URL scheme for embedded content is a rather major migration, and not to be done lightly. Among the many issues that have arisen during this process is what the URLs should look like. I spent a lot of time evaluating the Flickr URL scheme, as they're the biggest and we were looking to model their architecture instead of Livejournal's this time. One thing I came to appreciate about their scheme is the elegance. You can check it out here:

http://www.flickr.com/services/api/misc.urls.html

The longer I worked on various combinations of schemes that would give us the structure we wanted, the more I realized that their scheme included everything you needed and nothing you didn't, and did so in under 80 characters. Making something that nice or nicer became a goal.

I got to the point of evaluating how to alter our object model to accommodate the new information that the filesystem would need to back up the new scheme, and darn if it wasn't hard. Adding the data I wanted was going to be expensive. There were easier schemes I could use involving long hashes or other things that would be just as secure, just as functional. But they'd be huge. And something in me didn't like that, and a few halfhearted dust-ups with my officemates found me unable to articulate why.

Part of it felt like well, Flickr has already proved this scheme works. They've learned lessons about it that we don't haven't, so let's not reinvent the wheel here. But that doesn't get me very far. Other, easier schemes would work, and who cares what the URLs look like?

And I couldn't escape the fact that I do, and I had to leave it at that.

But the more I thought about it, stronger I felt that not only should a new scheme be functional, but it should be nice. It should bear the mark of a system made with care for people, not tools. I think the ability to make this small part of the system exceed requirements in an elegant and surprising way became important, because if all I do is make tools that work, I get bored. Anyone can write code that does what the customer wants. The magic happens when we make code the customer doesn't realize he wants. You might not realize that nice URLs make the system more humane to use, but when they're obnoxious, it's noticed. "Huh," your users will say, "that's funny-looking." Not a thought that should be going through your users' minds, even for the half-second their subconscious will think about it.

I think we as developers have a lot of responsibility to think like a user even - maybe even especially - when it makes our jobs harder. Thinking for them helps us develop products that exceed their expectations, which allows teams to gel, which is the only way great products are made.

PHP in a nutshell

# is_writable — Tells whether the filename is writable
# is_writeable — Alias of is_writable

On Moving, Part 3

Arrival

We've been working toward this move in parallel with our next major treemo.com release. The two coincide so closely that today, on our second day in the building, we're shipping our Biggest Release Ever.

One of the key considerations when performing such a trick is to keep productivity up while adjusting to a new space. The best way to do that is to make sure that when you arrive, everything is ready to go. That we managed this is remarkable, and I'm still kind of taken aback. When I arrived on Monday there was little to do except set up my workstation, plug in, and get to work. We had our first meeting in the new conference room to plan the release, and got to doing it. Today, we had lunch delivered and camped out smashing bugs. I got some delicious cider from my sister, who works in a coffeeshop on the first floor.

We are so spoiled. :)

On Moving, Part 2

Departure

Here are some things we did that worked when leaving our space in Ballard:

• Sent contingents from each team to the candidate office spaces
• Put our office manager really in charge of the moving details and scheduling
  
• Had everyone fill out the office map in the way they felt best and combined them to create the final layout
• Allowed our IT team to spend plenty of time readying the infrastructure move
• Hired a mover (we didn't do that the first time...)
• Bought everybody FlexPasses to compensate for the loss of parking

Mercifully, I was insulated from most of the thousands of decisions and jobs to be done when moving 10 people's workspace. All I had to do was pack up my things and unplug my workstation. It seems like that's exactly right for what I need to do for my job. And after so much time here having to worry about everything, it was a nice change.
I'm certain that others in the company were frantically busy trying to get everything moved, and obviously they did a wonderful job. I love it when a plan comes together.

On Moving, Part 1

Promise

The space in which you work completely defines the parameters of your activity there. It outranks even your CEO by placing hard physical boundaries around what types of work can and cannot be done. Work which requires quiet cannot be done in an environment full of noise. Work which requires collaboration cannot be done in a small room. Work which requires creativity will suffer in a dreary environment, and thrive in a beautiful one.

On Monday we will have the opportunity to discover what kind of work we can do in a large, window-rich, cosmopolitan downtown office space. Downtown! The lights! The glamor! New restaurants! Bus passes!

At every stage in our growth we have bristled against too-small office space that failed to meet our needs. Not enough privacy, not enough rooms, not enough wiring, not enough light, something. I want to code, and someone's one cube over arguing about a feature. I need to have a conference call, but have no door. I need to pee, but there's only one bathroom for 12 of us. I want to see if it's raining, but I have to hit F12 because the window is down the hall. I want to sketch a brilliant design, but the wall's too small for a decent whiteboard. I want to work 8 hours and wonder where the time went, but the overhead lighting gives me a headache before noon, and this desk is too small to put my coat, notepad, and lunch on it all at the same time. I wonder if Google would give me a bigger desk?

Obviously when you're a startup, even a funded one, you can't afford Building 99. But you do have to strike a balance, because every millisecond I spend thinking one of the above thoughts, I'm not writing great code.

But! Downtown! Here's some of the things our new space enables us to do:

• Allow our receptionist to greet visitors immediately at a striking entry desk
  
• Hold a meeting in a real conference room
  
• Enjoy our view of Westlake plaza from any point within the office
• Retire to a secluded space to be left undisturbed when necessary
• Write on the half-glass walls with whiteboard pens
• Put huge desks in the offices
• Work from home over a real VPN
• Step out the elevator doors to the middle of downtown, anytime we want

All of which are things that enable us to spend less time thinking about the stuff we can't do, and more time doing what we want to do - making great software.

Tomorrow, Part 2: Moving Day