Topic: Labor

I’ve started to realize that, fundamentally, the questions I’m asking of the world and that I’m trying to address by learning more about technology, center on work and the meaning and process of working. Work lies at the intersection of the all the things that I seem to revisit endlessly: interfaces, collaboration technology, cooperatives and economics institutions, and open source software development. I’m not sure if I’m interested in work because it’s the unifying theme of a bunch of different interests, or this is the base from which other interests spring.

I realize that this makes me an incredibly weird geek.

I was talking to caroline about our respective work environments, specifically about how we (and our coworkers) relocated (or didn’t) for our jobs, and I was chagrined to realize that this novel that I’ve been working at (or not,) for way too long at this point spends some time revolving around these questions:

• How does being stuck in a single place and time constrain one agency to effect the world around them?
• What does labor look like in a mostly/quasi post-scarcity world?

Perhaps the most worrying thing about this project is that I started writing this story in late August of 2008. This was of course before the American/Financial Services economic crash that got me blogging and really thinking about issues outside of technology.

It’s interesting, and perhaps outside the scope of this post, but I think it’s interesting how since graduating from college, my “research” interests as they were, all work them into fiction (intentionally or otherwise.) I suppose I haven’t written fiction about Free Software/open source, exactly, but I think there’s a good enough reason for that.¹

I’m left with two realizations. First, that this novel has been sitting on my plate for far too long, and there’s no reason why I can’t write the last 10/20 thousand words in the next few months and be done with the sucker. Second, I’m interested in thinking about how “being an academic” (or not) affects the way I (we?) approach learning more about the world and the process/rigor that I bring to those projects.

But we’ll get to that later, I have writing to do.

In many ways, I think you could say, I live and work in a bubble of the technical future that, as Gibson said “isn’t evenly distributed,” yet. I have developed a set of tools and work flows that enable me to work nearly anywhere and on a moment’s notice. I work for a company which great and open internal infrastructure that allows us to securely communicate and collaborate in whatever way we think will best serve the projects we’re working on. And I know enough to be able to automate the boring parts of my technological experience. In all, pretty good.

Here’s the thing though: despite all of this technological infrastructure, all this know how and frankly awesome connectivity: all of the tools we use to collaborate technologically: chat rooms, wikis, paste-bins, version control systems, instant messages and email all work better when you’re in the same room. Examples:

I was sitting in a talk with a coworker, and we were both logged into an IRC room from our laptops, where we were able to share some useful examples, links, and other commentary without being (very) disruptive. In day to day work, I (and my coworkers) spend a lot of time using chat rooms to communicate and share information with people who are only a few feet away, and in the end we get a lot done.

There are probably a lot of reasons why this is the case: digital relationships are almost always supported by real life relationships, there’s a level of hard to document interstitial and context setting that we do in real life that is difficult to efficiently create digitally, but that can be accomplished without second thought *in real life, and so forth. But, having made this realization, I think there are a few conclusions to be drawn about collaboration technology:

• It helps to centralize information flow. So much collaboration technology is “pull” based, and there’s no good way to ensure that people know you’ve done something that they might consider without pushing information to them in some manner. Even so, create one place where the people you’re working with can see what you’re working on.

  Use something like an IRC channel, or an xmpp MUC room, combined with a service like notifixious or something similar. In a lot of ways, the incessant emails Facebook sends achieve the same goal.

• Communities come together to work on something specific and concrete, but inevitably they bond and endure for other reasons and other kinds of conversations. While creating “off topic” silos is awkward, creating the space for people to get to know each other is essential to making people work together well (and thus use collaborative technology better.)

• Focus most of your attention on “getting things done,” and less attention on the “how things are done.” There are so many technological solutions, so many options, and so many different contexts that it doesn’t really matter how things get done as long as they do get done. The right and preferred tools will arise and present themselves when needed, and as long as things are getting done using the right tool doesn’t matter much.

Onward and Upward!

This post covers the role and purpose (and utility!) of analysts and spectators in the software development world. Particularly in the open source subset of that. My inspirations and for this post come from:

• Why is there no Anthropology Journalism?
• This Video Featuring an interview with Michael Coté of Red Monk

