Refactorings Extended: Please Welcome Mike, Drew and Kevin

I’ve been writing ribbonfarm as a solo act for over five years now. Blogging can get to be a pretty lonely activity, so I figured I could use some company for a change. I didn’t quite like any of the existing models of collaboration in blogging, so I invented my own: the blogging residency. Think of it as something of a cross between a sabbatical and a writer-in-residence program.

We’ll start our little experiment with Mike Travers of Omniorthogonal, Kevin Simler of Melting Asphalt and Drew Austin of Kneeling Bus, all of whom contributed guest posts last year. For me at least, their posts were like breaths of fresh air in this increasingly insular little refactoring shop, which has gotten a little too full of my own in-a-rut ideas over the years.

Each of them will be contributing between 4 to 6 posts here through the year. Check out the Blogging Residencies page to learn more about the “refactored perception” themes they plan to explore.  Thanks to your ongoing support since I began accepting sponsorships, I can afford to actually pay these guys small honorariums for their contributions. So there is hope yet for the future of publishing.

To kick things off, I asked all three of them to articulate their understanding of “refactoring,” the umbrella theme here at ribbonfarm. So here you go (and for once, I can grab the popcorn and let somebody else defend their ideas).

Three Perspectives on “Refactoring”

 Mike

Refactoring as a writing technique, in its most obvious interpretation at least, means the willingness and ability to slice, dice, and recombine existing conceptual structures in the hopes of coming up with new and more powerful ways of thinking about the world. This is not that new — this is what philosophers and scientists have been doing since abstract thought was invented.  But putting a new label on it, and considering it in light of the software engineering practice from which the word derives, takes it to a meta level. Can we actual refactor thinking itself?

Drew

To refactor something is to recode the familiar version of it–to effect change by moving information around rather than by changing properties of the thing itself. Reorienting one’s own perception of reality is a principal means of refactoring and an ability that writing and technology share. In a civilization that has refined its ability to detach information from concrete objects and freely manipulate that information, refactoring becomes more powerful, more unstable, and more frequent (see Taleb’s “Extremistan” metaphor) which is why it is an ever more compelling lens through which to view the world we currently inhabit.

Kevin

In one word:  reconceptualizing.

In one phrase:  finding new structures for existing ideas.  (Analogous to the concept in programming — finding new structures for existing code.)

Goal:  producing insight — seeing things differently, and hopefully more clearly and powerfully (which allows you to build out further ideas and conceptual structures more easily).

Contrasts (but is not in conflict) with the following:

  • original research
  • summarization of existing ideas
  • education
  • popularization

Examples of conceptual refactoring:  perspective shifts, perspective inversions, metaphors (how X and Y are related), generalizations, reframing (or creating a new framework), distinctions (splitting a formerly atomic concept into two related concepts, by introducing a new dimension).  There are probably more examples here, which would be interesting to try to catalogue, a la code refactorings.

Why Blogging Residencies?

Despite the place of the medium in “social” media, blogging doesn’t really have good social models that actually allow for interesting collaborations.

  • Blogrolls are basically an exercise in mutual back-linking transactions. They don’t generate new value, just mutual admiration and SEO-juice.
  • Team blogs are difficult to pull off except under special circumstances, given the highly individual voices of different writers. Most team blogs are effectively either aggregators, or magazines in the old sense of the word, rather than a true expression of the unique characteristics of blogging.
  • The culture of guest posting is the ephemeral: drive-by blogging that misses more often than it hits. Most bloggers use it more as an expedient way to have somebody “cover” their posting schedule. Sort of like substitute teaching. It works for some types of writing, but is too limited for other types.

I like the idea of an extended “residency” because it fosters more serious collaboration. Last year’s guest posts from Mike, Kevin and Drew felt like a breath of fresh air to me (and to many long-time readers).  I am hoping to not just play off themes introduced by them this year, but I hope they are able to play off each other’s themes as well, in a way that enriches their home blogs.

We’ll see how this experiment goes. In the meantime, please welcome our new blogging residents. Starting in February, one in every three or four posts should be a resident post. Should keep me on my toes.

Get Ribbonfarm in your inbox

Get new post updates by email

New post updates are sent out once a week

About Venkatesh Rao

Venkat is the founder and editor-in-chief of ribbonfarm. Follow him on Twitter

Comments

  1. Because I wasn’t going to get anything done this year, anyway.

  2. Perhaps I may use these interpretations to attempt a contrast.

    These approaches are somewhat rooted in the linguistic framing of the question. Refactoring, as suggested here, at the very least, seems linguistically open ended. Maybe this has something to do with the looseness and variety of large or complex code blocks. Never mind the Java, C, (etc…) programming language choices.

    There’s a sort of fatalism about code too; after all, if a computer program that doesn’t function as intended it’s considered buggy. Metaphors themselves suffer and often imply fatalism (as one assumes (or pretends for that situation) one thing is “similar enough” to another).

    I’m find myself wondering what conceptual pile the refactoring complier is hidden under.

    Otherwise without that relative object, how do we avoid the problem created by the need for a vehicle of shared understanding? Refactoring’s approach seemingly welcomes and encourages individuality in its search for insight. Yet you run into a problem when communicating that individual understanding outside of the self (I’m looking towards Venkat’s posts on Literacy which, at times, appear to imply that the problem with the reader).

    In this day and age, especially, how do you anticipate and account for having your meaning meme’d, fractalled, and trolled? or Is there no conceptually wrong understanding? and thus is this the desired course?

    Absent then a refactoring compiler, is there a sort of formal philosophical language or symbology that would be a natural growth out of a project like this? This all has a sort of David Foster Wallace quality to it. Indeed his essay on _Fate, Time, and Language_ comes to mind: the timing of the application of the concepts matters, and matters a great deal.

    Otherwise as I’ve stated in the past refactoring appears to risk producing insight that remains locked among the shared understanding of the few initiates. Who knows perhaps that’s what its all about…


    http://www.amazon.com/Fate-Time-Language-Essay-Free/dp/0231151578

  3. Being educated as a coder, but having left that profession for a while now, my understanding of refactoring has changed a lot. Everytime I refactor something, the process of doing so changes my understanding of it and hence lends itself naturally to the next cycle of refactoring. Hence refactoring is no different to thinking, but only one way of getting on with it.
    Merging in another heavily used term from the programming discipline, “patterns”, may also be interesting, as both concepts entered the programming world approximately at the same time. You refactor because you recognize patterns your coding problem maps to, that suggest some proven way of dealing with it. And you agree to explore this suggestion. Hypothesis: refactoring is always triggered by pattern recognition, be it conscious or not.