Ask HN: Books that impacted your work that few other people seem to care about?
There are a few resources that really changed how I approach my job for the better, but that largely don't seem to stick with anyone else.
This made me curious about what unpopular resources I might be missing out on.
Doesn't have to be a book -- any resource or technique is fine, it was just easier to say 'book' in the title.
40 comments
[ 1.8 ms ] story [ 110 ms ] thread[edit]
reddit: https://camas.github.io/reddit-search/#{%22author%22:%22comb...
hn: https://news.ycombinator.com/threads?id=sklogic
When you are solving a problem with a program, the program has two types of complexity; essential complexity which is needed to define the problem, and incidental complexity that comes from executing the program on the computer (variables, functions, class definitions, etc).
He argues that there is no way to eliminate the incidental complexity from the program without defining a DSL at the level of abstraction of the problem domain.
So a DSL for generating a flow chart would contain keywords for 'start', 'end', the various states and structure to join the states together, just the minimal amount needed to uniquely define the flowchart. Unlike when solving the problem using a general purpose language, what the DSL would not contain would be functions and variables, methods to draw boxes, housekeeping for export formats etc. In this way the essential complexity of the problem is captured entirely by the DSL, and the incidental complexity has been moved to the DSL implementation.
So once a DSL or language has been defined for the problem, he argues you now compile it down to an underlying metalanguage (anything with a quasiquotation operator, macros basically), rather than using an interpreter or something. The reason he argues for compilation is that compilation can be defined as a series of tree rewrite rules, as trivial as needed (nanopass was used as an example of a compiler framework that operates this way), then combined linearly until it's expressed in the underlying metalanguage (or another DSL). Any primitive runtime features needed for the program would be written in the metalanguage or another DSL.
He argues an advantage of having a common underlying metalanguage is it allows him to combine the DSL's as needed, and whip new ones up on the fly as needed. His threshold for making a new DSL is anything that takes more than 5 minutes. He has a bunch of tools to make this whole process easier, inferring IDE integration code, autocomplete, debug info, etc.
I find it compelling, and getting convinced by the argument that there's no other way to eliminate all incidental complexity from the program other than a babel tower of languages, linguistic abstraction.
I've argued for DSLs many times here on HN due to a slightly different, although intimately related, reason.
I think it's the only way to avoid the Turing tarpit [1]. In other words, getting some clean semantics where it is easy to prove things. IMHO, the only way to get formal methods to scale.
[1] https://en.wikipedia.org/wiki/Turing_tarpit
A part of the book covers balancing the cost of abstraction with the amount of complexity it is hiding. The ideal is: simple interface (DSL in this context) and lot of hidden complexity.
I agree with your point, but the threshold for writing a DSL needs to be carefully considered.
I found the first half of "Prometheus Rising" by Robert Anton Wilson to be incredibly useful for understanding human dynamics -- I use the framework presented there every day. The core of this is in my opinion just a very straightforward computer-focused analogy that gives me insight into the behaviour of other people and myself that I haven't found elsewhere.
Of course, outside the core is a LOT of wild new age, Crowley-Leary-Regardie syncretism that provokes strong negative throw-the-book-across-the-room reactions in most people. A lot of very reasonable people would look at the wikipedia page or the cover of this book and not only think that the book is crap, but also that I'm a crazy hippie for even considering reading it.
Would you be willing to give an example or two of some topics the books discuss that might be counter to what that perception or that you just found really insightful?
Or is my perception that the focus is new age mysticism correct?
I'm not saying that this is literally correct -- the brain is way more complicated than that! But I find it quite useful as a metaphor for processing and understanding social dynamics that I inherently find "irrational".
2) Principles of Product Development Flow, Donald G. Reinertsen
3) Step Away from the Computer or Hammock Driven Development, Rich Hi ckey
https://github.com/matthiasn/talk-transcripts/blob/master/Hi...
did you by any chance find a translation that wasnt like that?
* Translation by Gregory Hays published in "The Modern Library" classics. This is highly approachable and should be the first one you start with.
* Translation by Martin Hammond and published by Penguin Classics. Lots of illuminating Notes.
* Translation by Robin Hard and published in "Oxford World's Classics" series. Robin Hard also has a translation of Epictetus' Discourses/Enchiridion/Fragments and Sayings and Anecdotes of Diogenes in the same Oxford series, both of which are also excellent.
PS: All of the above contain a detailed Introduction to the work which you should not skip. They set the background, Worldview, Time etc. which help you understand the ideas in the book better.
This great website allows you to compare the public domain translations: https://www.stoicsource.com/
The Stoicism subreddit : https://old.reddit.com/r/Stoicism/ Checkout the Recommended texts.
It's a really outdated book about a "perfect" anarchist sociaty. I started reading it for the political theme, but the author was so hopeful and puts so must trust in common people that I couldn't stop smile while reading it. It hit me harder that I could've ever imagined, I started putting more trust in others and totally changed the way I confront people. At that time I was a team leader in a really chaotic company and the change of approach did wonders. Management even started to receive request from other developers to join our team.
I do find a lot of it holds up pretty well as long as you sub-out some of the more specific examples with modern equivalents.
It took me while to see why, but I can't denied it now
This is not a straightforward article, so I can see how people could struggle with it, but I love every bit of it.
The author taught me to slow down, work less, and pay more attention to the other things.
[0] https://medium.com/@the_jennitaur/how-to-do-nothing-57e100f5...
---
The Life-Changing Magic Of Not Giving A F*ck, or at least the first chapter or two. This book should have been a blog article, so you don't need to read the whole thing.
Long story short, it's minimalism for obligations. If it doesn't bring joy or serve a purpose, chuck it.
It's not a clever book, but I suppose it hit at the right time. It made me realise how most work obligations are negotiable. It emboldened me to cancel meetings, cut their headcount, and send people back to their desks once they played their part in them.
When I went freelance, I applied the same energy to maintenance tasks like accounting, comment moderation and the dreaded introductory phone calls.
First published in 2007, Patterns... describes a kind of grand unification of network protocols, collapsing the fraught OSI model into a single, recursive layer. Notable features include: the unification of transport semantics, from TCP to UDP; the decimation of Internet routes through private-everywhere, topological addressing; the supplanting of URL and DNS with application names and a dynamic, distributed directory; elegant approaches to mobility and multicast/anycast; emergent security and DDoS mitigation; emergent throughput and connection scaling; a sophisticated approach to monitoring and management; and much more.
With the arguable failure of IPv6, the deepening swamp of IoT, and the now-leaning tower of HTTP-based transports, Patterns... illuminates a different path, one that can still be taken, both in the small and the large.
Incidentally, I found this book referenced in this article: "Why Should Doctors Read Medical Books?" by Dr. Eric Cassell [0]
[0] http://www.ericcassell.com/download/WhyShouldDoctorsReadMedi...
Should the authors of lousy APIs be held accountable for their crimes? Why changing APIs might become a criminal offense Why changing APIs might become a criminal offense - Should the authors of lousy APIs be held accountable for their crimes?
A couple of interesting insights:
- Software engineers are more like doctors/lawyers so why do software organizations look more traditional businesses rather than agencies?
- The way corporations are structured there is no incentive for software engineers at the bottom of the hierarchy to put more than a token effort in.
There's also a previous ASK HN about the "books that improved your career" [1].
[0] https://www.goodreads.com/en/book/show/35051753- developer-hegemony
[1] https://news.ycombinator.com/item?id=27963226
Doesn't work with the space before "developer". :-)
Also, "The Death of Ivan Ilych" [3] by Tolstoy. I felt like a ping-pong ball in the hands of the author: whichever way he wanted me to think at a certain point in the plot, I did. Masterful insight into the life and death of an ordinary, diligent man. And, above and beyond that, it depicts the rarely avoidable self-centeredness of humans.
Oh, and lately, the prominent Finnish deep ecologist Pentti Linkola [4] has been a huge influence on me. In the Nordic countries, he is sometimes called "ecofascist", but this is an obvious cherry-picked overstatement of his views to my mind. I think only one of his books has been translated into English, though: "Can Life Prevail?" [5].
1: https://en.wikipedia.org/wiki/A_Confession
2: https://en.wikipedia.org/wiki/The_Kingdom_of_God_Is_Within_Y...
3: https://en.wikipedia.org/wiki/The_Death_of_Ivan_Ilyich
4: https://en.wikipedia.org/wiki/Pentti_Linkola and a fan page at http://www.penttilinkola.com/
5: https://www.goodreads.com/book/show/6397542-can-life-prevail
In programming, the analogous problem is API design: taking whatever data structures are used by a software tool internally, and figuring out how to present them to external programmers in a useful, intelligible way. If there’s a mismatch between the internal structure of the system and the structure of what-users-want, then it’s the API designer’s job to translate. A “good” API is one which handles the translation well.
User interface design is a more general version of the same problem: take whatever structures are used by a tool internally, and figure out how to present them to external users in a useful, intelligible way. Conceptually, the only difference from API design is that we no longer assume our users are programmers interacting with the tool via code. We design the interface to fit however people use it - that could mean handles on doors, or buttons and icons in a mobile app, or the temperature knobs on a fridge.
I've always been fascinated, and driven by, good health; particularly in the context of working at a desk on a computer all day long.
This book has helped me to understand the implications and negative impact of typical habits surrounding working at a computer; specifically sitting all day.
By considering, and practicing, the advice presented in the book, I've changed the way that I physically work which in turn has significantly impacted my efficiency and performance.
I now stand a majority of the day and have learned methods for doing so effectively without simply tiring out my legs and causing a different set of problems. I've learned much about posture, particularly in the context of typing, which has helped reduce various aches and pains. And I've also learned various mobility exercises which have reduced stiffness in my arms, shoulders, and neck.
All in all, I feel better, which in turn has helped me to gain mental clarity and stay focused.
[0] https://www.goodreads.com/book/show/22557522-deskbound