The bad thing about these sort of tools is when you work in a shop where multiple platforms are used for development and one of the platforms doesn't support the tool, or the tool fights with other tooling on that platform. You should for example never use pre-commit to enforce line ending style because git has brain dead defaults (which is to say, unless you have a .gitsettings file in your repo to prevent it, it will change line endings itself, fighting pre-commit). This just creates confusion and wasted time. In aid of what? So some anal so-and-so can get their way about code formatting as though it makes everyone else more productive to format code THEIR way. When in fact it makes others LESS productive as they fight "computer says no" format-nazi jobs in CI that don't even report what is "wrong" with the formatting and rely on tooling that they don't have installed to run locally.
Not to mention the overhead of running these worthless inefficient tools on every commit (even locally).
Tools like this just raise the debate from different opinions about formatting to different opinions about workflows. Workflows impact productivity a lot more than formatting.
Very interesting take that is probably true in my experience. (And not to say I doubt you at all but would be interested in a citation for that correlation.)
I think also that bright people like to solve problems, and not all bright people consider complexity a problem - and indeed, whether the intent is consciously there or not, it provides future opportunities to solve tricky problems!
In the context of scrum, with short sprints aimed at delivering immediate business value, it's challenging to make simplifications that have positive value in the long term, especially when you're unsure at the outset whether such simplifications are even possible. Meanwhile if you got the desired outputs from the specified inputs, you had a fun enough time conquering the complexity and you can get a pat on the back and move on to the next challenge.
My theory is that an org works best with both types of personalities, and if it knows what's good for it (especially if it's bought into scrum) knows who its best refiners and simplifiers are and lets them have at that kind of work while others concentrate on the immediate delivery pressures (usually more junior engineers but sometimes also just career specialists in fast delivery whatever the complexity cost).
I have respect for all these people as long as they have respect for each other.
Mostly pretty sound advice here, but oh, this rankles! --
"In situations where bugs aren’t mission critical (ex. 99% of web apps), you’re going to get further with shipping fast and fixing bugs fast, than taking the time to make sure you’re shipping pristine features on your first try."
In 99% of web apps, your end users have no possible way of telling you that you shipped a bug, and your bug will remain there forever, frustrating users and losing your client money as they abandon your site. Telemetry won't help you either becuase you'll misunderstand the observations it provides.
That makes much of the sword part of the ceremony, but surely it's the "red cord raised by City police" that signifies some self-authority -- what other part of the country may purposefully and physically stop the monarch and receive no investigation or punishment?
For direct user interactions (such as opening a combo box) the threshold of perception is actually much closer to 30ms than 300ms. 300ms is usable but far from a pleasure to use.
I found myself interacting with a Windows Server 2008 VM the other day (don't ask!) and was astonished how snappy the UI was, relative to today's machines (Windows or Mac).
I strongly disagree on this. If a search with no results costs them about the same amount of compute as one with results, then satisfying that requirement would give them a commercial incentive to lie to you about whether they have any good results for you, and to waste your time scrolling through bad results. Your time doing so is almost certainly worth more than what the search itself cost you.
Not to mention the overhead of running these worthless inefficient tools on every commit (even locally).
Tools like this just raise the debate from different opinions about formatting to different opinions about workflows. Workflows impact productivity a lot more than formatting.