fdsfsaa
A change like this is how you do that. Good job, Mozilla.
> 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.
https://www.fastcompany.com/3056662/the-future-of-work/she-c...
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.
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?
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.
Some people like to cower behind "Google scale" as a reason never to change anything. Not me.
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.
I hope you grow out of this phase.
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.
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.
I'm not suggesting that communication is bad. I'm objecting strenuously (perhaps stridently) to the design document as a step in a rigid process and a requirement imposed from above.
Personally, I'd rather see two teams work toward our improved hypothetical launcher than to see zero teams do that work because process imposed too high an "activation energy" on the launcher experiment.
Also, why are both teams working in isolation for a month? If both teams check in code, the checkins themselves can provide an indication that other people are working in the same area. Incidentally, it's this effect that makes me strongly dislike feature branches. It's better to develop unstable code behind a feature flag, where the code is visible even if not active, than in a feature branch, where nobody can see it.
(It's true that not all changes can be gated behind a flag, but most can be.)
The kind of design document that I frequently find superfluous isn't a specification of some protocol, but a prose description of the code one intends to write.
In concrete terms, an RFC might describe TCP header flags and the TCP state machine, but it'd be silent on the Linux kernel's sk_buff structure. A design document would describe sk_buff in detail.
So again: how does a design document requirement help?
Microsoft has not collapsed. In fact, it's doing better than ever. If Microsoft of all companies can reform itself, so can Google.
> PII and other security implication
When your developers are both smart and invested in the product's success, they learn about these things on their own. Sure, they can make mistakes, but so can some damned review committee.
It's interesting to see how people rise to challenges. If there's a security committee tasked with reviewing the security implications of various changes, developers won't take security as seriously. "That's the security committee's job", they might think. But if you entrust developers with their own security, and they're high quality developers, they'll take the responsibility seriously and do a better job.
(I know I'm making a "no true Scotsman" argument, but I think there's a real qualitative difference between developers you can trust with this sort of responsibility and developers who aren't as invested.)
I don't think you can look at security/PII/whatever problems that a committee catches and conclude that those problems would have made it to production absent the committee.
> That is correct, but based on advancements on technology and materials, what's your point?
The Brooklyn Bridge was designed to be six times stronger than it needed to be for its design load. Modern bridges are only about two times stronger than they need to be. The Brooklyn Bridge needed its large safety factor because suspension bridges were not well understood at the time. With modern technology and design tools, we don't need to pay for a safety factor of six.
Imposing Google-style process in 2016 is like building every modern suspension bridges like the Brooklyn Bridge because the Brooklyn Bridge is still standing. "That's evidence that it works, and the process is roughly where it needs to be."
> For instance, the average east asian phrase is shorter (graphically) than the same phrase in a western language, and that all has to be translated and dealt with.
Pseudolocalization and dogfooding help. I'd argue that rapid iteration helps most on UIs. A/B testing and metrics beat heavyweight up-front design any day of the week.
> Design culture evolves. Google wrote all of its own integration systems, code review tools, and many static analysis tools. Even though they have top class systems, they still stick to the same way of doing things. That's evidence that it works, and the process is roughly where it needs to be.
There's an ever-increasing morale cost. How do you expect developers who have experience in process-light environments to come to Google and be happy? "Yes", nobody says, "I want to go from experimenting rapidly on my ideas to writing internal documents to convince people to maybe let me try something."
> If you actually implement [checklists] correctly, they do eliminate many common mistakes.
It's a lot easier to back out a problem diff than to remove the staph you accidentally introduced into a patient's bloodstream.
Process should be proportional to the difficulty of undoing a mistake. If a mistake is easy to undo, it should be easy to do. If a mistake is very costly to undo, it's worth investing in not making the mistake in the first place.
The vast majority of programming errors are of the "easy to undo" variety.
And by the way:
> [Uber's self-driving cars is] a false comparison. Right now, Uber still has to have drivers behind the wheel, whereas Google self-driving cars strive for a higher level of autonomy. Also, Google has not wanted to get into a directly customer facing role, instead looking for partners to manufacture the cars.
Uber recently delivered beer fully autonomously. In a truck. They're definitely planning for L5 autonomy.
Another trigger could be a reviewer commenting, "Hey, this diff stack is getting pretty tangled. Can you write something that describes how it all fits together?"
You should trust your developers' judgement.
That information is very useful, particularly as a comment or a commit message. Storing this information in a separate unversioned document off on some enterprise management system makes it harder to find. If you put the rationale for a change in the commit message, the rationale is right there when you run blame!
Why should anyone be bound today by decisions made two years ago? Maybe that strategy no longer makes sense.
I've seen it go both ways. On one hand, sometimes a new developer in an old codebase does something "against the grain" of the system due to unfamiliarity or JavaScript-induced brain damage. On the other hand, sometimes circumstances change and even good old designs become obsolete.
A culture of good taste and transmission of institutional knowledge helps preserve the good aspects of design. I don't think design documents help: they're just bytes on a disk. Unless you have people to enforce them, these documents won't do a thing. If you do have people who know what the system is supposed to look like and who shepherd changes to work with the original design, you don't need the design document.