Still thinking about the "present - future of codi...
# thinking-together
m
Still thinking about the "present - future of coding spectrum", is building tools to make it easier to build docs/pages like this something that falls on the FoC spectrum? https://stripe.com/docs/checkout/integration-builder
✔️ 1
Another way of stating it: what do we incentivize? what do we value? For example:
Copy code
The IETF community works mostly online, guided by the informal principle: "we believe in rough consensus and running code".

The IETF's mission is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. IETF standards are built on the combined engineering judgement of participants, including individuals from academia and network operators, router vendors and open source projects. Success is measured by the extent that the protocols and practices developed in the IETF is used to make the Internet work better.
j
Copy code
"we believe in rough consensus and running code"
Encountering this culture in the 80s was very important to my worldview 🙂
a
What does rough consensus mean? (In this context)
m
probably to be direct in discussions? maybe similar to the newer term "disagree and commit"?
r
I think docs would fit. I think you'll find a wide variety of what documentation is considered good and a lot of it depends on the future you see for code, or at least the part you focus on. If docs aren't in service of code, they probably don't fit in FoC.
o
For me Future of Coding (or computing, or programming) is about tools that make easier to create and think about programming artifacts. So, for me this kind of doc tools is fully part of the adventure.
j
The IETF way was predicated on (1) the existence of a working reference implementation (no arguments about possible futures without working code) and (2) our ability to disagree productively until we reach some kind of general consensus, meaning we didn't need to all agree, but that the community more or less settled on a way forward. None of this made flame wars completely non-existent, but it was an extremely useful approach when dealing with a wide variety of engineering problems back in the days. (This isn't important for "let's dream the future" discussions, but is very important when it comes time to herd the cats into shipping software.)
e
foc-> max(costof(asIsUseCase) - costof(toBeUseCase)) for me it is mostly about use cases. taking a use case and looking for ways to add value. ... you looks at current solutions, current solutions to real problems and ask if there is a better way of doing this.