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

Open-source advocates have rightly noted that free software is a natural fit for any organization that requires solutions based on open standards, interoperability and re-usable components — key elements of the European Commission’s new digital strategy

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

Flips the idea on it’s head and invites us to explore moments of exclusion by design. Mostly a call to action, nothing prescriptive.

4. A Post Mortem on Growth Hacking

Achieve product market fit through positioning, scalable acquisition channels, ideal org structure, know when to optimise vs innovate and maintain pipeline of user/customer insights

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

Peskin ratio is basically a newfangled memefied term for a failure rate.

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?

Containers contain images which hold the entire information that the containers need to execute. Containers encourage splitting monolithic applications into micro-applications and then setting up communication amongst them. The fundamentals of microservices allow IT teams to only enhance, implement and deploy the required parts of the applications.

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

Pick meaningful names. Names must reveal intent of the code. Names must make meaningufl distinctions. Names must add meaningful context.

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

I spent way too much time on this. Lessons both on interesting tools to make the most of your machine and also lesson design and delivery. Simple and elegant. Quick explanations with examples.

Data Science

1. Browse state-of-the-art

THIS IS JUST A GREAT REFERENCE GUIDE. Inspiration for other community-mapping initiatives

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

Truly inspiring! Ultimately it seems to be about turning what you wish to achieve into a replicable, consistent process. Time to look at some of my goals and turning them into processes.

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

SO MANY BUZZWORDS. yet a lot of questions unanswered. So how does the actual energy move around? Otherwise isn’t it some sort of simulated market? Wouldn’t there have to be some kind of corresponding energy storage grid that is connected globally and you somehow need to track this?

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

Only a matter of time before this came about! The recent block reorganisations could be studied in greater detail here. I think I need to find out what are some important metrics one could try and run on these datasets. I like how he tried the GINI coefficient and the Nakamoto coefficient as measures of decentralisation/ inequality.

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

Blockchain powered voting promising anonymity, transparency, security and instant announcements. Would like to see their smart contract.

5. Kleros’ IICO Analysis

Explains the bits and pieces of the mechanisms that this IICO (interactive-ICO) entails.

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?

Stablecoin is pegged to another stable asset. DAI is pegged to US dollar. User deposits asset into a smart contract as collateral for a loan, generating the equivalent USD value in DAI they wish to borrow.

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

I wonder if there are simpler ways to model these game mechanisms. It would really help draw ups some parameters based on simulations rather than assumptions about the world.

Blockchain-Ethereum

1. Writing Smart Contracts with Solidity > 0.5

Goes into a brief introduction of what are some of the issues that arise from the upgrade (?) noted that there is still a lot to be done for documentaiton. Probably this is due to solidity being a major work in progress.

2. Security Considerations While Developing Ethereum Smart Contracts in Solidity

Great coverage of common issues that can be uncovered by changing patterns and linting

Life Optimisation

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

MostImportantTask — critical task that create the most signifcant results.

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.