Kuckuck. Notizen zur Alltagskultur 1/21: “Code”
In the age of ubiquitous digital computer technologies and human-machine collaborations, code is experiencing a revival in various contexts: source codes, binary codes and algorithms; software, encryption technologies and cryptography; numerical codes, formulas and functions; (geo)mapping, biometrics or computational genomics.
Codes are attributions, representations and entanglements of information and meaning. They are relations and dependencies which they simultaneously co-produce. However, codes also enable practices of appropriation, counterdiscourse and reinterpretation or even become an end-in-itself in code art.
The 1/2021 issue of the magazine “kuckuck. Notizen zur Alltagskultur” focuses on code in its multiple forms, on its engineering and (de-)ciphering.
We are looking forward to abstracts and ideas for scientific/essayistic or artistic contributions until August 15th, 2020. Please send your Abstract to: L.Veprek@ekwee.uni-muenchen.de
The deadline for finished papers and contributions is January 30th, 2021.
code as the new craftsmanship (tying it with cultural histories)
also the fact that software developmen kinda grew organically, as infrastructure needs appeared, more hands than brain
how is it similar?
how is it different? - mentorship? (diffusion/acquisition of knowledge) - relationship with tools (communal rather than personal) - - therefore uncertainty as to what it does? (skilled labor vs. unskilled labor? is that a valid parallalel/distinction?) - the scale and nature of the network?
why is it important/interesting? - appreciate code as a practice, with the learning models appropriate - alternative to monopolies with highly-skilled workers distributing information for less highly-skilled workers? (bootcamp vs. workshop? leaning online was the online workshop? but there is also the fact that only a few maintainers contribute actively on a project)
According to Risatti, technique in craft (a sum of technical knowledge, set of procedures or rules) and technical skill (motor skill) requires two kinds of learning: (1) technical knowledge of the materials and how they are worked to create objects (theoria), and (2) technical manual skill to work the material (praxis) (Risatti 2007). Craftsmanship, on the other hand he says, fuses theoria and praxis into poiesis with both abstract and practical material concerns. In this dialectical, dialogical process and feedback system of craft, thinking and making; visualizing and executing; perception and action; knowledge and manual skill go hand in hand (Risatti 2007, 169). Anthropologist Tim Ingold argues that skill exists within a system of relations between the maker and his or her environment; and is transmitted through practical hands- on experience not abstract descriptions (Ingold 2000, 291). While Risatti writes that craft involves technical knowledge and skill, and Ingold writes that skill is a virtue of relations between the mind, body, and environment, Sennett argues that technical skill involves making and repairing (Sennett 2012). According to him, repairing things comprise restoration, remediation, and reconfiguration. The long-term goal of this study is to develop this concept of “repair” and craftsmanship through the lens of computation.
ingold:
conjecture and refutation between idea and practice - but this assumption places knowledge OUTSIDE, in the object observes (a way of knowing from the outside)
thinking through making is a way of knowing from inside
also hackers are a good example of those who “find” ideas in the material
robert gordon
interchangeability (modularity) can lead to a disappearance in craftsmanship, ad hoc.
the examination of the final product shows us how it was done. however, that’s not the same for code (sometimes, the finished product is extremely messy)
markings: the traces that the tools leave
We call this “skill” because it cannot be adequately described in verbal or quantitative terms p.769 mechanical ideal, mechanical reality
related to above: what are the skills of a software developer?
polanyi
personal knowledge
destructive analysis is the fact that analyzing something makes it disappear/incomprehensible
skill involves tradition, connoisseurship (experience, direct experience)
the tool as something known to be useful (with a purpose) + subsidiary awareness (diffuse) and focal awareness (tight)
alexander in gabriel
what is the chartres of programming? probably unix
the kinds of craftspeople on the chartres building site? highly skilled, not too much use for planning skill (there was an architect), but rather for dexterity and judgment
could be similar to programmers today? after structured programming
cathedral and bazaar
place of slang/jargon?
similarity in geography: cities as hubs for learning and practicing? switch in geographic compactness (unix/bsd) to global diffusion (linux)
it’s actually very explicit knowledge that is out there, and the highlight is to learn the tacit/informal knowledge
hackers have “individual techno-heroism”
intrinsic motivation is #1 in FOSS
programming has inherent complexity
studying great designers is essential, says fred brooks in no silver buller, and he suggests to make them apprentices
classification of hackers by knowledge exchange behaviour -> meritocracy seems to be in place
cennino cennini has written a handbook on craftsmanship. he weaves in both technical advice and slightly more broad, social, personal advice.
wolek, managerial principles of craftsman guilds
The three principles are regulation, standards of accomplishment and apprenticeship. At first glance, it seems like these are radically opposite to managerial styles of software development.
Lequin, 1986, highlights the somewhat emotional and subjective approach to craftsmanship: how some mythologize it, and others demonize it.
guilds enabled:
the standards in software development today are focused more on production process, equally with quality control (test suites, code reviews), but no longer so much on commercial regulation (undercutting prices, monopolizing access to materials)
and then in terms of apprenticeship, it wasn’t so explictly documented, but:
The guilds could and did not analyze the development of know-how, but they could recognize it as a chief reason for their personal pride and group solidarity (Hudson and Hunter, 1981).
mcgee, from craftsmanship to draftsmanship
we use “craft” as a category to highlight its contrast to “non-scientificness” wit other endeavours
he notes interesting questions raised by mumford and others regarding how the switch from technics to technology might affect the personality of man. it could however be said, or counter-argumented, that technology might always hold a little bit of technics within it. For instance, examples of the use of skill in creating and replicating scientific studies is, in that sense, a continuation of craftsmanship with the industry/manufacture.
three traditions of design:
in the crafts tradition, there is no separation between designer and maker (thinking of unix, wozniak, etc.)
his analysis suggests that where time, labor, and materials are absolutely or relatively cheap we might find a great deal of craft innovation.
Code is really cheap. With regards to worksmanship of risk vs. worksmanship of certainty, I’m not certain where code falls. You cannot waste materials as easily, but you are prone to errors, typos, etc. There is also a lot of innovation in software development. Most of the innovation we think of comes from CS per se, but there are also techniques, protocols, build processes and toolkits which improve work.
Agile Software Development should be mentioned as one of the responses to handle the conflict between programming as craft (uncertainty, malleability, organic growth of features) with the top-down planning resulting from industrial economies.
In the case of softdev, the relationship to science is quite ambiguous, because it seems to be reversed: the science came first, and the code (the symbols) second, as sort of an unexpected offshoot.
He argues that science cannot come before a design, because one must start with a purpose, a direction for the thing to be built. Only then can scientific principles be applied to an existing design.
Harold Osborne, The Aesthetic Concept of Craftsmanship
Indeed it is not uncommon nowadays to hear talk of a new kind of craftsmanship, meaning skill resulting from practical experience in the efficient manipulation of a machine.
A part of craftsmanship consists in a man’s understanding the tools of his trade, possessing the skill and dexterity to use them to the best advantage, and also in the invention of new and more effective tools and the corresponding skills.
Following his discussion of tools and machines, in which the latter is considered more automated and more controlling than the former, it could be argued that softdev is one of the trades in which the machine gets very close to the tool. Of course, toolsets do also constrain and control, but once the deliberate decision has been made to use them in a particular configuration and setting.
In modern machine production judgement, experience, ingenuity, dexterity, artistry, skill are all concentrated in the programming before actual production starts.
He argues that small irregularities are the things which are a testament to handiwork, but I would argue that this is the opposite for softdev: true craftsmen make code impersonal, perhaps only identifiable in its optimization tweaks.
In the past men valued accuracy, precision, regularity of workmanship because these were signs of care and skill, dexterity and experience.
In some way, these skills are still relevant: scoping data structures, outputting constantly quality code, precision in the defining of variables and functions, etc. In other ways, because the whole idea of “dexterity” is now less and less relevant due to automation of most tasks, it might be possible to think of new kinds of skills which are developed by softdev (not reinventing the wheel e.g. choice of tools, translating architecture into workable code, documenting one’s work, etc.)
Most of the benefit is to the worker, not to the consumer.
There is intrinsic quality and extrinsic quality. Machine fabrication can exhibit the latter (surface-level perfection), and lack on the former (shoddy materials and design)
Craftsmanship is also pride. (Osborne, Oxford Companion To Decorative Arts). This constant yearning and desire for excellence is described by Osborne as being almost a moral obligation.
Seidel, Coders at Work
Norvig says the the IBM Master programmer was a bad idea. It’s even interesting that they decided to try such an approach, but ultimately the biggest difference is the scarcity of resources (or lack thereof)
The essential skill for programming is improvement and refining, less motor-based than traditional craftsmanship, but tied to attempt for excellence.
Norvig describes a point in his debugging process involves intuition (p.314)
Norvig, responding to wether he’s a scientist, engineer, artist or craftsman, says he’s a craftsman, because functionality comes before beauty.
Steele became a programmer because he was “internally motivated”. He also tells the story of Emacs and early customization and key-bindings.
Most of them do associate as craftsmen.
Peyton Jones, talking about craftsmanship, says that one shouldn’t describe the code (the artifact), but rather the intent (the reusable idea behind the artifact). This is still compatible with the fact that the idea and the artifact are entangled in their creation.
He also refers to Haskell (of which he’s one of the main designers), as a material, when comparing the kinds of materials that different groups de developers (imperative, functional) use and rely on. He then adds that the “crafty” part of programming, in constrast to its engineering part, is that programmers always aim for more, since there are no practical constraints.
Cosell, on making the Internet: “The time-out isn’t big enough and so we would make it bigger, not doing it by first principles or algebra, but just tuning it until it works.”. This is a very crafty approach for a research project, perhaps an indicator that, in this case, science isn’t so different from craftsmanship.
You can’t explore a new idea in doing something if you are not craftsman enough to make the computer do what you had in your mind. (p.543, Bernie Cossell)
paul graham, hackers and painters
He argues for a parallel between hackers and painters because of their common “making”.
and then the way that hackers are valued is actually by their productivity, by how much functional code they can write.
In his article on taste, he focuses on simplicity, timelessness, correctness (particularly in terms of which problem it solves, and the problem(s) can be theoretical or metaphysical), suggestiveness (in that it evokes something beyond itself), hard to reach (requires lots of work), along with:
mckenzie wark, hackers
relationship to IP law?
certeau sennett uncle bob ruskin simmel [https://www.editionsladecouverte.fr/catalogue/index-De_la_programmation_consideree_comme_un_des_Beaux_Arts-9782707121547.html]