1. It's a very naive idea that our actions can always be construed as evidence of what we want. The fact is, humans aren't purely rational beings, and we don't always do things that lead to what we want. Particularly, short-term dopamine-rush type desires can override our more fundamental wants and even needs. The person who wants to lose weight gives in to a short-term craving for a cookie, the guy who wants a relationship gives in to a short-term fear of rejection and doesn't approach the girl, the person who wants to save money buys the cigarettes to deal with their stress. The idea that anyone is immune to this is arrogance, and it's uncompassionate to not allow for this in our understanding of others.
2. Simplicity is defined in a lot of ways, many of which don't make much sense. For example:
> A lot of developers want simplicity in the same way that a lot of clients claim they want a fast website. You respond “OK, so we can remove some of these 17 Javascript trackers and other bloat that’s making your website horribly slow?” – no, apparently those are all critical business functionality.
This is assuming simple == fast, but that's not in evidence. One might plausibly improve speed here by loading the 17 Javascript trackers asynchronously after the visible parts of the page have loaded, thereby creating the visual impression that the site is faster, which is likely what the client means when they "claim they want a fast website". By any reasonable definition this is more complex, but it's faster by the definition the client is likely using.
In optimization this is super common: quicksort is faster but more complex than bubblesort, hash tables are faster but more complex than lists of key/value pairs, etc. "Fast" is a really poor approximation of "simple" in this context.
Really this is an example of really poor listening on the part of the author. They're not taking the time to understand what the client wants to be faster, and are instead incorrectly telling the client that they need to remove core business functionality in order to do that[1].
[1] As a side note, I've managed my entire career to avoid working for companies that have 17 Javascript trackers installed, and in all likelihood you can too. If you don't like working on sites that have trackers installed, then I think it's more mature to be honest about that with both yourself and your clients, rather than setting up artificial roadblocks like "this can't be fast because of trackers" which is passive-aggressive if you're saying it just because you don't like the trackers.
1. It's a very naive idea that our actions can always be construed as evidence of what we want. The fact is, humans aren't purely rational beings, and we don't always do things that lead to what we want. Particularly, short-term dopamine-rush type desires can override our more fundamental wants and even needs. The person who wants to lose weight gives in to a short-term craving for a cookie, the guy who wants a relationship gives in to a short-term fear of rejection and doesn't approach the girl, the person who wants to save money buys the cigarettes to deal with their stress. The idea that anyone is immune to this is arrogance, and it's uncompassionate to not allow for this in our understanding of others.
2. Simplicity is defined in a lot of ways, many of which don't make much sense. For example:
> A lot of developers want simplicity in the same way that a lot of clients claim they want a fast website. You respond “OK, so we can remove some of these 17 Javascript trackers and other bloat that’s making your website horribly slow?” – no, apparently those are all critical business functionality.
This is assuming simple == fast, but that's not in evidence. One might plausibly improve speed here by loading the 17 Javascript trackers asynchronously after the visible parts of the page have loaded, thereby creating the visual impression that the site is faster, which is likely what the client means when they "claim they want a fast website". By any reasonable definition this is more complex, but it's faster by the definition the client is likely using.
In optimization this is super common: quicksort is faster but more complex than bubblesort, hash tables are faster but more complex than lists of key/value pairs, etc. "Fast" is a really poor approximation of "simple" in this context.
Really this is an example of really poor listening on the part of the author. They're not taking the time to understand what the client wants to be faster, and are instead incorrectly telling the client that they need to remove core business functionality in order to do that[1].
[1] As a side note, I've managed my entire career to avoid working for companies that have 17 Javascript trackers installed, and in all likelihood you can too. If you don't like working on sites that have trackers installed, then I think it's more mature to be honest about that with both yourself and your clients, rather than setting up artificial roadblocks like "this can't be fast because of trackers" which is passive-aggressive if you're saying it just because you don't like the trackers.