Mental models

Here’s a nice collection of mental models:

These are some mental models I find useful. They’re rooted in decades of experience of thousands of experts – a modern equivalent of folk wisdom. Mental models are useful to quickly and correctly reason about seemingly intractable problems. They require quite a bit of intuition to properly internalize, but once you’ve internalized them they’re relatively easy to apply. They’re also easy to forget in the moment – use this post as a checklist when thinking about complex problems.

Of those that I read through so far, I found the Planning fallacy the most useful:

Planning fallacy – the observation that humans are overly optimistic when predicting success of their undertakings. Empirically, the average case turns out to be worse than the worst case human estimate.
Corollary: Be really pessimistic when estimating. Assume the average case will be slightly worse than the hypothetical worst case.
Corollary: When estimating time, upgrade the units and double the estimate (e.g. convert “one week” to “two months”).

 

Let’s Encrypt is leading Top SSL Issuers

Netrack reports some statistics for the Top SSL Issuers, and it’s nice to see Let’s Encrypt leading the race with a significant advantage over the rest. Well done, ladies and gentlemen!

You fired your top talent. I hope you’re happy.

You fired your top talent. I hope you’re happy.” is a response to “We fired our top talent. Best decision we ever made.” article.  It’s one of the best things I’ve read all through last year.

GitHub GraphQL API v4

I’ve briefly mentioned before that GitHub joined the adopters of the GraphQL for their API.  Here’s the link to the full documentation and more details.

GitHub chose GraphQL for our API v4 because it offers significantly more flexibility for our integrators. The ability to define precisely the data you want—and only the data you want—is a powerful advantage over the REST API v3 endpoints. GraphQL lets you replace multiple REST requests with a single call to fetch the data you specify.

Defensive Programming : Object Calisthenics

I came across this nice and somewhat strongly opinionated video on Defensive Programming:

Marco Pivetta makes quite a few good points with I agree (and a few with which I disagree).  One thing that he mentioned though I haven’t heard about – Object Calisthenics.  Which turns out to be yet another set of rules and best practices for the object-oriented design and programming.  Here are the rules to get you started:

  1. Only One Level Of Indentation Per Method
  2. Don’t Use The ELSE Keyword
  3. Wrap All Primitives And Strings
  4. First Class Collections
  5. One Dot Per Line
  6. Don’t Abbreviate
  7. Keep All Entities Small
  8. No Classes With More Than Two Instance Variables
  9. No Getters/Setters/Properties

Read the whole article for explanations and examples.