baddspellar

I would argue that goodreads is not a particularly good way to determine whether a non-fiction book is worth reading. goodreads reviewers are just regular people who evaluate books based on how much they enjoyed them, not how accurate of useful the books are.

If I'm looking for a book I want to learn from, I scout recommendations from journals, magazines, blogs, respected radio programs/podcasts. End of year "best of" lists are also a good source of ideas. Then I read some in-depth reviews of books that strike my fancy by reviewers who have reason to know what they're talking about. Many of these have 4+ star ratings in goodreads, some don't.

Also, a blanket rejection of books by journalists or other non-experts is going to lead you to miss some really good books. That rule immediately called to mind Tracy Kidder. So, "The Soul of a New Machine" is off limits. Really? No thanks. I can think of many others.

As long as "Percent faculty with terminal degree in their field" is an evaluation criterion for ranking school quality (I took those exact words from the US News and World Report rankings criteria), there is little chance that non-PhD holders will be able to become tenured faculty at research universities going forward. Let's not fool ourselves. Schools work towards higher rankings, as they are rewarded for doing so.

A PhD is a credential, as is a BS, an MS, or a CCIE.

As long as employers demand a credential for hiring, that credential will be necessary. In the US, few companies are willing to take on the burden of training scientific researchers. Further, much of the pure research in this country is done at Universities, and virtually all US universities require a PhD for tenure track faculty. So a PhD is a necessary credential to do scientific research in the US.

The linked article states that Asian companies are willing to invest in training smart university graduates to do research. That means the PhD credential is not required. The required credential is instead a "University Degree".

Now, if the question is whether the PhD system is the best way to create scientists, that's entirely different. There's no reason to believe the University PhD system necessarily produces better scientists than a corporate lab would. University professors are not necessarily good teachers, and University labs are not necessarily well equipped.

It's very similar to the "BS or higher in Computer Science or Engineering" credential on help wanted ads in the US. Does that BS or higher really make you a better programmer than someone who learned on his/her own? Of course not. But it's a credential, so you get it.

Disclaimer: I do have a PhD

Now that's what we're talking about! Good job.

Radical, one-time, short-term actions like this aren't lifestyle changes. They're not sustainable, so they don't work in the long term.

If the author said he made sustainable lifestyle changes I'd have some reason to believe he's won his weight battle. If he said he's been getting up an hour early each morning for the past 3 months to walk, or has been learning how to prepare tasty low-calorie meals and has kept that up for the past 3 months, or has taken up cycling and has commuted to the office by bike every day it would be a different story. I know plenty of people who've done these things and successfully kept their weight down indefinitely.

On the other hand, I know plenty of people who've lost weight with short term, unsustainable diets, and who gained every pound of that back.

I've run software projects on the technical side for going on 20 years now.

In all those years, I've been lucky enough to have exactly 2 good product managers. The rest have ranged from useless to downright harmful

Here's what made the 2 good ones good: They knew their limitations. They didn't imagine themselves to be programmers, architects, or user experience experts, regardless of how many books they read. They never, ever, specified requirements in terms of architecture or implementation. They might give a sketch to clarify what they're talking about, but they'd never defend it as the required (or even a good) approach. They trusted the rest of the team in their areas of expertise. In turn, we trusted them in their area of expertise.

Their focus was on talking to real customers about the problems they faced, finding out why current products (ours and competitors) didn't solve those problems, and getting that information to the people who had skills in building products. When we had something to show, they'd give us feedback based on how well it met the customers' needs, and they'd use their relationships with customers to get some customers to give us feedback on intermediate results. They did research. If they didn't know something, they'd say so, and find out.

They trusted us to give them fair estimates. If something was going to take so long it would miss a market opportunity, they'd work with us to figure out alternatives.

They'd prioritize, and stick to these priorities unless significant new information came along, in which case they'd sit with us to make tradeoffs.

What did the rest of them do?

They'd specify requirements in terms of implementation. They'd tell us how they wanted something architected. They'd attempt to design a UI and tell us the requirement was to implement that UI. They'd trust their gut without doing actual research. They'd promise features in a specific timeframe before getting estimates from engineering.

Does anyone know if they have an active program to cut the bottom performers? If not, I suspect they have quite a collection of overpaid mediocre programmers.

I worked for many years at a company that paid significantly higher than average salaries. Even with a program to cut the bottom 10% per year, we had quite a few people who were mediocre at best.

It's easier for a busy manager to hold onto the people they have than to hire and train new ones. Paying high salaries is an easy way to do that if you have the cash.

"Knowing the code base is a pretty hefty requirement... even seasoned developers don't know everything about their product... so it would be nigh impossible for a Product Manager to do so. It's more important that their minions think they know the whole code base, to try to keep the lazy virtuous developers honest."

I let the "CEO of a product line" slide, but the above comment had me seeing red. A product manager thinking programmers are his minions? I guess it might be true if the programmers are so incompetent that they can't see through a blowhard who pretends he knows the code base.

I don't know the root cause, but something this esoteric would most likely be discoverable only in a code review, or possibly a unit test. It's hard to imagine someone thinking of testing the case of 2 files that differ in every 128 bytes without reading the code.

I have an 11 year old daughter who I help with math homework every week. Some of the new methods work for her, and some are terribly confusing to her. I think it's good to expose kids to a variety of methods in math. I am concerned, however, and the near-complete lack of emphasis on memorizing the basic math tables and doing calculations in your head. Doing that at a young age really helped me to understand numbers. Many of the techniques they teach in school are techniques I figured out on my own by exposing myself to large numbers of calculations.