In the video Coté says (basically,) open source projects need to be able to justify the “business case” for their project, to explain what’s the innovation that this project seeks to provide the world. This is undoubtedly a good thing, and I think we should probably all be able to explore and clearly explain and even justify the projects we care about and work on in terms of their external worth.

Project leaders and developers should be able to explain and justify the greater utility of their software clearly. Without question. At the same time, problems arise when all we focus on is the worth. People become oblivious to how things work, and become unable to successfully participate in informed decisions about the technology that they use. Users, without an understanding of how a piece of technology functions are less able to take full advantage of that technology.

As an aside: One of the things that took me forever to get used to about working with developers is the terms that they describe their future projects. They use the imperative case with much more ease than I would ever consider: “the product will have this feature” and “It will be architected in such a way.” From the outside this kind of talk seems to be unrealistic and grandiose, but I’ve learned that programmers tend to see their projects evolving in real time, and so this kind of language is really more representative of their current state of mind than their intentions or lack of communications skills.

Returning for a moment to the importance of being able to communicate the business case of the projects and technology that we create. As we force the developers of technology to focus on the business cases for the technology they develop we also make it so that the only people who are capable of understanding how software works, or how software is created, are the people who develop software. And while I’m all in favor of specialization, I do think that the returns diminish quickly.

And beyond the fact that this leads to technology that simply isn’t as good or as useful, in the long run, it also strongly limits the ability of observers and outsiders (“analysts”) to be able to provide a service for the developers of the technology beyond simply communicating their business case to outside world. It restricts all understanding of technology to journalism rather than the sort of “rich and chewy” (anthropological?) understanding that might be possible if we worked to understand the technology itself.

I clearly need to work a bit more to develop this idea, but I think it connects with a couple of previous arguments that I’ve put forth in these pages one regarding Whorfism in Programming, and also in constructing rich arguments.

I look forward to your input as I develop this project. Onward and Upward!

Every system that requires your attention and responsibility comes with some sort of “management cost,” this includes servers that run websites and email, as well as the notes you take and--in my case--the novels you avoid writing.

This post, and really the last one as well, grows out of my interest and desire to stay organized, to work effectively without spending too much time and energy thinking about organization. Except of course that I write a bunch about this sort of thing on the blog, so maybe I’m a bad example of success. At the end of the day we’re all just folk', I guess.

The argument at the present moment revolves around consolidation rather than an approach to design or organization. And the basic premise is: “no matter how complex your organizational problem is, you can probably accomplish what you need to by doing less.”

• Feel like you spend too much time reading email, or have too many email inboxes to check (personal email, work email, special project email, listserv email, facebook email, etc.)? Forward your email into one box and filter the hell out of it so that you only read what you really have to and it’s manageable.
• Feel like you have too many todo lists? Compile them into a single list and use some sort of tag system to organize it.
• Feel like your notes and documents are scared in too many places? Combine them and use some sort of search tool to find things when you need them.

And so forth. In the analog information world (i.e. with papers, notebooks, and books) we often take the approach of sorting things into distinct piles of similar sorts of things, and arranging things physically in our worlds to reflect this basic sorting. For instance, “the science fiction books will be on the first three shelves, the 20Th century philosophy on the next three, college textbooks on the next, and […]” These habits, combined with unfortunate conventions like referring to hierarchical organizational units of a file system (e.g. directories) “folders,” encourages us to translate these real-world conventions to our digital existences. This is undoubtedly a bad idea.

The more data you pile together in one place, even dissimilar data, the more powerful it becomes. Say you have a PDF collection of articles on the anthropology of death and dying, post-colonial literature, and linguistics hanging out in different directories of your file system, and you begin to do research for a story you want to write set in the 1930s in India, where do you look? What if there are relevant articles in all three folders. What if you have a dozen or two dozen folders? What if you have a number of hierarchical organizational trees, and you store your notes, the actual text of what you’re working on, and your reference materials separately with parallel hierarchies?¹ Quite suddenly you’re over-organized and disorganized all at the same time,

The more “system” you have the more difficult it is to manage. The key to success, or part of it at any rate, is being minimalist about your organization. Recognize that adding responsibilities, projects, directories, lists, email accounts, and so forth all come with a cost. And sometimes, being a little less organized means that you’re able to get more done, if that makes sense.

If your experiences reflect this (or run contrary to this logic,) I’d be very interested in hearing about how you have solved, and have continued to solve the issue.