🏛 Stoas near [[@agora/2023 03 15]]
📚 Node [[2023-03-15]]
↳ 📓 Resource [[@agora/2023 03 15]]
- I didn’t realize that Diablo 4 was coming out very soon #gaming
Kyle Mathews A Social Protocols OS
What if we had social networks that are actually incentivized to help us form complex friendships and groups that work well together over time?
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 is their workflow?
What hacks are they using to patch the problem?
- 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
- Mask-related complaints: wanting to be someone. Status or autonomy. Ways to show they are trustworthy, 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
- Where do people go out of their way to avoid things that they wouldn't call a problem?
Adherents avoid, starters solve.
- What is in your way?
- What is a pain to do?
- What is annoying?
- What blocks 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?
- 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?
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?
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.