Companies and wealthy individuals don't fund the same research as the government.
The government funds research that other scientists think is important. That's long term, often not flashy, meat and potatoes kind of stuff.
Companies tend to have very short time horizons. And wealthy individuals want splashy things. None of these are an option if the federal government is going away.
10-15 years ago my foreign grad students all wanted to stay. Only question was how.
There was always a big crowd who found the process of staying in the US painful, random, humiliating, and sometimes even downright abusive, so they went home.
What has really changed is China. That's what this paper shows too. Many of the Chinese students want go back home.
10-15 years ago when I would talk to grad students from China most wanted freedom and democracy. Now most tell me about how the Western system has failed and how a centralized government is more efficient.
Between making it harder to stay, China changing the narrative on dictatorships, and the West doing a horrific job in the last decade on pretty much every front, yeah, we're going to see a lot of folks move back.
Even 10 years they wanted to stay. I was at Microsoft China at the time, and management would complain about Google or Facebook in CA still getting the best prospects from Qinghua/PKU. It wasn't about freedom or democracy at all, they just wanted big paychecks without the 996.
Today it is an easier case to stay, although 996 is still a thing. Still, if you can make your FU money by age 35 (and it still has to be by age 35 according to a relative), you have it set.
There was no "change of narrative", the West just stopped delivering, similar to what happened to the Soviet system starting with the 1970s (and which ended the way it did by the early 1990s).
This is terrible advice that will hurt your career progression. The problem isn't that people speak out too much. It's that basically no one is proactive enough to speak out. In my experience the people who speak are the people who get promoted.
Knowing when to shut up is great advice and knowing how the wind is blowing. If I know their is an edict from the top down to be an “AI first company”, no matter how much I disagree with an initiative that comes from on high, I’m going to shut up and be all in.
“The avalanche has already started. It is too late for the pebbles to vote.”
The last time I worked for a product company was as at a startup where I was the second technical hire by the then new CTO who was building up the technical staff internally. The founders bootstrapped the company through an outside consulting company.
There I had a relationship with the CTO where I could just say “that’s a really bad idea” and he would listen.
Fast forward a few years and I was working for a shitty consulting company, I kept my head down for a year, let them fail after I was sure they wouldn’t listen to me and started interviewing and only stayed a year.
My career progression isn’t dependent on the job I have at the moment.
As someone who is an expert in the area, everything in this article is misleading nonsense, failing at even the most basic CS101 principles. The level of confusion here is astounding.
> People were saying that this meant that the AI winter was over
The last AI winter was over 20 years ago. Transformers came during an AI boom.
> First time around, AI was largely symbolic
Neural networks were already hot and the state of the art across many disciplines when Transformers came out.
> The other huge problem with traditional AI was that many of its algorithms were NP-complete
Algorithms are not NP-complete. That's a type error. Problems can be NP-complete, not algorithms.
> with the algorithm taking an arbitrarily long time to terminate
This has no relationship to something being NP-complete at all.
> but I strongly suspect that 'true AI', for useful definitions of that term, is at best NP-complete, possibly much worse
I think the author means that "true AI" returns answers quickly and with high accuracy? A statement that has no relationship to NP-completeness at all.
> For the uninitiated, a transformer is basically a big pile of linear algebra that takes a sequence of tokens and computes the likeliest next token
This is wrong on many levels. A Transformer is not a linear network, linear networks are well-characterized and they aren't powerful enough to do much. It's the non-linearities in the Transformer that allows it to work. And only Decoders compute the distribution over the next token.
> More specifically, they are fed one token at a time, which builds an internal state that ultimately guides the generation of the next token
Totally wrong. This is why Transformers killed RNNs. Transformers are provided all tokens simultaneously and then produce a next token one at a time. RNNs don't have that ability to simultaneously process tokens. This is just totally the wrong mental model of what a Transformer is.
> This sounds bizarre and probably impossible, but the huge research breakthrough was figuring out that, by starting with essentially random coefficients (weights and biases) in the linear algebra, and during training back-propagating errors, these weights and biases could eventually converge on something that worked.
Again, totally wrong. Gradient descent dates back to the late 1800s early 1900s. Backprop dates back to the 60s and 70s. So this clearly wasn't the key breakthrough of Transformers.
> This inner loop isn't Turing-complete – a simple program with a while loop in it is computationally more powerful. If you allow a transformer to keep generating tokens indefinitely this is probably Turing-complete, though nobody actually does that because of the cost.
This isn't what Turing-completeness is. And by definition all practical computing is not a Turing Machine, simply because TMs require an infinite tape. Our actual machines are all roughly Linear Bounded Automata. What's interesting is that this doesn't really provide us with anything useful.
> Transformers also solved scaling, because their training can be unsupervised
Unsupervised methods predate Transformers by decades and were already the state of the art in computer vision by the time Transformers came out.
> In practice, the transformer actually generates a number for every possible output token, with the highest number being chosen in order to determine the token.
Greedy decoding isn't the default in most applications.
> The problem with this approach is that the model will always generate a token, regardless of whether the context has anything to do with its training data.
Absolutely not. We have things like end tokens exactly for this, to allow the model to stop generating.
I got tired of reading at this point. This is drivel by someone who has no clue what's going on.
> This isn't what Turing-completeness is. And by definition all practical computing is not a Turing Machine, simply because TMs require an infinite tape.
I think you are too triggered and entitled in your nit-picking. Its obvious in potentially limited universe infinite tape can't exists, but for practical purpose in CS, turing-completeness means expressiveness of logic to emulate TM regardless of tape size.
I was saying the same thing you were, this is the original post:
> If you allow a transformer to keep generating tokens indefinitely this is probably Turing-complete, though nobody actually does that because of the cost.
Either they're equivalent to Turning machines or not. Claiming that practically they aren't because no one runs them long enough defeats the very notion of a Turning machine in the first place.
I'm shocked a post like this that isn't even at the level of an intro to computation class is getting attention.
If people actually read history books we'd make much better decisions as a society.
No. Water and electricity were not mandated in a magical past where the government was awesome. The government has been captured by corporations and special interests forever. The level of corruption in the 1800s was astronomical compared to today.
People fought for those rights. Often literally. And they still don't exist in some places.
Arkansas just passed a law that you need a working roof, electricity, heat and water, in 2021.
So no. Sitting around lamenting a past that never existed won't get us anywhere.
Oh yah I remember that time when government was so captured by corporations that they forced the politicians to institute a 90% tax on incomes above $3 million
I don’t think that an awareness of the past is suggested because the past was great. I think it’s because seemingly good ideas weren’t, so it’s a chance to avoid repeating mistakes.
None of this makes a lot of sense. Validation errors are largely irrelevant for LLMs and they can understand them just fine. The type structure looks good for LLMs. You can definitely pretty print a schema at runtime.
> In short, you manage people. You tell others what to do and you think about what to do.
As a principal scientist I definitely don't manage people.
Mainly, people managers have power to tell people what to do and when. I have zero power over anyone. No one needs to listen to me. Ever. If people ignore me there's literally no one I can complain to. And no one tells me what to do. If I wasn't competent at my job I'd be sitting alone in an office staring at a wall.
The reason why anyone would ever talk to me is because I have well over a decade of experience more than every other scientist in my org (200+ people) doing very complicated things, at scale, across many areas of AI/ML, and publishing many dozens of papers in top venues. So I know what I'm doing and can find problems, shortcuts, keep them from wasting time, find creative fixes to AI/ML issues, and see connections to business problems. Basically help scientists deliver better features faster. I can find new projects that those scientists are excited about. And I can communicate with product, managers, leaders about very complex technical ideas in ways that more junior scientists cannot.
People in my org come to me because I provide value basically. Not because they have to.
> You tell 10x people to do 10x work and you get 10x the credit when management only is like 1x of talent and effort.
If only! 70% of the work I do is invisible small course corrections here and there across multiple orgs that fix things no one ever hears about but would be disasters down the road. 20% is working on projects that scale with many people. 10% is strategy for new experiments and projects.
For the vast majority of what I do other people get 100% of the credit and my name is a small footnote at best.
Maybe an example would help. Sorry that I need to be a bit vague. A large project recently was going in a particular direction. I saw two months ahead of time that this direction was going to run out of steam for a combination of science and business reasons. It would end up missing metrics. Leadership was asking for something that was broadly correct but subtly wrong. I spent a month finding a new direction that was the opposite of what everyone thought we had to do, finding the right small 1-2 person experiments to derisk the new direction, get senior people to understand it and agree to it, set up the correct relationships to make it viable, and then I had the evidence to convince project leadership and management to shift. A few days later we had a VP review and the response was that they're delighted with the direction, it's far better than they ever though, and this will be a flagship for an org with tens of thousands of employees. That review would have gone horribly without what I did because the problem I saw two months ahead of time would have surfaced and the project would be seen as dying and aimless. But the team got the credit for being on top of things as a whole, not me. As it should be.
> They are managers that don't need to do 1 on 1s.
I have more 1:1s than managers, because they can afford to just tell people what to do. I need to develop junior scientists, keep relationships up, stay on top of other orgs, business priorities, etc.
Managers fail by creating chaos around them. Principals fail by becoming irrelevant.
This is much like real Principal Engineer roles I've seen.
The skeptics of the role might not have seen how easily and badly a large multiple-team effort can go astray, and the value of someone spotting the problems, and making sure they get addressed, before the product line or company is ruined.
I agree with your second sentence. But Anyone can do that, it's not a skill exclusive to principals. The idea that only certain types of people have the intelligence to spot things like this are principals is wrong.
Maybe we should think of the Principal role as complementary? If you're working on a compiler, you're going to be interacting cross-team with hardware engineering team, etc., and spotting lots of things. But someone who is looking at all the teams, and not spending so much time on compiler details specifically, will spot some things the compiler person doesn't. So together you get better coverage of problems that neither alone could spot.
Of course, once we throw differing pay grades into an organization, everything gets more complicated. And people might resent something being called "complementary", if what's bothering them is that the role in question pays better or is considered more prestigious.
Though, the Principal role is in the engineering career track of that compiler writer, if they want that kind of ulcers.
it can be, but the fact of the matter is the role is viewed as "better". Principals are better, smarter, more experienced and higher ranking than people who don't hold that position.
From what little I have seen, this kind of role is tightly coupled and dependent on the their Manager. The manager has to you like as a person and some how believe that all these activities are adding value.
> From what little I have seen, this kind of role is tightly coupled and dependent on the their Manager.
As you go up the chart you have more independence and are less tightly coupled to your manager. By the time you get to principal you should be largely independent. At the same time, you have much more responsibility.
That's just a practical problem. As your manager becomes more senior (director/VP) their scope also increases. They just cannot "manage" you the way someone would manage a more junior IC. Also at the principal level you aren't just bringing value to your manager, but to other parts of the org as well.
In other words, I can't ask my manager "what should I do today?". I cannot even imagine what his reaction would be if I asked that question.
> The manager has to you like as a person and some how believe that all these activities are adding value.
For what it's worth my manager is a great person. But he wouldn't for a moment believe anyone when they say they add value.
It's up to me to find ways to document and express my value. Figuring out how to do this is part of becoming a principal. So I keep notes, I record wins, I make sure that I do things that bring me visibility, that I present new ideas, I contribute to larger roadmaps at the org level, I make sure that other scientists can say good things about me, I help fix problems that other orgs have so that they report I was useful, etc.
> People in my org come to me because I provide value basically. Not because they have to.
In most orgs sadly that's not why people talk to a principal. It's that the process requires it, the manager wanted them to and/or there's you i.e. someone else to take responsibility. Of course they won't tell you that directly.
How do you get a role like this (even with the 10 year head start) without owning the organisation? Very few places I’ve worked have the kind of long-horizon pragmatism to invest in this kind of role.
Big companies tend to have Staff/Principal/Distinguished type roles. Usually those roles give you a lot of independence. But that independence means you need to be able to find projects to do and advocate for them and get them staffed and planned and executed and out to production. Often those projects can span many teams and multiple organizations, depending on how the company is structured. So I suppose the most valuable skill is being able to earn the trust of the managers so that you're able to even get them to listen to you so your stuff ends up on their roadmap.
so i do sympathize with a lot of the negative sentiments about the role here in this thread, and i think that in general there is a lot of navel gazing about the staff+ tech ic roles, there is an actual place for them as tech leads of large projects.
One way to gather the skill set is to rotate through and master different aspects of the role. First become really solid at the technical fundamentals. Then volunteer to spend some time focusing on complementary skills like project and product management (in very technical areas, where you couldn’t just hire a nontechnical person in one of those job families). Start looking out for the problems worth solving that take multiple technical experts to accomplish, and make the solution great. Maybe be a manager for a while. Understand how to make your managers for at least a couple of levels up better in some ways, and help them with that. You will become someone trusted to get the right things done well. When it comes time to find the next job, focus on carefully vetting opportunities and interviewing prospective employers at least as much as they do when hiring, to find that opportunity you can be truly great at.
If you have the skill and you're in a smaller company, you can just keep doing the role and the org will adapt to use you in it
If you have the skill and you're in a larger company they may already have a structure around it you can apply. Otherwise you should talk your manager into trying it, or you should find a new job in an org that does have this kind of role
If you don't have the skill, you should get the skill first, by making your team more effective, then make your team and all related teams more effective together
>But the team got the credit for being on top of things as a whole, not me. As it should be.
>If only! 70% of the work I do is invisible small course corrections here and there across multiple orgs that fix things no one ever hears about but would be disasters down the road.
>For the vast majority of what I do other people get 100% of the credit and my name is a small footnote at best.
Then your case is the exception, not the rule. To reach the level of principal, you generally have to be recognized for delivering high impact. Visibility is not just ego, it is how organizations perceive value. If your work earns you no visible credit, then no one really knows what you contribute. And if no one knows, how could anyone justify promoting you in the first place.
That is the ideal. In the ideal world, principals are elevated because they have a visible history of making the system better. They build frameworks that others rely on. They turn chaos into structure. They guide teams through impossible projects. Their reputation is not something they chase, it forms naturally from the wake of their work. In the ideal, visibility is the residue of real impact. People talk about them because their fingerprints are on every success.
But the corporate world rarely functions on ideals. In the real world, power accrues to whoever is closest to power. Titles often flow through social gravity more than technical merit. Some people climb because they deliver, others because they simply survive long enough to become unmovable. The higher you go, the more politics matters and the less evidence is required. Impact becomes subjective. Influence becomes reputation. And reputation, once earned, decays slowly.
In that reality, being invisible is not a liability. It can be a strategy. A principal who keeps their head down, avoids controversy, and stays on friendly terms with the right directors can outlast a dozen brilliant but abrasive engineers. The irrelevant survive because they are not a threat to anyone’s ego. The company quietly carries them, paying tribute to their title while forgetting their function.
Even the ideal, though, cannot escape the need for visibility. A principal who does great work in secret still fails the fundamental requirement of leadership: to be seen. Influence requires perception. You cannot guide a culture if nobody knows you are there. Quiet impact might keep systems healthy, but it does not create belief, and belief is what organizations promote. The best engineers learn to make their results legible. They translate their impact into stories others can tell. Without that, the work disappears into the background noise of everyone else’s effort.
So there are really two systems running in parallel. The first is the ideal, where promotion is earned through visible excellence and quiet authority. It demands both impact and awareness. The second is the reality, where promotion is often granted through time served, connections maintained, and an ability to avoid friction. The ideal rewards contribution; the reality rewards endurance.
You can succeed in either system, but they ask for different currencies. The ideal asks for mastery, courage, and the discipline to lead by example. The reality asks for patience, diplomacy, and the instinct to stay useful enough but never threatening. One builds respect. The other builds stability.
And most companies, if we are honest, prefer stability. Stability requires engineers to act the way you describe but talk the way I do. You talk about the ideal, you even believe you walk it, but because no one can see your impact, no one can tell the difference.
I've held the ranking of staff in many companies. I've interacted with principals, staff, and distinguished engineers and I can tell you visibility is required to fulfill the ideal. If visibility wasn't there, than the person earned the rank through other un-ideal means.
> Then your case is the exception, not the rule. To reach the level of principal, you generally have to be recognized for delivering high impact. Visibility is not just ego, it is how organizations perceive value.
Of course you need visibility and impact. But it's not the kind of crass taking credit for what other people did that the original poster talked about.
As a principal you need to actively build visibility because so much of your work is normally invisible. It means being an active participant with discussions with leadership, clearly being the person that sets the agenda on something, becoming someone who other principals turn to on a topic and then report to their managers, leading the conversations on a topic, being the person that people can bring a hard problem to and then see results, picking up on a business need first and finding a way to deliver on it, etc.
In the example I gave for the quiet change in direction of that project, there are many ways in which I get visibility. I told my manager this was a risk and I have a strange solution. I told the manager of that project. The other principals that I needed to involve and their directors know I pushed this. My VP knows because no one talked about that kind of feature until I did. I checked how crazy this direction change would be with more senior scientists and product people. I actively make sure that these gentle communications happen, and in a sense they're natural, because I'm taking the lead on something.
But no one is going out of their way to say "I take credit for all of this work that everyone else did".
> A principal who keeps their head down, avoids controversy, and stays on friendly terms with the right directors can outlast a dozen brilliant but abrasive engineers.
I don't think that abrasive people should become principals until they change their ways. There's so much cross-org coordination that you need to do, if you're abrasive, that's going to hurt everyone.
That doesn't mean you should be a pushover. I don't back down from technical arguments if I know I'm right and have the data to back it up. I have gotten into deep weeks-long disagreements reported far up to chain. But it's important that you can still go have lunch with your peers and collaborate on other topics even while you're trying to show that they're totally wrong in one area. That's part of building trust.
> In that reality, being invisible is not a liability. It can be a strategy.
A strategy to be fired. This is not viable.
There is no tension between "quiet authority" and visibility. If you're invisible no one will ever come to you. Visibility is what consistently demonstrates to people that talking to you will make their lives better.
Not true at all. Plenty of invisible people in the world who don't get fired. You're ignorant.
Your initial post talked about lack of visibility, now you're talking about it as if it's required comically to the point of claiming that "invisible" people are absolutely on the path to get fired or that people who keep their head low and don't grab attention isn't a strategy. Ever heard of the saying the tallest blade of grass is the first to be cut? Also have you seen how Xi, the current leader of China rose to power?
Part of being a principal is the perception of principled and expert reasoning/expertise. That means being able to flip what you're saying on the fly so that other people continue to perceive you as an expert who knows what they are talking about. Did you say something that was completely off and wrong and it made no sense? How do you hide this from the people above you?
You expertly did this with your response. First you say you take none of the credit, now you say taking credit and being visible is required. Expert pivot and THIS is truly the primary skill of a principal engineer and you display it unequivocally.
You don't even need to actually be responsible for all the changes you claimed to have influenced. You just need people to perceive the reality as if you were responsible. And I see this kind of BS in many, many engineering organizations.
A lot of this is self delusion too. These high level strategies and directions aren't hard to come up with. Likely tons of lower engineers have thought of the method too, they just don't have the "visibility" or the time to actually drive that direction into the organization. Some people tend to think the ideas they have are genius and that these ideas are what makes them "principle". No. It's mostly politics that puts you into a position to take credit for ideas anyone can come up with.
> The problem is that in Canada we're willing to invest a little for a long time. But we're not willing to make big bets.
Element AI.
It's not that the bets are not made, the winnings are captured by those that corrupt the existing system before it's even started, so tney go nowhere. This has been the status quo for so long everyone assumes it is what is happening with every new initiative.
It's been almost two decades and we're still taking steps backwards on accessibility and features because of Wayland.
From day 0 Wayland put their idea of a beautiful design above the needs of users. It's hard to see how we can claim to be inclusive when even our most basic decisions are hostile to large groups of users.
I never thought I would say this, but after 30 years of open source and Linux I don't see much of a bright future. Everyone I know from the community back then has moved on to using a Mac because of these issues.
But the Mac compositor (Quartz) implements the same permission model as Wayland, that's why you get a popup requesting permissions to share screen etc.
This particular case is about accessibility not permissions. AFAIK accessibility still isn't completely supported in major Wayland compositors so it's a legitimate complaint.
Wayland, traditionally, has not believed that. It believed "applications shouldn't be able to spy on or manipulate each other" and doesn't give users any mechanism to suggest that they might have permission to do so because the idea of that happening was just not on their radar.
I'm not sure about the modern state of Wayland but last time I saw it the situation was terribly messy and I was forced back to X11 because I rely on screensharing to do my job properly.
> I was forced back to X11 because I rely on screensharing to do my job properly.
Wayland screensharing has worked for a long time. I remember using it early in the pandemic when the entire working world seemed to move to Zoom/etc for meetings. So, at least ~5 years?
There are countless such threads. Something that always worked perfectly out of the box now has endless workarounds per compositor/desktop system that you use.
Exactly this. Somehow the wayland evangelists don't seem to understand that it's not acceptable that something that was trivial to do and reliable for decades is suddenly buggy and broken half the time.
I RESOLVED IT by using the x11 protocol
Lol, yep, that's the solution for most of these issues.
"There should be global hooks and applications should be able to register themselves should they wish" would solve all these cases, but horse blinders are also very important to wear.
> Is there any reason that Xorg couldn't tack on a permission system, other than that it would be inelegant?
That's the whole reason for Wayland's existence: such things were not "easily" possible...
Linux+Xorg desktop would be hopelessly insecure for ever because these security features were deemed too hard to the point of not being "worth it". So Wayland was started.
Someone is developing XLibre, and Xorg fork. It may be pulled off, but I doubt it. Making Xorg safe was tried many times for many safety-holes.
> Linux+Xorg desktop would be hopelessly insecure for ever
People keep repeating this claim over and over, but in nearly 30 years as a Linux user and tech news reader, I've seen exactly zero news articles about an epidemic of Linux keyloggers.
> Making Xorg safe was tried many times for many safety-holes
The anti AI hysteria is absurd.
reply