this repo has no description
docs: ✏️ Add insights on smart contracts, blockchain incentives, and team diversity
- Enhanced the definition of smart contracts to include human rights enforcement.
- Noted the undesired consequences of blockchain incentives like Bitcoin's energy consumption.
- Emphasized the impact of diversity on collective intelligence.
- Added external resources on consensus, system complexity, and software laws.
+7
-2
+2
Blockchain.md
+2
Blockchain.md
···
12
12
- Fungible (there isn't a difference between two items. eg. storing files). All the coins are mutually interchangeable.
13
13
- The resource can be provided by a lot of people.
14
14
- Smart contracts can be defined as code that's replicated and executed on all the blockchain nodes.
15
+
- You can encode "human rights" in a smart contract and the contract will enforce them.
15
16
- Smart contracts allow permissionless composability. [Composability allows anyone in a network to take existing programs and adapt or build on top of them, it unlocks completely new use cases that don't exist in our world](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/).
16
17
- [Blockchains could replace networks with markets](https://twitter.com/naval/status/877467629308395521).
17
18
- One of the main downsides of blockchains is that most humans are not good at protecting their passwords, credentials or private keys.
···
19
20
- Blockchains solve distribution problems but they don't solve the problem of who will add the money to the ecosystem. That's a political one. Unless there are good incentives to move to blockchains.
20
21
- Once a system moves to a blockchain, it'll get its properties (e.g: transparency and verifiability).
21
22
- Open source has the failure mode of not enough incentives, cryptocurrency has the failure mode of excessive and overly concentrated incentives.
23
+
- Blockchain incentives can have large real world undesired consequences. E.g: Bitcoin incentivizes miners to use a lot of energy.
+1
Coordination.md
+1
Coordination.md
···
37
37
- We are individuals, with different talents, predispositions, and backgrounds.
38
38
- The idea of "structurelessness" does not prevent the formation of informal structures, it becomes a way of masking power.
39
39
- Make the group structure explicit, not implicit. The rules of decision-making must be open and available to everyone, and this can happen only if they are formalized. Having an established process for decision-making ensures that everyone can participate in it to some extent.
40
+
- [The more you need consensus, the less work you can do](http://hintjens.com/blog:100).
+3
-1
Programming.md
+3
-1
Programming.md
···
16
16
- Write code that's easy to delete.
17
17
- If you can't easily explain why something is difficult, then it's incidental complexity, which is probably worth addressing.
18
18
- Reuse [patterns](https://www.digitalocean.com/community/tutorials/gangs-of-four-gof-design-patterns).
19
+
- The number of moving pieces on average doubles every 18-24 months. No one fully understands [[Systems]].
19
20
- **Do one thing and do it well**.
20
21
- By focusing on a single task, a program or function can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and a lack of flexibility. [Good software makes hard things easy](https://medium.com/s/story/notes-to-myself-on-software-engineering-c890f16f4e4d).
21
22
- Design composable primitives.
···
53
54
- Doing 100% of anything is difficult. [Don't focus on perfection](https://youtu.be/pYIho556BS8).
54
55
- Focusing in the 80% is far more efficient and cost-effective. "Better" is the enemy of "good".
55
56
- Handle the 80% and let the 20% fend for themselves.
56
-
- [[Pareto Principle|80% of the impact comes from 20% of the work]].
57
+
- [[Pareto Principle|80% of the impact comes from 20% of the work]]. If shitty code solves the problem, it's not shitty code.
57
58
- [Software is never finished, only abandoned](https://stackoverflow.blog/2020/02/20/requirements-volatility-is-the-core-problem-of-software-engineering/).
58
59
- **Treat all the data as an [append only event log](https://www.youtube.com/watch?v=ZQ-MdKj3BjU)**.
59
60
- Use a central log where consumers can subscribe to the relevant events.
···
78
79
- [Engineering Axioms](https://martinrue.com/my-engineering-axioms/)
79
80
- [CUPID](https://dannorth.net/2022/02/10/cupid-for-joyful-coding/)
80
81
- [Things they didn't teach you about Software Engineering](https://vadimkravcenko.com/shorts/things-they-didnt-teach-you/)
82
+
- [Amdahl to Zipf: Ten Laws of the Physics of People](http://hintjens.com/blog:100)
81
83
82
84
## Resources
83
85
+1
-1
Teamwork.md
+1
-1
Teamwork.md
···
157
157
- The team is staffed adequately and work is evenly distributed.
158
158
- The team, overall, has the level of functional expertise required to do the work, and a reasonable number of stretch goals are available.
159
159
- Conflicts are resolved in a fair and respectful way.
160
-
- Diversity is represented and embraced; a broad spectrum of views are considered.
160
+
- Diversity is represented and embraced; a broad spectrum of views are considered. Diversity is not a political slogan. It's the basis for collective intelligence.
161
161
- Progress and set backs are regularly communicated to key stakeholders.
162
162
- When collaborative projects are completed, credit is shared among the contributors.
163
163
- Management is prediction. In order to run a team well, you need to be able to predict the outcomes of your team actions.