I’ve recently been attending the open meetings of my local hackerspace, Bloominglabs http://bloominglabs.org/index.php/Main_Page, as part of the ongoing development of my research. These visits have led to some interesting insights, and I’ve decided to record them here. I’m hoping that “HackerCraft” might become a series of blog posts in which I explore Hacking and Hacker culture as a craft. By “Hacker culture” I’m referring to Maker Culture, DIY Culture, Free and Open Source Software Development, and Electronics appropriation. Lumping all of these together and calling them all Hacker Culture will probably lead to some backlash, but this is how I think about them at the moment and hopefully I’ll be able to cover why in more detail in a future post.
In this post, I’m going to focus on a comparison I’ve noticed over several visits to the Hackerspace that I find interesting: the difference in accessibility of material characteristics in a hacker craft and in a traditional craft.
Hacking as a Craft
I hope to expand on this idea in a future post, but for now I’ll give a quick and dirty explanation for why I consider Hacking to be a kind of craft. In A Theory of Craft, Howard Risatti points out that craft disciplines are often discussed in terms of the materials used in those crafts. Fiber art, woodworking, ceramics, and glass blowing are examples of craft disciplines that are named after their materials, and there are many more. When it comes to hacking crafts, such as coding and electronics appropriation, I think it all comes down to what we consider to be the materials of the discipline. For coding it’s the specific languages and how they’re used. The materials for electronics appropriation are electronic components, microcontrollers, and conductive materials. These materials, in my experience, define the discipline for which they are used. When dealing with code, the type of code and the way that code is used can define the difference between programming and scripting, which are considered completely separate activities by many programmers. It is partly because of this reliance on the materials that I consider these disciplines to be kinds of crafts. My consideration also relies on the similarities of process, outcomes, types of knowledge associated with the experience, and functionality of products, but I will not get into that in this post.
Accessibility of Material Characteristics
In traditional crafts, the characteristics of the materials being used are highly and immediately accessible; the feel of the material and its appearance give much of these characteristics away. When it comes to knitting, the weight of a thread can say a lot about how it should be used and what it will be like to work with. If the thread is chunky it will require larger needles, if it’s itchy then it probably shouldn’t be used in something that goes against the skin, if it’s a single ply yarn then it’s going to split on the needle constantly and is likely to fray if pulled from the center of the yarn cake or skein. If I, as a knitter, found a ball of yarn in my closet that I had forgotten about, I would know enough from the feel or appearance of the material to be able to use it without consulting any kind of documentation.
When it comes to electronic components, however, these characteristics aren’t as visible, and documentation is often required. An electronic piece found on the floor of a hackerspace is not always immediately recognizable. Even when it is recognizable, it’s not clear from the feel or physical appearance of the object how it can be used because there are so many things to take into account, including the wattage the component can handle, which inputs or outputs map to which functions, how much resistance it will add to the current, and on and on. Documentation and schematics have to be consulted to acquire the information necessary to make the object useful. There are, of course, some visual indicators on electronic components which usually take the form of color-coding for resistance and arrows for polarity, but these are mostly useful for augmenting knowledge acquired through documentation and cannot stand alone.
A similar argument applies to code as a material for programming. After being dropped into the middle of an open source software development project, significant time must be invested to understand how it works and how to add to it. This requires consulting documentation in the form of APIs and/or comments in the code. Even a function with an innocuous name like “toString” can lead to serious problems if it isn’t understood carefully.
I think this contrast is interesting because it causes what I consider to be hacker crafts to have a significantly different learning curve than traditional crafts. The barriers of entry to these crafts might be similar (I’m still considering this, taking tutorials and use of precedent into account), but the amount of knowledge required before a crafter can begin experimenting with materials is enormous for hacker crafts, but not as high for traditional crafts. This ability to experiment with the materials is, in my opinion, one of the most important milestones in the development of one’s craft. I think the accessibility of material characteristics in a craft has a direct impact on how quickly one can become proficient enough to experiment with and thereby improve the practice of a craft. Right now I think the sheer complexity of dealing with electronic components as a material in a craft might just be too great for the characteristics to be able to become more accessible, but maybe by being sensitive to this distinction I will be able to figure out a way to change that.
Risatti, H. A Theory of Craft: Function and Aesthetic Expression. University of North Carolina Press, 2007.