# Is it worth writing about? | notes.eatonphil.com
source: https://ift.tt/czKDOGy tags: #literature #writing uid: 202212112114 —
To practice writing
This is the easiest reason. While practice does not imply improvement, you cannot improve without practice.
Providing variety
When I learn a topic I normally go through dozens of posts, papers, docs, videos or books to find a version that clicks. If I can. I prefer to start with blog posts and often there are not blog posts on the subject. Books, docs, videos, and academic papers aren’t often as accessible.
Even if you’re writing about a popular topic, there’s still a chance your post gets through to someone in a way other posts do not.
To cement understanding
Finally, honest writing forces you to either understand the dark corners of what you’ve learned or to ask for help in these dark corners.
Topics
Some topics I think are always worth writing about and sharing:
- Your process, failures and successes, to figuring something out
- How to hack on some major open source project
- In-depth comparison of projects or approaches, down to source code, benchmarks, and architecture when relevant
- Building minimal versions of some production system
- How some major systems works under the hood, down to the code
- Mistakes you made in structuring organizations, or production architecture, or testing, etc.
# CRDT (Conflict-free replicated datasets) vs total order broadcasting
source: https://ift.tt/qKi0Uxd tags: #literature #programming #distributed-systems uid: 202212112110 —
To run an application from the web, you connect to a server. Since the server is centralized anyway, we can have it enforce a global ordering over the events. That is, every replica receives events in the same order. With this, we can sidestep the need to pay the CRDT complexity tax.
Evan Wallace of Figma writes:
Figma isn’t using true CRDTs […]. CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be. There is some unavoidable performance and memory overhead with doing this. Since Figma is centralized (our server is the central authority), we can simplify our system by removing this extra overhead and benefit from a faster and leaner implementation.
Path #2 in its pure form represents state machine replication. We ensure that each replica receives changes in the same “global” order, and apply change on each replica in that same global order. This ensures that each replica stays in sync, even if change operations are not commutative.
This is total order broadcast, covered in DDIA (https://readwise.io/bookreview/13143902).
5 Things to Do When You Have Too Many Ideas and Never Finish Anything
source: https://ift.tt/Qsqlbg4 tags: #literature #insights #productivity uid: 202212101840 —
As per the diagram above, for every 10 funds added to the array of options, the rate of participation drops by 2 percent. In fact, for those employees who chose to invest, adding more investment choices increased the chances that employees would invest in more conservative funds.
This is the paradox of choice. More choice often leads to less action. The more ideas and goals we pursue, the less likely we’ll follow through on any one of them. And vice versa.
- Create mini-deadlines.
The more time it takes to complete a task, the greater the likelihood that we fall victim to ‘Parkinson’s Law,’ which states that, work expands to fill the time available for its completion.
Use the 80-20 rule 202212291608
Trust your gut.
Often, we hesitate to get started and take action on ideas, because of the fear of failure, rejection and self-doubt. Countless hours are spent researching and planning to take action, but when it comes time to jump ship, we stay on the boat and fail to follow through on our plans.
- Develop the habit of finishing.
Many people have mastered the art of starting, but few have built the habit of finishing. Starting is easier than finishing, but the bulk of the results we seek, lie at the finish line.
Practice Quitting.
Contrary to popular opinion, the most productive, successful people, quit on their goals all the time—they just know what to quit and when to do so.
The upside of quitting is that you redirect time and energy wasted on an unfruitful idea or goal, towards another more rewarding venture.
# Three Things I’ve Learned About Bayes’ Rule
source: https://ift.tt/dK5Hq3u tags: #literature uid: 202212101128 —
In the context of Bayes theorem 202212092211
Update Multiple Hypotheses
I tend to tell stories about evidence that cause me to under-update. For example, suppose I think I’m good at essay writing, but I am struggling to write a particular essay. The story I tell myself is, “I guess this essay was harder than I thought.” This story might be accurate, but it ignores that struggling is also evidence that I’m worse at writing than I thought.
Conditioning is Critical
I once read a story about someone (let’s call them Jane) trying to determine whether two people were courting. Jane observed the pair both going to a museum and having dinner. Jane estimated the prior odds that these people were courting at 1:20 and the odds ratios of “going to a museum” and “having dinner” to both be 10:1, arriving at a posterior of 100:20, or 5:1. The pair turned out to be siblings.
In theory, it is not a mistake to assign a high probability to a given false statement; it does suggest, however, that a mistake was made. Jane made a mistake in reasoning — subtle but damning. The first odds ratio Jane estimated was for “the pair went to a museum.” The second ratio Jane estimated should not have been for “the pair went to dinner”; it should have been for “the pair went to dinner, given that they had already gone to the museum.” The mistake Jane made was forgetting to condition when considering dependent pieces of evidence properly.
# Think real hard
source: https://ift.tt/hAVulo8 tags: #literature #insights #selfgrowth uid: 202212101100 —
When I started programming professionally, I was really excited about figuring out how to become a better programmer. (I still am!) So I asked a lot of people, “how can I become a better programmer?” But nobody gave me very satisfactory answers. They would tell me to play around with obscure programming languages, or study algorithms, or read papers, or do a bunch of other stuff that felt tangential and didn’t really move the needle.
That’s my preferred reading of the Feynman Algorithm: there is no one weird trick.
On the other hand, I have gotten a ton better at programming in the last four years. Not through any specific piece of advice, or any weird trick. Rather, it’s come by constantly trying to learn small new things, make small tool improvements, make my models a little deeper, work a little faster, come up with slightly better ideas. By, literally, thinking real hard, for a long, long time. The Feynman Algorithm works!
Bayes Theorem
Source: https://arbital.com/p/bayes_rule/
If H_i and H_j are hypotheses and e is a piece of evidence, Bayes’ rule states:
Waterfalls are one way of visualizing the “odds form” of “Bayes’ rule”, which states that the prior odds times the likelihood ratio equals the posterior odds. In turn, this rule can be seen as formalizing the notion of “the strength of evidence” or “how much a piece of evidence should make us update our beliefs”.
More generally, suppose we have a medical test that detects a sickness with a 90% true positive rate (10% false negatives) and a 30% false positive rate (70% true negatives). A positive result on this test represents the same strength of evidence as a test with 60% true positives and 20% false positives. A negative result on this test represents the same strength of evidence as a test with 9% false negatives and 63% true negatives.
uid: 202212092211 tags: #insights