14 Matching Annotations
  1. Mar 2021
    1. Title: "goal the use case is trying to satisfy"[23]:101 Main Success Scenario: numbered list of steps[23]:101 Step: "a simple statement of the interaction between the actor and a system"[23]:101 Extensions: separately numbered lists, one per Extension[23]:101 Extension: "a condition that results in different interactions from .. the main success scenario". An extension from main step 3 is numbered 3a, etc.

      Not sure why I find this example so interesting.

      Probably because it is a human-readable outline that uses machine-readable (programming language source code) constructs, namely loops/iteration.

      The format in which this is written in, then, is itself a kind of (high-level, human-oriented) programming language.

      Example:

      • numbered list of steps [introduces/names the loop/iterator/enumeration being done]
        • Step: "a simple statement of the interaction between the actor and a system" [defines the inner part of the loop that gets "executed" once per iteration]
  2. Feb 2021
    1. The golden standard I suppose is set by the rhyme: There is a hole in my bucket, dear Liza, dear Liza. Of course, fixing it requires the use of the bucket at some stage, and so the loop closes.
  3. Oct 2020
  4. Sep 2020
  5. Jun 2020
    1. Note that we are not making the common argument that making new tools can lead to new subject matter insights for the toolmaker, and vice versa. This is correct, but is much weaker than what we are saying. Rather: making new tools can lead to new subject matter insights for humanity as a whole (i.e., significant original research insights), and vice versa, and this would ideally be a rapidly-turning loop to develop the most transformative tools.
    1. Most people think you build the product then you market it. Thinking in loops means you build the marketing into the product. The product doesn't precede the marketing. The product is the marketing.

      By thinking in loops Harry Dry refers to a way of thinking about your acquisition strategy as being part of your product.

      This reminds me of Brian Balfour's idea of product-channel fit and how stresses that the product gets shaped by its acquisition channel.

  6. May 2020
    1. Ericsson claims (2016, p. 98) that there is no deliberate practice possible for knowledge work because there are no objective criteria (so, poor feedback), because the skills aren’t clearly defined, and because techniques for focused skill improvement in these domains aren’t known.

      According to Ericsson deliberate practice for knowledge work is not possible because the criteria are not objective (you don't know if you're doing well).

      This collides with Dr. Sönke Ahrens' contention that note taking, specifically elaboration, instantiates two feedback loop. One feedback loop in that you can see whether you're capturing the essence of what you're trying to make a note on and a second feedback loop in that you can see whether your note is not only an accurate description of the original idea, but also a complete one.

      Put differently, note taking instantiates two feedback loops. One for precision and one for recall.

  7. Sep 2019
    1. forEach() loop other than by throwing an exception. If you need such behavior, the forEach() method is the wrong tool. Early termination may be accomplished with:
  8. Aug 2019
  9. Sep 2016
    1. The success of Arduino has had the perhaps retrograde effect of convincing an entire generation that the way to sense and actuate the physical world is through imperative method calls in C++, shuffling bits and writing to ports, instead of in an environment designed around signal processing, control theory, and rapid and visible exploration. As a result, software engineers find a fluid, responsive programming experience on the screen, and a crude and clumsy programming experience in the world.
    2. But the idea that you might implement a control system in an environment designed for designing control systems — it hasn’t been part of the thinking. This leads to long feedback loops, inflexible designs, and guesswork engineering. But most critically, it denies engineers the sort of exploratory environment that fosters novel ideas.

      On short feed back loops and modelling, this talk from Markus Denker, one of the main architects behind Pharo Smalltalk, can be enlightening: Perfection & Feedback Loops, or: why worse is better