Author: Henning Diedrich
- "Blockchains collapse agreement and execution [with smart contracts]"
- "Blockchains are about guarantee of execution"
- "Ethereum programs cannot be stopped"
- "Decentralization pre-empts outside control"
- "Blockchains prevent things from going wrong in the first place"
- "With blockchains, programs take on a life of their own"
- "Who doesn't agree is simply kicked off the network"
- "Because everything is signed, there is no need to trust"
- "A blockchain survives as long as one node stays up"
- "The ultimate arbiter for blockchains is social consensus [on what to value and how to value]"
- "If it doesn't use guaranteed execution, it's not a blockchain use case"
- "Blockchains allow for bearer-like, yet auditable instruments"
- "Blockchains add the dimension of trust to data"
- "A blockchain protects the accounts [and what's in them] when a node is compromised"
- "Total validation replaces central control [but this is slower]"
- "All accounts 'pre-exist.' You just grab a random key for one."
- "Blockchains substitute for trust"
- "Blockchains replace intermediaries with mathematics"
- "Blockchains introduce digital scarcity"
- "Proof-of-work incentivizes consensus instead of enforcing it"
- "Decentralized code cannot be altered or shut down"
- "Smart contracts dis-intermediate the intermediaries"
- "Smart contracts allow for new markets by forcing honesty [in markets which were previously too small to control]"
- "A blockchain transfer is very fast to finality [as opposed to verification that the payment occurred which most systems excel at today]"
- "Blockchains commit state very slowly"
- "Ethereum is a chain for everyone, hardened for public exposure, designed for interoperability and openness first"
- Slow and steady wins the race
- Small-minded people scorn what they can't have
- The wicked often fall into their own traps
- You cannot believe a liar even when he tells the truth
- Too-powerful neighbours should be avoided, for in a quarrel, the weaker suffers
- Those who play jokes on others must expect them in return
- Friend's fights are their enemies' opportunities
- The tyrant always finds an excuse to injure the innocent
- Changeable people are not easily satisfied
- Persuasion is better than force
- There are always others worse off than you
- A bird in the hand is worth two in the bush
- Deeds, not words
- Example is better than precept
- No situation is so bad it can't be turned to someone's profit
- More treasure than gold can be found beneath the sun
- There's more than one way to bait a trap
- Your own eyes may be your best witness
- Give assistance, not advice, in a crisis
- To thine ownself, be true
- To each his own
- Utility is most men's test of worth
- They complain most who suffer least
- Do not attempt too much at once
- Beware of those who wish to bring you down, not up
- Sometimes the slow ones blame the active for the delay
- The blame doesn't always lie in the obvious
- Nobody can judge his own worth
- What is worth most is often valued least
- If you grasp at the shadow, you may lose the substance
- The farthest you go is with using your own gifts
- Many a service is met with ingratitude
- One man's pat is another's swat
- Don't play both sides against the middle
- He who gives in to other's wants will have no principles of his own
- Advice from the greedy is best ignored
- Thoughtless friends can be as bad as enemies
- Goodness is the greatest strength of all
- Be content with what you're sure of
- Respect the wisdom of those who came before you
- When the rich surrender the rights of the poor, they endanger their own privileges
- You can look at the stars, but watch where you're going
- Advantages that are dearly bought are doubtful blessings
- Think twice before you act
- Be happy with what you have
- Flattery should get you nowhere
- Our own vanity is our worst flatterer
- The other fellow's plate always looks fuller than our own
- It's easy to cry "coward" when it's not you in danger
- Some people find fault even with the things that benefit them
- Misfortune awaits those who love unwisely
- When you hit back make sure you have the right man
- There is no virtue in giving to others what is useless to oneself
- Live and let live
- Better a certain enemy than a doubtful friend
- The enemy you know is better than the enemy you don't
- Clothes do not make the man
- Appearances are very often deceiving
- It's easy to fight someone who can't fight back
- The flower in the vase smiles, but it can no longer laugh
- Those who pretend to be something they are not only make themselves ridiculous
- Unused riches create no good
- Vengeance may be worse than the deed that provoked it
- It's far better to bend than to break
- We may often be more important in our own eyes than in the eyes of others
- Better poverty without a care than wealth with its many obligations
- Nature never disobeys her own laws
- Necessity is the mother of invention
- One man's meat is another's poison
- Those who live by thievry can't complain of robbers
- Position is everything in life
- There are two sides to every question
- There are two sides to every truth
- To everything there is a season, and a purpose
- Friendship is a hedge against adversity
- That governs best which governs least
- In union is strength
- The advice of an enemy is not to be trusted
- Much wants more and loses all
- The greedy never know when they have had enough
Author: Pieter Hintjens
- Programming is science dressed as art
- "The science of programming: make building blocks that people can understand and use easily, and people will work together to solve the very largest problems"
- New software crisis (is it still one?): creating connected applications is incredibly costly (and centralized)
- To fix the world, with science: solve how to connect code, and give the solution to people in the simplest way possible
- "Classy programmers share the same motto as classy hit men: always clean-up when you finish the job"
- "Software dies, but community survives"
- Large-scale and long-lasting software usually goes hand-in-hand with a flourishing free software community behind it
- "Software is about people"
- Software architecture:
- "How we organize is more significant than who we are" --> processes, coordination
- We're bad at understanding complexity, but good at working together to divide and conquer large problems
- Psychology:
- Stupidity: we're all stupid at some point; simplicity beats functionality
- Selfishness: we're all selfish, so the architecture has to leave room for people to express their selfish acts
- Laziness: we make lots of assumptions, and most of them are wrong; test these early and cheaply
- Jealousy: we're competitive and like to prove others wrong; the architecture should provide space for open competition (to get the best result)
- Fear: we're afraid of being embarrassed and failing; the architecture should be easy and cheap to silently experiment
- Reciprocity: rules should enforce how people work together, and what to avoid
- Conformity: establish clear, documented, and efforced patterns and you'll get people following them
- Pride: allow attritibution, as we're all silent egoists
- Greed: value must flow to all producers, either that be reputation, money, etc; think of the architecture as a economic marketplace
- Collective works usually have two outcomes:
- Failure, at which point everyone stops caring, or
- Success, at which point everyone vies for control and power
- (Worth trying) providing upfront terms of conflict settlement makes conflict less likely
- Projects with GPL licenses are allowed to fork and re-merge, whereas BSD (including MIT, Apache, etc) do not allow re-merging, potentially killing projects that have fall-outs
- BSD licenses were meant to be non-profitable and leaky, given to the masses at under cost for adoption
- "The license we choose modifies the economics of those who use our work"
- Closed source makes people see you as an enemy, BSD makes them see you as a free lunch, and GPL as allies (if they try to run off with it, you can always remerge theirs into your original project)
- Interesting views on the Github fork/PR model with GPL
- Allow others to become owners and be empowered that way
- Forks allow for experimentation and competition; branches give too much power to maintainers and are more complex to manage
- Community needs:
- Symbolic leadership for easy, authoritative conflict resolution (or forking)
- Rules and processes that are enforced
- Financial backing
- A market to connect experts with customers for support, integration, etc.
- "Going fast in the wrong direction is not just useless, it's actively damaging"
- Development:
- Identify problems and then make minimal, accurate solutions to these problems
- Publicly explain the problem, why it's a problem, and how to solve it, giving others the chance to review and correct
- Patents and ideas: you shouldn't be able to "own" an idea, only the manifestation of one (the real work put into giving life to an idea)
- "You need a goal that's crazy and simple enough to get people out of bed in the morning"
- Transparency -> trust -> scale
- Interesting views on innovation:
- No lone geniuses, but continual acceptance of good solutions crowd sourced and disposal of bad ones (market competition)
- Individual creativity matters less than process
- Processes should be able to replace road maps, given competition favours better solutions
- Solutions are discovered, not invented
- Intelligence is social, even if it feels individual
- Size and diversity of the community speed up processes for discovering problems and solutions
- Design processes:
- Trash-oriented design: prioritize Brilliant Ideas, create grand designs irrespective of actual problems, work the engineers, and agressively market
- Complexity-oriented design: high cost means more value, so increasingly complicated architectures and features are taken for granted to provide more value (despite usually decreasing value)
- Obsessively solving the wrong problem in collective delusion
- Instead of asking "What if someone wants to do X?", ask "What is the real value of solving Y?"
- If you make stuff nobody asks for, you're probably wasting your time (although I'd say it depends on if you have a vision for what you're doing rather than technical masturbation)
- Solving simple problems usually is more valuable than solving really hard ones -> engineers like to focus on the most interesting but least worthwhile
- Simplicity-oriented design: end result is fluid through rapid, incremental stages of work, starting from an evaluation of a set of interesting problems for their worths and solving the most important, at any given time, with a brutally minimal solution (Minimal Plausible Patch)
- Always ask: "Can it be done simpler?"
- Judge simplicity by the number or difficulty of concepts someone new needs to learn (or guess)
- "Design is about removing friction in the use of a product"; good designers notice annoyances and thinks about how to smooth them
- My default state is likely best described as a "Canary Watcher": watch for pain, figure out why, and make it better; "people should feel joy in their work"
- On Sun Tzu quotes: " It's hard to be angry at a Chinese general, especially when he has been dead for 2,400 years."
- "Do not invent concepts. The job of a designer is to remove problems, not add features."
- On using code generators for model generation:
- Use it only where you would otherwise be writing tiresome code by hand.
- Design natural models that are what people would expect to see.
- Write the code by hand first so you know what to generate.
- Do not overuse. Keep it simple! Do not get too meta!!
- Introduce gradually into a project.
- Put the generated code into your repositories.
- "There's a joke about UDP but sometimes you'll get it, and sometimes you won't." 😆
- "Some cultures teach us to aspire to perfection and punish mistakes in education and work, which makes this attitude [avoiding failure] worse. To accept that we're fallible, and then to learn how to turn that into profit rather than shame is one of the hardest intellectual exercises in any profession."
Author: Julia Lovell
See notes in book
Author: Richard P. Feynman
See notes in book
Author: Benjamin Franklin
See notes in book
Author: Pankaj Mishra
See notes in book
Author: Wang Hui Translator: Michael Gibbs Hill
See notes in book
Author: William B. Irvine
See notes in book
Author: Yuval Noah Harari
See notes in book
Author: David Kushner
- Build an empire, or just build good code?
See notes in book
Author: Mortimer J. Adler, Charles Van Doren
- The Activity and Art of Reading
- Knowledge is a prerequisite to understanding, but we do not need to know everything to understand something
- Modern media (e.g. TV) are designed to make thinking seem unnecessary (not true!)
- Zombie play-back state of opinions in people vs. critical thinking
- The more active the reading, the better (i.e. more thinking and analysis; see later)
- Receiving communication is not entirely passive; writers and readers work together to send and receive information
- Note the difference between reading for information vs reading for understanding
- What vs. why, how, meaning, and relations to other information
- If you understand everything in the book perfectly from the start, you might have only gained information
- Going to work on a book: work from a state of less understanding to one of greater understanding using only your own mind
- Understanding: new perspectives or intelligence that casts new light on all information related
- Widely read vs well read
- Learning via instruction (aided discovery) vs discovery; reading is former but exercises same skills as latter
- Learning via an absent teacher
- The Levels of Reading
- Levels:
- Elementary: illiterate to literate
- Inspectional: reading with time bound; get the most out from a time bound; examine the surface of a text
- Analytical: best, most thorough reading you can complete given unlimited time
- Syntopical: understanding common themes and topics from multiple sources
- If you don't inspect a book, you have to build both a superficial knowledge of the book as well as an understanding at the same time
- Levels:
- Elementary Reading
- First have to master elementary reading before being able to read on higher levels
- Inspectional Reading
- Systematic skimming
- Discover whether the book should be read, and at which level
- Look at:
- Title page and preface
- Table of contents
- Index
- Publisher's blurb
- Chapters that seem pivotal to main points, and their opening and closing summaries (if any)
- Dip in and out for a few paragraphs and pages, and epilogue (if one)
- Superficial reading
- In reading a difficult book, do a superficial reading first; go through without stopping to look up or ponder on ideas you don't understand
- You'll grasp it much better on a second reading
- Getting distracted by too many things detracts from the whole picture and understanding
- Don't miss the forest for the trees!
- If you speed read, you should also know what to speed read and what to spend time on
- Not all books are equal; nor should they be read equally
- Not all parts in a book are equal as well
- Know which parts should be read slowly for proper comprehension
- Know what to look for (and what you're looking for), and when you've found it
- Speed reading is reading at the speed of your mind, rather than your eyes (mental vs physical)
- "Every book should be read no more slowly than it deserves, and no more quickly than you can read it with satisfaction and comprehension"
- Systematic skimming
- Inspectional Reading 2
- Be a demanding reader, keep your mind on the goal: understanding and growing from reading
- Ask questions while you read, and try to answer them as you read (make it a habit!)
- Creating understanding from a book means asking yourself questions as you read
- Ask no questions = get no answers
- Questions for active reading:
- What is the book about, as a whole?
- What is being said in detail, and how?
- Is the book true, whole or part? (Needs first two; make your own decision, not just the author's)
- What of it (new understanding)? Why is it important, what follows, is suggested, etc?
- Need both the will and the skill to demand more from reading, otherwise it'll just be frustrating
- "Elevate yourself by mastering what at first sight seems to be beyond you"
- Write answers in the book as you read
- Thinking tends to express itself in words
- "Reading a book should be a conversation between you and the author"
- Try to summarize and outline the author's points
- First, take notes of the structure of a book:
- What type is it, what of it, and how is it structured?
- Then, take conceptual notes:
- What are the truths? What of them?
- When reading syntopically, you can takes dialectal notes (see Part 4): a communal discussion taken by all the authors
- Art and skill are formed by operating in accordance to rules
- Pigeonholing a Book
- Rule 1: You must know what type of book you're reading, and should know this as early as possible
- Sometimes this can be hard to tell apart (e.g. fiction from nonfiction)
- You can (and should try to!) infer a lot from just a book's title
- Know not only the grouping, but what the grouping means (and how it differs against other groupings)
- Practical vs. theoretical
- Practical: what works, and how
- Theoretical: something to be seen and understood
- Knowledge vs application (that vs how)
- Fact (truth) vs judging, giving opinions, and persuading
- Theoretical:
- History: specific events in a single time and space
- Science: laws of generalizations
- Philosophy: similar to science, but falling into daily, routine experiences (armchair thinking)
- Different types of books (and authors) will frame arguments and facts differently
- We should read them differently as well
- Rule 1: You must know what type of book you're reading, and should know this as early as possible
- X-raying a Book
- "Every book has a skeleton hidden between its covers." -- your job is to find it
- Rule 2: State the unity (theme) of a whole book in a single sentence, or at most a paragraph
- What is the author up to; what is he trying to do?
- "Feeling" it is not good enough; state it!
- Only you can formulate the unity of a book for yourself; take the author's hints and help, but do not rely on them
- Rule 3: Set forth the major parts of the book, and show how these are organized into a whole, by being ordered to one another and to the unity of the whole
- The author is architecting the structure of the book, and unifying many independent ideas into a whole
- "Unless you grasp the organization of its parts, you cannot know the whole comprehensively"
- Make your own outline based on your own understandings and groupings; you do not have to follow what the author has given you (e.g. chapters)
- Rule 4: Find out what the author's problems were
- What did the author question himself (which are primary and secondary? which are priorities?) when he began the book? What did he want to answer?
- Theoretical questions:
- Does something exist?
- What kind of thing is it?
- What caused it to exist, or under what conditions can it exist, or why does it exist?
- What purpose does it serve?
- What are the consequences of its existence?
- What are its characteristic properties, its typical traits?
- What are its relations to other things of a similar sort, or of a different sort?
- How does it behave?
- Practical questions:
- What ends should be sought?
- What means should be chosen to a given end?
- What things must one do to gain a certain objective, and in what order?
- Under these conditions, what is the right thing to do, or the better rather than the worse?
- Under what conditions would it be better to do this rather than that?
- Understanding the organization of a book is the effort of understanding how and why you've come to the theme of a book
- "The best books are those that have the most intelligible structure."
- "To recognize [plot tropes] is to learn what it means to say that there are only a small number of plots in the world"
- Difference between good and bad plots, then, is how the author dresses it up
- "Most readers cannot read outlines" ;)
- Writing guideline: "A piece of writing should have unity, clarity, and coherence"
- Coming to Terms with an Author
- Ideal towards both writer and reader: unambiguous conversation
- Rule 5: Find the important words and through them come to terms with the author (understand the same meaning he is trying to convey)
- Interpret language, and look beyond it to the ideals behind words
- Words can have many different contextual meanings; it's important to grasp which ones the author places importance on (in which context), and why
- The most important words are likely those that give you trouble, that make it difficult to understand what the author is talking about otherwise
- The author may give you help by defining, or stressing certain words
- Look for each field's technical vocabulary
- Don't be a non-active reader!
- Find out if the word is meant to have one or many meanings, what the relations between the meanings is, and why the author switches them
- Note that words can have multiple meanings, but that multiple words may have the same meaning (synonyms)
- Determining an Author’s Message
- An author declares his judgement about something through his words; a declaration of knowledge
- These are just personal opinions unless they are supported (and even then, those justifications may be personal)
- An argument is always a set of statements stating the argument and its supporting rationale
- Interpreting moves upwards; it goes from words, to terms, to phrases, to prepositions, to paragraphs, etc.
- Outlining and interpretation meet at the level of prepositions and arguments
- Notice the difference between a grammatical unit of language (sentence, paragraph) versus a logical unit (preposition and argument)
- Break down complex sentences into their major ideas so that you can discern what's being conveyed and what to judge
- "So long as words, sentences, and paragraphs are opaque and unanalyzed, they are a barrier to, rather than a medium of, communication. You will read words but not receive knowledge."
- Rule 6: Mark the most important sentences in a book and discover the propositions they contain
- Similar to words, those that require an effort of interpretation are likely to be important
- You are likely to have the most difficulty with the most important concepts
- Important words often lead to important propositions
- They must be premises or conclusions related to the main theme of the book
- "The heart of [the author's] communication lies in the major affirmations and denials he is making, and the reasons he gives for so doing"
- If you treat everything as the same, read at the same speed and care, "that usually means [to you] that everything is equally unimportant"
- Pause for the sentences that puzzle you, not the ones that interest you
- State propositions made in your own words
- Don't mistake thought or knowledge for words
- Find examples in your own life (or imagine them) that are related to the propositions made
- Propositions relate to the actual world we live in
- Similar to words, those that require an effort of interpretation are likely to be important
- Rule 7: Locate or construct the basic arguments in the book by finding them in the connection of sentences
- Search through paragraphs or larger grammatical constructs to find sentences to piece together an argument
- "If the book contains arguments, you must know what they are"
- Discriminate between inductive and deductive logic
- Find the underlying assumptions for the argument
- Rule 8: Find out what the author’s solutions are
- Are there any he failed to solve? Does the author acknowledge them?
- Don't mistake the author's world for his ideas; look through the (perhaps outdated) world to what he wants to express
- An author declares his judgement about something through his words; a declaration of knowledge
- Criticizing a Book Fairly