2019-09-16 Social Architecture

This morning I’ve been skimming *Social Architecture* by Pieter Hintjens. Sadly, he died in 2016. The book is like a summary of all the things one learns slowly, growing up as a programmer online. Group dynamics, encouraging newbies, using distributed version control, picking the right license, but with a focus on people and groups, not on the particular tools and the details of how to use them. This is not the Git book.

he died in 2016

You can get the book via GitBooks. Notice the PDF link. You can also get it (and other books) from Amazon. See his Books page for more information.

via GitBooks

Books

You’ll find his blog on the same site. I didn’t read it because life is short. But the table of contents for the last blog post looks very interesting!

his blog

Anyway, I recommend it. Take a look at the “reusable protocol for collaboration” or Collective Code Construction Contract, C4. If you’re interested, read chapter 4 of the book. It goes through the C4 document, giving you the background for all the various things it says.

Collective Code Construction Contract

I was particularly intrigued by the idea that *all* correct patches are merged. In the book, it’s discussed as *optimistic merging* vs. *pessimistic merging*.

Fascinating.

​#Books ​#Programming

Comments

(Please contact me if you want to remove your comment.)

As @deshipu noted, there’s also a FAQ that mentions “optimistic merging” and the question is: “How do you deal with rude contributors who are brilliant/highly skilled?”

@deshipu

a FAQ

It is better to embrace a bad contributor, and give them time to show their damaging behavior. By rapidly merging their (awful) pull requests, then quickly reverting or cleaning them up, it creates a historical record. “You did not use our guideline of clear problem statement with minimal solution. I’m going to revert your patch, sorry.”

– Alex Schroeder 2019-09-16 20:06 UTC