There have been multiple leakers from the various US national security industrial complexes since Snowden. It's hard to spot unless you're really paying attention, but it's clear that it's happened several times now - I think we're up to at least three other leakers, all of whom are anonymous. You can tell because the info comes from non-NSA agencies, or the material is dated after Snowden left, or (most subtly of all) the articles don't attribute the source of the leak to Snowden.

So it's not obviously useless. There are people leaking anonymously. Though for obvious reasons they don't tend to shout from the hills about it.

For context, I develop complex scientific software. We use the browser (desktop) as our client and push the limits of what you can do there.

That's the problem with web development. People are always pushing the limits of browsers. Nobody used to talk about "pushing the limits of the Windows API" back when I used to write desktop apps in Delphi, because it hardly limited you.

At some point our industry has to get past this collective web fetish. The browser was never intended to run apps. Trying to use it as an app platform results in stuff that's horribly bloated and bug ridden, with decades of accumulated experience in how to write good software just thrown down the toilet because HTML5 got fashionable. When was the last time a mobile or desktop app had an XSS exploit?

Back when I was a lad, we knew that an "email address" was like a physical address - useless unless people know it. People even made them publicly available on the web!

Yes, spammers abused this. But hiding addresses hardly helped. So many addresses have been dumped or dictionary brute forced by now it's hardly a big deal if your email address appears in one more place.

So colour me unexcited by this terrible misstep.

That's like the opposite of what happened.

Pakistan does not exist because of the machinations of the British. Rather, Pakistan came into existence due to the withdrawal and general shutdown of the British Empire, which like many occupations was suppressing tribal and ethnic dissent in order to keep their territories together. The moment the Empire (which was weak and failing at this point in time anyway) released its hold on the country there was a huge bloody massacre and a civil war ("The Partition") which resulted in the creation of Pakistan.

So it's not like the British stood around and encouraged Muslims and Hindus to fight each other. They did that all on their own.

You laugh, but old school rotary phones could still call for emergency help if the power went out, they didn't hang, they didn't get viruses, they didn't get firmware "upgrades" that stopped them from working properly or at all, they didn't run out of their own batteries in the middle of a long call...

For once, I'm 100% in agreement with Khyber. Smartphones in a world with modern laptops, tablets, headsets and feature phones just look like a mediocre compromise to me. About the only thing they seem to be better at than any of the numerous other devices available is letting someone check Facebook every 10 seconds without actually having to take anything out of a pocket. At least until someone updates something remotely for them and breaks that functionality, anyway...

It sounds like you're a little older than me but we both see this much the same way.

I have as much interest in useful or interesting new technologies today as I had when I was 21. I'm also significantly quicker at getting up to speed with them and more aware of things like pros and cons and the importance of choosing the right tool for the job than I used to be at that age.

However, if you asked me right now, I'm quite sure that I couldn't crank out a new TodoMVC example in this week's front-end JS framework as fast as a 21-year-old who just learned it can. Since not a lot of people solve real problems or make real money writing toy to-do apps, I don't find this situation too threatening. ;-)

The thing is, I've long since stopped being impressed by this week's front-end JS framework, this week's UI trends and visual design language, and this week's new programming language that looks and feels like C or JS with a thin coat of paint over it. I could get up to speed with them to the point where I too could write to-do apps in half an hour, but to me that's like deciding to learn some new GUI toolkit just to write Tetris or learning some new database API just to write a PIM or whatever we're calling them these days. As you say, these kinds of tools are so ephemeral now that they tend to be very trendy and generate a lot of hype, but they are often popular more because of some big sponsoring organisation than any particular innovation or technical merit.

To me, about the only thing more dull is evangelists for a specific browser (why?!) telling us all about these great new features it has for writing large-scale applications... when the biggest web apps out there still tend to be orders of magnitude smaller than stuff many of us "old programmers" were working on in the last millennium, at which time some of those features actually were quite innovative.

