This is not necessarily about the code, but I've been really impressed for a while by the lodash project and its maintainer's dedication to constantly keep the number of open issues at 0. Any issues get dealt with at record speed, it's quite a sight to see.
In my experience, knowing when work on some functionality will _start_ plus a rough estimate on effort (talking hours/days/weeks level) is quite acceptable for most stakeholders. It is also far easier to provide, and less likely to be off by an order of magnitude, which some low-level estimates may suffer from.
Please don't fall into the Dunning-Kruger[0] trap by assuming a straightforward task is also easy to perform. These things may very well be complex and include aspects that are not immediately obvious. And even if they don't, even simple code executing simple tasks can be vulnerable to bugs or flawed reasoning without the authors (or tooling) being stupid or naive.
This also reminds me of a talk by Maxim Februari at the most recent TEDx Amsterdam[0]. From the description:
The infrastructure of connected things [..] imposes norms on citizens. Not in the form of written laws: the norms are hidden in the design of things. Citizens can’t protest the new laws, or change them, because they do not know them. And because decisions are made automatically, the laws can’t even be violated [..]
Git only started really clicking with me when I started thinking of most of my actions as graph building and traversals. It also helps to realize that for most intents and purposes, commits in git are immutable and "destructive" actions such as rebase don't _actually_ rewrite history, but rather create a new path in the graph and moves your branch pointer to it, leaving all previous commits intact (though potentially hard to reach and subject to garbage collection).
Which contains (apart from the obvious Murphy's law and Occam's razor) such pearls as the Peter Principle, the Dunning-Kruger effect, and Hofstadter's Law. 20+ tabs guaranteed!
To me this is a form of the Dunning-Kruger effect[0], where only somewhat informed people estimate the cost of a "0.1" (or POC) release without considering the famous "unknown unknowns" which may involve scaling, billing, 3rd party integrations, etc.
While luck isn't something you can completely control, it doesn't have to be entirely random either. I read this article a while back talking about a "luck surface area"[0], which you can expand, increasing your odds of being "lucky" in the future.
I would love to see a general purpose API client that works similar to the Elasticsearch client Sense [0]. A simple, free-text scratchpad style client that allows for easy editing and firing of requests. Maybe it's hard to support all the advanced functionality this way, but I find Sense absolutely invaluable when working with Elasticsearch and would love to use it on other API.
Try writing YAML in combination with templating (such as in Salt). Because indentation means hierarchy, it's terrible. I'd much rather use JSON in such a context.
https://github.com/lodash/lodash/issues