Instruments.app is the official way to access performance counters. I believe it can use a few more (non-whitelisted) events, which are described in /usr/share/kpep/a14.plist - I couldn't figure out how to hijack the single-consumer API that I think it's using. (Edit: it seems it just shows non-whitelisted events in the GUI, but doesn't let me use them.)
If I were to take one book with me "down into the bunker," as Dartnell puts it, I'd hands-down take with me the Bosch Automotive Handbook[0], a phenomenally dense and thorough text covering not just cars, but their constituent parts--and their constituent parts' constituent parts--all the way down to the materials. It has wonderful tables of data on the properties of various materials (from advanced plastics and alloys to leather, paper, and common fluids) accompanied by clear and precise mechanical diagrams. It's precisely the kind of book that would secure a time-traveller's position as court wizard, all geared (ha) toward the eminently practical domain of moving across the surface of the earth.
A vaguely related notion is that naive analysis of big-O complexity in typical CS texts ignores over the increasing latency/cost of data access as the data size grows. This can't be ignored, no matter how much we would like to hand-wave it away, because physics gets in the way.
A way to think about it is that a CPU core is like a central point with "rings" of data arranged around it in a more-or-less a flat plane. The L1 cache is a tiny ring, then L2 is a bit further out physically and has a larger area, then L3 is even bigger and further away, etc... all the way out to permanent storage that's potentially across the building somewhere in a disk array.
In essence, as data size 'n' grows, the random access time grows as sqrt(n), because that's the radius of the growing circle with area 'n'.
Hence, a lot of algorithms that on paper have identical performance don't in reality, because one of the two may have an extra sqrt(n) factor in there.
This is why streaming and array-based data structures and algorithms tend to be faster than random-access, even if the latter is theoretically more efficient. So for example merge join is faster than nested loop join, even though they have the same performance in theory.
When teaching mathematics I like to always mention that the greats like Ramanujan, while it seems like they just knew everything from pure thought, they all actually did a ton of work by hand. Ramanujan in particular is known for his fastidious notebooks calculating thousands of digits numbers like pi. From writing out the calculations for hours and days, he'd come up with simplification formulas and develop new insights. These days, we have a tendency to just look at the formula and go "wow, how the heck did the think of that?" Well, what we would call "busy work".
Do the busy work. Do the calculations. Write it all out. Nobody is better than the busy work: it pays off and it's how you learn.
The problem with stack ranking at places like microsoft was twofold. First small team managers were forced to rank their reports, and each manager had to get rid of the bottom 10% each year. If you had 20 employees you had to fire 2 employees each year. But statistics doesn't work like that, there were many microsoft teams with all productive employees. And there were probably teams where 30% of the group should have been moved/retrained/let go.
The second is that people respond to incentives. So a manager might make a bad hire because so they don't have to fire any of the people they like. The team might not help someone struggling because they need a sacrifice every year. And finally people might trade to barely avoid the bottom 10% (if you'll make this decision i want, i'll rank you higher). Then the people you are keeping are the low productivity, agile political operators. And a low productivity highly political worker is 10 times worse for productivity than the plain version of low productivity worker.
There doesn't seem to be any indication that Amazon is forcing this kind of decision on small teams. On a larger scale of 1,000 or 10,000 workers it makes sense to track if you are losing people that you don't care about losing or "un-regretted attrition". It's also good to have a process where a manager says "this person isn't doing well" and HR says "tell them what they need to improve and give them a few months" (or find them a different position). And the manager says "hey that worked" 2/3 of the time and then fires them when it doesn't. Otherwise you end up with sudden surprise firings or managers who never fire anyone.
Every single fabless semiconductor designer failed to predict demand because their customers lied to them. The car industry pulled a really dick move last year, and then pulled an even more dick move in the opposite direction, and now everyone is screwed. Back in early 2020 the car manufacturers decided that demand for cars would go down, and because they have a religious aversion to keeping any stock, cancelled lots of orders with their vendors, screwing said vendors over. Their vendors could not afford their fab slots because automotive is such a big part of their revenue, so they cancelled their fab slots. Those slots were happily sold on to entertainment and computing customers, who anticipated a jump in demand due to people staying home more. So far so normal.
However, the car industry got it badly wrong - people, afraid of public transit, started buying more cars rather than less. The car industry, being screwed due to their just-in-time religion of zero stock, was faced with their production lines stopping so they called up all their vendors, and asked for those orders back, and some more on top. The vendors then tried to get their fab slots back, and were told to come back next year. Some of them ended up buying other fabless IC designers out of their slots, causing the problem to spread. Others cancelled their existing orders to other customers, and auctioned off their existing inventory to increasingly desperate car manufacturers at a 6x to 8x premium. Anyone who was not prepared to pay that or didn't act fast enough was screwed. From that point on, a bunch of companies that depend on those lines of microcontrollers had to rapidly redesign their product to use another device, taking even more devices off the market with unplanned demand. The users of those devices then had to move to others, causing even more availability cascades. This is how two nasty moves by the car industry caused global market disruption in a number of industries that depend on electronics. This is not a normal "demand has increased, and industry can't keep up" event, it's elephants dancing and trampling everyone else underneath.
This is further aggravated by the top three automotive semiconductor suppliers (NXP, Renesas, Infineon) having their facilities destroyed in two unrelated disastrous events - a fire at Renesas' wafer processing plant, and Texas freezing over, destroying NXP's and Infineon's fabs through cleanroom contamination and process interruption. Those events took out months' worth of production, and destroyed product that had already been sold before manufacture. This would have been recoverable in a normal market, because distributor stock could hold a couple months, but in this case it was game over for non-automotive customers as all distributor stock was already gone by then.
I see this in my work every day now - customers coming to me for help with redesigning products to use a different microcontroller, or help with sourcing parts from unusual sources because their normal channels are gone. I've been in this industry a long time and never seen anything like this before. This is not a failure of supply chain analysis and projection on the part of the fabless semicon vendors. This is their biggest customers fucking their vendors over not once but twice by lying to them about their own demand.
https://news.ycombinator.com/item?id=39316653
https://news.ycombinator.com/item?id=39316653
https://news.ycombinator.com/item?id=37021837
https://news.ycombinator.com/item?id=36922114
Some good recs in the above threads. You'll be able to learn and thrive with those, IMO.