Hum Qing Ze

Feb 10, 2019

9 min read

Notes from 5/2–11/2/19

A bit of a slow read but surprisingly useful for upcoming work! I find that the accidental theme for this week is about solving problems effectively through different means such as organisations, mental models or tools.

1. If Software Is Funded from a Public Source, Its Code Should Be Open Source

Moving to open-source solutions does not guarantee that personal data will not leak out, but it does ensure that the problems, once found, can be fixed quickly by government IT departments — something that isn’t the case for closed-source products.

It seems that open source models are finally being embraced by governments. I wonder how the landscape will shift in the next 10 years. If open source projects might become publicly funded and available things would be so much more.. democratic.

2. David Kelley on the 8 Design Abilities of Creative Problem Solvers

Such a great cheatsheet for the right mindset when doing design work

3. What We’re Leaving Out of the Discussion Around Inclusive Design

4. A Post Mortem on Growth Hacking

5. What comes after open source?

Because of the permissionless nature of open source code, software tools benefitted from combinatorial innovation and evolved quickly.

First, a community of inventors must be interconnected through communication technology (language, writing) so ideas can flow widely and efficiently. The presence of a culture of sharing allows ideas to be challenged and refined (scientific method, peer review), and for the strongest ones to rise to the top.

Participation in a global marketplace for ideas (capitalism) provides the incentives for inventors to compete, driving innovation.

But all of these together are complex systems. Complex technology naturally leads to modularity. Specialists subdivide and conquer that complexity to improve the building blocks, creating fractal competition.

Over a service’s lifespan, the utility of its code begins to diverge with the utility of its state.

State compounds and becomes more valuable superlinearly. Code, while crucial for the stable operation and evolution of a service, becomes less important and necessary to defend.

As crypto networks evolve, they are likely to provide strong incentives to unlock further state and create open services in many areas dominated by closed ones today. Open services powered by crypto networks will present unprecedented opportunity for a new generation of developers and entrepreneurs to innovate.

Open services… using the idea of a shared state…

Systems

1. Defining the Peskin Ratio, and why (some) scooter networks fail

But wow okay scooters are so dangerous here in SF. I suppose Grab is doing a pretty good job so far choosing a controlled roll out strategy.

2. What Is Containers Architecture?

So a container is basically finding a way to isolate but use shared resources on your application. Then because it’s isolated you can just plug and play or restore to older versions. It’s more efficient because it just has what it needs to run what you need.

3. A novel approach to onboarding

This totally describes so many of my personal processes. Key to identify which points to take on and tackle them one by one.

4. Defining the “Design mindset”

“Engineers are trained to think logically. As a result, they come to believe that people must think this way, and they design their machine accordingly. When people have trouble, the engineers are upset, but (…) the problem with the design of most engineers is that they are too logical. We have to accept human behaviour the way it is.”

To provide good answers, the designer need to frame good problems. To frame good problems, the designer shall gather relevant information. To gather relevant information, the designer shall listen and ask good questions.

Ironic that we are given the opportunity and education to do all this and yet the school’s frontline staff seems to be the main bottleneck.

Computer Science

1. Effectively Naming Software Thingies

Avoid mental mapping. Use conventions for common operations.

Don’t add additional info that have no meaning. Avoid comments.

Avoid related words that mean too much to each other.

“Programs are meant to be read by humans and only incidentally for computers to execute” — Donald Knuth

I think principles like this can always help anyone who does product design. I’ve found that a great name sticks and signals intent to the user.

2. Hacker Tools

Data Science

1. Browse state-of-the-art

2. What I Learned from Writing a Data Science Article Every Week for a Year

Blockchain

1. Building Confidence, Not Dapps

Your dapp should teach me the things I need to know in order to use your dapp successfully and with confidence. People need to know whythey are doing something, not just what they are doing.

Crux is basically… user-oriented design! It’s about helping users cross the usability barrier and gain some sort of mastery over the program that you are creating to allegedly solve their issue.

Should take the time to test usability of different security tools as landscape mapping

2. Ewald Hesse, Energy Web Foundation

Came across EWF a while back but I’m really amazed at how far they have come. It’s so difficult yo concoct a viable blockchain business strategy but they seem to have something here.

3. Analyzing Ethereum Classic with Google BigQuery

4. Second-Largest Korean Political Party to Implement Blockchain for Member Processes

5. Kleros’ IICO Analysis

Don’t see what the particular advantage is in this ICO other than greater flexibility to customers to withdraw money if they feel sufficient regret.

6. What is DAI, and how does it work?

So with that happening, Maker voters govern the DAO that maintain the value of the currency. The Target Rate Feedback Mechanism isn’t really explained how it works, except that it’s suposed to correct prices when they become out of whack.

7. THERE’S NO GOOD REASON TO TRUST BLOCKCHAIN TECHNOLOGY

In it, I listed four very general systems our species uses to incentivize trustworthy behavior. The first two are morals and reputation. The problem is that they scale only to a certain population size. Primitive systems were good enough for small communities, but larger communities required delegation, and more formalism. The third is institutions. Institutions have rules and laws that induce people to behave according to the group norm, imposing sanctions on those who do not. In a sense, laws formalize reputation. Finally, the fourth is security systems. These are the wide varieties of security technologies we employ: door locks and tall fences, alarm systems and guards, forensics and audit systems, and so on.

This is the OG trust system

In his 2018 book, Blockchain and the New Architecture of Trust, Kevin Werbach outlines four different “trust architectures.” The first is peer-to-peer trust. This basically corresponds to my morals and reputational systems: pairs of people who come to trust each other. His second is leviathan trust, which corresponds to institutional trust. You can see this working in our system of contracts, which allows parties that don’t trust each other to enter into an agreement because they both trust that a government system will help resolve disputes. His third is intermediary trust. A good example is the credit card system, which allows untrusting buyers and sellers to engage in commerce. His fourth trust architecture is distributed trust. This is emergent trust in the particular security system that is blockchain.

This is the ‘new’ trust system.

Does the blockchain change the system of trust in any meaningful way, or just shift it around? Does it just try to replace trust with verification? Does it strengthen existing trust relationships, or try to go against them? How can trust be abused in the new system, and is this better or worse than the potential abuses in the old system? And lastly: What would your system look like if you didn’t use blockchain at all?

Key questions to consider when thinking of blockchain usage.

In between, the article mentions that the issues blockchain solves are essentially manufactured/blockchain-specific and doesn’t warrant adoption for most organisations.

I suppose the big questions is how do we find some sort of usage that can parallel that core properties of a specific blockchain platform?

8. An Ultimate Guide to Crypto-Economics

Blockchain-Ethereum

1. Writing Smart Contracts with Solidity > 0.5

2. Security Considerations While Developing Ethereum Smart Contracts in Solidity

Life Optimisation

1. Never feel overwhelmed at work again: how to use the M.I.T. technique

Clear that and you can consider it a productive day. I think applying a bit of strategy and schwerpunkt to your work is highly useful.