Humane Ingenuity 26: Considerate Over Clever
by Dan Cohen
Next month in Barcelona at the PH21 Gallery there will be an exhibit of photography documenting the aching feeling of being alone in normally crowded urban spaces during this pandemic.
Zoltán Dragon, Passing I.
Georg Worecki, Schauspielhaus Düsseldorf
Georg Worecki, Philharmonie Luxembourg
Sari Fried-Fiori, Urban Walk
If you want to help us transcribe the titles and authors (many of them famous later on) of articles in the Boston Phoenix, Boston’s alternative newspaper, head on over to Zooniverse for some crowdsourcing fun. Northeastern University’s Archives and Special Collections has digitized all of the index cards from our complete Phoenix collection, including a lot of behind-the-scenes gems, and our head of NUASC, Giordana Mecagni, has set up this site to let the public relive the 1970s. You can see so many social, cultural, and political trends begin right there on those cards.
Brent Simmons, the thoughtful software developer behind two of my favorite Mac apps that support an open ecosystem of writing and reading, NetNewsWire and MarsEdit, was laid off during the Covid recession and went looking for a new job. His blog posts about the job search highlighted Silicon Valley’s problematic emphasis on hiring for individual cleverness and efficiency rather than social intelligence and clarity. It is worth reflecting here on Humane Ingenuity about the long-term impact of “clever” coding versus “social” coding.
Brent does not have a CS degree but has decades of experience writing software. In preparation for applying for jobs, he researched what he was likely to be asked during an interview. His heart sank just a bit as his methods, honed since the mid-1990s and guided by experience, collided with contemporary rapid-fire coding preferences. Brent’s summary of his failures to grasp what tech firms want today has especially stuck with me:
My style of coding is to break problems into steps and make it super-obvious to other people — and future-me — what the code is doing. I like to write code so clear that comments aren’t needed.
Google and Facebook seek those with brilliant insights followed by compact code, which is perhaps a measure of aptitude and intelligence but a very narrow lane indeed. Brent has an array of talents, and more importantly they are connected: his thinking about software is related to his thinking about social issues related to that software and to the communities of developers and users that gather virtually around an app. (Brent was eventually hired by Audible, FYI.)
Clever over considerate is, I suppose, the unstated motto of Silicon Valley. Nothing new here. And of course it only gets worse as you examine SV’s business prerogatives, which can be even more anti-social. But it’s revealing to see it so deeply rooted in behind-the-scenes, and critical, hiring processes. Organizations are, ultimately, the people they choose to hire.
Brent Simmons used to work with Dave Winer, whose short imagined computer science course seems right on target for HI, and often unconsciously the one taken by software developers I appreciate:
If I were teaching computer science, I’d start with a working piece of software, probably an HTTP server, and give the students a series of assignments.
Assumptions: The software is documented, has users, and bugs, avoiding breakage is important.
Set up and install the software on your own server. Verify and demonstrate that it can handle a request. You can add a new page to the site. Authorize a new user.
You’ve encountered a problem. Write a great bug report.
You’ve got an itch. You wish the software could do X. Come up with a plan for adding the feature, outlining the steps, and how you’re going to test the new version. (Two versions of this assignment, one with X specified, and another where the student comes up with X.)
Write a doc showing the user how to turn on a feature in the product, with all the configuration options.
Here’s a bug report. Find the problem and fix it, without breakage. How will you verify that there was no breakage. Document the change, and circulate the change note to the users of the product.
One of the features of your product is new and competitors are copying it. It’s time to document the file formats and protocols it uses so your competitors can interop with you. Write the spec in clear language with numerous examples so users won’t get locked-in to their products, or yours for that matter.
Most important, this would all be with an existing working piece of software that real people use. Most student projects are scaled-down versions of real-world projects. They don’t behave like real communities. Esp because the users have expectations about how the software works.
As I ponder where this newsletter is going (maybe a short book?), I keep coming back to a set of values, some of them reflected in these case studies: a long-term rather than presentist view, the critical importance of perspective-taking, and ensuring that you are not doing things in the abstract, but in a real social context. It is also noteworthy how Brent and Dave emphasize writing well — not code, but the text that is often viewed as secondary, but which is to them very much primary: the documentation and communication for and with other people.
Kent Klaudt, Untitled, from PH21’s Urban exhibit. I really, really miss going out to eat.
Last month JSTOR Daily covered some early nineteenth-century forerunners of virtual reality. Before he created the photographic method that would carry his name, the French inventor Louis Daguerre was an apprentice in the workshop of Pierre Prévost, who created gigantic panoramic paintings that would encircle the viewer, creating a fully immersive experience.
(Pierre Prévost, A Panoramic View of London, from the Tower of St. Margaret’s Church, Westminster, 1815, via the Museum of London. It is nearly 20 feet long.)
Daguerre wanted to make this experience even more realistic by including motion and sound, which he finally succeeded in doing using cave-like dioramas. The musicologist Thomas Grey:
Rather than working with slides, however, the diorama manipulated natural daylight by a complex of screens, shutters, curtains, colored filters, and so forth to illuminate images painted directly on large, scrim-like hangings (averaging about seventy by forty-five feet in area).
John Tresch’s essay “The Prophet and the Pendulum; Sensational Science and Audiovisual Phantasmagoria around 1848” goes into depth on Daguerre’s accomplishment:
More than just a new kind of painting, the diorama was an immersive, hallucinatory experience housed in a specially made building that allowed an audience to gather in a darkened room watching a lighted screen, transparent and opaque at various points, slowly transform itself from night to day, from winter to summer, often accompanied by music and other sound effects. The building itself had moving parts: the viewing platform rotated to bring visitors face to face with two and sometimes three distinct views. The most striking of these were a transformation of a scene in the Alps, complete with yodeling maidens and a live, braying goat, and the midnight mass, in which an empty, day-lit cathedral gradually darkened, grew bright with candles, and filled with worshipers for a mass by Haydn. These uncanny transformations were accomplished through continuous changes in the angle, color, and intensity of lighting, with paint of various degrees of transparency applied to both sides of a silk canvas such that the change in the color and angles of the light brought out different aspects of the image.
This led directly to major advances in opera and ballet sets, perhaps the truest precursors to VR.