Nice work on that strap. Super unique

While ramda does have some lens capabilities (see http://ramdajs.com/docs/#lens – should this have been included?), I didn’t know about Optika – very cool.

edit: I plan on doing a full writeup on using lenses to transform data, so I will at least cover them there.

This is a pretty standard thing to do once you’ve protected the master branch on a project, which is also a pretty standard thing to do.

I think focusing your critique on a specific point is what’s actually valuable.

For example, with the leftpad debacle:

• “Node.js/npm is a garbage fire”: This is….. super useless! I get told this, what do I do with this? Reply “ummm OK then guess I like trash”? But this is what people were saying
• “This shows the dangers of having 10 layers of dependencies”: Well now we’re getting somewhere! You end up still being in a bit of a dangerous discussion (“should I be hand-rolling all my code?”) But at least it’s a real critique. If you can avoid being antagonistic you can explore this space and learn stuff as well (“JS has no real standard library so…”)
• “There needs to be better way to ensures dependencies can’t just disappear”: This is a bit nicer! It’s not as subjective a critique, and at the same time can be applied to other places as well. Nobody wants their dependencies to disappear! You can disagree about the probability of the issue, but at least you can explore solutions.

Ultimately people care about what community they’re in, and you can almost always reformulate things in a positive manner, and move forward.

Another example is Rick Hickley’s clojure conj 2017 opening (this thing). This is a pretty good example of how not to make critiques. He spends a bunch of time complaining about types so people like me (who has seen massive productivity gains from Typescript in particular) just gets completely turned off.

But if you listen, there’s kernels of truth and insight that everyone wants to hear. He’s not against any sort of static verification, more against overbroad/program-wide stuff. He’s in the same camp as many Typescript people, but alienates them immediately! Meanwhile he has interesting points (“Don’t mess with things”/“offer low coupling”/“a la carte static verification”) that are … even more interesting to people in the more typed domains. Interesting stuff to think about, all ignored because of the rant-y feel of the message.

Your thing could be better than someone else’s…. so offer why your thing is good! Don’t insist on why their thing is bad! Then they can try to take some stuff from there, instead of just getting pushed away

I tried to address this behavior from a team-oriented, “we-know-not-what-we-do” perspective earlier this year in a talk at New Zealand’s JavaScript conference in Wellington:

“Behaviour & Your Team” https://robertwpearce.com/blog/behaviour-and-your-team.html (VIDEO)

You can critique something without holding it in contempt, but it’s nearly impossible to write politely about something you are contemptuous of.

One way is to contribute to that community. Demonstrate that you’re critiquing it because you want to make it better, and that you are in the process of making it better.

I loved Cryptonomicon and hated Three-Body Problem, for what it’s worth.

Would you recommend reading Cryptonomicon first? I’ve just purchased The Three-Body Problem, and it’s next on my list.

I enjoyed The Three-Body Problem but have really struggled with the second book in the series. I’m not sure exactly what to pin it up to, but I think some lack of cultural understanding is making it harder to keep my attention.