Why is the LinkedIn app almost half a gig?
threadreaderapp.com
threadreaderapp.com
Yes, you pay a bit for the sandboxing, GC, rendering, built in accessibility. But that’s a rounding error when businesses, especially large ones, go on a PM-centric feature frenzy. You get out exactly what you put in. Performance, security, user experience..
Whether it’s frontend, backend, embedded, whatever, the engineers are alright. Generally. It’s when you stop listening to them, or punish the grumpy ones in favor of the people-pleasers, that this crap happens. That’s worrying, because it’s become so prevalent.
I was laid off from my last gig in January because the company was running out of money. Last week I saw a former coworker share how excited they were to turn a perfectly functional and internal website built with html and css into a react app with redux and nextjs. I couldn’t believe a company running out of money would have a developer do that when it doesn’t affect revenue generation whatsoever. And I can’t believe the dev didn’t stop to think that the previous website was already perfect. There were never any complaints. Their LinkedIn post had tons of likes. I’m happy that they were happy, but I was left a little concerned.
Do developers have any agency whatsoever, or are they at the mercy of doing whatever their managers suggest (while always knowing the "right" answer, of course)? Does our industry attract people who avoid accountability?
Fraud? It's the executive's fault. Business struggling? It's the MBA's fault. Bad product? It's the PM's fault. Must be nice!
Take scaling for instance: there is such a thing as unnecessary scaling. I've seen junior devs in AWS shops insist on embedding insane levels of serverless AWS tech, all to serve minimal systems with minimal data and bandwidth and minimal customers. When questioned about the drivers for all of this scaling, they have no reply - its all fairly obvious that they feel that they do not have a career without all of the latest TLAs on their resume.
Apart from creating billions for Jeff Bezos, this is creating bloat on staggering levels. PMs are often unable (or unwilling) to push back, because who wants to questions devs these days?
I see senior devs doing that all the time as well; they have resumes to work on as well. Applications that probably will not get more than a few 10000 hits a day, if that, getting set up and stress tested so someone can say ‘set up app that could handle millions of hits a minute’. All on the company’s dime of course.
This is a feature, not a bug, as far as management is concerned. They’re often proud of saying things like “if you can’t measure it, it doesn’t exist.” There’s often managers that are very sympathetic to the idea of pushing for quality, but then they’ll ultimately say something like “but, if you can’t come up with a number to show benefit, perhaps it really isn’t worth pursuing ¯\_(ツ)_/¯” and we move on to the next feature.
The only way any real quality improvement happens, is if motivated individuals do the work basically on their own time. You will not get organizational support for it. If you’re lucky, it will pan out and an improvement will be made. If you’re not, maybe your refactoring causes a regression somewhere (nobody’s perfect!), someone notices, and if that person is particularly angry about it you’ll get yelled at for making “rogue changes” that cause bugs. If your rogue change was done in some other part of the codebase, you’ll probably have your access revoked (ie. others will be put on the approval chain to prevent you from making such changes again.)
Quality doesn’t come from metrics, it comes from giving a shit.
Obviously that’s not unique to the PM role, but seemingly more prevalent. I think it’s an effect of the rootless roaming you get when you spread people thin over large areas, and don’t have clear ownership and responsibility – which I think is a prerequisite for (the good kind of) pride.
But overall, yes, it’s definitely a structural issue with the organization at large. Clearly, when it’s gotten as bad as in this case.
I also agree about your point on ownership and responsibility. That's why I like Amazon's principle of Single Threaded Leaders.
"The best way to fail at inventing something is by making it somebody's part-time job" — Dave Limp, CEO, Blue Origin, formerly Amazon
YES YES YES. It's why I gave up on working as a product manager after nearly a decade. It's turned into KPI Management and everyone suffers, especially if you care about delivering good product
There is a balance though - in some cases you have to roll the dice and strike out in bold new directions. But this needs to be done with eyes wide open and everyone in full acknowledgement that this is an experiment and conversations with users are the next step.
This isn’t exclusive to technology, but I see this all the time at my large organization. As a grump, I have to pick which shitstorm to care about and spend my time chipping away at, which ends up being really draining.
To help with this, we began focusing a team of great folks with shared values, leaning in on modern operations/SRE best practices.
We started to have some real success with SDLC for our operations workflows.
That’s when management changed our teams direction. Good times.
People like to build corporate empires by having more subordinates. Those subordinates need to justify their existence somehow. Bloated, inefficient software is one of the unfortunate outcomes.
You know, grumpiness really is a thing. I wonder if it should be treated as a symptom like left arm tingling before a heart attack. A call to make some serious changes.
It is when you - a normal, well adjusted engineer - realize you are feeling grumpy about something.
It might be a sign to explore what is really going on.
There are long-tail risks to the stability of codebases, organisations, institutions, governments.. the soviet union collapsed.
It seems likely that some engineers can intuit such long-tail risks.
If linkedin is subject to a competitive threat which requires rapid innovation, the org will lose because it's development practices preclude it.
Short the stock.
There other bad things I don't refer like that, like something that is bad but if I quit and they get a new guy he can probably figure it out in a few weeks tops.
Depends on how you frame the problem.
If you declare the problem is that although batteries became way more efficient you don't get out more hours because they are wasted, then the story is a different one.
Same when you don't have an abundance in RAM but are forced to use certain programs and applications. I have 64GB Ram these days, colleagues at clients of mine only have 16GB and they face certain challenges I don't, because of the tools forced upon them by their superiors.
These problems can be real, they can be "artificial" (there is a philosophical note to this somewhere ;)), but in the end, there is undeniable truth that launching a whole browser engine for each and every app can be and indeed is wasteful compared to alternatives.
Of course if you don't see this as a problem "ex falso quodlibet" takes precedence and it all becomes futile to discuss :)
Wasteful and always, always a worse experience. I'm sorry if this ruffles feathers here or people feel called out, but I can FEEL the difference in these web-cruft apps every single time, full stop. I would Pepsi challenge this as many times as people want and I will eat my snow boots if I get it wrong.
If you make your app with web tools, I will not use it if I can conceivably manage doing so. And if I must, then I guarantee you I will do it as grudgingly and as little as I possibly can.
My colleagues have tiny Macs with 16GB. To accommodate them, we had to split mono dev setup into separate K8S cluster.
On single machine I could easily split test build process. Now we have spaghetti of dependencies. And spinning up secondary dev instances is not permitted due to high AWS cost.
So investing result binary (like this blog post) is now impossible.
Time for a new employment opportunity.
People love taking photos on their phones, they love big games, and Apple are notoriously stingy with storage space and iCloud storage to ship off device. It is a very significant portion of the population who are borderline out of storage all the time. I work quite closely to this sort of stuff on a regular basis.
Does Apple send telemetry information back to developers about failed app installs due to users' device being out of space?
I don't have a current Apple Developer account to test this but the documentation doesn't have any obvious statistic concerning failed installs: https://developer.apple.com/help/app-store-connect/view-app-....
EDIT reply to: >I don't think there's any special permissions required to get free disk space, so presumably he's getting it via telemetry from his app.
I was thinking of new users who didn't have the app at all.
E.g. hypothetical... "We're a brand new YC tech startup. Our app is 500 MB. This bloated size prevents 20% of potential new users from installing the app." <-- Does Apple provide enough stats to make that type of confident correlation?
For all I complain about OKR’s, this is a super simple one for LinkedIn to understand: Every MB your app takes up can probably be shown to decrease user stickiness by some percentage. Fix it!
Ah who am I kidding, they’ll probably switch to moving the assets out of the app bundle and making them live-download on first run and stored in the Caches folder somewhere, which will make the app “smaller”. Problem solved on their end, app-size OKR accomplished. The fact that it makes the app slower due to asset fetching is next quarter’s problem.
In my experience publishing on the Apple App Store, and as a user of iOS, there's likely no material difference between iOS and Android with storage issues, or if there is it's probably in Android's favour with the (mostly historical) availability of expandable storage and Google Photos providing a lot more off-device photo storage.
Read: company doesn't care about including a large % of potential audience. It only cares about including the users that are most easily turned into profit.
P.S.: maybe those companies are right. But it also means they're fishing in a small & crowded pond. There's a lot of untapped market out there if only a company would care to cater to it.
P.S.2: Things change, and people's circumstances change. Today's 'useless' user could be your company's most valueable asset tomorrow. Get 'm while you can.
To me it is just disgusting.
The trend towards huge installations is one of the many reasons I install as few apps as possible, especially in this class of "should have a fully functional web version" type social media things.
The damage is also cumulative: I have a perception that "apps" in general are likely to be huge piles of junk, so I'm reluctant to install any of them, regardless of their own merits. Even if LinkedIn were to spend the time improving their app it would suffer from the overall reputational damage to the entire ecosystem, and I still wouldn't even think to install it.
They are very sensitive over this kind of bloat over there, and it is definitely a key metric. You will even get a warning in your email if one of your builds increases bundle size too much!
On my phone, 500MB would put you as ~30 largest app on my phone. Those largest 30 include, messages (large attachments), photos app, music/media (downloaded for offline play) and a variety of junk games I never play.
I'd have to delete LinkedIn 40x to save the same amount of space as the dozen or so junk games I have on my phone.
You are referring to a hypothetical scenario where A/B testing took place.
I uninstalled the app recently because I find it maddening that I can't get notifications about comments on my own posts unless I also accept notifications for 'person X and person Y like such-and-such random post'.
I find it maddening and unjustifiable that these two types of behaviors would be categorized under the same notification toggle. Then I remember LI is now owned by MS, and it makes more sense.
(Makes sense considering LinkedIn is about jobs, but "half a side gig" makes no sense which should have been a clue.)
>300 MB for just dynamically linked frameworks & Plugins is...a lot. In fact, just the Dylibs & Plugins today are bigger than the entire app was back in November 2022
>Here's something else that jumps out - in March 2023, the TodayExtension was < 400 KB. Today its ~60 MB...
>Seeing as Today Extensions have been deprecated, its doubtful that they added THAT much functionality to them
https://news.ycombinator.com/from?site=timac.org&next=175530...
In detail: This is how death by a thousand papercuts looks like.
I've had the (dubious) pleasure of observing a roughly similar BigTech app project.
There are likely 100s-1000s of app developers involved in the LinkedIn app, and they are likely under immense pressure to Just Ship Already (tm). Some of them consider it conscionable to do weird things like statically linking to an asset library - whether through unawareness/incompetence or just by wanting to make it through the next performance review.
In smaller projects, there's some kind of a feedback that can make it through the system to make sure local and global incentives are aligned, but at the LinkedIn scale that would have required the people in charge to be engineers and not suit types.
One interesting solution to this very problem that I actually saw in action was employing a team of top-tier systems hackers (in this case: people with a security research background) to hack through the build process. This solution naturally premises on such individuals wanting to work for an app project, incentivizing them along the right global metrics and giving them the go ahead to push back on egregious violations.
I don't understand why you'd need 1000 or even 100 developers to produce such app. It's a CRUD frontend for a backend that already exists. What am I missing? Are you counting the developers of all the third party libs they integrate?
Probably a million features that are all relevant to different people who use the app? As a developer you probably use maybe 1% of LinkedIn, but you're not the primary user. It's a professional social network. It's going to have a lot to do.
> I had conversations with that manager where I was told in literally so many words, ‘You’re too idealistic. You don’t care enough about the bottom line. You should change your values.’ And I was like, no, nope, that’s not how this is going to work, man. Uh, outside I did the politic.
If you in the web app and open the network tab you will ve surprised how much junk they are moving around for a seemingly simple app.
The apps were roughly identical in the services that they provided (they both sold the same products but maybe some of the payment methods were different).
I'm still not sure why one company needed 10x the people to maintain the same thing.
So the group of users can be small, but those can be the "whales".
Also recruiters and HR who use paid features also probably use the app.
2) nobody measures such metrics: size, bloat, speed...
3) where are the code reviews?
4) nobody checks if the same library, same icon pack are not attached twice?
5) 1000 people? What do they even do? I suspect a lot of slides, politics and "high visibility projects"
Meanwhile the product suffers. Companies sure talk a lot about ecology, then we get apps like that.
Not related to Libkedin, but what is the carbon footprint of all electron-based apps that take hundreds of megabytes and gigantic amount of processor time?
Have you ever looked at the bloat of linkedin web? I've had tabs over 1GB memory use. Most bloated site I've ever used with any kind of regularity.
> Not related to Libkedin, but what is the carbon footprint of all electron-based apps that take hundreds of megabytes and gigantic amount of processor time?
I make an election app. It uses 70-80 mb of RAM when running. It's not that bad when you don't blow out your dependencies and code structure.
I often have multiple tabs open since I revisit some sites.
Biggest culprits of memory bloat seem to be discord, linkedin and a specialist page that shows some maps.
Gmail (!) feels incredibly bloated now as well - it has random jumps in processor usage, especially when loading.
At the same time: firefox simply is uncompatibile with youtube - random freezes and lags. There are multiple therds about it on the intetnet. Some say that youtube is intentionally slowing down firefox.
I think nobody at firefox uses own browser so they dont know youtube runs bad with an ad blocker. Also probable reason is that they try to kill firefox by conforming to some web standard (just like conforming to .webm - when you save pictures from reddit they arent saved as .png, but as the crappy .webm - I guess someone at mozilla is working very hard to lose the last few users they have. And yes I am aware you can solve this with an addon. An addon that is not checked for viruses / spyware)
Whether the CO2 footprint is high or low (and I assume it is very high), the real problem is that it would be a very simple way to improve CO2 efficiency.
> 1) where are the architects? Arent they supposed to deal with such issues?
The architects are the ones being told “we need these features, figure out how to do it”, and they build little box charts and sequence diagrams to sort out which systems are responsible for which. Never mind if a “feature” could just be a few functions somewhere. Architects think in terms of boxes and what does what. If the current boxes don’t have a role for a new feature, a new box is created. Boxes are assigned to engineers and interfaces are designed. Nobody cares if things can be done more simply, because the architects are looking to climb the ladder too (more boxes means your job is more justified.)
These same architects often don’t understand what each box actually does in implementation either, so they often are blind to radically simpler approaches to problems (I’ve seen cases where people just have no idea that a box already does the thing they want to do, and instead spend an entire quarter trying to build the functionality into the edges of the system, plumbing huge amounts of stuff around, when the thing they wanted could have been a 2-line change. These are fun meetings when that realization happens.)
> 2) nobody measures such metrics: size, bloat, speed...
They might be measuring speed, but with a kind of perverted reverse ratchet, where they say “this is within X% of production, so the regression is acceptable” and it ships. Once a perf regression ships it becomes the new baseline, so the next change can then be within X% of this one, and in turn the product gets exponentially slower. Nobody ever looks more than one release back. Nobody ever sets out to improve speed, unless by happy accident. If you stumble upon some horribly slow thing and fix it in happenstance, you can get a nice bonus. It’s never the plan though.
> 3) where are the code reviews?
There are code reviews but they’re completely toothless because the person making the change can easily say “this is high priority for making $DEADLINE” and push it through while filing a ticket to fix it properly in a follow up. The follow up never happens, and in turn any bad code becomes the new baseline and used as an excuse to make the same bad choice in other areas.
If you actually reject a PR and push back against the deadline, you are considered not a team player, and, guess what? You will get routed around anyway. They will find a way to get this change into another part of the system you don’t control (because code owner’s files mean there’s probably some other place they can make the change at some cost to the system complexity. This is another factor in (1), because the code base has fiefdoms and often architectural boxes are created purely because nobody wants to make PR’s into box A because of that one grumpy engineer, so functionality is built into box B instead.)
> 4) nobody checks if the same library, same icon pack are not attached twice?
Yes but there’s always an excuse, see 3.
> 5) 1000 people? What do they even do? I suspect a lot of slides, politics and "high visibility projects"
The bureaucracy expands to meet the needs of the expanding bureaucracy. All this complexity needs tooling, all this tooling causes complexity. Existing behavior is used to justify bad decisions, bad decisions become existing behavior, the cycle repeats.
The real problem with these organizations is that nobody dare admit (or even attempt to understand) how few engineers these kinds of products could require if things were done carefully from the start. And after years of such an org, shrinking becomes impossible: the weight of the complexity of the product means you need all the engineers you have to manage it. The mistakes were already made and there’s no way to close Pandora’s box here. You have to carry on until some day it just collapses (or gets disrupted, etc.)
> Not related to Libkedin, but what is the carbon footprint of all electron-based apps that take hundreds of megabytes and gigantic amount of processor time?
Trust me I’d love to hate on electron and JavaScript as much as the next person, but all you read above is from an org where we write bare metal code using as many system frameworks as possible, using everything we can that’s native to the platform. No JS, no GC’d languages, no electron/etc. As native of an app as you can get. This stuff has basically nothing to do with tech stack, it’s all organizational. I’ve heard it described as “building software at large” but it really means “letting the software grow unchecked”, and it’s the attitude that’s the problem, not the technology.
Makes me wonder where they got their ideas, maybe they are just imitating larger companies.
It's real bad when you get a refugee from a large bureaucratic org into any key position somewhere much smaller that would really need to grow a lot to compare at all.
Ultimate decision-makers sometimes think that type of overpaid climber will prepare them to grow to the size of the company they once worked at. When the opposite is true because they thrive on the bureaucracy more than the business, and can barely perform when all that overgrown bureaucracy is not there at their disposal.
And you don't want to pattern your company like a large bureaucracy until it is actually large. And then only deploy the bureaucracy part judiciously when and if it becomes absolutely necessary, no reason to do it the 19th century way any more.
From another comment:
>Sounds like bad product management as much as bad engineering. I mean, the outcome — a bloated product — is bad for everyone: the users in the first place, the engineers building the product, but also the PM who can't conceivably be proud of shipping a bad product.
"Bless their hearts, they don't know any better."
"This is why we can't have good things."
> Knowledge is Power - France is bacon.
I wish my company would use something else but the CIO is hellbent on “rEdUcInG tHe nUmBeR oF tOoLs” and MS was apparently throwing in teams for “free” as part of o365 sub.
Teams uses Active Directory, and they can argue it's "good enough".
Had similar (although not as bad) with the Okta login libraries as well. I eventually created a separate application just for the login page so I wouldn't need to bundle those libs with the main app.
That’s what I’ve been told when I also question these things.
Not sure if it's deliberate, but one does generally look for a gig in LinkedIn.
For many of these apps, I use them frequently enough that the space tradeoff is not a concern.
For many others though, they're in that awkward middle zone where I use them once every month or two. But because the apps are so large, I don't want to have to waste a quarter gig of data to download them on the fly, so instead I keep them on my phone. And collectively they take up 5-10 GB of space.
I'm trying to imagine how this proposal would change the face of the planet while I wipe up this mess.
What message would it send if they can develop this with 5 devs, but the customers they sell their advice and licenses to needs a 1000?
So they have to dogfood, leading to all of these bullshit bloated apps
So with a company full of people whose #1 concern is their paycheck and their resume, they'll make choices to optimize those, which means turning a trivial 20-minute shell script into a 3-month project requiring a whole team of devs.
1. Believe it or not the LinkedIn app is huge in terms of the amount of things it does. It’s basically a super-app for professionals. News, social interactions, an entire chat app, a job board, recruiting and sales tools, etc. Of course it relies on a lot of frameworks.
2. You don’t need a “high end” phone or expensive data plan to have this size of install be reasonable. A brand new $159 Samsung A03s phone can take a 1TB SD card which itself only costs $60 from a reputable brand. You can get an unlimited data plan for $30/month from Mint mobile. Basically, the poorest consumer in the US can “afford” to install the app. Mobile download speeds in the US are far into the double digit Mbps. I’ve seen speeds go up into the hundreds of Mbps. Of course the option exists to have your apps update over WiFi automatically and use no mobile data at all.
3. Install Size != Slow performance. Grand Theft Auto V is a 100GB install on my computer, but it runs at a buttery smooth framerate on modest hardware.
4. Those criticizing LinkedIn for having a large development team that has to rely on frameworks rather than custom-building tightly integrated functionality are just on another planet entirely. The app is optimized for ease of development, not install size or perfect performance. LinkedIn isn’t going to hire a bunch of expensive, impossible to find 10X developers just to over-optimize their app so that somebody will notice that it only consumed 50MB of space instead of 500.
I mean you're not wrong that install size != slow performance, but GTA5 is a funny example for being the game that had 6 minute loading screens to start online mode until someone reverse engineered it and found it was mostly from parsing a giant 10MB JSON blob, and reduced the loading time by 70% with a small patch.
Very possible the bad priorities lead to both the ginormous install size and the fact that no one internal was tasked with fixing the load times.
Perhaps it’s still a decent little business lesson: the highest earning video game of all time had an egregious loading bug and nobody cared for years.
The user doesn't want to end there session until they are sure that they won't want to play for the next hour. They might quit a fast loading game after 15 minutes because it's so easy to start again when they want to.
Any time my laptop fan starts spinning fast, is due to LinkedIn tabs using high CPU in the background, confirmed every time using Firefox task manager.
For me the question is why anyone would even consider installing it.
The other is easy: It's Microsoft,
(I'm also not a career developer, so maybe my priorities are different.)
Is app package size something users care about?
Same reasons - bloat over time, developers with powerful machines and network connections who don't notice the impact, users with huge devices that don't care about 500M space for an app and management and corporate culture that don't care much about optimisation.
And it always uses local calendar alignment, which is “fun”.
Imagine my joy when every google site helpfully switched to German, ignoring my browser's accept-language.
Thankfully some googler must have been also annoyed by this at some point, so there is a somewhat little-known URL: google.com/ncr (No Country Redirect) which will revert everything to US English. Doesn't help if you wanted to default to any different locale, but it was perfect for me. Thank you unknown annoyed googler.
Works fine for me, including when I'm in a foreign country and I need to change back to my home currency. Are you sure you're not disabling cookies or whatever?
Okay I retested with a EU VPN and I can confirm it's due to you declining the cookies. If you decline cookies and change currencies, it adds your desired currency to the url as a query parameter, so if you navigate to flights.google.com again you lose it.
>but in any case, that sort of behavior shouldn’t be governed by any privacy-concerning cookies.
In other words:
you: "don't store cookies and data about me"
google: "ok, we won't store cookies and data about you"
you: "why didn't you store my currency?"
Actually if you read the cookie prompt that you declined, it specifically mentions that they use cookies for "personalization" purposes, and that if you decline they will not use cookies for that purpose. Storing your desired currency arguably counts as "personalization" purposes, so I don't really see the issue here.
And, as I said, I’m logged in when this happens, proving that it is intentionally user-hostile, since they actually have the tracking data they need on the backend but are too lazy or organizationally incompetent to assemble it.
So no, that doesn't change depending on where you are.
I live in the US, use Uber, and have used Uber in India. The service offerings were very different in the two countries. I was glad that the same Uber app I used in the US, connected to my credit card, works well in India without needing a new app to be installed.
I believe they optimized for that usecase.
Does localization involve more than a few hundred strings per locale, all of which should compress really well? Maybe add in some localized icon sets, but much fewer than the number of supported locales.
I'm not saying you're (or they're) wrong, I'm genuinely curious.
So for the traveler, when they arrive in a new area that's supported by Uber, the app will just work instead of a "Please wait while we download the necessary payment SDK for your current location..." notification.
You didn't just download Uber "for USA" - you've downloaded Uber for "all countries where Uber exists" just in case you might leave your home area and travel a location that Uber operates.
Testing matrix must be complex...