Pieter Hintjens

As someone who only discovered Pieter by finding his last article posted on HN, and then subsequently learning a lot from reading many of his other articles on his website (different perspective on life, humility, consulting in tech outside of SV, presentations), here is his homepage for those who are curious: http://hintjens.com. Three examples I'd recommend: Life, Consulting, Humility, Calming Down: http://hintjens.com/blog:125 (confessions of a necromancer) Presentations: http://hintjens.com/blog:107 (ten steps to better public speaking) Life, Humility, Time: http://hintjens.com/blog:123 (fighting caner) He's one of the few online writers who keeps my attention no matter the length. His humor is fun and his imagery and story telling style are engaging. [edit: formatting]

Unrelated to the article: I nearly jumped out of my seat when I saw a link to Martin Sustrik's blog on here. I recently discovered his blog and really enjoy his writing. He's one of the main programmers behind ZeroMQ and is now working on a new messaging library named nanomsg, using some of the lessons learned from building ZeroMQ. It's a great read if you enjoy the melding of technical and social writing. Pieter Hintjen's blog is also very interesting[0] for the same reasons. 0 - http://hintjens.com/

I can recommend his books, listed here: http://hintjens.com/books Confessions of a Necromancer is his work biography, I was totally caught off-guard how relatable his stories turned out to be.

An even more radical version of this idea was popularized by the late Pieter Hintjens —an amazing guy— in his post (and later book) “Confessions of a Necromancer”: http://hintjens.com/blog:125 One of the most inspiring engineering biographies I’ve ever read.

There is an excellent (and free) book on this topic by the late computer scientist Peter Hintjens. [1] This book should be required reading for every adult. These toxic people are out there and understanding how they operate is the way to defend yourself. [1] http://hintjens.com/blog:_psychopaths

If you check his website at http://hintjens.com/ you'll see "In April 2016 he was diagnosed with terminal metastasis of a previous cancer". So his choice was that or further suffering to the same end result.

(The late, great) Pieter Hintjens wrote a short book about psychopaths, which I found fascinating. It's available for free on his site: http://hintjens.com/blog:_psychopaths

Article is a book plug. I recommend The Psychopath Code by the late Pieter Hintjens [1]. It is frighteningly analytical & accurate with many analogies, examples and references to work with. Bonus points for using security terminology (he refers to the psychopath as Mallory). The book is freely available as PDF, and a physical copy can be bought as well. Changes can be suggested at gitbook [2], though the author (a long-term member of the open source community) passed away oct 2016. Although anecdotal I also enjoy reading posts from self-proclaimed psychopath "Athena Walker" on Quora on the subject. [1] http://hintjens.com/blog:_psychopaths [2] https://www.gitbook.com/book/hintjens/psychopathcode/details

I admit I am one of those conference speakers that doesn't prepare a lot. I tend to discuss the topic beforehand with the organisers, go inside the venue to get a feel for the audience, go on stage and just deliver. IMHO it is all about creating a bond with your audience and interact with them as spontaneous as possible. Works for me, but I know it's not for everyone. I also rarely use slides nowadays. That helps a lot. Sometimes I use a whiteboard. The way I deliver keynotes and presentations is maybe best summed up (and definitely inspired by) this article from the late Pieter Hintjens: http://hintjens.com/blog:107 Ten Steps to Better Public Speaking

I would add to this list the late Pieter Hintjens, known for ZeroMQ and many other projects over the years. http://hintjens.com/ Beyond programming, his writings about society and how it can be explained algorithmically are very interesting to programmers.

http://hintjens.com/blog:117#toc4 ``For ZeroMQ, our stated mission was "Fastest. Messaging. Ever." This is a nice, and nearly impossible answer to a problem we could all agree on: namely, the slow, bloated technology available at that time. However, my co-founder Martin and I had conflicting goals. He wanted to build the best software possible, while I wanted to build the largest community possible. As the user base grew, his dramatic changes, which broke existing applications, caused increasing pain. ``In that case, we were able to make everyone happy (Martin went off to build a new library called "Nano").''

