1. Don't start with the argument, start with the data. Debates/arguments/discussions etc. are what to do about the underlying data, but I've found very often the disagreement stems from people having different bits of data. Before you get into how to marshall an argument, you have to start with collecting what ground truth is. Many people don't practice this intentionally, so they get into a debate over some decision the team is making without having all the facts.

2. Form opinions easily, be ready to discard them quickly. I am quite happy to share my understanding of some technical matter, and I almost always provide that understanding with an invitation for people to tell me why I'm wrong.

3. Over the short term, yes, it's hard to change people's minds. Over the long term, you don't have to change people's minds, you can change the people you work with. You can vote with your feet or (if you're more senior) you can influence how your organization hires and promotes people. I actively seek out working with people who disagree with me in interesting ways. Not pedantically, and not over minutiae, but in ways that change how I see a problem. It turns out, when you seek out people who are good at productively disagreeing, you don't run into some of the problems OP writes about as often.

4. One of the ways to help sift out who the people are you want to work with is by offering feedback. Most people are terrible at giving feedback, so it's important to first get good at giving feedback. The author says that people don't learn from feedback, people learn from consequences. One of the effective ways of delivering feedback is to structure it as "Here was the situation, here are facts about what happened, here is the outcome." However, once you get decent at giving feedback, some of the benefit of giving the feedback is in the signal of how the person responds. The people I want to work with generally take this feedback well, and in turn offer me similar feedback.

5. Debate what matters. A lot of technical debates engineers engage in are either not important to the end product are easy to change later. Don't waste your time on those.

1. 'You’re not “part of the team” anymore.' - You're not part of the software dev team, but if you're doing things right, you're part of a team, just a new one. I encourage manager mentees of mine to read a book "Five Dysfunctions of a Team" which talks about figuring out who your "first team" is. Even in environments where you manage an autonomous team, you likely are working alongside other teams towards some bigger goal. Some of the things that worked being part of a software development team continue to work in the new setting, but you also need a new set of tools.

2. It's a two-way door. I've bounced back and forth between IC and manager roles. Some of it is just how the job market is (you look for a job, there aren't manager jobs, you go back to being an IC). Sometimes, people do it intentionally because they like being an IC. It's ok to try out being a manager, and realizing you don't like it.

A lot of what's here isn't specific to managing, and if you advance in your career as an IC, you'll experience similar.

As a specific example, I had never been exposed to much in the way of networking concepts before. Black Art has a chapter in adding networking functionality to a game which was my introduction to networking concepts and how to build networking software. Until much later when I learned about higher-level frameworks, I used the design patterns for network programming in several projects in school over the next several years.

I can't say that this isn't happening, but at least the parts of the company I get visibility into, what the article describes isn't my experience. There is a lot of interest in using GenAI, but people are mostly getting kudos around creative uses for GenAI, not just for raw amount of tokens. For most scaled GenAI efforts, there is a lot of focus on output metrics (metrics like accuracy, number of findings, number of things fixed, and so on).

The intentions of a government aren't enough. You need feedback systems. China doesn't have effective feedback systems, because the CCP actively destroys them. No one is "turning towards China" - they have negative net migration since 1968 (https://data.worldbank.org/indicator/SM.POP.NETM?locations=C...).

For many companies, a lot of their value is in their intellectual property. Non-competes exist not because the company will enforce it against employees (they might, but they usually don't), but more as a fig-leaf to potential investors down the line asking about the value of the intellectual property. The argument goes, if someone could easily leave the company with the knowledge earned and go to a competitor, then the investment wouldn't be as valuable.

Being so pedantic, and then saying "but I'm not going to use the technical term voice" is particularly off-putting. If this is an article about grammatical pedentry, let's go all the way. Otherwise, the author should focus on providing useful advice.

Writing this from mid-town Manhattan. There are a lot of strong feelings about congestion pricing. It was a common topic in the local media. The stronger voices tend to be those who drive and are affected by it. For Manhattan that is a relatively low percent of the population.

There are some people who are pro-congestion pricing, but as often has with these things the benefits are distributed whereas the costs are concentrated, leading to certain behavior.

The Wager- a book about a ship by the same name which wrecked in the Drake Passage.

Eccentric Orbits - about the Iridium constellation.

The Great Bridge by David McCullough - goes into a pretty good amount of detail in the engineering and sub-problems of construction of the Brooklyn Bridge.