Through my college education & industry experience & curiosity, I have learned a lot. But, even after trying to search about books on the philosophy of engineering or the art / craft of engineering - I have fallen short.
I would love to hear what books / and projects that you have seen that have inspired you as an engineer & have provided you with your own philosophy of engineering.
I am talking about general "engineering" here, not just specifically "software engineering".
Requesting the universe to enlighten me :)
Computer Power and Human Reason by Joseph Weizenbaum (1976). Weizenbaum wrote Eliza, the first AI chatbot, almost sixty years ago and was appalled at the reception. This book is still very pertinent, especially the Introduction, Chapter 1 On Tools, chapter 9, Incomprehensible Programs, and chapter 10, Against the Imperialism of Instrumental Reason. Chapter 4, Science and the Compulsive Programmer, is one of the first written accounts of the hacker culture.
Weizenbaum's original paper on Eliza (1966) [0] is still very pertinent to the present generation of chatbots, especially the introduction and discussion.
Tools for Conviviality, Ivan Illich (1973) [1]. Influenced recent work by the computer scientists Steven Kell [2],[3] and Kartik Agaram [4].
Computation and Human Experience, Phil Agre (1997) (excerpt at [5]). Agre got a PhD in AI at MIT in the 80s and 90s and became very critical of the field. I think his shorter writings [6][7] are a better introduction, especially the personal memoir at [6]: "about how I became (relatively speaking, and in a small way) a better person through philosophy."
0. https://dl.acm.org/doi/10.1145/365153.365168
1. http://akkartik.name/illich.pdf
2. https://www.humprog.org/~stephen//research/talks/kell19de-es...
3. https://www.humprog.org/~stephen//research/talks/kell19softw...
4. http://akkartik.name/akkartik-convivial-20200607.pdf
5. https://pages.gseis.ucla.edu/faculty/agre/che-intro.html
6. https://pages.gseis.ucla.edu/faculty/agre/notes/00-7-12.html
That said, I haven’t read it in a long time so not sure how well it holds up.
My introduction to tech criticism was To Save Everything, Click Here by Evgeny Morozov. He describes a lot of tech culture as "solutionism" which I think is a great lens to have in your pocket.
And am certain that Grady Booch's book was itself mostly based on older material.
I also really like any really good book on doing requirements (they all have 80% of the same info). Getting the true needs of all your stakeholders (your users, the business people, the devs themselves, and the technical needs of the system) is probably the step that is done the poorest in most organizations, and the one that could save project the most time and money if done well.
Additionally, you can sort of intuit this by looking at very successful commercial products like Google Search, the iPhone, and ChatGPT. Search is a single text input. The iPhone is a screen with a very small number of buttons. Chatgpt has a simple chat interface. All of these systems are incredibly complex, but they're able to present a simple interface to the public to allow most people to leverage that complexity without having to think about it.
Just my 2 cents.
https://press.stripe.com/the-art-of-doing-science-and-engine...
Heartily recommend!
- Doing things as simply as possible to start off
- Keeping iteration time to a minimum, for maximum exploration of ideas
- Being willing to think outside the box
My takeaways above, hardly do these books justice, but they are as follows:
- Skunk Works: A Personal Memoir of My Years at Lockheed [0]
- Hackers: Heroes of the Computer Revolution. [1]
- The Dream Machine: J.C.R. Licklider and the Revolution That Made Computing Personal [2]
[0]: https://www.goodreads.com/book/show/101438.Skunk_Works
[1]: https://www.goodreads.com/book/show/56829.Hackers
[2]: https://www.goodreads.com/book/show/722412.The_Dream_Machine
When I was CTO of a software startup, I wrote a blog post reviewing various books about engineering and software teams, neatly organized into six sections. The three sections that you might find interesting, each featuring a few relevant books:
- Debugging dysfunctional product cultures: https://amontalenti.com/2020/11/28/definitive-reading-list#d...
- The psychology of deep work: https://amontalenti.com/2020/11/28/definitive-reading-list#p...
- Programmer mindset and philosophy: https://amontalenti.com/2020/11/28/definitive-reading-list#p...
I would also recommend "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin. It focuses on crafting higher quality code, which is the property of it not only running well, but being easy to understand and to work on
That book is a top three software book for me. It made me understand why OO is a thing and what concepts I should pretty much always use from that ecosystem.
The concept of interfaces (not just the programming construct, but the general idea) was massive and it changed my view on the testability of code.
Martin has some other good stuff related to professionalism as a programmer. He has a few talks and The Clean Coder and those are absolutely worth it as well.
I have been wondering this question ever since, I wish I had reached out to request help earlier. I am glad I did, nonetheless. I am 26, hope there is a lot more to learn, apply & build.
I am grateful to the universe (and the internet/hackernews). Thank you :)
I thought Shop Class as Soulcraft was excellent and found the author's theories on the lack of job and life satisfaction among those doing "knowledge work" compelling.
It reminded me of the movie Margin Call when Kevin Spacey's character, who manages a trading floor for a wall street investment firm, laments that if he'd been a ditch digger, at least he'd have a bunch of holes left behind as evidence he accomplished something.
by William J. Rapaport - ( https://www.apaonline.org/news/254862/William-Rapaport-is-th... )
> The APA is pleased to announce that William Rapaport (University at Buffalo) has been selected by the APA committee on philosophy and computers as the winner of the 2015 Barwise Prize!
This corresponds to the class https://cse.buffalo.edu/~rapaport/510.html
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
The table of contents can be read at https://www.wiley.com/en-us/Philosophy+of+Computer+Science%3...
You are likely interested in sections 3.12 through 3.18
3.12 CS as Engineering 64
3.13 Science xor Engineering? 66
3.14 CS as “Both” 66
3.15 CS as “More” 68
3.15.1 CS as a New Kind of Science 68
3.15.2 CS as a New Kind of Engineering 70
3.16 CS as “Neither” 71
3.16.1 CS as Art 71
3.16.2 CS as the Study of Complexity 71
3.16.3 CS as the Philosophy(!) of Procedures 72
3.16.4 CS as Computational Thinking 72
3.16.5 CS as AI 73
3.16.6 Is CS Magic? 74
3.17 Summary 76
3.18 Questions for the Reader 77
5 Engineering 95
5.1 Defining ‘Engineering’ 95
5.2 Engineering as Science 97
5.3 A Brief History of Engineering 98
5.4 Conceptions of Engineering 99
5.5 What Engineers Do 100'An Introduction to General Systems Thinking', Weinberg, and he's got a dozen more worthwhile books behind it.
'The Logic of Failure: Recognizing and Avoiding Error in Complex Situations', Dietrich Dorner
Engineers (and scientists) often boast ourselves as master of causality. We solve problem by understanding the domain. We laugh people as cargo-culting - not knowing why one does things. The Secret of Our Success shows it is a feature rather than a bug. The effect of "culture" takes much longer to manifest, often beyond our comprehension. One example given by the book is how we process cassava, lots of superfluous ritual. Without those processing culture, people get poisoned slowly. Only with modern chemistry do we comprehend the full extend of those ritual. But people have been eating cassava way before modern science were available. Similar can be said about medicine, lots of folk remedies don't work. But when they do, they do. Is not understanding a feature or a bug?
With the advent of LLM, things seem to come in full cycle. We now prompt the engine and get a result/an opinion of sort. No longer is understanding required. I see the use of LLM in software engineering very anti-engineering, hindrance to learning and understanding. But it might not be a bug after all.
P.S. I love the VSI series. Fits in my back pocket and usually gives a satisfying overview of a discipline. I always get a few fascinating ideas from every book. I've read probably 20 from the series at this point.
Look no further than “The Specialist” by Charles Sale
“YOU'VE heard a lot of pratin' and prattlin' about this bein' the age of specialization. I'm a carpenter by trade. At one time I could of built a house, barn, church, or chicken coop. But I seen the need of a specialist in my line, so I studied her. I got her, she's mine. Gentlemen, you are face to face with the champion privybuilder of Sangamon County.”
Sometimes the best books are also the shortest.
https://www.toiletrevolution.com/wp-content/uploads/The-Spec...
For engineering in general: To Engineer is Human - Henry Petroski The Art of Doing Science and Engineering - Richard Hamming Structures: Or Why Things Don't Fall Down - J.E. Gordon
http://worrydream.com/refs/Alexander%20-%20A%20City%20Is%20N...
I'd recommend Elements of Clojure[0].
Don't be fooled by the title, it's not really about Clojure, it just uses Clojure as an illustration as it discusses a very subtle general problem. From the website:
> The first chapter, Names, explains why names define the structure of our software, and how to judge whether a name is any good.
> The second chapter, Idioms, provides specific, syntactic advice for writing Clojure which is clean and readable.
> The third chapter, Indirection, looks at how code can be made simpler and more robust through separation.
> The final chapter, Composition, explores how the constituent pieces of our code can be combined into an effective whole.
I find it a thoughtful and considerate overview of an area that everybody has some implicit knowledge of, and something that leads to a more abstract concept of quality.
There is a lot of emphasis on simplicity and that things are the best when they work seamlessly.
Chapter 17, from the translation by Derek Lin, which I wholeheartedly recommend:
The highest rulers, people do not know they have them
The next level, people love them and praise them
The next level, people fear them
The next level, people despise themEssentially, in Chinese philosophy, any given situation has a propensity (water tends to run downhill). It is therefore more effective to work with that propensity, than it is to work heroically against that propensity. This is very much a layer in what the Tao Te Ching talks about.
Interesting, this is similar to the Hindu/Indic idea of dharma (e.g. the dharma of water is to flow) and the idea of working with/towards dharma (both of oneself and the world generally). (Dharma refers to both the proper order of things and to the actions one takes to uphold it.)
Edit: The "See also" section on the Wikipedia page for Ṛta is interesting:
• Asha (Zoroastrianism) https://en.wikipedia.org/wiki/Asha
• Maat (Egyptian religion) https://en.wikipedia.org/wiki/Maat
• Me (Sumerian religion) https://en.wikipedia.org/wiki/Me_(mythology)
• Tao (Chinese Taoism) https://en.wikipedia.org/wiki/Tao
and a few others. In Hinduism there are Ṛta, Dharma, etc. (https://en.wikipedia.org/wiki/%E1%B9%9Ata https://en.wikipedia.org/wiki/Dharma) (also in Buddhism Jainism etc)
> The rug is a fabrication which ties our ruminations together.
1. https://dudeism.com/thedudedeching/
Edit: There is an online version available as well, https://aui.me/text/the-dude-de-ching/
I think AI Engineers would be interested in a more Zen take, examining 'conceptual mind', 'subjective experience'.
""The Zen Teaching of Huang Po: On the Transmission of Mind""
https://www.goodreads.com/book/show/276779.The_Zen_Teaching_...
What you think is so good about this book for engineers, in a nutshell?
In engineering school I was taught to see the world in a special and unique way, to be able to solve engineering problems as a professional. In the book, this worldwiew is very well laid out.
An example:
> Precision instruments are designed to achieve an idea, dimensional precision, whose perfection is impossible. There is no perfectly shaped part of the motorcycle and never will be, but when you come as close as these instruments take you, remarkable things happen, and you go flying across the countryside under a power that would be called magic if it were not so completely rational in every way. It's the understanding of this rational intellectual idea that's fundamental. John looks at the motorcycle and he sees steel in various shapes and has negative feelings about these steel shapes and turns off the whole thing. I look at the shapes of the steel now and I see ideas. He thinks I'm working on parts. I'm working on concepts.Although Pirsig didn't explore it, quality is very much at the heart of any engineering, particularly when you try to quantify it. How effective is ISO-9000? GE was big on that. Boeing measured quality of their builds, until they compromised the process. What about Deming's approach (Total Quality Management)?
What is quality in software engineering? (We often sidestep that question and call it Software Craftsmanship instead). And there's a whole can of worms when we try to apply this to AIs.
[1] https://en.wikipedia.org/wiki/What_Engineers_Know_and_How_Th...
IMO in a similar vein is 'The Making of the Atomic Bomb', Richard Rhodes, another industry- and world-reshaping project.
It's not a book, but it's a place to go to lead to things to continue the search.
- Technics & Civilization
- The Culture of Cities
- The Story of Utopias
Lewis Mumford talks about technology, but from an anthropological pint of view.
Another book I would recommend is The Nature of Technology by Brian Arthur
The other I would recommend is James Burk's Connections he's has some books but I but the documentary is highly recommended.
0 - https://www.cs.virginia.edu/~robins/YouAndYourResearch.html
1 - https://www.youtube.com/watch?v=e3msMuwqp-o (lecture version)
Add Edsger Dijkstra's The Humble Programmer (1972 Turing Lecture) as a companion read for software engs: https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340... / https://archive.is/U8GwX
- https://www.goodreads.com/book/show/61899637-philosophy-of-c...
- https://www.goodreads.com/book/show/60965426-the-creative-ac...
- https://www.goodreads.com/book/show/530415.The_Art_of_Doing_...
It is offered from the perspective of how not to design systems, based on system engineering failures. The primary precept of the treatise is that large complex systems are extremely difficult to design correctly despite best intentions, so care must be taken to design smaller, less-complex systems and to do so with incremental functionality based on close and continual touch with user needs and measures of effectiveness.
https://www.penguin.co.uk/books/447751/how-to-build-impossib...
Enjoyable, not a philosophy of engineering but philosophy with engineering.
"Keep it simple, stupid!"
https://en.wikipedia.org/wiki/KISS_principle
The Basecamp's books are enjoyable, recommending https://basecamp.com/books/rework
IIRC chapters are contributed by different authors, so it's not a single point of view (even though of course there is some filtering by the editor).
Since it's from 2010 it is light on more recent developments like AI, however (unlike software) it's rare for ethic ideas to become outdated. So I would not dismiss it due to age. Also it's 5$ used on Amazon, so depending on your situation it's not a huge deal to get it and skim it - IMHO this kind of work doesn't have to be read front to back, instead it's great to get back to it when you feel like and think about a few pages and explore new ideas, re-evaluate your own concepts, etc.
Description from the publisher: "The Cambridge Handbook of Information and Computer Ethics, first published in 2010, provides an ambitious and authoritative introduction to the field, with discussions of a range of topics including privacy, ownership, freedom of speech, responsibility, technological determinism, the digital divide, and online pornography."
Editorial reviews stolen from Amazon: "...This five-part work examines difficulties in the field of information ethics and offers practical applications and criticisms... Recommended..." --B. G. Turner, Faulkner University, CHOICE
"...This is a rich and fascinating book, bringing to interpretative debates much that has been hitherto unknown. The chapters are long and complex, and the argument is multidimensional and far-reaching." --George Lăzăroiu, PhD, Institute of Interdisciplinary Studies in Humanities and Social Sciences, New York, Contemporary Readings in Law and Social Justice
I would begin with "Do Artifacts Have Politics?" and continue with "Autonomous Technology: Technics-out-of-Control as a Theme in Political Thought", M.I.T. Press, 1977.
The most influential content on engineering in my life is not in a book but a YouTube talk entitled How Complex Systems Fail by Richard Cook, which is about designing resilient systems. I’ve applied these ideas to many aspects of life, not just engineering.
https://www.amazon.com/Art-Doing-Science-Engineering-Learnin...
“The Social Construction of Reality: A Treatise in the Sociology of Knowledge.” Berger & Luckmann 1966.
Perhaps the core insight to me is that not only does every practice of engineering exist as embedded in the context of a socially constructed reality, but the practice of engineering itself also fundamentally involves the continual construction of such realities. In other words, for a software engineer to be able to do their job, they must among other things be a kind of applied social epistemologist.
I expect this framing doesn’t make much sense to many readers — I’m hoping the following articles might serve to illustrate:
“Programming as Theory Building.” Peter Naur, Microprocessing and Microprogramming 1985 (https://doi.org/10.1016/0165-6074(85)90032-8)
> … suggests that programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. This suggestion is in contrast to what appears to be a more common notion, that programming should be regarded as a production of a program and certain other texts.
“Interpretation, Interaction and Reality Construction in Software Engineering: An Explanatory Model.” Kari Rönkkö, Information and Software Technology 2007 (https://doi.org/10.1016/j.infsof.2007.02.014)
> Floyd’s paper Outline of a Paradigm Change in Software Engineering requested that we move from a product oriented paradigm to a process oriented paradigm.
> Naur’s paper Programming as Theory Building made it painfully clear to us that exemplary resources in the form of material and available support are not enough when modifying others’ programs. In fact, if Floyd’s claims had been taken seriously by the software developers in Naur’s study, and if the same developers had access to an explanatory model … their difficulties could have been both anticipated and prevented.
> This article … explains from a natural language point of view, how interpretation takes place, and discusses the consequences of this in relation to interaction and reality construction in software engineering practice.
I wrote a (short) review on the book directly after reading it here[1]. I've since reread the book, and while some of my opinions on it are the same, some I understand the nuance much more in context of the rest of the book, I need to update it.
"Philosophy of Technology" in general is a pretty rich field with a long history, and you might find more references in it than in engineering specifically.
It’s about designing houses, and in a more general sense spaces for people. There is a powerful philosophy that he conveys in this book which applies to software engineering as well.
Some notes of caution though. The book is not an easy read. It’s also not very direct and quite philosophical. Also, don’t try to reduce it to just software patterns. There is a lot more in there about a sense of beauty, quality, and essence which people miss when they mechanically reduce the message to the patterns.
The Civilized Engineer The Introspective Engineer The Existential Pleasures of Engineering
A few others I haven't read
Posting it here since the author has kindly allowed me to share this file with my colleagues in order to familiarize them with the ideas laid out in the book. Also, seems like the paper version is no longer available on Amazon, so I don't see any other way. Especially since the author's goal was to leave a heritage.
https://leanpub.com/info-ops/c/LeanpubWeeklySale2024Jan19
Note: Book 2 is more code-centric, with active strategies to minimize solution complexity. This book is all about how to minimize to-do list complexity and tracking (which arguably is more important)
"Engineers in every discipline learn the limits of the tools and materials they work with. If you’re an electrical engineer, you know the conductivity of various metals and a hundred ways to use a voltmeter. If you’re a structural engineer, you know the load-bearing properties of wood, concrete, and steel.
"If you’re a software engineer, your basic building material is human intellect and your primary tool is you."
Page 819
https://www.amazon.com/Structures-Things-Dont-Fall-Down/dp/0...
Books:
- Rickover's "The Never-Ending Challenge of Engineering"
- Taichi Ohno's "WorkPlace Management"
https://www.asme.org/publications-submissions/books/find-boo...
https://www.amazon.com/Risk-Society-Modernity-Published-asso...
Changed my way of understanding what engineering is. Read the chaoter on designing cathedrals without math, science or modelling.
uses scheme to illustrate how to think about computation abstractly.
It' smaybe check out the Computer History Museum.
Read Feynman's (or about) books. "Surely you're joking, Mr Feynman" is light but profound. Max Tegmark's "Our Mathematical Universe" is great. "I am a strange loop" by Douglas Hofstadter will connect many dots. If you want to peek deeper - "Through two doors at once" describes experiments at the edge of our reality. "The singularity is near" is a good perspective that connects dots through time back many years to many in the future.
These are just some incomplete starter points. It's deep, beautiful rabbit hole. Enjoy it.
Critical Path by buckminster fuller
* The Art of Computer Programming
The Intentional Engineer
- From Mathematics to Generic Programming by Stepanov & Rose
- Gödel, Escher, Bach: an Eternal Golden Braid by Hofstadter
- The Little Schemer / The Seasoned Schemer