Next week, all these elite young programmers, who are leaving people like you and me and our meaningless track records of building actual working and revenue-generating projects in their wake, will probably notice that MV* is not the only possible UI architecture, that building an application that has to run for years around a framework that has a shelf life measured in months might not be such a great idea, and that JS is actually a very bad and very slow language that just becomes not quite so bad with the ES6 changes and only moderately slow with modern JIT compiling engines.

Just don't tell them that the entire web apps industry probably represents closer to 5% of the programming world than 95% and some of these state-of-the-art ideas are actually 50 years old. Such talk is the stuff of nightmares, and they aren't old enough to hear that kind of horror story yet. ;-)

You might consider that there are at least two plausible explanations for this.

1. Older people can't or can't be bothered to keep up.

2. Older people can keep up just fine, but actively choose not to use certain new technologies or to avoid them for certain types of projects because in their judgement those new technologies aren't the best option for what they need to achieve on those projects.

There are plenty of both types of older developer around in the software development industry. Obviously one type tends to get more useful work done. Unfortunately but inevitably, inexperienced developers frequently mistake one for the other. Knowledge and wisdom are not the same thing.

The context is US employees. The majority of employees are in the US

No it's not and no they aren't. Most Google employees and most Google revenues are outside the USA.

Name your country with a significant number of Google employees in which Google routinely hires people who do not speak an official language of that country, please.

Switzerland, as just one example.

Young people are working long hours, as you said yourself. Those young people are not staying, as the data confirms

Jesus christ, you're bad at this. The data doesn't say that. Google has very low attrition rates and always has. If all the young people were burning out and leaving the average age would be higher than it is, wouldn't it?

Google are low on gender, age, and race diversity compared to nearly every other tech company

You haven't shown that, or even begun to lay the groundwork for that. The demographics of Google engineering are pretty similar to the demographics of people taking CS courses at universities, which should not be surprising to anyone.

Like a few of my friends who walked away from the Google interview process, the moment I started hearing discussions of fitting into the "culture", I saw that it was a business comprised of smart but narrowminded techs who did not really know any better

All organisations have cultures, it's inherent to any group of people that's allowed to be selective. If you don't believe this then all that suggests to me is you work at a place where you fit in well enough that you don't recognise that there is a culture at all.

Who said anything about the USA? You realise Google has offices all over the world, right?

And who said anything about burning out? You're the one who decided that must happen. I've not seen any burned out young people at Google. The only burnout I knew there was a guy in his 50s.

And the only "evidence" of discrimination in hiring comes from this article, which is deeply questionable. Amongst other things it assumes every employee at Google does software development, which is very far from true (there is a massive sales division that skews young for the same reason bar staff do - it's not a very appealing long term job).

Yes, you're right, in America that must definitely be a component of it. I'm from the UK where political parties get a lot of public funding so the influence of money is less overt (it still happens).

It's sounds bizarre but could have happened. Some people do crazy stuff to get a job there. When I was an interviewer there, part of interview training was learning tricks to detect candidates who were looking up answers on the internet. Sometimes you could ask a question and hear them typing in the background.

The article says the interviewer requested him to read the code out over the phone and that the interviewer was barely fluent in English. Those are two massive red flags that something odd was happening.

Google has a large pool of interviewers and some of them are better than others. There's no doubt about that. But in many years of working there I never encountered anyone with less than excellent English skills, and I cannot imagine anyone asking a candidate to read code out over the phone. That's just an obviously stupid thing to try and do, especially when the candidate offered to share it via Google Docs. SOP there is to send the candidate a Docs link for shared coding together, but even if something went wrong with that process, when the candidate offers to fix it that sounds and the interviewer refuses that sounds very much like he wasn't really talking to a Google employee. Think about it - if the person on the other end of the phone was a MITM then he'd need to have given his own very obviously non @google.com email address to receive the document. Busted.

I always joked that if you ask me to write a sort routine in the interview, I'm going to lecture you about why you need to go off the shelf, and doesn't Google have anyone who can make a shareable library? Do we really need to know how to code a lightning sort ad hoc? To sell more ads? heh

Then you wouldn't get hired. Former Google interviewer, 220+ interviews. I used to pretty frequently ask candidates to solve the following problem: write a program that loads lines of text from a file, shuffles them, and writes them back out again.

The reason companies like Google ask ridiculously academic questions in interviews (and that question is academic) is not because they're all ignoramuses who can't imagine anything outside their PhD box. It's because judging someone's technical and programming ability in under an hour any other way is really freaking hard. If you haven't done a lot of interviewing then it's easy to imagine, "If I were hiring, I'd only ask questions that REAL programmers would solve". But then you try lots of different kinds of questions and discover that for most of them, by the end of the interview you often have no real clue about whether the candidate can actually write a functioning program. CVs and qualifications are no help - they routinely seem to have no correlation with actual demonstrated skill.

Speed-coding whilst someone is watching you in a high pressure environment is difficult at the best of times. Doing it from scratch for any kind program of you're likely to actually write in the real job is impossible - nobody codes up a fully blown web app with the latest stack de jure (which Google doesn't use anyway) in 45 minutes. You don't even know what languages the candidate knows, in some cases, as not everyone thinks to put them on the CV. So you end up asking for a small, simple program that shows basic knowledge of basic language constructs like looping and different kinds of lists. Then there's time to write some code and ask questions about it. Additionally, there are multiple "off ramps" so even slow candidates don't feel like they are running out of time and panic, but faster candidates can keep being challenged with minor modifications to the task.

