Cathedral, Forge and Waterwheelby Frances Gies, Joseph Gies · published 1994 · read 2021-08-01
Officially my new favourite history book: I'm in love with Frances and Joseph Gies showing off the technology and technological development of the Middle Ages. The book is dense and doesn't coddle the reader, and, as many of their works, is often on recommended reading lists for history courses. In good medievalist tradition, they oppose Gibbon's view of medieval society as “the triumph of barbarism and religion”, and they bring tons of evidence to the table, combing through one thousand years of the Middle Ages. It's fascinating and well-written. I finished this book and immediately wanted to read more of the same (and was very disappointed when I couldn't find anything like it)!
The Victorian Internetby Tom Standage · published 1998 · read 2019-05-24
My first non-fiction book in quite some time, The Victorian Internet is a nice introduction into the rise and fall of the electrical telegraph, and all its implications. Tom Standage shows us in an easy, meandering style how the world changed due to the telegraph, and how people changed (and/or didn't). While he's often very direct (or on the nose) about his theories, and some minor facts looked not quite well researched (Karlsruhe was never part of Prussia, thank you very much), I liked both the very human approach to history, and his final – if simplistic – comparison between telegraph an internet evolution.
Talking about Machinesby Julian E. Orr · published 1996 · read 2022-02-17
This is technical anthropology, and it is thorough and much better than you'd expect from a potentially dry dissertation from 1990, described as an “underground classic among ethnographers of work”. The central thesis of the book is that (technical) knowledge is a socially distributed resource that is transported by way of oral culture and that debugging works by constructing a narrative between technician, customer and machine. More details below, but this is both a central insight, well described and documented, and applicable to most areas of (work) life. Orr was shadowing Xerox technicians at their work of servicing and repairing photocopiers (helpfully, Orr had learnt this job, on slightly different machines, too, so he wasn't just an annoying nosy interloper). He initially describes their work as a “continuous highly skilled improvisation within a triangular relationship of technician, customer, and machine”, which very clearly demonstrates the respect and depth Orr displays throughout the book. He was only accompanying them during their work hours, there were no additional structured interviews. Debugging as narrative In Orr's experience, a diagnosis involves the creation of a coherent narrative explaining the problem, starting from available pieces of unintegrated information that is transformed into a coherent narrative. This narrative is both used to fix the problem, and to share the whole story of problem, diagnosis and fix with colleagues (see below). A significant part of the job is social. Extracting information from non-technical users, discovering their understanding, and then reflecting the technician's knowledge in a way that will shape the users' behaviour is tricky, and also always fraught with office politics, history, colleague's opinions and so on. They are very aware themselves that users are a large part of the equation – they even have a saying: “Don't fix the machine; fix the customer!” (Side note: I'm shorthanding Orr's “diagnosis and repair” to “debugging” here.) War stories Once a story has been formed by means of diagnosis, and performed by means of repair, it can be shared with the professional community. The tellers use it to build their identity (either of competence, when in the starring role, or as knowledgeable part of the community, when repeating somebody else's story). Stories are told in a very concise manner, as repeating obvious story elements would be superflous and mildly insulting to the listeners. It's assumed that all competent technicians will tell stories, both to display status, and to instruct. This comes with a certain civil competitiveness that manifests in one-upmanship in their stories about hard fixes, or challenges when the narrator only tells the problem, and asks the audience to provide diagnosis. This kind of one-upmanship, or challenge-response jokes, are only used in private, never in front of customers, where technicians present in a carefully controlled manner, and only joke at their own expense. This social cohesion also shows up in the interesting way that technicians are more worried about the social damage to another technician, when they have to take a job in their territory, than about the machine they are servicing, because they know full well that social relationships are harder to repair than machines. Knowledge as distributed resource Orr observes that the telling of debugging narratives both demonstrates and shares the technicians' mastery, creating and celebrating their identities (in this case: as masters of the black arts of dealing with machines and customers, both). They provide information about technical matters – past fixes, emerging problems, warnings of incorrect documentation –, but also social and administrative topics, like changes among customers, area distributions, and office politics. These stories, usually shared during meals, are necessary for the technicians to remain capable and perform their work. The official documentation is not always correct, and rarely sufficient. Well-known workarounds int he fields (starting with valid substitutes for individual parts and ending with MacGuyver style solutions to common problems) are only communicated here. On the nature of work It's interesting to see notes from a time when service work was still coming into its own. The remark that “Leftists routinely orient themselves to service work by assuming that service workers are a new proletariat even though most service workers apparently don't see themselves this way.” has aged well. This time also reflects that the technicians' status straddled both worlds: They were skilled workers dressed like office workers, ties and all, their tool boxes made to look like briefcases, while also performing dirty work, setting them apart from pure office workers. Orr also pointedly observes that this shift has also shifted the meaning of “to work” to have an added, possibly even primary, meaning of “to be employed” rather than “to do a thing”. Defining the job Another still very relevant comment is that the definition of work seems to be up to management, who focus on the activities required to deliver a product, and disregard other equally necessary activities, that need then to be snuck in by people on the ground. For example, there is no alotted time for services technicians to casually visit the clients, inquire as to the state of everything, provide quick checks and education. But these encounters are vital, and technicians take care to get them done despite their tenuous status as not-really-work. Orr also mentions that all the common management definitions of work are focused on individual workers, while the fact that work is commonly done by a group and an emergent professional community is rarely acknowledged. In this example, all work would be much, much worse or even impossible without the frequent shared lunches and exchanges of experience. However, no management would have classed those things as work. But that's not the only failure of management! They also tend to see technicians not as skilled workers (as they see themselves), but as easily replaced by semiskilled labour with a good set of instructions. This state is obviously advantageous to the company, and they try to produce and maintain it by providing worse documentation, dumbed down to a level that does not permit complex troubleshooting to emerge. So the second a problem diverges from the manual, it's again down to skill and shared oral tradition. Because intentional de-skilling cannot deprive workers of skills they have, it only reduces the amount of information they receive. When management attempts to de-skill and break up a community like that, it will resist in several ways. It may switch to "work-to-order" mode to show management what it would miss out on (in this case: only service machines according to the manual, not developing further fixes, and not maintaining customer relations). They may also devalue promotions heavily, preferring to remain a service technician rather than being promoted into in-house service or management. "This resistance can surprise employers who think of labor as a commodity that can be arranged to suit their ends." Other Notes I liked the apt description of the relationship between customers and technicians as the “contract between the customers' need and the technicians' ability”, and he goes on to describe the relationship: “The principal issues for the technicians in this triangular interaction are control and understanding, and one reward for achieving the two is their own identity as competent technicians.” Equally, I liked the observation that technicians have trouble reasoning about details of the machine when they can't see it in front of them. They can still figure out the larger scale problems, but they don't remember things like the location of individual components in the machine. They also sometimes leave the technical field and get promoted to be managers, but few succeed there, most return to being technicians: “Most technicians would rather remain a technician-hero than become an organization manager”. “The division between technician and senior technician is just one of seniority and salary; reputation and skill are not thought to be related to this distinction.” – things never change. And, how Marxian: “The occupational community shares few cultural values with the corporation; technicians from all over the country are much more alike than a technician and a salesperson from the same district.” “What really holds their interest is a situation they do not understand.” - haha, nerds. Machines are very much not all the same: technicians talk about the ones in their territories as individuals, with their specific histories, users, problems, anticipated problems, past fixes requiring special attention, and so on. And this kind of tricky detail is what really stood out to me: there is infinite complexity in detail, and you don't know the dimensions of complexity involved in any job until you have worked it or have had trusted conversations with people who work it. This book is part of the 2022 Backlog Incident.
Forge Your Future with Open Sourceby VM (Vicky) Brasseur · published 2018 · read 2019-09-20
Forge Your Future with Open Source by VM Brasseur was a book I started with incorrect expectations: I thought I was the target group, and it would explain different things from its actual content. Bummer.
SSH Mastery: OpenSSH, PuTTY, Tunnels and Keysby Michael W. Lucas · published 2012 · read 2020-02-05
Well-written as usual. Teaches both implicit cultural knowledge and exciting obscure details in a structured, concise, and comprehensive way.
HTTP/3 explainedby Daniel Stenberg · published 2018 · read 2020-01-12
HTTP/3 Explained is a little free booklet by curl developer Daniel Stenberg explaining the principles and history behind HTTP/3. I liked the inclusion of recent history and explanation of discussions in the working groups. There is also some frank discussion of potential downsides in terms of security, performance, and adaptability, but usually there is one argument presented per point, so I had the impression that my opinion was being nudged (because of the lack of differing arguments). This is mostly due to the booklets short texts that don't expand much upon anything. Both the writing and the general structure are a bit rough around the edges.
Because Internet: Understanding the New Rules of Languageby Gretchen McCulloch · published 2019 · read 2020-04-18
Excellent book on internet linguistics! Touches all the important points and then some. I learnt about Third Places and where thankful!Tobias notation originates, and felt myself and my internet habits covered quite comprehensively.
How to Solve It: A New Aspect of Mathematical Methodby George Pólya · published 1944 · read 2020-03-31
How to Solve It is decent, but overrated – the first 10% are pretty good, and then there are a few nuggets of really good advice interspersed with the neverending examples of the principles introduced in the first part.
The Checklist Manifestoby Atul Gawande · published 2009 · read 2021-10-30
Checklists good – this message has been spread through all tech conferences for the last several years, so I didn't expect much from this book. It's the slightly more fleshed-out (but also just inflated) version of the original essay. If I hadn't heard all the good conference talks about pilot checklists (for example https://rixx.de/blog/andrew-godwin-you-have-control/), I'd have rated this book higher.
Stuff Mattersby Mark Miodownik · published 2013 · read 2022-03-12
All my notes are lost to a hardware disaster, so the tl;dr is just: material pop-science, fun read, drags on in places. Nice without being great. The chapters on steel and chocolate were great, the one on concrete could have been great but instead was grating. All in all cool info, presented well, if you can stand the voice. This book is part of the 2022 Backlog Incident.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Winby Gene Kim · published 2013 · read 2013-09-01
The Phoenix Project is a very nice management introduction for IT projects, talking about ITIL, about processes and about Agile Methods.