jkingsbery

There's a reason 5 Why's Analysis is a thing. If you just say "here's a bunch of stuff we're changing," but you haven't said enough about the root cause, then no one will understand whether we're doing enough (or too much; or the wrong things). I like the framing of being empathetic - everyone is smart, doing the best they can with their knowledge and experience at the time - but sometimes we didn't do all the right things, and getting feedback from more senior engineers helps drive that improvement.

After doing a talk, my second favorite thing is to get feedback.

My favorite thing (mostly works with internal talks) is to hear people using the ideas I shared or doing some of the action items I talked about.

Isn't Infantino European?

I'm both happy to argue about it, and have someone tell me why I'm wrong.

Since this is at the top of Hacker News: this article is not good advice generally. Here's what I do (and mentor people to do the same):

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.

Mostly agree with this article. When I mentor people about managing, some other bits I also usually mention:

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.

I was in middle school at the time, learning programming. I think by that time, we had home Internet, but it was really slow, and so a lot of my learning about programming was either from the help files that came with the IDE (at the time for me learning Java, that meant Microsoft Visual J++) from books I convinced my dad to get me from Barnes and Noble as a reward for doing the "important" summer reading. I had a couple Java books before, but they were more focused on the mechanics of the language. Your book was the first that talked about how to put together a system.

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.

Not a question, just thought I'd throw out that I worked through Black Art of Java Game Programming when I was learning Java in 1997 or so. I still have my copy because I don't like getting rid of books. I found it really helpful for learning patterns for building medium sized software projects. I hadn't realized that you wrote that until years later when you mentioned something about it in The Startup Way.

Not OP, but within Amazon we have pretty good connectors around integrating with our task system (so you can pretty easily ask your GenAI tool "look up the next item in our sprint board, let me know if you have any clarifying questions, but otherwise start implementing it"). We have decent integration with internal wiki and search systems, so it's easier now to figure out the best Amazon way to do some coding task. And Amazon being a big doc-writing company, there are lots of great tools for helping improve all phases of writing.

I work at Amazon (standard disclaimer: just sharing my own experience, not an official spokesperson, etc.)

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).

Within a few years Xi coined this phrase, China began having a massive real estate sector problem due in large part to speculation: https://en.wikipedia.org/wiki/Chinese_property_sector_crisis... . Part of this speculation (which the article I cite talks about) was due to private Chinese organizations, but it's also in part due to the Chinese government's decisions to overbuild in order to drive urbanization (https://en.wikipedia.org/wiki/Underoccupied_developments_in_...).

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...).

In my experience as a former astronaut, international spy, and traveler to half the countries in the world, the jury is still out.

I am glad most places are getting rid of non-competes. But here is the best argument I've heard for them:

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.

Not sure if this is meant sarcastically or not, but it is - it helps reduce transaction costs of changing employers. Anyone who has ever signed a contract with wide non-competes knows that it is hard for an individual to negotiate against it on an individual basis, but they are rarely enforced in practice, which leaves open individuals to worries about "maybe I'm one of the unlucky few?" These clauses then primarily only increased transaction costs, so eliminating them aids free exchange.

1984 is 22 on the list.

The examples in the first paragraph, while not grammatically passive, are functionally passive. They would be stronger in most cases if the author wrote them with the actor as the subject. For example, yes "the bus blew up" is active, but does not answer who acted on the bus.

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.

This isn't really just a big company problem, lots of start-ups fail too. It plays out a bit differently at big companies, as those failures tend to be more public but also done in a way that lets the company shuffle people around to the next project. There were lots of start-up companies that tried to build social networks or ERP systems or map applications that most people don't hear about.

With other engineers I mentor, I often give similar advice: break the promotion into two steps. The one everyone talks about is when the email goes out. The one that probably matters more is when your manager says: "I'm going to start treating you like <target promotion role>." A lot less attention goes into that step, particularly at bigger companies that have more formal promotion processes.

> The strength of conviction people have about this policy–almost either way, but certainly among those against–seems to scale with distance from the city.

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.

Mostly because of the Maker's Schedule vs. Manager's Schedule (https://www.paulgraham.com/makersschedule.html) issue. It's really hard to be in a role that deals with a lot of randomization and then sit and focus for 4 hours straight on something.

The Last Viking - a biography of explorer Roald Amundsen

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.

"No one goes there anymore, it's too crowded" finally makes sense. Yogi was presciently talking about X, being crowded by bots.

Yes, the case would be stronger with specific examples. However, I did not find it alienating, as examples of these 6 myths readily come to mind. We see people appeal to expertise all the time, rather than using their expertise to explain. There are lots of examples of people trying to "solve" economics problems rather than, as Thomas Sowell puts it, realizing that there are no solutions but only trade-offs.

I had a similar reaction. I plan on using this paper mostly for it's bibliography.

I work at a FAANG (and obviously, I'm not a company spokesperson, just sharing my own experience). Those who are passionate about interviewing internally all seem to agree on not asking leetcode questions. I know leetcode questions get asked anyway, but there's pretty clear internal guidance and training for interviewers saying not to use them.

At least part of the problem is that leetcode questions are easy to ask, and most interviewers don't want to go through the hassle of coming up a question that scales well to the candidate's experience and knowledge.

> “We should phase in new energy sources and technologies when they are genuinely ready, economically competitive and with the right infrastructure,”

On the one hand, that seems like a reasonable approach. On the other hand, if we only have on the order of decades of known oil reserves, we'll have to phase out of oil use at some point (likely in most of our lifetimes), no?

> It’s difficult to type and think at the same time

I'm pretty good at typing, but not anything special, at around 90-95 words per minute. I type while thinking all the time, although usually the thinking is the slow part.

Other have mentioned speed and accuracy, but one thing that has been a huge advantage to me is being able to type confidently enough while not looking at the keyboard or screen (or only checking infrequently). It is pretty helpful to be able to have a conversation looking at the person while taking notes, rather than saying "let me write that down" every 5 seconds, interrupting the flow of the conversation.

I don't know much German, so I can't read the original article.

It would be helpful to know if by "they might otherwise engage in climate protests," the people in question had planned to just say things but otherwise stay out of the way, or if rather the people in question had made public their plans to break laws (like blocking traffic, which many climate protesters have been doing lately). In the one case there is no crime, and governments shouldn't be detaining people just in case they commit a crime later. In the other case, even if someone isn't a terrorist, planning on breaking the law is itself a crime, and it's not "preventative detention."

I had a math professor in college, whom I had for Real Analysis. He told us that one thing that helped him learn was to ask somewhat-obvious sounding questions to try to make connections to things to check understanding. There are at least two good reasons for this: (1) if you don't understand the basic (unsurprising) things, you probably won't understand the more nuanced things, and (2) what counts as surprising varies with the audience.

If someone were to come to me looking for advice along these lines, I'd say: sure, focus on the surprising thing, but it has to be grounded in the familiar, and what counts as "familiar" depends on the audience.

> We have a good leader, which makes all the difference.

I think this is the trick right here. Our paycheck might come from such-and-such company, but really we work for the people in our management chain. I'm currently at Amazon, and I've been pretty lucky with having good leaders, but part of that is because I've had the luxury of being selective (my first director in my time at Amazon was someone I had worked with previously, and when I switched teams I joined to work with someone I knew).