"Tell them I was a writer. A maker of software. A humanist. A father. And many things. But above all, a writer. Thank You. :)" - Pieter Hintjens http://hintjens.com/

Here is a pretty amazing post he did "A Protocol for Dying": http://hintjens.com/blog:115

His post on living systems is absolutely great, just discovered thanks to his thread... http://hintjens.com/blog:74

Recommend reading this piece: http://hintjens.com/blog:115 for some context, and because it's excellent. Glad to see another update from Pieter, I hope he finds his way out of limbo, preferably healthy.

I can recommend Pieter Hintjens' "Psychopath Code" if you want to learn more on how human/social predators operate: http://hintjens.com/blog:_psychopaths Edit: I neither know the accused nor the writer of that piece, I just wanted to share that there's lots of layers to reality and that this book was eye-opening to me in that regard.

Very interesting read: worth the time. See also: http://hintjens.com/blog:112

Pieter Hintjens is writing a series on psychopaths. I found what I've read so far to be worth my time. Start here if interested: http://hintjens.com/blog:78

Or just deploy the half-assed solution, which will get the job done and allow your limited engineering staff to focus on higher priorities. Then, a decade later, when the company is worth hundreds of billions, you can rewrite it from scratch the proper way. See also: A Tale of Two Bridges http://hintjens.com/blog:16

I wasn't aware of this particular workflow, but I've heard of similar ones before. The late Pieter Hintjens, of ZeroMQ fame, advocated for a strategy called "optimistic merging"[1], which essentially abandons the standard code review process in favor of merging changes ASAP, and fixing any issues as they arise later. I'm not a fan of this. It allows contributors to abandon any established coding standards, while placing more burden on maintainers to fix issues later. This in practice never happens, so the quality of the codebase degrades over time. Not to mention that it allows malicious actors to merge changes much more easily. As for "ship, show, ask" specifically, I have similar reservations. I think all changes should go through a review process, even if someone just glances at the changes. It not only gives the opportunity to leave feedback, but also serves as communication so that everyone is aware of the proposed changes. Also, making the decision of whether to choose "ship", "show" or "ask" might only work for senior and well disciplined developers. I think that in most teams you have a mixture of experience, so you'd inevitably end up in situations where a change should've been "show" or "ask", but was "ship", and viceversa. I don't think teams will ever align on a single strategy to make a correct decision, since it's based on subjective opinion to begin with. Always following the same workflow gets rid of these uncertainties. [1]: http://hintjens.com/blog:106

> the greater opportunity there is for a manager to take wealth Pieter Hintjens (creator of ZeroMQ) wrote a lot about this, and how organizations from big companies to small charities to software projects ought to design their internal structures of roles, titles, voting, auditing, to defend themselves against this kind of attack. Particularly if there's any kind of treasury, an opportunist will become tempted to take that role, but any kind of credit will attract people who want to take the credit without doing the work, power structures will attract people who want the power, and programmers who "just want to code" and avoid politics will find themselves at the bottom of a dysfunctional infected organisation structure with no power, no credit, and being instructed by distorted requests. IIRC he tried to design the ZeroMQ organisation so that there wasn't any way for one person to insert themselves in a key point. I'm not sure where on his blog I was reading that, but it's related to his writings about psycopaths[1] as the opportunists, and might be part of his book Social Architecture[2] [1] http://hintjens.com/blog:_psychopaths [2] http://hintjens.com/books

You have to get people there, and you have to get them to want to bother coming back. 1. raise awareness. e.g. though word-of-mouth recommendations, or advertising (online, TV, events, IRL?) 2. it has to have something to keep attention, 3. it has to be worth coming back to It happens through phased growth, sometimes explicitly planned, always interactively managed. A marketing and sales pipeline provides a google-able articulated view of a similar process. Or go as far "Manufacturing Consent" They're built on positive feedback cycles, where contributions spur further engagement of viewing, and prompting others to engage. These are called virtuous cycles, when it's going in a desired direction (e.g. more contributions drive more views drive more contributions), and vicious cycles when they're not (bad drives out the good, e.g. toleration of off-topic / inappropriate content, deters helpful contributors from returning, while encouraging more detrimental contributions). I would recommend reading Peter Hintjen's "Social Architecture"[1]. He addresses a question worded exactly the same as yours. He built a more narrowly scoped community as an integral part of building the ZeroMQ messaging library and tools, and ensuring that it was useful to as many people as possible. Also, check out his other books [2]. Though, note that gitbook.com broke the links, and…

> Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing? Yes, absolutely. Read https://rfc.zeromq.org/spec:42/C4/. We developed the C4 contract (in the form of an RFC) precisely to teach maintainers how to welcome new contributors while keeping quality high. It took many years to refine this approach. By formalizing it, it becomes really simple for projects to adopt: all you need in your README 'Contributing' section is a license (we recommend MPLv2), a link to this RFC, and later a style guide to ensure consistent code style. The thing about C4 is that it teaches people to make small testable patches, and to trust new contributors. We know from experience that it's users of a project who keep it alive. Original authors and core maintainers burn out, get full time jobs, start new projects. As long as you have users, though, you have potential contributors. Small patches, merged immediately, with reviews and improvements made asynchronously over time. This style is lovely to work with, kills bike shedding (we argue with new patches rather than comments), and reduces the friction in the project to as low as possible. More on optimistic merging: http://hintjens.com/blog:106 In terms of friction: we aim to get a patch live on master within a few minutes. If that breaks master, we fix it either with a new…

The section on security is just... bonkers. First it starts by talking about how ZeroMQ security is an "afterthought", linking to an article that should hopefully convince even people with casual security backgrounds this isn't the case: http://hintjens.com/blog:48 For what it's worth: ZeroMQ implements the closest thing to a real-world implementation of Dan Bernstein's CurveCP protocol, with a few design flaws fixed, and also a certificate form that allows a limited hierarchical PKI. Normally I'd say using anything other than TLS is a huge warning sign, but as far as non-TLS protocols go, ZeroMQ's "CurveZMQ" protocol actually ends up looking fairly good in my book. Iris does none of this, advocating the use of global PSKs. Global PSKs are the bane of security professionals everywhere, as they make any system that shares the PSK the weakest link, greatly increasing the chance that the most overlooked system will become a vector for total system compromise. This is why we've generally seen a move away from such systems to running internal PKIs with unique keys per host. Instead, they claim: "This is achieved through the observation that if a node of a service is compromised, the whole system is considered undermined." This is pretty much the opposite trend of modern crypto practitioners. It's been awhile since I actually looked at their crypto, but at a cursory glance-over again it's hand-rolled and uses bignums without random blinding, greatly increasing the chances…

Pieter Hintjens who started ZeroMQ, advocated for 'optimistic merging' as a strategy to encourage community & project building [1] (prev discussed in [2]). For all of the benefits listed it does open it up to lower quality or malicious merges. [1] http://hintjens.com/blog:106 [2] https://news.ycombinator.com/item?id=39880972

I immediately remembered one of us, Pieter Hintjens (ZeroMQ) and his “Protocol for dying" http://hintjens.com/blog:115 He was lucky to be Belgian resident and thus had a choice to go peacefuly without horrors of those last weeks and days when there’s no hope, just suffering and pain. After seeing how it looks first hand, I think veryone should have an option for euthanasia.

Sounds like the optimistic merging principle of the late Pieter Hintjens: http://hintjens.com/blog:106

It's part of the URL path. schema: http, domain: hintjens.com, url path: /blog:99 It looks a bit like a port number, but it's in the wrong place. For that you'd want http://hintjens.com:99/blog

Canonical article about that: Pieter Hintjens "Why Optimistic Merging Works Better" (2015) http://hintjens.com/blog:106

"CMake, you say? Yeah, CMake is like smashing your face on high quality pavement. You can admire the stonework while the blood pours down your face." Pieter Hintjens, http://hintjens.com/blog:79