Maybe this is hyperbolic and unhelpful but...once you've fully digested Scott's thesis I think it becomes difficult to see computing as anything but a sprawling legibility project.
To me it helps to expand it from "computing" to "automation" in general. Taking the things people do based off of vibes and experience and codifying them into rules, whether they're algorithms or steps in a manufacturing process.
Bureaucracy is all about automating and formalizing human decision-making.
I would scope it differently: bureaucracy is about formalising coordination.
Automating, in the context of bureaucracy, is a complicated thing: half of the time, something automatic is added to the process and the total amount of work for the same meaningful output increases…
ETA: And I say coordination not decision-making because this is a bit wider.
It’s interesting because computing is closely tied to fields all about illegibility, e.g. cryptography.
With the Discord age verification event we saw how people are becoming less willing to make themselves legible to unpleasant entities in exchange for digital services.
So there’s hope yet for illegibility in computing, imo.
Right, I think productionized cryptography falls on the side of increasing legibility, but cryptography in the hands of regular people can serve to reduce legibility.
As much as I disagree with the popular thought-terminating cliché of "technology X is just a tool" (in favor of McLuhan's "the medium is the message"), I think, if anything, cryptography serves as a good example of X being just a tool. Math can serve both you and the totalitarian state. Its power is of course magnified tremendously in the hands of the state...
Anticipating a gathering of philosophers, I want to take this chance to ask whether (and if so, how) this matter of illegibility has something to do with the Real. Please also point me towards some accessible primers into these topics, for as interesting as it looks like in the wiki article, I didn't spend years studying philosophy to be able to actually understand this stuff. After scouring through the entire article, I could only find this somewhat more comprehensible explanation towards the end..
Glyn Daly also provided a further elaboration of Žižek's three modalities through his pre-established examples from pop culture: [...]
The symbolic Real refers to the anonymous symbols and codes (scientific formulae, digitalisation, empty signifiers...) that function in an indifferent manner as the abstract "texture" onto which, or out of which, reality is constituted. In The Matrix, for example, the symbolic Real is given expression at the point where Neo perceives "reality" in terms of the abstract streams of digital output. In the contemporary world, Žižek argues that it is capital itself that provides this essential backdrop to our reality and as such represents the symbolic Real of our age.
Zizek is approaching philosophy from the point of view of Lacanian psychoanalysis and Marxism. In that field, the Real is not so much “reality” as the matrix of symbols that make reality legible to individuals, but the Real is also always incomplete and unstable. For Marxists, individual psychology is created by social forces (capitalist ideology, class consciousness) and for Lacan, individual psychology has a lot of unconscious mechanisms to classify and simplify reality into understandable units. Zizek basically combines the two systems to mostly talk about how we’re blinded to capitalism all around us working through symbolic patterns.
I find it thought provoking, but I’m not sure it’s a full account of what's going on. In particular, the Lacan stuff doesn’t seem that well grounded. It’s definitely interesting though.
I don't think it's hyperbolic but I think it's too broad and assertion. What is "computing" in this context?
If it's "the tech sector" - the structure of predominantly (but not exclusively) private interests which dominate mainstream tech, then yes, absolutely.
If it's "the discipline of computing", well, that's less clear. It's obviously deeply entangled with the tech sector.
In both cases these subcategories are still super broad, and "computing" existing across a huge range of industries and practices.
So while I agree that the state of mainstream/commercial computing is very tied up with rendering human activity legible to governments and capital, I don't think this is an inherent limitation of the form, if that makes sense.
I agree that it's critically important to make a distinction between the computing industry and computer programs written by pro-user developers.
However, even if you are not programming in the pursuit of profit, you can't escape the fact that Programming is Forgetting: http://opentranscripts.org/transcript/programming-forgetting-new-hacker-ethic/ You are inherently always taking some element of the real world and simplifying it in order to represent it using bits. You can't avoid having to make decisions about which pieces of information are important to represent and which can be ignored, because you cannot represent reality with perfect fidelity.
I strongly agree! But I think that extends to all human knowledge building. Cartography works the same way, for example, as does arguably almost all science and engineering.
Maybe you could argue that those things are also exercises in making the world legible, (quite literally, in cartography's case!) but I suspect at that point we'd be getting quite liberal with the use of "legible".
In summary though, I should definitely find some time to read Seeing Like a State.
We’ve all heard the story of the person who learned how to automate their job down to a simple script they run at the start of the week and then they spend the rest of the week just pretending to work but actually slacking off. From the corporate point of view, this is bad. The person is idling! But from the individual point of view, being able to control your time is important and makes the job tolerable. Legibility is about trying to make sure the corporation can “see” all the work being done and ensure it is done to their favor rather than the favor of the worker.
Legibility has always been partial and incomplete because making things legible is a process itself and inefficient and it forces sub-optimal shapes onto work.
For example, fruit has to be packed onto a truck and kept fresh long enough to be delivered to consumers, so it is tougher and less flavorful than fresh fruit off a farm. “Legible fruit” is superior in transportability and shelf life, but inferior in flavor.
In software development, a small team of motivated developers working without any management controls is often more productive than a larger team with extensive management controls, but corporations still prefer the controls because it is manageable, predictable, replaceable, etc.
From the corporate point of view, this is bad. The person is idling!
There are two kinds of corporate points of view: this is bad because the person is idling, or this is bad because the person's work output is consistent beyond what should be reasonable for their (corporate) idea of the work done and they don't even know it until the person is not available…
Good read, I'd say I'm mostly in agreement with the author.
One quibble:
In my view, Brooks’ Mythical Man-Month takes the opposite stance of Naur’s, that programming is TOO illegible. Brooks ultimately advocates for more companies to turn the act of programming into an engineering discipline.
Having read The Mythical Man Month twice, I think this is not quite right. Yes, it advocates for different structures around programming. But if you look at the actual team structure advocated by Brooks, the people in the team are not all fungible engineers but they each have quite different roles!
Moreover, there's a difference in the level of abstraction that engineering processes serve vs the theory of the program operates at.
MMM is really about project management at its core. Sure, that involves some durable artifacts. But someone can simultaneously hold the viewpoints that introducing processes & durable artifacts is good (e.g. "all teams should use the same issue tracker", "all major systems should have architecture doc"), as well as value tacit knowledge ("new engineers should pair with experienced ones during on-boarding"). I don't think these two are in opposition.
E.g. the bit quoted from MMM would cover things like "we useTypeScript and Go because we have many supporting libraries for them." That doesn't also carry the implication that "programmers are intrchangeable" or that "we use Go because we can quckly hire new Go programmers". Yes, some people might think that! But I don't think the former implies the latter.
Thanks for the feedback. "Opposite" wasn't the right word here, so I definitely agree with you on all of this. That said, I do think Brooks was advocating for more "legible" processes and structures around programming, and was mildly foreshadowing events such as the Therac-25 disaster as an outcome of poor project management and heroic development.
I read Sean's article after writing mine, and enjoyed his perspective. He comes at the subject from the perspective of the tech company, while I focused more on the individual contributor. His description of "dangerous advice" also stuck with me, as ways of navigating illegible processes.
One goal of a well-oiled software-producing machine is to for the software-producing cogs in their machine to be interchangeable, hot-swappable, bus-factorable.
This is the goal of the agile ticket factory but in reality as much as Jira pretends to control the software development life cycle, the real work happens despite all the Atlassian stuff, not thanks to it.
Meanwhile, I long for a tool that makes it easy to write specs and link them to tickets, tracking who is tackling what, which is ephemeral, but retaining the intention, which tends to be more persistent.
Maybe we should be writing something like FEATURES.md, not just CHANGELOG.md.
The point here is important. Software developers are not just code-monkeys. The code they produce is just documentation run by a computer. It's like saying the product of an HR department is the amount of printed pages they write. The important parts of software (implementation, design, and architecture) are the parts where policy is designed to perform a business goal. This is something computers don't understand and cannot. It's a human problem and the humans who wrote it understand the nuances of that policy the best.
I do think that as a profession we haven’t actually tackled theory building in the sense of making our theories explicit. Literate programming is one attempt to make the implicit explicit; proofs and specifications are another stab at this from another angle.
I think explicit theories are better than implicit theories because we can reason about them, and we become more free to change the code radically in response to refinements in the theory.
Obligatory vibecoding reflection: vibecoding lets us defer a certain amount of theory building but usually at a certain point the user has to start explicitly instructing the agent in theory for it to make progress.
Clearly Seeing Like a State needs to go on my reading list; [another essay on it]https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/) is in my backlog. (Via Titus Winters' valediction when departing Google, "resist the push for legibility". He was the C++ library/language TLM-- context seems relevant.)
It's an interesting read for sure, but I won't lie and say every chapter is gripping. I found the middle sections to drag a bit, as Scott provides more and more examples illustrating very similar points.
I too read Venkatesh's article after writing mine - his summary of the book is very good. If you enjoy those ideas in the essay then you'll probably like Scott's book too.
edsu | 16 hours ago
Maybe this is hyperbolic and unhelpful but...once you've fully digested Scott's thesis I think it becomes difficult to see computing as anything but a sprawling legibility project.
icefox | 10 hours ago
To me it helps to expand it from "computing" to "automation" in general. Taking the things people do based off of vibes and experience and codifying them into rules, whether they're algorithms or steps in a manufacturing process.
Bureaucracy is all about automating and formalizing human decision-making.
k749gtnc9l3w | 5 hours ago
I would scope it differently: bureaucracy is about formalising coordination.
Automating, in the context of bureaucracy, is a complicated thing: half of the time, something automatic is added to the process and the total amount of work for the same meaningful output increases…
ETA: And I say coordination not decision-making because this is a bit wider.
gwil | 11 hours ago
It’s interesting because computing is closely tied to fields all about illegibility, e.g. cryptography.
With the Discord age verification event we saw how people are becoming less willing to make themselves legible to unpleasant entities in exchange for digital services.
So there’s hope yet for illegibility in computing, imo.
quad | 10 hours ago
I’d have said cryptography is about control. For example, the entire idea of a PKI is a legibility project.
pzel | 10 hours ago
Right, I think productionized cryptography falls on the side of increasing legibility, but cryptography in the hands of regular people can serve to reduce legibility.
As much as I disagree with the popular thought-terminating cliché of "technology X is just a tool" (in favor of McLuhan's "the medium is the message"), I think, if anything, cryptography serves as a good example of X being just a tool. Math can serve both you and the totalitarian state. Its power is of course magnified tremendously in the hands of the state...
smlckz | 9 hours ago
Anticipating a gathering of philosophers, I want to take this chance to ask whether (and if so, how) this matter of illegibility has something to do with the Real. Please also point me towards some accessible primers into these topics, for as interesting as it looks like in the wiki article, I didn't spend years studying philosophy to be able to actually understand this stuff. After scouring through the entire article, I could only find this somewhat more comprehensible explanation towards the end..
carlana | 8 hours ago
Zizek is approaching philosophy from the point of view of Lacanian psychoanalysis and Marxism. In that field, the Real is not so much “reality” as the matrix of symbols that make reality legible to individuals, but the Real is also always incomplete and unstable. For Marxists, individual psychology is created by social forces (capitalist ideology, class consciousness) and for Lacan, individual psychology has a lot of unconscious mechanisms to classify and simplify reality into understandable units. Zizek basically combines the two systems to mostly talk about how we’re blinded to capitalism all around us working through symbolic patterns.
I find it thought provoking, but I’m not sure it’s a full account of what's going on. In particular, the Lacan stuff doesn’t seem that well grounded. It’s definitely interesting though.
strongoose | 10 hours ago
I don't think it's hyperbolic but I think it's too broad and assertion. What is "computing" in this context?
If it's "the tech sector" - the structure of predominantly (but not exclusively) private interests which dominate mainstream tech, then yes, absolutely.
If it's "the discipline of computing", well, that's less clear. It's obviously deeply entangled with the tech sector.
In both cases these subcategories are still super broad, and "computing" existing across a huge range of industries and practices.
So while I agree that the state of mainstream/commercial computing is very tied up with rendering human activity legible to governments and capital, I don't think this is an inherent limitation of the form, if that makes sense.
icefox | 8 hours ago
Agreed, this is part of what I was trying to say. There's plenty you can do with computing besides automation. Art, games, community, etc.
technomancy | 4 hours ago
I agree that it's critically important to make a distinction between the computing industry and computer programs written by pro-user developers.
However, even if you are not programming in the pursuit of profit, you can't escape the fact that Programming is Forgetting: http://opentranscripts.org/transcript/programming-forgetting-new-hacker-ethic/ You are inherently always taking some element of the real world and simplifying it in order to represent it using bits. You can't avoid having to make decisions about which pieces of information are important to represent and which can be ignored, because you cannot represent reality with perfect fidelity.
strongoose | 40 minutes ago
I strongly agree! But I think that extends to all human knowledge building. Cartography works the same way, for example, as does arguably almost all science and engineering.
Maybe you could argue that those things are also exercises in making the world legible, (quite literally, in cartography's case!) but I suspect at that point we'd be getting quite liberal with the use of "legible".
In summary though, I should definitely find some time to read Seeing Like a State.
[OP] ashwinsundar | 3 hours ago
That's what makes it such a potent idea!
carlana | 8 hours ago
We’ve all heard the story of the person who learned how to automate their job down to a simple script they run at the start of the week and then they spend the rest of the week just pretending to work but actually slacking off. From the corporate point of view, this is bad. The person is idling! But from the individual point of view, being able to control your time is important and makes the job tolerable. Legibility is about trying to make sure the corporation can “see” all the work being done and ensure it is done to their favor rather than the favor of the worker.
Legibility has always been partial and incomplete because making things legible is a process itself and inefficient and it forces sub-optimal shapes onto work.
For example, fruit has to be packed onto a truck and kept fresh long enough to be delivered to consumers, so it is tougher and less flavorful than fresh fruit off a farm. “Legible fruit” is superior in transportability and shelf life, but inferior in flavor.
In software development, a small team of motivated developers working without any management controls is often more productive than a larger team with extensive management controls, but corporations still prefer the controls because it is manageable, predictable, replaceable, etc.
k749gtnc9l3w | 5 hours ago
There are two kinds of corporate points of view: this is bad because the person is idling, or this is bad because the person's work output is consistent beyond what should be reasonable for their (corporate) idea of the work done and they don't even know it until the person is not available…
carlomonte | 14 hours ago
Thanks, Ashwin, for making me finally read Naur's essay.
typesanitizer | 13 hours ago
Good read, I'd say I'm mostly in agreement with the author.
One quibble:
Having read The Mythical Man Month twice, I think this is not quite right. Yes, it advocates for different structures around programming. But if you look at the actual team structure advocated by Brooks, the people in the team are not all fungible engineers but they each have quite different roles!
Moreover, there's a difference in the level of abstraction that engineering processes serve vs the theory of the program operates at.
MMM is really about project management at its core. Sure, that involves some durable artifacts. But someone can simultaneously hold the viewpoints that introducing processes & durable artifacts is good (e.g. "all teams should use the same issue tracker", "all major systems should have architecture doc"), as well as value tacit knowledge ("new engineers should pair with experienced ones during on-boarding"). I don't think these two are in opposition.
E.g. the bit quoted from MMM would cover things like "we useTypeScript and Go because we have many supporting libraries for them." That doesn't also carry the implication that "programmers are intrchangeable" or that "we use Go because we can quckly hire new Go programmers". Yes, some people might think that! But I don't think the former implies the latter.
[OP] ashwinsundar | 4 hours ago
Thanks for the feedback. "Opposite" wasn't the right word here, so I definitely agree with you on all of this. That said, I do think Brooks was advocating for more "legible" processes and structures around programming, and was mildly foreshadowing events such as the Therac-25 disaster as an outcome of poor project management and heroic development.
faassen | 9 hours ago
This reminds me of this essay: https://www.seangoedecke.com/seeing-like-a-software-company/
This argues that a software company wants to make everything legible, but that illegibility is essential in making stuff actually happens.
[OP] ashwinsundar | 4 hours ago
I read Sean's article after writing mine, and enjoyed his perspective. He comes at the subject from the perspective of the tech company, while I focused more on the individual contributor. His description of "dangerous advice" also stuck with me, as ways of navigating illegible processes.
alper | 8 hours ago
This is the goal of the agile ticket factory but in reality as much as Jira pretends to control the software development life cycle, the real work happens despite all the Atlassian stuff, not thanks to it.
mordae | 5 hours ago
Meanwhile, I long for a tool that makes it easy to write specs and link them to tickets, tracking who is tackling what, which is ephemeral, but retaining the intention, which tends to be more persistent.
Maybe we should be writing something like
FEATURES.md, not justCHANGELOG.md.sonicrocketman | an hour ago
The point here is important. Software developers are not just code-monkeys. The code they produce is just documentation run by a computer. It's like saying the product of an HR department is the amount of printed pages they write. The important parts of software (implementation, design, and architecture) are the parts where policy is designed to perform a business goal. This is something computers don't understand and cannot. It's a human problem and the humans who wrote it understand the nuances of that policy the best.
The code was never the important part.
Student | an hour ago
I do think that as a profession we haven’t actually tackled theory building in the sense of making our theories explicit. Literate programming is one attempt to make the implicit explicit; proofs and specifications are another stab at this from another angle.
I think explicit theories are better than implicit theories because we can reason about them, and we become more free to change the code radically in response to refinements in the theory.
Obligatory vibecoding reflection: vibecoding lets us defer a certain amount of theory building but usually at a certain point the user has to start explicitly instructing the agent in theory for it to make progress.
cceckman | 8 hours ago
Thanks for sharing!
Clearly Seeing Like a State needs to go on my reading list; [another essay on it]https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/) is in my backlog. (Via Titus Winters' valediction when departing Google, "resist the push for legibility". He was the C++ library/language TLM-- context seems relevant.)
[OP] ashwinsundar | 3 hours ago
It's an interesting read for sure, but I won't lie and say every chapter is gripping. I found the middle sections to drag a bit, as Scott provides more and more examples illustrating very similar points.
I too read Venkatesh's article after writing mine - his summary of the book is very good. If you enjoy those ideas in the essay then you'll probably like Scott's book too.
strongoose | 10 hours ago