This is a perfect example of why the problem isn’t the stack, native vs web, or programming languages. I’ve been saying this for ages when people bash JS for being slow, or the web for being bloated.
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.
It's not just PMs though: developers are forced into resume driven development by hiring practices. If they stick to the toolkit already established in the app they set themselves up for a career trajectory towards Uber driver. The risk of knowing only what was fashionable five years ago is just too big.
> It's not just PMs though: developers are forced into resume driven development by hiring practices
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.
Taking it a step further, this is what happens when the monetary authority's mandate is maximum employment and not maximum production. We're optimizing against efficiency.
Literal cargo culting. The mindset, of whoever is approving those decisions, is often that they just need the right software ‘cargo’ to attract more money and save the company.
50% of the reason Kubernetes is getting so popular, devops people need k8 experience to move up in their careers and therefor your company is now using k8.
I think ai/llm have overtaken kubernetes in this regard, everything’s needs to be solved with AI, even if it doesn’t solve the problem in a better way. But I guess that’s also part of the learning process, trying it everywhere to learn from experience what doesn’t work.
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!
On balance, devs have more agency than ever before, but they choose to use it to load in every daft technology imaginable that makes their resume look good. IMO developers are less and less inclined to act like professionals that bring data to the decision table, so as to create meaningful business solutions.
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've seen junior devs in AWS shops insist on embedding insane levels of serverless AWS tech
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.
Maybe when you tell your engineers you need X feature implemented in two weeks, leaving them no time to plan or refactor, and they're building on an already bloated, ancient spaghetti codebase because every deadline has been two weeks under a skeleton crew for the past decade...
They have very little agency. Priorities are driven by OKR’s, which require measurability as one of the core tenants. If you want to accomplish something, you must be able to point at a number somewhere, and have a plan to make it to up and to the right. Refactorings to pay down tech debt rarely can pass as OKR’s unless there is a true business need.
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.)
Your post sort of boils down to me as "be annoying and measure stuff all the time" or "hope you get lucky". I think there's a middle ground in there but it's too easy to err on one side or the other ad a methodology and then get stuck - either you're ruled by OKRs and playing games with metrics and juking the stats all day, or you're shooting blindly in the dark with no direction or accountabilities.
Or you can trust your engineers to know where the quality issues are (they live in the code base all day) and trust that when they say fixing something is important, and that they can make a logical case for it, that it should mean something.
Quality doesn’t come from metrics, it comes from giving a shit.
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.
In my experience PMs are not rewarded for good product, but rather a mix of shortsighted metrics and whatever their VP/senior person has on their personal agenda. At big companies, employees are often not even using their own products. The corporate ladder is all that matters.
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 very much agree and I've seen that a lot in large companies. I really like how Bain explains it: "growth creates complexity; complexity kills growth". They talk about in The Founder's Mentality: https://media.bain.com/the-founders-mentality/
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
>In my experience PMs are not rewarded for good product, but rather a mix of shortsighted metrics and whatever their VP/senior person has on their personal agenda. At big companies, employees are often not even using their own products. The corporate ladder is all that matters.
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
My background is natural sciences, so I took a paycut to go back into an academic lab and rekindle my bench chops. Been really fun so far and my hope is to continue working in the field as a lab manager or researcher in the private sector. Won't pay as high as a software PM, but a lot more satisfying and healthy
Yup. If you're not talking to customers and hearing the problems on the front line you run the risk of solving problems nobody has.
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.
> punish the grumpy ones in favor of the people-pleasers, that this crap happens
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.
Perhaps, but in my experience, this is often what happens when you have too many cooks.
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.
Meh, developers are people too. They are right and they are wrong. I've seen some guys who are proud of having the grumpy persona, which is really just a nice word for "I know better than the other people I work with" and it's not a great attitude. Engineering choices all have trade-offs yet the grumpy guys always frame it as "my way or everything will collapse later".
Agree with this. And why it’s important to have spaces to blow off steam and vent without being shunned as a bad team player or whatever. I’ve seen quite a bit of toxic positivity that makes people sit on their grievances in silence instead and become complicit and resentful (like the parent comment mentions). It’s much better to air it out - oftentimes there’s constructive things behind discomfort. In fact, discomfort is a guiding light for innovation imo.
You joke but when something is really bad I make a point of saying it is "job security" for myself in front of my tech lead (and my teach lead's manager). It triggers something in their heads that "oh, if he quits we are screwed". Those things tend to get addressed.
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.
We're not doing waterfall, but we're going to plan out every little detail of a change into small parts and plan out how many sprints it should take to do them all and split that work across the team so that you are always relying on someone else's work or somebody is waiting on you to start something.
Literally described my workplace, and it won't change b/c everyone wants to game theory the wrong way to make themself look like a 'team player' (I hate that term)
> This is a perfect example of why the problem isn’t...
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 :)
> there is undeniable truth that launching a whole browser engine for each and every app can be and indeed is wasteful compared to alternatives.
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.
It goes opposite way as well.
I have workstation with 128GB ram with a few terabytes of storage, I can run full stack with everything in single machine. I also have VM snapshots, versioning etc... There is simple script that installs all deps and setup dev machine.
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.
The short business answer is that it's currently not a metric that influences people's decision to install or uninstall an app. If it were one, we would've seen an engineering effort to reduce bloatware and duplications as seen in the post.
On the contrary, lack of storage is a huge limitation on installations. This may not be worth optimising 50MB to 30MB, but optimising 500MB to 300MB would be very impactful to installation rate.
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.
>, but optimising 500MB to 300MB would be very impactful to installation rate. [...] 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?
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?
I’m imagining a lot of users find themselves low on space, go to Settings, find what apps are using a lot of it, and delete them. “I’ll re-download LinkedIn if I need it again” they’ll think to themselves. This is terrifying to LinkedIn because it means push notifications no longer deliver, and how are you gonna increase engagement now?
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.
I'm not sure if Apple does, but the Play Store provides plenty of information about size of app, size relative to similar apps, size change over time, installation rates, and basically all the pieces necessary to figure out that size is preventing installs. I have to be careful about what I say here given my role, and this is all opinion or public information, but I'm not sure that Apple's telemetry is particularly insightful in this regard.
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.
Apple doesn't incentivize developers to build smaller apps. Instead they push users to throw away their phone and buy one with more storage (at a cost of $100 per 128 GB) and/or buy iCloud subscriptions.
When I’m low on space I don’t even install some apps that I see on the App Store or, more commonly, I install them just to try them out and remove shortly after.
^^ This. Companies often don't care about app size, because the (potential) users that avoid their app for size and/or performance reasons, are not the ones with the fat wallets (or valueable data).
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.
I have ~30 of either Banks or Payments Apps and Social Media Apps. Every single one of them are 500MB+ in size. That is 15GB of Apps. My HSBC Apps is 800MBs and I dont have a fucking idea why. And then there are Gmail, Google, Outlook all 300MB+.
Although I think you're exactly right, the irony is that they'll never actually be able to determine why somebody doesn't install an app due to this kind of junk. It's not like they can a/b test "bloated app" versus "good app" installation metrics, and they have no way to know why people are not installing something.
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.
When I was in an internship, I needed a new library for some feature in one of the sites. The _first_ thing their PM objected on was bundle size. Only after confirming that adding my feature would bundle size remain sensible could I continue.
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!
I'd conjecture even further. The most valuable users of LinkedIn, those with in-demand skills, are more likely to be running a high-spec'd device where they don't care about these issues.
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.
And that department will take immediate action, communicate efficiently across corporate governance teams, all in perfect harmony, to address at the next sprint, as ever. /s
On android there is a way for apps to initially provide a barebones package, that downloads and installs quickly, but that then fully downloaded itself afterwards. So I guess there already has been some engineering effort, just not in making sure apps are small
Actually, it's a huge metric. Not sure on iOS, but on Android this is so fundamental that usually companies even launch after a "Lite" version exactly because of this.
Another question: why does the feed reload when I go 'back' to it? This happens on the website and the app whenever I click into a link and then go back to the feed. It just spontaneously reloads! If I wanted to comment on the link or even just like the post, I can't (unless I remember who posted it, go to their profile, and go to their recent activity, which I almost never have the patience to do).
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.
Because, as it happens with a lot of apps, the developer teams, product managers or whoever with decision powers are not users of their own applications.
You’re definitely not the only one. I expected a rambling about how some not very sane person spends half of their working hours on LinkedIn, constantly updating their profile and whatnot.
>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
Which is why you don't become a prophet in your hometown, they know nobody listens to you so they don't listen. But as a traveler people can think you are important and then you can become important.
Actual business model: shame users for having 2 year old phones and push them towards throwing it away and buying one with more storage (for a premium, of course).
TL;DR: There're few global incentives for a LinkedIn app developer to make an overall good app, as opposed to making their PM happy.
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.
> There are likely 100s-1000s of app developers involved in the LinkedIn app
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?
> It's a CRUD frontend for a backend that already exists. What am I missing?
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.
Management might have been too interested in features to fix deep technical issues.
> 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.
You are missing:
- Every interaction needs to be recorded (metrics!)
- Every interaction needs bot protection
- A/B testing, show some users new stuff
- Gather all that good user data for tracking and selling
- Probably at some point they refactored the UI and now they maintain old and new stuff, they still ship everything of course
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.
I kind of agree but I've worked for two companies in the same industry - one had an app team of five people, the other had an app team of 50 people.
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.
Furthermore, I would like to see some stats how much of their traffic is via the app and how much is via the website. Of course many people have LinkedIn profiles, but are there really so many "hardcore" users who install the app? So maybe the app just isn't that important for them in the grand scheme of things, and the bloat is more the result of neglect than of hundreds of developers working (specifically) on the app?
The mobile web version is intentionally feature degraded, with occasional pop-up nags pushing the app. For that reason, I’d guess a lot of people are using the mobile app.
If you use firefox mobile, there's a toggle switch under the menu to set "Desktop Version", I have found it prevents these intentional mobile degraded sites.
Ah! I know that from Yahoo Mail (the email address I still use for historical reasons). I even tried the app once, saw that it was actually worse than the website (which is not feature degraded as far as I can tell, at least not the features I use), and since then I just curse and ignore the nags...
Crippling your website on mobile to push your app is a scumbag move and guarantees I'll never create any persistent account on your system. Definitely won't be installing the app, because if you're already scum, you probably have no limits and I'm not installing what you're pushing.
1) where are the architects? Arent they supposed to deal with such issues?
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?
> nobody measures such metrics: size, bloat, speed...
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 actually was looking recently at memory (and processor) usage of my browsers.
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)
My experience with FireFox and YouTube has very much not been this. YouTube works perfectly for me on FireFox. I would check your config/addons and see if there is some setting that is causing errors on YouTube.
> 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?
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.
Speaking from experience in a similarly unhealthily large org:
> 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.
This was incredibly well written and I really enjoyed it. Never worked for a large org but if I extrapolate stuff I've seen in smaller places I can see how this would be the end result.
>if I extrapolate stuff I've seen in smaller places
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.
These are examples of dangling modifiers [1]. They’re related to garden-path sentences [2] because they trick you into parsing one way and then get you to backtrack. One of my favourite grammatical constructions!
That's great. Now do one on why Microsoft Teams grinds away with 100% CPU on my laptop for a few minutes just to bring up my calendar, or why Outlook on Android freezes for a minute or so when looking at a single small email.
Microsoft Teams is so awful. Between the subpar audio and video quality, and performance issues with basic chat. The experience all around is awful.
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.
Having said that, even though I complain about Teams sitting there with 100% CPU while doing nothing that appears useful, at least it does actually manage to do video conferencing full screen (3200x1800) within the limits of the Intel Atom in my current laptop, which is more than I can say for Google Meet, which was jittering all over the place until I made the window really small and switched off my camera.
The thing that consistently baffles me is how Slack, Teams, etc., routinely get demolished in terms of usability and performance compared to Discord. It's not like Discord isn't also doing the ridiculous "package a whole browser as a GUI lib" dance.
Deleted that creepy app one minute after installing it, as it started trying to reconnect me with people from decades ago, whom I had no desire whatsoever to reconnect with.
One of the products my company offers is an SDK and we are happy and proud to shave away 10s of kilobytes on it whenever possible, as large SDK sizes seem to lead to loss of opportunities with potential new customers. and then there is this. What I want to say is: Some companies DO care how big their apps are.
I once looked at Zendesk (the thing that powers most of those little customer support chat buttons on the bottom right of web pages), I was appalled at the size of bloat they push down to the browser. I don't remember exact numbers but I think it was ~2mb gzipped. I couldn't removed it from our app but I at least added a 5 second delay before loading it.
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.
I don't have LinkedIn installed, but it's hardly the only app guilty of this. My phone has probably a dozen apps or so that take up much more space than I would expect (400 MB for the iRobot app that runs my Roomba? 250 MB for Firefox Focus which is now the same size as 'full' Firefox?)
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.
That is wild. Firefox on Android is an 85 MB download, and it's real Firefox with all the associated features. LinkedIn is 45 MB. I don't see how anybody can believe Apple is spending any effort on automated static analysis in app review if they're leaving such low hanging fruit.
Because LinkedIn is run by people who do not care anymore. They have a monopoly and nobody is interested enough in that boring industry to disrupt them.
I think it's more than that. Big companies like this don't exist to provide solutions in the most efficient manner possible, nor do they (contrary to popular opinion) exist to create the most "shareholder value". Their real reason for existence is to provide employment. (True, the investors really only care about RoI, and would prefer more efficiency with a lower headcount, but the reality is that you need to hire people to actually build things and create solutions to sell, and for those people, including the top executives, the company's mission is not their priority, only their own personal career and bank account.)
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.
One of these lovely discussions again. I’m firmly on the devil’s advocate side here: some install bloat isn’t a big deal.
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.
> Grand Theft Auto V is a 100GB install on my computer, but it runs at a buttery smooth framerate on modest hardware.
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.
I forgot about that incident! I guess a better example would have been Baldur’s Gate 3.
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.
I'm suspicious that long initial loads and things like login queues are actually an advantage.
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.
The app may do a lot of things, but what fraction of users use all of the things? Even if I use 10% of what an app is capable of, I still have to store 100% of the app on my phone.
I see the effect most with friends/family who aren't that technical wondering what to do when their phones run out of space. I don't think they expect that the most effective way to free up space is to delete a handful of apps, and instead they go through hundreds of photos trying to free up 5 MB at a time.
Don’t know about the app but LinkedIn website is a piece of utter shit.
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.
I have literally never logged into LinkedIn on my mobile. I stay as far away as possible. On the desktop - yes, occasionally. The messages are usually spam from recruiters.
> Venture capitalists have a list of danger signs to watch out for. Near the top is the company run by techno-weenies who are obsessed with solving interesting technical problems, instead of making users happy. In a startup, you're not just trying to solve problems. You're trying to solve problems that users care about. -pg
Why does the web page presenting this complaint take 140 requests to serve and transfer 10Mb?
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.
Uber actually had a pretty reasonable explanation for their app being huge when their rather large app size made the rounds several years ago. Turns out localization takes a lot of space. I wonder how much of LinkedIn’s insane size can be attributed to that vs just lazy coding
A few years ago I moved to Germany, not speaking a word of the local language.
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.
>It displays prices in local currency, no matter how many times you go to the menu and pick a currency.
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?
Nope — happens when I’m logged into my Google account even. I’m sure I decline whatever cookie notifications they throw at me (except when some dark patten tricks me), but in any case, that sort of behavior shouldn’t be governed by any privacy-concerning cookies.
> I’m sure I decline whatever cookie notifications they throw at me (except when some dark patten tricks me),
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.
Bundling basic app functionality with do-not-track prefs is user-hostile.
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.
This is not meant to be disrespectful, but it looks like you have not yet traveled to a location where Uber offers a service that is very different from the one they offer where you live.
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.
In India, for example, you can call a tuktuk or a scooter, which you cannot do in the States. Not to mention all the different localized taxes, fees, regulations etc
If Uber offers different services depending on the locale, then it needs to dynamically load/select from different views available. It's not just language translations. Sibling commenters have mentioned all the different views/functionalities that vary by region: https://news.ycombinator.com/item?id=25376346
I think App Store's app thinning doesn't care about locales, so any such attempt should download an additional localization file from Uber's servers. While not technically impossible, it will mean that downloading an app is no longer sufficient to use the app; it should also go through the initial (or incremental) download, which was significant in the case of Uber's case (1 MB per locale according to the blog AFAIK), so it won't be as optimal.
But the moment you need the new localization information, you'd have just gotten off a long flight in a new country on a data plan that might not be as cost-effective as your plan in your home country.
You can still use it without waiting for a MB of the localization file to be downloaded. (Maybe that can make much more sense to, say, social media apps where you will have to download as much data to do anything.)
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.
This "localization" also includes the code for online payment methods available in a particular locale.
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.
The simple example I gave in a sibling comment is that in India you have the option to call a tuktuk or a scooter which has a whole different guide set, flow, more screens. And lots of different airport specific, town specific, county specific, country specific regulations about things that need to be shown, taxes, etc. For all of that to be seamlessly available as you travel you need to be downloading a pretty large bundle upfront. Else you end up in a situation where you need the service’s reliability the most (travelling in a foreign country) and not being able to use it easily (because you have crappier data from bad infrastructure or a cheap SIM card and can’t download a location specific bundle)
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.