“I know that major API changes are always a pain for developers and they would rather not have to deal with them, but please keep in mind stats like “42% of malicious extensions use the Web Request API” when you’re considering what we’re trying to improve here.”
Google is using a large number—42% of malicious extensions—in isolation to justify a decision. This number shows that a large proportion of ‘bad developers’ use this API. But this single data point gives no clue about how big is the total pool of developers using this API.
Are bad developers a large proportion of users of this API, or are they a tiny minority? In the latter case, Google’s action to deprecate/restrict the API may be fairly justified. In the former case, they could have chosen a better, alternative approach in dealing with the bad actors, rather than punishing the mostly good users.
An analogy for case 1:
Bank decides to close all doors leading to the street because 42% of all robbers walk-in through those doors.
Analogy for case 2:
Bank decides to close all waste disposal tunnels because 42% of all robbers sneak-in through those doors.
All we know is that 42% of robbers come in through a point. We don’t know if it’s the main customer entrance, or the waste disposal.
If this statistic was a big argument for this decision’s approval inside Google/Chrome-Dev, then they really need to revisit their decision-making fundamentals.
I seriously doubt this though. Googlers are very smart. They are dealing with mostly smart people on the outside. This number is not for them or us. This number is being published solely to turn the narrative, for the common reader, from ‘Google blocking APIs that stop ads and tracking‘ to ‘Google blocking APIs that stop malicious extensions‘.
This is what greeted me when I tried to comment on Fred Wilson’s post today.
Fred Wilson wrote about signing up to Pocket, and requested suggestions for becoming a power user. Naturally, I wanted to comment with a plug for my Chrome extension for Pocket. I also wanted to offer my 2c on why I found Instapaper better than Pocket 1.
Removal of the easiest to observe input metric – face time – reduces the availability bias in remote work organisations, and helps them focus on the more productive outcome-based metrics.
This switch to emphasis on outcomes can be helpful for individual productivity, but is truly transformative when the whole organisation goes remote-first.
Behavioural biases confuse performance appraisal in office-based organisation culture
The time spent in office looking productive is a key factor in performance appraisals across teams and organisations. Even when time in office is not a formal factor, it unconsciously creeps in and affects rating scores on other factors.
The outcomes of an individual/team’s work are delayed and often diffused – hard to credit exactly. However, the inputs are visible and trivially measurable. In pursuit of productivity metrics, the manager/organisation substitute the hard to measure outcomes with the easily available input factors (time spent in office, calls made, lines of code) etc. Continue reading Availability bias and the remote work advantage
Income tax rates are based on current/last year’s income. This makes them easy to calculate and implement.
This immediacy of taxes also makes them painful, and makes the tax slab thresholds as artificial barriers to income mobility. An example of this is when we get a raise which pushes us from near the top end of one tax rate bracket, to the bottom end of a higher tax rate bracket. This frequently means that even though the employer is paying us more after the raise, we are actually taking home less money due to a higher tax rate.
Government benefits work similarly. For example, the unemployment benefit / social support payments cut off (or reduce dramatically) when we start working. However, after accounting for taxes and loss of benefits, the take home income from pay is often lower than the unemployment benefits.