It is not equivalent, but if someone has the time to read the list, I would recommend instead the reading of R. L. Glass "Facts and Fallacies of Software Engineering" [1].

[1] https://www.amazon.com/Facts-Fallacies-Software-Engineering-...

Hi,

If you want to be a generalist, you may want to learn things which are useful independently of the programming language.

Some books that would qualify in my opinion (as examples):

- Code Complete: A Practical Handbook of Software Construction, Second Edition by Steve McConnell

https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...

- Facts and Fallacies of Software Engineering by Robert L. Glass

https://www.amazon.com/Facts-Fallacies-Software-Engineering-...

Learning the different approches taken by multiple programming languages is certainly useful. It may not be that much relevant which language it is unless you want a job specifically in that language.

I can't speak for Google but I guess it is more relevant how familiar you are with software development practices and general knowledge about architecture, design, testing, algorithms to name a few than a specific language.

  and how do you know the others solutions
  are really secure? Linux is going to get
  the most eyes, critics, scrutiny on this
  because is way more widely used ...

This is commonly known as the "given enough eyeballs" fallacy[1]. While it might help when more people have an opportunity to review security critical subsystems, a given OS' popularity certainly does not guarantee this. Heartbleed[2] is often cited as an exemplar for this very situation.

1 - http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

2 - https://en.wikipedia.org/wiki/Heartbleed

Facts and Fallacies of Software Engineering (http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...). It may be starting to get a little dated, so it's hard to say that all the referenced research is still applicable in the same way. But it's a good antidote to a common problem everywhere I've worked: the idea that our team is in some way special or unique in a way that implies reasonable standards of software engineering practice don't apply. It's almost always part of a rationalization cycle that justifies the way things have always been done or some kind of Taylorist management practice.

No wonder I had a hard time finding that Glass book in Google, it's Robert Glass, not Phillip. http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering...

Greg Wilson did a book, which I did not enjoy, on this topic: http://shop.oreilly.com/product/9780596808303.do and a slideshow, which I recommend: http://www.slideshare.net/gvwilson/bits-of-evidence-2338367 .

My take is that there is much to learn from science about how to evaluate propositions regarding software engineering (most, but not all, of them are unsupported) but few new useful ideas.

Another reference along these lines: http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

Also, make sure to read tons about how programmers feel about business guys / managers, and figure out how not to be like those people. There's tons of advice out there, and there may even be some good advice in the most offensive rants. Read those rants, feel the pain of those programmers, and see the opportunity to improve yourself so you don't inflict similar pain.

Some possibly helpful resources which you may have already seen:

http://www.amazon.com/Peopleware-Productive-Projects-Teams-S...

http://www.joelonsoftware.com/ (right sidebar has a ton of articles)

http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

Never meaningfully demonstrated? Have you tried to verify the claim?

Go read Peopleware. You will find described very carefully set up coding comparisons that routinely found a factor of 10 productivity difference between different experienced programmers on the same task, and also a discussion of what organizational factors lead to those productivity differences.

There is other research on the topic as well. For instance http://www.computer.org/portal/web/buildyourcareer/fa035?utm... cites "individual differences" research that found a 30 fold difference between mediocre programmers and the top programmers. That article is supposed to be a distillation of http://www.amazon.com/Facts-Fallacies-Software-Engineering-R... so I'd look there if you want citations into how that research was done and what exactly they found.

A lot of these come from Glass's excellent book "Facts and Fallacies of Software Engineering": http://www.amazon.com/Facts-Fallacies-Software-Engineering-R...

It's quite concise (224 pages), but it's chock full of quite excellent advice. Each one of these points (and many others) is fleshed out in a separate chapter that gives a good deal of background, clarification, and supporting evidence.