Link Search Menu Expand Document
Max Learning FI

Notes | Tutorial 50

Date: 2020-10-26

thoughts on error msgs

  • 7.19
  • not enough detial to know
  • infinitely many alts - “what would system be like”
  • building on stuff that’s not clear enough

  • no concretes about what i”m thinking about

  • had specific ctx in mind - not stated
    • overly broad; over gereralisation
    • mix and match contexts
  • if there’s plenty of critical feedback on good qual stuff, dw as much about lower qual stuff.
  • communicate to readers that things are low-qual if they are; b/c otherwise ppl presume high-qual

no conflict of interest

  • objective truth, so we end up converging if we’re ~rational

  • time traveller sitch

virtue of selfishness - conflicts of mens interests

  • two ppl applying for the same job example

https://www.elliottemple.com/essays/liberalism#harmony-of-interests

2018 ish ET swithcing away from liberalism project

project planning

  • lots of ppls plans too vague
    • what would be useful, prereqs, etc

digipol

  • goal/purpose: allow voters to …
  • components (repositories): …
    • tech stuff included: flutter/dart, blockchain stuff, AWS stacks, …

method

  • curi’s big project example

  • scrum/agile

  • goldratt warns against breaking stuff down into too-small pieces; ends up micromanagement

planning

  • goal
  • resources
  • requirements

  • “fixed points” - i.e. decisions that have already been made or things we can’t really change

  • what are alternatives / why is this a priority
    • do we need to do this; should this be our project?

  • goal should be linked to a problem it’s solving

  • bigger problem(s):

    • Flux has said “we’re going to make an app to do X” but haven’t made said app
      • putting out fires; not a mission/game plan to get somewhere really good
      • removing a negative instead of working on a positive goal
    • Flux has not demonstrated that it’s capable of doing something like this (note: someone analysing the situation might conclude we could; but it’s not been demonstrated).
      • Why will it succeed?
        • track record – smart contracts done, blockchain+AWS stack done, Flutter UI v0.1 done (not pretty but works)
    • Get’s ppl involved
      • mid level goal/benefit
      • not looking for silver bullet
      • not even claiming it’ll bring massive success
      • just gradual improvement
      • implied: more and more steps that make stuff 10% better
      • goldratt criticises this methodology
        • basically there’s bigger lower hanging fruit
        • focus on thing that matters the most (bottlenecks)
        • find big wins
        • problems can look complex but aren’t
        • solving bottlenecks gives orders of mag benefits, not 10%

    • what are the bottlenecks – this is the only thing that really matters

    • problem: not being able to campaign without foundation. Soln: have an app that works / can show ppl / etc.
    • do we need to do this; should this be our project?
      • parent proj: need to run a campaign
        • do we need to do this; should this be our project?
        • parent proj: get someone elected somewhere
          • do we need to do this; should this be our project?

if you want to make small improvements - why start a new company to do that instead of joining an existing company who’s already in the lead.

new small agile competitor – you need a large competetive advantage over existing players. – depends on size of the goal. advantage matters less for smaller goals

assuming we do the project

  • app has to meet criteria to fit into bigger picture

  • requirements: X, Y, Z

  • details of project itself: timeline, budget, staffing, requirements (goods/services), etc

  • uncertainties

    • e.g. state management of system state – not well defined; issues w/ mutable state; etc.
    • consistent => need an interface that changes them at the same time
      • architecutre risks
    • user adoption - rate? ignore? no one likes it?
    • marketing?
    • UI/UX? In progress

app goals / situations: sell-itself vs adequate-for-users-to-achieve-X

Supposed to be part of competetive advantage? Or necessary thing to focus elsewhere?

recap so far

  • we need problems, goals, solutions all laid out clearly
  • list requirements, details, uncertainties
    • uncertainties are potentially new problems - can deal with recursively or put in “do later” list
  • anything that’s informing the project plan should be really clear, stuff like the situation the app is designed to exist in (sell-itself vs adequate-meets-some-functional-requirement, etc)

goldratt

  • 5 focusing steps & 3 focusing steps
  • current reality tree – it’s not luck
    • then map out cause/effect (c/e) relationships
  • future reality tree w/ goal state
  • transition tree
    • objections to transition - how do we address those?
  • method for curr reality tree
    • list 12 problems or complaints (about current reality?)
      • start looking for c/e relationships between them
        • connect both directly and indirectly (can add nodes in the middle to connect them)
      • then find root problem (other stuff should be downstream problems)
      • simplicity of reality

smaller picture

  • project plan – make a bunch of claims (we have x resources, these actions will work together to do Y, etc)
  • how can we check those claims are true? how do we test those claims? how can we monitor if things are going wrong? how do we know if we’re wrong? (time delay on finding out?)
    • helps show details and fix them => prevent failure
  • challenge own plan – how do I know that? how am I sure? what have I done to check it?

notes

  • need vision and longer term game plan thing – 8:11pm

  • focus on learning a few things at once
    • issue with checklists – when they need active ongoing consideration
    • pre and post checklist? like super important stuff up front and then lots of check other minor stuff later?
  • can use project planning for small projects like essay

  • can do lots of tiny projects specifically till it’s autopilot

  • should probably learn everything the experts know at some point, worth learning

  • have notes on mostly full method
  • identify the 1-3 things as current targets to autopilot
  • review notes prior to doing activity
  • self-marking criteria
    • important in general for learning: how do I know if it’s right/wrong, how will i tell?
    • judging outcomes => one of most effective things for learning efficiently
  • writing
  • project planning

  • discussions / paths forward

  • with project planning:
    • go through everything and question / doubt it
      • look for failure points
      • don’t be satisfied with “if it might work it is good enough”
      • should take into account all contingencies
      • “grill it”, be demanding, picky, etc

You can leave a comment anonymously. No sign up or login is required. Use a junk email if not your own; email is only for notifications—though, FYI, I will be able to see it.

Comments powered by Talkyard.