I wrote about this a fair bit as a party of my master's thesis, about tinkering as being a "conversation" with materials. Hacking can absolutely be looked at in this framework.
The philosopher Donald Schön I think was the first person to formulate tinkering in that way. The process of engaging with materials -- whether it's a broken motor you're curious about or a tune you're plucking out as a complete novice or some code on Scratch -- involves asking questions of the materials, learning to hear answers, and noticing when the materials themselves pose questions. It's a really nice way of looking at things.
2026-06-25 science, scientific software
Cultures of Programming - The Development of Programming Concepts and Methodologies is a recent book by Tomáš Petříček that analyses the history of programming from the perspective of five interwoven cultures. It contains a lot of interesting insight, so I encourage you to read it. At the very least, read the first chapter. In this post, I try to relate these five cultures to the wider world of technology, and to the practices of scientific research.
The five cultures identified in the book are the following (my summaries):
Mathematical culture sees computer programs as mathematical entities whose properties are amenable to proof.
Hacker culture sees programming as a conversation with a machine as it runs.
Engineering culture sees programs as technical artifacts whose construction according to established best practices is a trade-off between desirable properties and economic constraints.
Management culture sees software as an industrial product whose qualities depend on suitable organisation structures.
Humanist culture sees computation and programs as extensions and externalisations of human thought and notations.
Individuals typically adopt a primary culture that defines their main attitude towards programming, but also take the points of view of other cultures depending on context.
My first observation is that these five cultures fall into two categories:
Hacker, engineering, and management culture are about making software.
Mathematical and humanist culture are about relating to software.
These two categories are not completely independent. If you care about software having certain formally provable properties, for example, you better take into account that requirement during all stages of software construction.
My second observation is that these cultures are not specific to programming. This is perhaps easiest to see for engineering and management, the duo that has been piloting manufacturing industries for quite a while, with engineering focusing on the technical aspects and management on the coordination of human efforts. As for hackers, I see them as a reincarnation of craftspeople. They have the same approach of making something with their hands while constantly integrating feedback from their senses. They also work alone or in small self-organizing teams, and favor learning-by-doing over formal education. The trade-offs between bespoke artisanal software as made by hackers, and industrial mass-market software as made by a cooperation of engineers and managers, is very similar to the trade-offs between a tailor-made wardrobe and Ikea furniture.
Mathematical culture is not so much about the academic discipline of mathematics, but about applying the formal approaches associated with mathematics to software. In contrast, humanist culture emphasizes contextual reasoning about software. Formalization requires decontextualisation, which creates a tension between formally provable properties on one hand, and contextually relevant properties on the other hand. In simpler terms, formal methods can provide rigorous proofs of some properties, but those properties are often not the most relevant ones in your application context. Similar tensions between formal and informal reasoning exist in other intellectual disciplines. For example, many fields of science use both qualitative (informal) and quantitative (formal) approaches in research, and have subcultures that favor one or the other.
Early scientists worked in the same spirit as craftspeople and hackers: alone or in small teams, alternating between making things (instruments, experimental setups) and observing, and organizing in non-hierarchical institutions (learned societies) that support research while respecting individual autonomy. More recently, some scientific activities have been industrialized (see this earlier post), and organized according to management principles. Science thus has its own analogue of the tensions between hacker culture on one hand and engineering plus management culture on the other hand. Management culture is mostly seen as imposed from the outside, by funders, and it is a particularly serious mismatch for the inherently exploratory nature of research.
Scientific software inherits both the cultures of programming and the cultures of scientific research. In its early decades, from the 1950s to the 1970s, science was still dominantly a craft, and its practitioners adopted hacker culture in the creation of their software, which was typically small to medium-sized Fortran programs with no dependencies other than a Fortran compiler. A minority of researchers adopted humanist culture in publishing and reviewing this software much like a journal article - see my article on reviewing research software. With increasing software size and complexity, reusable libraries grew in importance, an early example being LINPACK in the 1970s. Software development started to become an activity distinct from research itself, dominated by engineering culture, and ultimately leading to the establishment of the research software engineer as a distinct profession. However, hacker culture continues to prevail for software produced as part of a research project, nowadays often taking the form of computational notebooks or workflows.
Given the importance of mathematics in the quantitative sciences, it is surprising that mathematical culture only plays a minor role for research software. My guess is that this is due to the dearth of mature formal methods for software. Quantitative sciences mostly rely on decades-old and well-understood mathematics, rather than on cutting-edge mathematical research. Applying this principle to formal methods for software, this leaves static type checking by compilers as the only formal method that is widely available in standard software development tools. Scientists are no different from software developers in embracing or despising static type checking. This is perhaps the most visible expression of the tension between engineering and hacker culture.