If you have a staff full of time-servers, implementing a no-exceptions rank-n-yank that kick out the bottom 10% without exception is the right thing to do. God knows I've worked in a few companies that would have benefited from a few iterations of that. But if you on the other hand have a staff that is essentially competent and motivated, a rigid system like that is going to do more harm than good as the staff compete to stay on the top of the pile by whatever means necessary. And in the process, not much useful work is getting done, but everyone looks very alert and busy. It's a hard problem, with no perfect solution. Solving such problems is why companies pay smart, experienced, successful people big bucks. If only more of them could sort out problems like this...

Once a year (optionally twice), every Google employee completes a structured self-assessment about what they've done since the last performance review, what went well, and what should have been better. They then solicit feedback on this report from a handful of colleagues they've worked with. These colleagues are typically on their own teams, but not always. Generally speaking, comments from more senior employees are encouraged; pretty much everybody asks their tech leads to comment. Managers then write assessments of each employee's work based on the reports and peer feedback, producing a grade from (2.5, 3.7, ...) and prose comments.

The process itself isn't that unusual, but Google undertakes it in a very ponderous heavyweight manner. The peer feedback takes quite a bit of time to write, particularly for senior engineers. And Google insists that managers vet the grades they give through a complex series of calibration meetings up and down the company, with the goal being fair and uniform assessment for comparable positions. The grading is also very fine-grained. There can be a lot of discussion about whether someone is a 3.1 or a 3.3. The process takes nearly two months end-to-end, in part because it is combined with promotions, which are scrutinized even more closely. Engineers love to bitch about "perf", and the long-term trend is toward a simpler, lighter process.

My take on the matter is that Google tends to be very deliberate and bureaucratic in what it considers truly vital activities. Hiring, for example, is very slow and formalized. Checking in code can require a quest of approvals, tests, and automated verification steps. The performance review process is therefore slow and ponderous because Google wants to be very sure it is making the right decisions in performance assessment and promotion.

I work for Google. 20% time is unpopular, undertaken by single-digit percentages of engineers. Despite that, the message coming down from management is generally positive.

My sense of the issue is that a lot of engineers are spooking at shadows, worried about their performance reviews if they spend 80% of their time on their teams' main business rather than 100%. The solution to this, as far as I am concerned, is to make sure there is someone who is willing to stand up and say positive things about your project at review time. Since Google has an intricate system of peer review, that should be enough.

And if you can't find _one_ person who thinks your project is a good idea, take some time to figure out what you are hoping to accomplish before continuing.

Contacting the earlier developers is good advice.

Unfortunately the OP doesn't say how much code there is. Understanding 10K lines by reading the source code is feasible; doing so for 1M lines isn't. Documentation is of some use, but it's typically scant and years out of date. Really, the best guide is an explanation given by someone who already knows the codebase.

A good way to proceed here is to spend a bit of time digging around the codebase by yourself, write up a proposal for some significant improvement, and send it to folks who were active when the project was up and running. With a bit of luck they'll reply with criticism and suggestions for improvement.

I predict we'll eventually require some kind of licensing and periodic hardware/software security inspections in order to connect a machine to the internet, and somehow impede traffic from countries that don't undertake similar measures. Yes, it will be a pain, but plenty of countries impose periodic certifications on cars, and this wouldn't be that different. It will also make Stallman's head explode from pure rage, but it will kill the botnets, probably.

What is the most recent genuinely useful educational technology? Word processing, maybe? That's a good generation old, now.

It seems like technologists are very keen to apply the latest and greatest to education, when plain-old pencil and paper mostly work fine.

Google is riding high right now, and has its pick of talent. Right now they can say no to even very capable people, since there's plenty more beating on the doors.

But no company stays on top forever, and I expect Google has pissed off some very capable people by telling them no. That could be a bit of a liability when Google declines a step or too, and has to go looking for staff.

Well, I don't know the case law, but I doubt mere non-cooperation constitutes "interference". He didn't prevent the cops from doing something, he just refused to help.

Also, I'd love to know how that bit about dangerous animals ended up in the statute. I suspect there's a bit of history there.

Most jobs suck to some extent; they're either strenuous or boring. And really, that's why you get paid to do them. The fun stuff people do for free.

That applies even to activities that are in and of themselves fun. Plenty of people like to play music. Relatively few enjoy the sheer mindless repetition of playing the same old standards night after night.

I figure you're doing well if a quarter of your workday is fun or interesting.