grumpy_coder

That is necessary but often not sufficient. It still leaves the problem of moving time from where garbage is created to the bulk 'collect' step. I've run collect every frame to keep stalls down, but the time always creeps up and up and you end up doing forensic analysis of which code is making the garbage in the first place.

This is more of a problem than it seems at first. At one place I worked that did mini-project interview most of the hires were currently unemployed and could spend all week on it. (then claim they did it in 3 hours)

This is a heavily massaged story built for a life long politician. (One hole in the story is only giving I think his mothers family background. There was clearly ~500k to buy a pharmacy early after 'penniless' immigration)

Though it's not finding the article. It's finding a link to the article on Reddit. I hope people aren't linking to the Reddit thread...

Are we sure this isn't just because lone developer projects are more likely to have the whole dev team gone when you want to ask questions?

Except the company cut has been getting bigger and bigger for the last 40 years.

Productivity has increased and wages have not.

Very much agree with this comment, creating and gaming KPIs is at the heart of most DEI departments now.

We do need long term improvements at the start of the funnel, but no-one is adding a 7 year KPI for improving stats of 14 year old girls quitting AP math.

Or more generally, how does doing the simple low complexity thing benefit them? If you are a manager who wants your reports to just do the work that makes your job easier and you look good then you are in for a long hard road in most corporate environments.

People should at least read about 'paint drip' people https://www.linkedin.com/pulse/paint-drip-people-jack-many-t...

I'm not really clear if David Epstein merging the two ideas is the 'true' idea of T-Shaped people in the hive mind of the internet or not.

tldr: T-Shaped could include multiple specialties (which make it not look much like a T)

The practice of having most 'final' decision making at some SVP level is stupid on its face. I can see a need for tie breaking between two teams, but the person who spends 4 hours a year thinking about a project needs to butt out generally.

Draw some circles and arrows in PowerPoint Then two years later claim to have built everything

Book has interesting parts, but seems to be trying to cover too broad a field, offering little of the tradeoffs promised in the title.

Is is often very opinionated about a highly technical area where the answer is always 'it depends', offering little balance of opinion before rapidly moving on to the next unrelated topic.

e.g. Somewhere in a section on API versioning is the statement - "Modern services should generally be designed with no downtime required when updating the servers to a new version."

As a grizzled developer in 2021 I would disagree with that, 24/7 365 up-time is hard and expensive, if the service doesn't require it then don't do it. There is a tradeoff between developer effort supporting multiple live versions and synchronization between teams to just stop the service and update everything.

In the authors context it may be true, but the book is titled tradeoffs and all too often only offers the architecture astronauts uncosted ideal world opinion.