Well, some people are threats. So maybe sometimes the important first step to fix your anxiety is to start avoiding those specific individuals (as opposed to generalizing the experience with them to everyone).
The woman is clearly not happy. So when you expand your own compassion to cover her, and try to put yourself in her shoes and feel her suffering. . . doesn’t that feel bad?
Maybe it feels bad for a short while... and for the rest of the day you are happy that you are not her?
While the selfish people spend their days annoyed that all their wishes are not immediately coming true.
Launching the first Mars church sounds like a success to me!
Not sure if this is relevant, but when I make subtitles for videos, I try to remove some unnecessary words. For example, if someone says "two plus two is... uhm, equals... uhm, four", I write "two plus two equals four". This is better in two ways: first, no one really cares about the "uhm"; second, shorter subtitles are easier to read.
Yeah, having the group of smart people who can work together is a crucial ingredient, and the attempts to replicate the success with different teams will fails miserably. And the next step is giving those people autonomy. What is the point of hiring people who are smart, good at their work, often obsessed with their work... and then having them micromanaged by someone who probably couldn't write a short shell script if their life depended on it?
The Scrum Guide is basically about how to get rid of managers, without everything falling apart. (All the bureaucracy introduced in Scrum was meant as a replacement for the usual company bureaucracy, not as an extra layer on top of it.) But companies somehow introduce "Scrum" while also keeping the managers and all the micromanagement, only now the developers have to do the extra daily stand-ups (where they do not literally stand up) and the ritual of estimating story difficulty (where the management has already decided that "this has to be done by the end of the month, because we have already promised that to the customer", and you are just choosing which tasks get done during the first two-week sprint, and which during the second one).
(This is a sensitive topic for me, because I actually have a Scrum Master training, and then I see how all companies talk about doing "Scrum" while often doing the exact opposite of it. Whenever a manager tells me that we need to do some pointless thing "because of Scrum", I suppress the urge to scream. But then, if you have a manager, you have already failed at Scrum. A good topic for the retrospective, except you probably don't have a retrospective, because the one thing the management hates is feedback provided in ways that are not under their control.)
And I guess it is similar in science. When you have smart people collaborating, great things happen, you just need to avoid some possible failure modes... such as people doing some esoteric thing for years with zero ability to communicate the meaning of it to the public (which pays the bills) and sometimes even to other scientists. But instead of keeping it at a reasonable level (such as: once in a year you have to publish an article describing your current progress, and I want other scientists' feedback on it) it becomes a game of maximizing the articles.
(Science is also broken on many levels. I know people who publish a scientific journal that contains some good articles and some bad ones. The good articles are worth it, but I asked why they also publish the bad ones, if they know they are bad? Their journal is not famous, so they do not get enough good articles. But why can't they simply publish less? Turns out, journals themselves are also somehow graded by how many articles they publish, so a journal that published only 10 good articles a year would get a worse rating than a journal that publishes 10 good articles and 20 bad articles a year! The numbers are not exact here, but this is the idea.)
In my opinion, the problem with Agile is that most companies adopt the keywords, but do not change their actual practices. Instead, they insist that they are giving new, more pragmatic meaning to the keywords. They would admit that they are not following the rules as they are defined in theory, because they think the theory is not realistic.
This sounds to me different from the situation in science, in the sense that there is no authoritative "Science Book" that the research companies would be clearly violating.
The problem with science seems like "suffocation by bureaucracy", the problem with agile seems like "using the keywords, without even trying to do the substance".
Yeah, two people can read the same Wikipedia page, and get different levels of understanding. The same is true for reading the same AI output. No matter how nicely the AI puts it, either it connects with something in your brain or it doesn't.
In theory, with a superhuman general AI, we could say something like "hey, AI, teach me enough to fully appreciate the thing that you just wrote" (with enough patience and a way to reduce hallucinations, we might be able to achieve a similar effect even with current AIs), but most people probably won't bother.
I wonder, in the unlikely case that the AI progress would stop, and we would be left with AIs exactly as smart as they are now, whether that would completely ruin software development.
We would soon have tons of automatically generated software that is difficult for humans to read. People developing new libraries would be under smaller pressure to make them legible, because as long as they can be understood by AIs, who cares. Paying a human to figure this out would be unprofitable, because running the AI thousand times and hoping that it gets it right once would be cheaper. Etc.
People are different, but I wonder: do you play with the fidget toy while working, or instead of working?
For me, the proper protocol would be instead of working -- the idea is that when I feel some bad emotions about the work, I stop working and start playing, and when I start feeling bad emotions about the toy, I stop playing and start working again.
Yeah, my experience suggests the same. I also had a few good managers... which only made the incompetence of the rest of them more obvious.
Another difference between programmers and managers is that programmers are usually in a flat structure (for example a team with three to seven developers), while managers are in a hierarchy (managers of managers of managers). That means, if one programmer clearly sucks, there are colleagues who can say that openly, and if you assign tasks to them, you will see which ones complete their tasks quickly, and which ones virtually never. That is a feedback mechanism. On the other hand, even if you have a good manager, but his boss is a bad one, well, the job of the good one is to obey the bad one, so there is a limit to what he can do right. You only get a good outcome when the entire chain is good, or when the lower managers are very good at shielding you from what happens above them (which is not always possible).
Who decides what ratio of managers to developers is ideal for a software development company? That's right, the managers! So you get companies that seem to have more managers than developers, the developers are overworked, but there is not enough money in the budget left to hire more developers. Meanwhile, the managers organize more and more meetings, to create work for themselves. (There are dozens of people in a meeting, even if most of them only say a sentence or two. No one writes meeting minutes. Many meetings repeat periodically and a large part of them consists of repeating what was told the last time.)
Yes to all of these points. It is so weird when your boss gets a new boss who talks about his hobby... and suddenly you boss has the same hobby, too. What a coincidence! Or when your IT company is 100% male, and no one seems gay, so you think "okay, this company is an exception, I see no way how sex could play a role here", and then you find out that this guys fucks that guy's sister, etc., and the entire management is practically one big happy family.
One more thing to add:
Developers are often blamed for optimizing for their career over what's best for the company. For example, the developers sometimes insist that the new project try this new shiny technology, regardless of whether that is necessary or not, just because "worked with new technology X" will look great on their CV. Yes, that happens. And guess what... managers play the same game! Sometimes good projects get decommissioned and replaced by new ones not because there was anything wrong with the old project, but because "created a new project" sounds better on the manager's CV than "maintained a project created by my predecessor".