• [[work]]
• [[flancia]]
  • [[agora]]
    • [[abra]] recipe?
  • [[social coop]]
    • [[mediawiki migration]]

• [[Niche]] [[market]] [[problem]] [[detection]]:
  • Who is [[asking]] for help with a problem? Which experts are asking for help with a problem? Who is helping them?
  • Who is asking for [[solutions]] to a problem they think they will face in the [[future]]? collapsed:: true
    • What are the common [[recommendations]] they get?
      • Who is recommending?
      • How do people react to them when they are openly selling something?
      • Is there follow-up on recommendations?
      • How do [[people]] [[pay]] for a recommended [[solution]]?
        • How much do they pay?
  • What is their [[workflow]]?
  • What [[hacks]] are they using to patch the [[problem]]? collapsed:: true
    • Is there a Google Doc doing something that would be better served by dedicated [[software]]?
  • What are they [[hiring]] for?
  • [[Ask]] them about what is getting in their way.
  • Look out for [[complaints]] about [[boredom]] or tedium, because they indicate a [[problem]] with [[friction]] that impacts [[time]].
  • Resource [[costs]]- how could resources be freed? collapsed:: true
    • [[Expense]], [[money]] complaints. Are the wrong people working on wrong things?
  • [[Mask]]-related complaints: wanting to be someone. [[Status]] or [[autonomy]]. Ways to show they are [[trust]]worthy, ways to show off their [[skills]], and ways to [[show]] they [[belong]] to a [[group]].
  • [[The Eisenhower Matrix]] can be used to determine [[urgency]], similar to a [[triage]] [[priority]]. collapsed:: true
    • [[Awareness]] of the [[Problem]]: collapsed:: true
      • Problem unaware
      • problem aware
      • [[Solution]] aware
      • [[Product]] [[aware]]
      • Most aware
  • Where do people go out of their way to [[avoid]] things that they wouldn't call a [[problem]]?
  • Adherents [[avoid]], starters [[solve]]. collapsed:: true
    • What is in your way?
    • What is a [[pain]] to do?
    • What is annoying?
  • What [[block]]s you from doing your job properly?
  • What is pointless to do?
  • What parts of your [[skill]] do you want to improve?
  • What are you putting off [[starting]]?
  • How do you [[show]] that you are an [[expert]]?
  • How can you [[help]] others [[win]]? collapsed:: true
    • Do you [[celebrate]] wins?
  • What do others [[see]] of what you do?
  • What is in the way of your next [[win]]?
  • What do you have to do to [[climb]] the next step of the [[hierarchy]]?
  • What would make you feel [[safe]]?
  • What [[challenge]] did you [[overcome]] in [[life]]?
  • What would you prefer to not do at [[work]]?
  • What is the most [[boring]] [[problem]]?

• Wednesday, 03/15/2023 ** 23:10 Coming back around to having a lot of trouble with javascript and build systems.

I'm learning more about the social aspects of ecosystems. In javascript's case, a single technical decision - to assume that transitive dependencies can be compiled in the same way that dependencies are, and to stay off of a clear decision to standardize a build process or module configuration for a long time.

Maybe staying away from administering standards is good, but this happens time and time again; I have personal experience with Nix flakes friction, Rust's erorr type / nighlies, Haskell's mess of a 'language extensions' idea, and so forth.

When do you want to institute a standard? How do you know where to start? Where?

Friction happens when interfaces are expected to be opaque, but aren't (or, conversely, are transparent). Build system errors are akin to internal compiler errors - they aren't problems in your code or even that of the upstream library, but somewhere in the processing pipeline to assemble everything. Build systems in javascript leak abstraction boundaries.

Library programmers have to build for every build system that end users could use down the line - and if I'm contributing in 2010, I have no way to conceive what people will want in 2020 something or how those standards might change!

The nix problem is one of a standard with a lack of appropriate tooling. The proposal was made and accepted by a minority of the community, then immediately implemented in 'production' by major Nix characters - making it industrial for some, but without the practice, backing or documentation to make this stuff broadly adoptable. Nix should be experimental - but instead of making it an external, experimental feature, it should have been implemented outside of the core - not strongarmed into the internals. Sure, flakes were hidden behind a flag - but half of the nix guides werre recommending flipping that flag without elaboration beyond pointing to the Tweag blog posts. Flakes are good; the launch was not and the community is still fragmented today.

Rust? They chose not to administer a standard that they knew they would need. The right decision for the Error trait was to provide a default, easily extensible error system that functions generically. A concrete Error was a bad move, and fragmented the ecosystem around all of these specific errors that people wanted but weren't supported by Error. Special casing would have been fine here - unnecessary but fine. The community deserved to be able to modify their system in ways that Rust's opaqueness doesn't tolerate.

Common Lisp runs the other way. Everything is explicitly modifiable, and that means you don't know what system you're working with. You can start from a tight core, but the core is a mess of hacks that have been accumulated, and none of them were built for the 21st century. Haskell's the same way - I dare you to walk into a production codebase, obfuscate the language extensions, and try to figure out what's going on. Too much could be going on on the other side of the interface, and the process of finding out is a mess. This is reasonable - Haskell was built for language experimentation, and Common Lisp was built to be a modifiable foundation - and fast.

I've had trouble with all of these because I've expected software systems that 'just work' and follow the same rules - heterogenous systems assembled with lots of simple, opinionated tools that serve their roles well. Type systems reach if not managed correctly. My current interface take is that users should be able to express ideas however they'd like within the rules of the system, but they shouldn't have to worry about a 'meta level' like a type system right away; types are useful to help document and solidify information across interfaces. I don't want to think about types; I want to think about values and data that will never be properly represented. Most Haskellers and Rustaceans will admit that over-perscription of representation - narrowing types of strings and numbers to minutiae - is a sin because it prevents iteration entirely. Maybe for system services, types are good glue - but for anything with a UI, your feedback is primarily delivered with visuals - not through any sort of type system. We don't need stronger types - we need better data visualizations - because when answers will inevitably occur, we want the best tools imaginable for navigating the system to track them down.