This article makes the naive assumption that "what is making money" is an objective thing.
Once a company reaches a certain size, basically once it has a financial planning department w/ different VPs owning their PnL, who is making money increasingly becomes a social construct. "how to get promoted" by spakhm is much more closer to how a large, successful org works IMO: https://spakhm.substack.com/p/how-to-get-promoted
I've seen this in my career multiple times. For example, when I was involved in search for some companies, we would demonstrate through A/B testing that we would make X more money per month. Executive team changed, they decided that "A/B test does not work and slows us down", the definition of making money changed, we overnight went from a money-aking org to a cost center.
Nowadays, most companies are pushing GenAI everywhere. Most of those things don't make money, and yet a lot of promotions will be obtained across the board until the tune ends.
Thank you. "Spearheading" is always valued and the way to do it is to leave for some new initiative somewhat before everyone realises the current one is a turd. The blame then attaches to the people left holding the turd.
But still there are objective metrics by which you can track which products are making money and which are not. You can do ALL the financial manipulation to an extent, but everyone above bragging VPs/Directors know which product lines are making money yoy
Say you are meta. You know that a big stream of revenue is ads. You are an engineer working for one of the myriad ML model around feeds, ads click prediction, whatever. Those ML models are in production, and cost a lot of money to maintain / operate. How much you are a cost center or a money maker will depend on a lot of non objective choices.
The essential issue is attribution, which fundamentally requires some choices about how money is actually made. Even when everybody is in good faith, there are reasonable ways to agree. And people are rarely in good faith around those things.
Ads are still bread and butter for Meta. The first to go will be the folks who are in vogue bcoz of cultural reasons, eg. diversity, green, etc. I would even go the extent of saying that a lot of open source maintainers will also be axed, the day Meta stops making ad money and fights for survival. The issue of `attribution` is to be decided at last, when anyway the house is partially burned and the company is fighting for survival. I am talking about the initial phase, where a lot of engineers work on teams that make no monetary/value sense for company and are there, bcoz manager/CEO don't care or are kind(mostly former).
Sure, but things like DEI, OSS, are tiny minority in most companies. At least they were in the companies I've worked at.
You mentioned that attribution is to be decided when house is burnt, but that certainly not my observation. Which department is responsible for what revenue is what senior leadership fights over all the time, whether times are good or not.
You have chosen a very very poor example in calling out Meta Ads. I can assure you that the entire org has a massive magnifying glass over it with insane amounts of data analysis, every % change in revenue is absolutely attributable to exactly what group brought it about whether it be DC hardware, ML teams, or backend infra. It is the lifeblood of Meta with many billions flowing through it of course it isn't just being cowboy'd with random changes that have undefined impact on yoy revenue.
I am not saying mature companies are "YOLO-ing" this randomly, but that many assumptions are made about how the input metrics trickle back to revenue/profits, and those can change. The attribution exists, but how it is done is far from an objective thing. E.g. how do you translate CTR into revenue ? How do you value an additional user ?
This can also be seen with cost saving. There are numerous examples on HN when people wonder why reducing the cost of something by X millions was not recognized (e.g. https://x.com/danluu/status/802971209176477696). Based on my own experience, most likely explanation is that's because there was no item related to this in the financial planning to be recognized.
It is at least in part because of how recruiting works, especially in large tech companies. Companies have many candidates for each role, and can't easily review all of them. Between bureaucracy, how busy the hiring manager is, etc. many candidates get lost in the process.
This is why 1) it really helps to have a referral and 2) tell the recruiter when you have competing roles. Neither will change much about getting or not a role, but they will really help the prioritization and avoid you getting lost.
Paradoxically, that effect is bigger nowadays when the market is not as hot as it used to be, because recruiting is more stretched. Even some FAANG are very understaffed on the recruiting side
That's my main use case not-yet-supported by uv. It should not be too difficult to add a feature or wrapper to uv so that it works like pew/virtualenvwrapper.
E.g. calling that wrapper uvv, something like
1. uvv new <venv-name> --python=... ...# venvs stored in a central location
2. uvv workon <venv-name> # now you are in the virtualenv
3. deactive # now you get out of the virtualenv
You could imagine additional features such as keeping a log of the installed packages inside the venv so that you could revert to arbitrary state, etc. as goodies given how much faster uv is.
So this is probably just me not understanding your use case, but surely this is a nearly identical workflow?
1. uv init <folder-name> # venv stored in folder-name/.venv
2. cd <folder-name> # running stuff with uv run will automatically pick up the venv
3. cd .. # now you get out of the virtualenv
The UX improvement would be to have a centralized managemend of the venv (centralized location, ability to list/rm/etc. from name instead of from path).
negotiation is very much a thing even at FAANG. If anything, it can help you being at the top of your assigned band. Other things can be negotiated.
Source: I am no great negotiator, but I've always negotiated my salary and got 10-15 % more than what I would have had w/o asking anything. This compounds after a few stints. And I've been a manager in startup/mid size/big tech: always negotiate.
There is also the signing bonus, which is usually available for a recruiter to sweeten things if the first offer is marginal. Google-recruiters for years claimed it was non-negotiable, all the while negotiating it for people who were willing to play the game.
1. A good python solution needs to support native extensions. Few other languages solve this well, especially across unix + windows.
2. Python itself does not have package manager included.
I am not sure solving 2 alone is enough, because it will be hard to fix 1 then. And ofc 2 would needs to have solution for older python versions.
My guess is that we're stuck in a local maximum for a while, with uv looking like a decent contender.
PHP and composer do. You can specify native extensions in the composer.json file, along with an optional version requirement, and install them using composer just fine. Dependencies can in turn depend on specific extensions, or just recommend them without mandating an installation.
This works across UNIX and Windows, as far as I’m aware.
Is that a new feature? Pretty sure it didn't a few years ago. If the thing I need needed the libfoo C library then I first had to install libfoo on my computer using apt/brew/etc. If a new version of the PHP extension comes out that uses libfoo 2.0, then it was up to me to update libfoo first. There was no way for composer to install and manage libfoo.
> Php-yaml can be installed using PHP's PECL package manager. This extension requires the LibYAML C library version 0.1.0 or higher to be installed.
$ sudo apt-get install libyaml-dev
This is basically how "pip" works, and while it's fine for basic stuff, it gets pretty bad if you want to install fancy numerical of cryptography package on a LTS linux system that's at the end of the support period.
I am guessing that PHP might simply have less need for native packages, being more web-oriented.
> Imagine the difference between "I want to give you feedback that you aren't spending enough time with new hires" vs "I know you've been wanting to spend more time with the new hires, why don't you take them for lunch and send me to your status meeting over Tuesday lunch time this week."
This is the proper answer. Ultimately, feedback should be about changing something. My experience is that most people are neither good at giving or receiving feedback, and that includes myself. There are more effective ways to change things.
OP's is useful when you have to give feedback, which is expected in most large companies in some form or other (evals, etc.).
One of the surest way to get your manager's back is to help them make their goals and put some stuff off their plates. Like other people said, most semi competent managers are aware of issues happening in their team. If you come up w/ some proposal to solve those issues, it will improve the team much more effectively than some feedback.
It also depends on your goals, but fixing some issues encountered by your manager is one of the most reliable way to promotion in up to mid size companies, unless your manager is a a*hole.
Japan suicide rate has decreased a lot, and is now almost the world average, it is actually lower than in the US and several European countries.
I agree however that this smells of orientialism. I don't speak anywhere fluently Japanese, but having lived there for 15 years, the only time I've seen or heard of the ikigai concept is in the "Book for foreigners" section.
For large companies, a big reason is to transform capex into opex, and the predictability. Moreover, large organizations tend to favor predictivity over levels, i.e. are ok to increase average if variance is decreased.
This. The beginning of my career on cloud was a POC, where the director shared with me this was a major driving factor (capex > opex), as well as some of the fringe benefits.
I got to see close up that a team of devs ran their whole solution (with a bunch of paying customers and everything) in the cloud, because cloud automation was good enough that they didn't need dedicated ops people.
Now I work for a cloud provider. I can't say that if I was running a business that I'd build it cloud-first instead of OnPrem. Certain use cases, sure. If I didn't need a lot of horsepower, I might build it on a cluster of VM's with some segmentation of duties - not quite microservices, not quite a monolith. Most likely if I was hosting on the cloud, I'd use the provider I work for, just because I know the system and how to get things done and how to talk to support.
I will say though - learning the ins and outs of cloud computing has made for a great career. Challenging, but lucrative.
FTA:
> Microsoft and Google decided not to officially comment on the survey's findings. However, a representative for one of the hyperscalers retorted that the figures seemed cherry-picked and pointed out that, as an example, customers using reserved instances could realize significant savings.
Reserved instances are a thing for sure. There's lots of other ways you can control cloud spend (enterprise agreements, dev/test subscriptions, spot instances, automated shut down / scale down, etc.) - it's enough complexity by itself that big companies hire entire teams of people to just work on tracking, projecting and controlling cloud costs.
It is true both countries were already industrious, but it was far from a given they could go back to their former self. They were both utterly destroyed, and things could have gone really badly, especially in Japan.
I can't find the reference right but I remember reading average adult calorie intake to drop to ~1200 kcals in 1947/1948 in "embracing defeat" by John Dower. That period has a huge influence on Japan to this day, including architecture of Tokyo through black market.
Both Japan and Germany had strong military govt culture, and became reliably democratic at the end of the allies occupation.
Sure things could have gone wrong. They did, for example, for Ukraine or most of Eastern Europe. But my point is, were these countries not previously industrialized, they probably wouldn’t have fared as they did now.
I guess this was a joke? But if not, fyi, ramen is from China. Sure, the Japanese have made it their own but even the Japanese don't list it in restaurant guides as Japanese food. There's a section for "Japanese food (和食)" and a separate section for "Chinese Food and Ramen" (中華閭里とラーメン) or it's in a separate category. It's still often called "Chinese Soba" (中華蕎麦）
It’s funny that ramen is literally lamian (拉面), but the Chinese will distinguish between Chinese lamian and Japanese ramen in their own country, it is considered foreign food although it is easy to find the Chinese food it descends from.
Once a company reaches a certain size, basically once it has a financial planning department w/ different VPs owning their PnL, who is making money increasingly becomes a social construct. "how to get promoted" by spakhm is much more closer to how a large, successful org works IMO: https://spakhm.substack.com/p/how-to-get-promoted
I've seen this in my career multiple times. For example, when I was involved in search for some companies, we would demonstrate through A/B testing that we would make X more money per month. Executive team changed, they decided that "A/B test does not work and slows us down", the definition of making money changed, we overnight went from a money-aking org to a cost center.
Nowadays, most companies are pushing GenAI everywhere. Most of those things don't make money, and yet a lot of promotions will be obtained across the board until the tune ends.