Do you want a fork? Do you want to drive more people to Pale Moon? Do you want to become even less relevant relative to Chrome? Do you want to make the web even less user-centric?
A change like this is how you do that. Good job, Mozilla.
You know what also makes you sick? A lack of professional accomplishment, missing respect from your peers, and a general sense of purposelessness. It's easy to look at the costs of ambition and ignore its benefits.
Nicotine is best administrated through gum or a transdermal patch. I haven't heard of many people using it in pill form. Nicotine alone is similar to smoking a cigarette, but not identical: cigarettes also contain MAOI inhibitors which have synergistic effects with nicotine.
Why is it surprising that nootropics exist? Half the good people in tech are on them. And there's nothing fucking wrong with that. "My body, my choice", as the slogan goes.
The specific root cause is Google's practice of promoting based on product launches; it literally doesn't matter whether that product goes on to be successful. This practice creates a strong and perverse incentive to continually launch new products while discouraging iterative development of existing products.
> Google is trying hard to make it's hiring and promotion process objective and unbiased
Google tries very hard to appear to be ethical, unbiased, responsible, and generally virtuous. Sometimes this attitude results in good work. Other times, and I think more often, it amounts to empty posturing and counterproductive gestures. In the social sphere, this "be seen as good" attitude manifests itself as annoying virtue signaling, speech policing, and other behavior that you also see on American college campuses. This behavior is annoying, but very common in tech and easy to ignore.
The "be seen as good" attitude also manifests in technical culture, however. There's this weird attitude inside Google that what is painful must therefore be right, as if difficulty were its own reward. While it's true that the right thing is often painful, the converse does not hold, so Google makes some bad decisions.
Google's attitude toward developer friction is, "This process is slowing you down? Too bad. That's how responsible engineers work." This hairshirt-loving attitude leads to large teams, moving slow, and general risk aversion, and I think it leads to bad engineering-cultural choices.
Google: "This language feature causes problems? Let's ban it. We'll add headcount to make up for the productivity drop."
Facebook: "This language feature causes problems? Let's add tooling to warn developers about the dangerous usages and make sure we can quickly find bugs."
I've worked at a lot of tech companies. I don't think the people at Google are actually any more or less ethical than the people at other top-tier tech companies.
> moving fast is not valued as much
It's important not to underestimate how much moving fast makes you happy and how unhappy you become when moving to a slow environment having worked in one that moves fast.
Facebook's elevation of moving fast to a first-class goal goes a long way to slowing the kind of decay that Google has suffered.
Netflix's stack ranking is a huge turnoff though. Netflix's philosophy is that it has no loyalty to employees and expects none in return. Regardless of Netflix's other attributes, this policy is a huge turn-off.
If I wanted great pay and cutthroat competition, why wouldn't I just work in finance? The finance industry isn't stupid. They have developer efficiency teams too.
I don't think there's a faster way to send me running away screaming. I'd actually take "100% Visual Basic" over "100% Pair Programming" if I had to choose one at gunpoint.
> My suspicion is that Apple / Tim Cook knows something BIG that we don't that they are going to get PERFECT while they still have the cash fire hose of the iPhone to drive the engine.
Possible --- but it seems to me much more likely that Apple is just another big company suffering from the classic combination of innovator's dilemma and big company internal politics. What special immunity would Apple have to the problems that bring down every big tech company in its old age?
Tech companies are like people. They get old. If they don't die suddenly, they eventually succumb to general systems frailty and self-aggrandizing cancers. Sure, Apple might be one of those rare 80 year old marathon runners, but why would you expect it to be?
> Also, the areas in which Microsoft is revitalizing itself are green field projects like the cloud and some other interesting hardware/software integration
The example I have in mind is in a big legacy product. I can't get more specific without outing myself, but it's very far from greenfield.
> Specialized labor does help.
Specialization of labor can also hurt. I've found myself frustrated with security people in the past because they spend so much time thinking about security threats that they start to veto massively useful functionality on very flimsy security grounds. Broad exposure helps too.
> AB testing on wireframes helps and gets most of the edge cases. After you roll out to production things get hairy.
Why? There's no rule that says that everyone needs to see the same UI in production.
> Otto was based from Google expats, one from Google maps and one from the Google self driving car company. Your point is?
It's telling that Google autonomous drivers experts had to leave the company in order to get their work into a real live product.
What about all the hundreds of decades of work lost because extreme risk aversion makes it impossible to add productivity features to GMail for fear of breaking what works already?
Some people like to cower behind "Google scale" as a reason never to change anything. Not me.
I can choose not to work in an environment riddled with "scar tissue". Instead, I can go work at a startup and eat that enterprise's lunch with a tenth of the budget. Unfortunately, thanks to inflexible and sanctimonious attitudes some programmers adopt about what is and is not "responsible" engineering, the only way to change practices is to beat the old practices in the marketplace.
Where are the mods? Does the rule against inflammatory ad-hominem attacks apply only to those holding unpopular opinions?
Believe me, I'm the furthest thing from junior you'll ever see. I don't particularly care what you call me, but I'm produced tons of value.
There's a certain type of mid-career programmer who's obsessed with "best practices" and thinks that anyone who doesn't stuff a program full of design patterns is being incompetent and irresponsible. It's a kind of "sanctimony porn". The attitude is that "if programming is hard for me, it'd better be hard for you too". It's this kind of programmer that shames other programmers for having opinions that result in the creation of simpler code.
> Internally open does not mean that everyone can always see everything though.
If secrecy is rare in an organization, secrecy-induced problems in that organization are also rare.
> I'm not sure I agree with this. I'm a developer, and I'm happier when there are formal rules about human code review, code style, automated testing, and minimal test coverage.
It takes all kinds, I guess. Personally, nothing galls me more than having to follow a rigid set of rules when I know the original motivation for these rules doesn't apply to my situation. I'd make a terrible soldier.
I understand your social contract argument, but IME, the benefit to me of other people writing design documents isn't big enough to justify my having to do it. I find that subscribing to actual code reviews targeting directories that interest me gives me enough ability to see and affect (and unfortunately, sometimes block or delay) changes before they go live.
If your culture is one of secrecy (Google's generally is not), then you need process to effect coordination, since nothing else can. Fortunately, good (IMHO) software companies are internally open, so there's no secrecy forcing them into heavyweight process. Process is one of the many costs of secrecy.
> formalized process
The problem with formalized anything is that it involves writing down rules. When you write down rules, you have to distill complex and subtle human interactions into essentially an algorithm for people to follow. The loss of nuance, while creating clarity, introduces inefficiency, since it forces everyone to follow the same steps even when these steps are inappropriate.
You can't write down exceptions for all the inappropriate cases (but you can for some of them). If you tried to allow for a large number of exceptions, the resulting algorithm would be too complex to follow or it would be vague enough to allow anyone to skirt the rules.
I prefer to avoid formal rulesets for human processes. In my experience, the efficiency loss arising from formal rulemaking has outweighed the gain in clarity. Maybe others have different experiences, but in mine, the higher the quality of developer you have in an organization, the fewer formal rules you need.
Applying lots of formal rules to good developers just makes them unhappy.
Saying that process is a necessary side effect of growth is like saying cancer is a necessary side effect of age.
I don't think you have the causation quite right --- it's not necessity that forces the adoption of process exactly. Process is what you get by default if you don't consciously counteract natural human tendencies in management. A lot of large companies stop consciously protecting their culture, so they get the default big company culture instead. The default big company culture is ever-increasing process.
A change like this is how you do that. Good job, Mozilla.