Computer scientists have long sought to uncover methods for efficient and productive use of machines, based on the ways in which humans interact both with devices and with each other. Over fifty years ago, J. C. R. Licklider described an ideal symbiosis between man and machine, in which "men will set the goals, formulate the hypothesis, determine the criteria, and perform the evaluations" while machines "will do the routinizable work that must be done to prepare the way for insights" (4).

Inherent here is the notion that man must architect the system before the system can function. "Architect," in this sense, encompasses the multiple tasks of planning, organizing, and (finally) building a machine, system, or process. Over the past fifty years, the human-computer interaction model has grown to the point of providing users with hardware and software carefully constructed to offer unobtrusive assistance, helping us complete tasks in our lives and work. In the last decade, we have seen the rise of ubiquitous computing—in which it is difficult to escape the gaze of screens—as well as all of the information sharing, user-centered design, and collaborative development that comprises "Web 2.0" (and beyond). One of many developments during our advancement toward Licklider's goal of man-machine symbiosis is that users find themselves more empowered than ever before to control the technologies within which they are embedded. This is good.

But in the workforce, when a sense of empowerment turns toward a sense of entitlement, forward momentum slows and innovation ends. To shift from empowerment to innovate to a state in which you believe you are entitled to involvment in innovative development is to ignore the strong craft tradition that exists in technical fields—particularly in software development, the area most closely aligned with Licklider's man-machine symbiosis.

My time as a technologist in the private sector, my relatively short time as a humanities scholar, and my position now as a technologist in a library setting has provided me with the opportunity to experience a wide range of labor practices and to uncover more than my fair share of myths. One myth in particular rests in the misguided notion that simply using a tool intensively can lead to expertise in its maintenance, enhancement, and implementation.  This goes hand in hand with the all-to-common notion that scholars with technical skills can easily step off the research and teaching track to obtain jobs in technical fields simply on the basis of their academic credentials and their experiences as tool-users. Certainly, being a user of a tool (or of a set of technologies) will increase one's chances of being able to innovate upon those technologies, and the craft (or hacker) tradition does not require formal academic training in technical fields on the path toward establishment as a solid technical developer. But software development is just that—a craft tradition—and carries with it its own norms, no less complex or valuable than those found among scholars. Here one finds apprentices, journeymen, and master-craftsmen as deeply invested in the art of technical development as scholars are invested in critical interrogations of literature and history.

Where academia and the craft-tradition of technical development differ is that developers who rise to the level of master-craftsmen are not necessarily those who have worked in the field the longest or who are possessed of the best (or in fact any) academic pedigrees. Instead, the master-craftsmen are those who can conceptualize interactions, intersections, and movements of information, all the while mindful of the underlying programmatic constructs necessary to represent that world in some tangible way. Master-craftsmen are those who architect solutions while also understanding that "interpretation takes place from inside a system, rather than from outside" (Drucker and Nowviskie). A journeyman technical developer might be well on her way toward architecting solutions to problems while also interpreting a system under construction, but then again she might not; journeyman technical developers who simply work to task without critical interrogation of the task at hand are not uncommon. I have seen many developers of information systems who can quickly code bubble sorts and do-while loops but lack an understanding of the roles their work plays within greater systems. This type of developer is not the type I would hire for my technical projects in an academic environment (or in any environment),—but more often than not I have seen academics assume that when they are hiring technical developers they are hiring people who lack the skill required to conceptualize the grand visions they hold in their own minds.

It comes as quite a surprise to many traditional scholars that a technical developer could even begin to understand such visions. However, it is precisely the developer's job to understand these things—perhaps even better than their progenitors—in order to bring them wholly to fruition within an architected system. Using the term "architect," with its connotation of both building and design, is common among technologists, but the concept of the system (and in fact all of cyberspace) as architecture, with architecture, and containing architecture can be difficult to grasp. This is especially the case if one lacks an inclination toward building, surveying, and participating in these structures on a daily basis and for years on end. Even if we do not fully understand certain arguments surrounding the architecture of systems, it is impossible to ignore our vernacular terminology, riddled with architectural terms for inhabitable places online (web sites, virtual worlds, etc.) and those charged with their development: network, application, and database architects. Technical developers are much like civil engineers: we construct connections among sites, worry about traffic patterns (and flow, and jams), and obsess over the placement of information within color fields (including color choice and other aesthetic issues) —all in the name of eliciting positive responses from visitors unknown.

More specifically, when academic technologists work to enact scholarly visions, we are able to do so by understanding the relationship among humans and the informational or social spaces afforded them by machines, in order to develop architectures and interfaces that enable scholars to create and extend new knowledge environments. Projects and processes that enhance critical and speculative inquiry are "dynamic and constitutive in their operation" and are not "merely procedural and mechanistic"—much like the master-craftsmen developers who create them (Drucker and Nowviskie). The term "architect" remains important not only because it connotes "building" but because it assumes a designer's hand as well. We might even speak of this as an artist's hand; Donald Knuth reminds us that "computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty" (673). The knowledge and artistry that a technologist brings to a scholarly project should not be devalued, as more often than not it is the mindfulness of an architect to her craft that enables foundations to be set and structures to be built.

To scholars who employ technologists to interpret, enact, and create the tangible artifacts of their scholarly visions: I encourage you to be mindful of the effort and collaborative, architectural attention that inheres in technical knowledge-work. I encourage you to interrogate any internal voices that whisper, "a programmer's paycheck is the most appropriate form of my acknowledgment—or in fact all the credit she is due."[fn]See two posts to Twitter (made during a workshop on the evaluation of digital scholarship for purposes of tenure and promotion) which, in part, inspired this essay: [1] and [2].[/fn]

Works Cited

Drucker, Johanna and Bethany Nowviskie. "Speculative Computing: Aesthetic Provocations in Humanities Computing." Blackwell Companion to Digital Humanities. Eds. Susan Schreibman, Ray Siemens and John Unsworth. Oxford: Blackwell, 2004.

Knuth, Donald. "Computer Programming as an Art." Communications of the ACM 17:12 (December 1974): 667-673.

Licklider, J. C. R. "Man-Computer Symbiosis." Transactions on Human Factors in Electronics HFE-1 (March 1960): 4-11.