… and Ruby 005 student Ben Serviss has cleverly used them as an analogy for learning to program. Who knew! Here’s his post, reblogged from here.
The first time I walked into The Flatiron School, I thought to myself: “What are these crazy orange things?”
I had come to one of the weekly NYC on Rails meetups in December of 2013 to check out the vibe and decide if I wanted to apply to the school’s web development program. Strewn about the main meeting space were knee-high, accordion-esque bright orange… things.
Were they chairs? Were they stools? Were they the missing business ends of giant toddler-sized toy hammers?
Spoiler: They turned out to be chairs. Ergonomic chairs, in fact, created by designer Alan Heller. The ErgoErgo chairs (as they’re officially called) were designed to encourage active sitting, relying on the sittee’s core muscles for stability as you rock gently back and forth.
Once I had gotten used to the concept, using the chair turned out to be fun in its own novel way. Figuring out how to best use the chair added a playful dimension in talking to the other meetuppers, helping ground the evening in a more open-minded mood.
Now that I’m a full-time student at Flatiron, I’ve noticed how easily my classmates have incorporated the chairs into their routines. Since they’re so modular and light, it’s easy to grab a few and turn any table into a lunch spot or meeting area, use one as a footrest, or even corral a bunch into a nifty nap corner. In just a matter of weeks, the ubiquity of these strange little chairs had become a given.
Cool, right? There’s something else entirely that explains why these peculiar little chairs fit in so well here – and it’s because the entire process of encountering, evaluating, interacting and experimenting with them is a perfect metaphor for learning to program.
Upon first glance, ErgoErgo doesn’t look like any chair that belongs in an office setting – there’s no back, they’re too short, the shape is wrong, the color is far too bright – and you’re immediately thrown out of your comfort zone, just as someone new to programming is quickly buried in confusion.
Then, as you figure out that it’s just another type of chair, you try sitting on it and gradually learn how it operates – how much rocking you like, how much give each side allows, etc. This is analogous to the long acclimation phase of learning to program – deciphering what error messages mean, how data structures behave, what kind of commands are expected, and so forth.
Finally, as you accept ErgoErgo’s new definition of what a chair can mean, you grow comfortable in its use – turning something that was strange and unfamiliar moments ago into something you totally understand. It goes without saying that the programming equivalent to this stage is rather long, but the metaphor is already complete. Something that once beguiled you as intimidating or impossible is now something eminently knowable, with time and experience the only obstacles to an increased understanding.
The entire process of encountering, evaluating, interacting and experimenting with them is a perfect metaphor for learning to program.
A major part of becoming a programmer is mental. The mental shift from “I need a programmer to help me” when faced with a technical problem to “I can figure this out” is an important one; the transition from being frustrated with code defects to being driven by curiosity to find the problem is critical in staying motivated to improve.
As much as I may be reading into this, and as off-the-wall a metaphor it may seem, having these odd chairs around as I’m trying to mold myself into a programmer is a constant reminder that what may seem unfamiliar and alien one day may become familiar, welcome and fun the next.
