Is there some name for the combination of text files and an IDE? A grouping like “GUI”
Can you say more? Typically, IDEs are used to edit text files (though they interact with other types of files as well). Are you referring to the directory structure of files that an IDE might open up?
(I know you know IDEs edit files, just trying to clarify the causal relationship)
I've been asked to speak a bit about sociocracy https://en.wikipedia.org/wiki/Sociocracy and how it works. It is a huge topic, but I'll attempt (perhaps foolishly) a summarization.
Sociocracy is a framework for self-governance of a group of people. This could be anything from a book club with your friends to a large corporation. In my mind, the main pillars of sociocracy are: consent, circles, and feedback.
If you'd like to learn more about sociocracy, I highly recommend "Many Voices, One Song" by Ted Rau and Jerry Koch-Gonzalez https://www.sociocracyforall.org/ And I can give a talk about it, if folks are interested. Thanks! 🙂
It sounds deceptively simple. :) Seems like a good framework for open source organizations, among other things.
Have you seen it in action on very contentious topics? Relatedly, have you seen it break down and maybe even recover?
Whoa — this seems like a really compelling framework for decision-making.
Something I've been puzzling over for the past, oh, two and half years… is how to change the evolving role of stewardship in this community so that it's not yet another lineage of white dudes, or a self-selecting board of mostly-white mostly-dudes. I could try to "hand the reins" to someone from an underrepresented group, but that feels like a token gesture, or like virtue signalling. It wouldn't, by itself, contribute to substantive change in our field more broadly, and changing our field is explicitly what we're here to do.
The most common wisdom that folks have shared with me here is that any attempt to improve the social conditions of our industry / culture will require building coalitions, not just inserting underrepresented people into the very seats of power established and defined by, well, folks like me. (Yes, there's also the spectre of capitalism here, but I think the sweet spot is making a move that's bigger than "ask non-male PoC to lead the group until someone says yes" but smaller than "rebuild the economy writ large".)
It feels like sociocracy would be a meaningful improvement with respect to the above, since (AFAICT) it's a framework with the goal of reversing the power imbalance inherent in hierarchical decision-making. It's about empowering individuals who would otherwise be drowned out.
Are you able to (briefly — want to respect your time) add any thoughts about (A) how sociocracy specifically can contribute to the broad goal of diversifying the social makeup of the community, and (B) how we might be able to implement it here, with that goal in mind?
Andrew F so difficult decisions are always going to be difficult, and compromises must still be reached. I've never seen a group completely break down due to a "block" (someone doesn't consent), but I can imagine some scenario where people come together, consent on an AIM, but then later on down the road, realize that they have different ideas of what the AIM means. That's the only scenario where I could see it completely breaking down. Because if the group has consented to the AIM, then really any disagreement is how to achieve that AIM. And if someone flat-out blocks a decision, their reason for blocking is going to be that the proposal in question is fundamentally opposed to the AIM in some way.
Ivan Reese yes, you've hit on something that is very alive right now: inclusion. And that's exactly what sociocracy provides in a non-hierarchical way, as you pointed out. So to answer your questions A) a sociocratic organization is going to be much more attractive to members of underrepresented communities due to its participatory and non-hierarchical nature. Giving people a sense of agency and a real voice (and real power) is a massively powerful tool for community-building, and can keep people around and engaged for a long, long time. B) really all it takes is a group of people who consent to being members of a circle operating under sociocratic rules, by defining the AIM, MEMBERS, etc. This could take many forms. We could consent to creating one giant "Future of Coding" circle, with everyone in the server being a member. But since that circle is so big and thus decision-making would take so long, we might instead decide to create multiple, smaller, independent circles like a "Systems Thinking Circle", and a "Cybernetics Circle", and a "Blue Sky Circle" and then each of those circles has 2 members that are also members of an overarching "Guiding Council of FoC Circle." It would really depend on what everyone is okay with. And since every circle and every decision comes with a term, we can always say "I propose we do X, for a term of 3 months" and then when the 3 months are over, we review and re-consent to the same structure if things are working, or we consent to a completely different structure if not.
Thanks @David Brooks for this succinct summary! I have seen references to sociocracy before, but it's your summary that got me interested in digging deeper.
My first question (as with nearly every new idea I see) is: what are the limits? In which situations would sociocracy not be appropriate? I always ask myself such questions early on because (1) nothing is perfect and universal and (2) it's best to explore some space being aware of where its walls are.
Something that does look like such a wall to me is decisions requiring expertise. How would consent work if 90% of the circle do not understand the impact of the decision they are making?
Our FoC community also looks like an inappropriate place for sociocracy, though I may well have overlooked something. We are a low-stake community for everyone involved. There aren't that many decisions to take, and they are mostly about how to deal with exceptional rather than regular situations. Any organized form of decision taking then looks like overkill. A benevolent dictator (which is how I see Ivan Reese's de-facto role, although I expect him to protest) is probably a pretty good arrangement in such cases.
Konrad Hinsen another thing that came to my mind when you mentioned "exceptional situations" that might be a wall is the speed of decision-making. At least I conjecture that larger circles (larger than say half-a-dozen people) might take too long to converge on a necessary decision especially in an unclear and somehow "controversial" situation that demands fast solution.
Maybe some hybrid structure can be employed with "emergency management expert groups" for various kinds of emergencies pre-established or something.
Konrad Hinsen so the difficult thing about sociocracy is the wonderful thing about sociocracy, and that is: everyone has a say, everyone has a voice. Consent. What this means in terms of limits and where it breaks down, is that the members of a circle must be willing to engage in civil discourse. They must be able to express themselves freely, openly, and with vulnerability. Holding back a frustration or anxiety because you don't want to "rock the boat" will cause problems down the line. Everyone in a circle needs to be able to bring themselves fully into that space. Something that is highly recommended in sociocratic literature is something called NVC or nonviolent communication. It is a toolbox for supporting open and honest communication with minimal conflict. The de-facto "texbook" on NVC is appropriately titled "Nonviolent Communication" by Marshall Rosenberg.
For the question of expertise, it essentially boils down to, as usual: "are we okay with it?" If the members of the circle don't understand the impact of the decision they are making, then the expert needs to make them understand. Not the details, per se, but the impact. No one should be pressured into accepting a decision that they don't understand. Alternatively, highly technical decisions could also be delegated to a child circle. If the members of the parent circle consent to the creation of a child circle that makes highly technical decisions without their direct involvement, that is perfectly valid as well. Since 2 members of the child circle are also members of the parent circle, there should be regular reporting of its activities, and since consent flows both ways, there should be solid information flow (feedback) such that the parent AIM is still the guiding star.
Alexander Chichigin the speed of decision-making is a fascinating story from my experience. If sociocracy is a new thing for the group, then decision-making does take longer initially. There is a learning period. However, once the group really understands and puts into practice the philosophy of "good enough for now, safe enough to try" and really adhere to the idea of "I can live with it" rather than demanding their preference, then decision-making (and meetings) amazingly gets shorter! And yes, larger circles (20 or more) do indeed take a long time, so if a group is huge, the first order of business is for that large group to consent to the creation of an array of child circles to delegate some of the authority and responsibility to. In my coop, we do have a rather large "member circle" that is the parent of all other circles, but it hardly ever makes decisions, because we've created a Team circle, a Delivery circle, a Marketing circle, etc. The only time the main parent circle needs to meet and deliberate is with monumental decisions like changing the bylaws or changing the name of the coop, or something like that.
Another thing to note is that each circle, parent or child (or grandchild, etc etc) is a group of people that consent to how that circle is run. So if that group of people all agree and consent to meeting once a week for an hour, that's what happens. If they consent to majority voting for decision-making, that's what happens. If every member of the circle consents to a single member doing all the work for that circle, that's what happens. It's a very flexible and dynamic system, and with TERMS for circle / policy / roles, it ensures nothing is ever "set in stone" since everyone must consent to the TERM as well.
@David Brooks The fundamental issue I see with expertise is that it comes with its own biases. Experts have not only a better understanding of technical issues, but also the biases of their professional communities. Example from a discussion I had last week in the first (virtual) meeting of a decentralized workgroup: when we had to agree on a means of communication, the two software engineers insisted on "state of the art" tools and proposed setting up a Zulip server. I am pretty sure that e-mail would have been a better fit, because it's the one technology that everyone was already familiar with.
Konrad Hinsen definitely! Bias absolutely has to be taken into account. In your example, if the group was run sociocratically, then if you were "not okay with" a Zulip server, then you would have raised the block and explained your reasons why. The other two engineers might attempt to change your mind with their own reasons, or maybe they themselves would be persuaded to go with your email idea. The important thing is that everyone in the group understands the consequences of the decision, and is at least "okay with" the final decision. And since all decisions in sociocracy have a term, it is a lot easier for people to be "okay with" something if they know the group will re-visit the decision in X months or so.
So let's take this name change as an example, and make it a bit contrived (to help me understand the mechanisms and process and such). What would happen if everyone active in the Slack wanted to change the name of the community, and all decided on a single name that they loved, but one person steadfastly didn't want to change the name. My sense of it is that this is working as designed, and the name would not be changed. And I imagine these sorts of situations come up in practice, not just in contrived examples — some people just don't like change, no matter the nature of it. That seems like a natural human tendency.
Ivan Reese the scenario you bring up touches on the concept of AIM. Every circle has a reason for existing. If every member of the circle has consented to that AIM, then it is the "guiding star" for where the group wants to go. If one individual absolutely blocks the name change, they have to have a REALLY good reason to do so, not just "I don't like change" because that reasoning doesn't match with the group's AIM. At that point, if there is just one member of the circle, who, despite consenting to the AIM, still wishes to block a proposal for a reason that has nothing to do with the AIM, then more than likely that person realizes their AIM doesn't match the group's AIM, and will resign from the circle. If they don't, then everyone else in the circle can always re-consent to forming the circle without that individual.
In practice, I have never seen this happen. When people consent to an AIM of a circle, that generally means that they all agree in a direction, and they all want to see the circle succeed in whatever its goals are.
Again, we want to gather consent, not preference. So if changing the name of the community is something that someone doesn't prefer, more than likely, they will at least be okay with it. They can at least live with it, even if they don't like it. Hard blocks like what you describe are extremely rare, and usually come with a very good reason that, once it is explained, is in preserving the AIM of the circle, and thus a good thing.
So if we wanted to use this endeavour to rename the community as an exercise in sociocracy (which, IIRC, you offered to help us do — which is very generous and I'm keen on that), what sort of a circle would we set up? Would we put out a call like "If you'd like to participate in the renaming of the community, please let me know and we'll form a circle to do so"? And then the circle would get together, select an AIM, and then proceed from there? (Apologies if this is already well explained in the above thread, which I've been following but it usually takes me a few passes over a subject before it sticks).
No worries Ivan Reese it's a lot to take in 🙂 So the AIM of a circle is much more important than its name. In fact, I think finding an appropriate name is going to be a lot harder without a clearly defined AIM. Once you have a reason for existing, the name usually comes almost naturally. So my advice would be to propose the existence of some unnamed community circle, with version 1 of the AIM for that circle, membership being anyone on this server who wishes to be a member of the circle, with the first order of business being selecting people as Lead, Facilitator, and Secretary, followed immediately by "what should we do about the name" as agenda item 1.
@David Brooks I see what you are getting at about experts, but then this seems to require a major shift in attitudes of everyone. Basically, the role of experts have to shift from "domain-specific leaders" to "community counsellors". And everyone else has to develop the courage to say "If you want to me accept your technology, tell me first why I should".
Yes exactly Konrad Hinsen :thumbsup_all: 🙂 You got it perfectly right. When groups work together to achieve a goal, rather than individuals telling everyone else what to do, you get massive buy-in and investment from the members of the group. But that does indeed come with an attitude shift. It's the same type of shift in attitude from a Dictatorship to a Democracy, this is just one more step in that direction.
Did programming go through the "PC revolution" too? Because to me, programming pre-PC, during PC, and now post-PC (tablet, etc) seems to have changed far less than hardware and other software, especially with respect to the qualitative nature of the changes the PC revolution brought about.
Change my mind? Anyone else ever talk about this with this lens?
When I started programming, my code was running on a pc with only ram and no hard drives, it loaded os from 5.25'’ floppy disks (attached). The current code of mine runs in CloudFlare servers which, I think, are also all in ram mostly. The only difference is that my code was running locally, and now it’s distributed worldwide. Well, this was an attempt to hilariously say that there was little revolution. Whilst in reality, heck, it changed gazzilion times!
Back then 25 ago I was coding with PolyPascal on monochromic monitor, writting loops and if conditions. Now my screen shows VSCode in almost nearly-monochromic color scheme, am still writting ifs and loops mostly:). Really - not much has changed.
So - agree 100%.
(I think I'm not the only one here who still uses floppy disks, though not the five-and-a-quarter ones thank goodness. My trusty Mac SE says hi crunch crunch.)
Ivan Reese I want to figure out how to hack my MNT Reform so it has a floppy drive in it
@Eric Gade - just googled what MNT Reform
is, watched the intro video. You have it already? What are experiences? thanks for sharing!
@Tomas Čerkasas The Reform is a great device. I have already modded the keyboard a bit and I'm not really a "hardware" person. It's got a great keyboard and the trackball kicks ass. The SOC on it is admittedly on the slower side, but that only encourages a kind of "slow computing"
I can't use it for heavy day to day web dev work, but pretty much everything else that matters to me runs fine. In short, I really like it!
Yep, programming goes through these revolutions. Each one rolls us back to C/C++, because the new shiny device is so slooowww! 😄
No I mean it. By the end of Mainframes and Workstations era they developed very advanced high-level languages and developing environments. PCs threw all of that out of a window because everything had to be done from scratch in Assembly! How many bytes of RAM 8086 had?
By the time we came to decent languages and IDEs on PCs, Apple revolutionized the platform with iPhone which had to be programmed in what? You guessed that, Objective-C with totally manual memory management! It took them almost two decades to transition to a decent high-level and safe Swift language.
And now IoT revolution is coming. Guess what it means for programming languages? 😉
That’s a really great way to think of it! And wasn’t C originally developed for a device considered resource-constrained at the time (the actual “eunuch” of UNIX), which is why we keep returning to it in subsequent evolutionary cycles?
Ivan Reese Part of the answer might reside in the fact that we generally program for hardware systems that no longer actually exist. That point was an important part of this talk: https://www.youtube.com/watch?v=36myc8wQhLo
I'm not sure hardware resources are "constrained" so much as the hardware makers feel the need to constantly improve performance by "faking" an architecture that is amenable to the Unix/C worldview. It's another way that the monoculture limits what we can actually do
Nick Fox-Gieg yep, compared to mainframes PDP-11 (or was it PDP-9 even?) was very resource-constrained. But the main constraint was the lack of everything but an assembler, that's why Kernighan and Ritchie had to do everything from scratch: a programming language, an OS kernel, a FS, a text editor and so on, and so forth. The C language was or become a "portable Assembly language" and when you have one you don't need another one, that's why we always go back to C (when we can avoid "naked" Assembly language).
Which tools/processes/media do you use to "approach" a problem before starting to write code in a text editor/IDE?
iA Writer where I write down the problem and how I want to approach it.
Whimsical to visualise how parts of a system are connected.
Codepen to sketch out code in isolation.
Also: any form of communicating the problem to someone else. Verbalising it often reveals potential solutions.
Freewrite (stream of consciousness braindump) about the problem, usually in a plain text editor; yesterday I just did it in a comment in the source file I was working on. Paper if I need to draw something: I've never found a computer graphics tool remotely as intuitive. There's a good point about it being easier to fix mistakes in software, but for exploratory stuff there's a lot of benefit in redrawing it from scratch anyway. Similarly in writing I iterate though different versions of my problem or solution.
Sometimes still a text editor (Drafts iOS) to type notes (I'm too slow at writing, don't usually need to diagram)
Usually a lot of Google to see what the noosphere's recent thoughts are
I like to get into a REPL experience before too long, even just on the CLI with curl, jq, basic tools – to get some things functional to prove I know what I'm working with
+1 to sleep, walking around, waiting until I feel latches click internally
I use a LOT of Miro for this; I also tend to add // TODO: something
comments on a branch and then look it over in git
If a problem needs to be approached, I make a list of terms - kind of an ontology - for the problem/solution. Then I try to organize them in groups. Encapsulation is all about isolating concepts. So I try to separate system wide ideas from subsystem specific ideas, problem domain ideas from implementation detail ideas. This is neither rigorous nor exhaustive, but helps me think about the problem.
Oh another set of groups is "contextual" vs "new" - stuff that is in the problem context, and not negotiable, vs new stuff that is being invented.