For what it's worth, if someone answered this question by writing a program that ran Collections.shuffle() or their chosen languages equivalent, that resulted in them being marked up not down, because you're right - knowledge of standard libraries is important and a good sign of experience. Then I'd ask them to do it again without using the standard library because I also want to see if they can write the code themselves. Using the most correct or optimal algorithm is not the goal, even if the question sounds algorithmic. It's just a scenario to get them doing things with data structures and basic control logic.

For what it's worth I am skeptical about the ages in the summary. If the average age at Google is 29 then that pretty much matches the average age across 25,000 developers on StackOverflow, which gave an answer of 30. However I suspect that the median age in engineering is higher if you take into account tech leads and technical management, and the age for the entire company is biased lower by the enormous ad sales organisation. That always seemed to me to be populated entirely by recent university grads. Selling ads is hardly exciting work with great potential for career advancement and doesn't require any specialist skills, so the people who do that tend to be young, and there have historically been massive numbers of them (like half the company).

So, you're confirming that young employees are overworking, which is the first part of the hypothesis, although then you go into a marketing style tangent with, "It's just that they are so excited that they don't want to go home!!!" That sounds pretty unhealthy to me, especially given the present evidence of attrition suggesting that it is not a sustainable way of working.

It's not marketing, it's the truth. I worked there for nearly 8 years. By the way, I'm 31.

Google is (a) a very desirable employer and (b) hires people from all over the world. The combination of these things mean that many, many developers, especially younger ones that move from poorer countries, get relocated across borders. They arrive in a new country where they don't speak the language, quite often with a girlfriend or wife in tow, and frankly many of them don't quite dive into making friends and socialising as much as perhaps would be a good idea. Combination of new city, no social life + interesting work == lots of people working odd hours. Eventually they do settle down and the hours get more normal.

But programming has always been this way, hasn't it? I never heard a lawyer say, "I've been doing lawyering since I was 8 years old" but it happens in software all the time. It's a sort of work that many people just enjoy doing, and do it as a hobby as well as a job.

That's partly because by somewhere in their 30s, a lot of the good programmers aren't working for someone else on salary any more. They're working freelance and picking their gigs, or they've founded their own business(es), or they've specialised and now do contract work with a combination of programming and industry-specific knowledge and skills.

In each case, they are probably earning at rates much higher than almost any salaried employee at almost any employer. Notice that in all of these scenarios the rates you can charge are based on real value generated, which doesn't have a glass ceiling the way wages usually do.

Good programmers who are still working for someone else as a full-time software developer at 40 probably have their own reasons for choosing that career path. Those reasons will often mean they aren't particularly looking to move either, and if they are, they're not going to do it by sending out numerous CVs to different employers the way a new grad does.

Who do you think is creating those modern programming languages, kid? :-)