[HN Gopher] Why is the LinkedIn app almost half a gig?
___________________________________________________________________
Why is the LinkedIn app almost half a gig?
Author : jshchnz
Score : 176 points
Date : 2024-03-25 20:01 UTC (1 days ago)
(HTM) web link (threadreaderapp.com)
(TXT) w3m dump (threadreaderapp.com)
| abraae wrote:
| 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.
| SOLAR_FIELDS wrote:
| 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
| saghm wrote:
| If I only ever use a single locale on my phone, why isn't
| there a way to avoid needing to download all of the extra
| info that my phone will never use?
| mavelikara wrote:
| In Ubers case, the app works well when you travel. Not sure
| why LinkedIn would need that, if that is your question.
| eptcyka wrote:
| The last thing I want is my phone or apps on it to
| automatically change locale depending on the GPS
| location.
| pcl wrote:
| Google Flights does this. It's so frustrating. It
| displays prices in local currency, no matter how many
| times you go to the menu and pick a currency.
|
| And it always uses local calendar alignment, which is
| "fun".
| gruturo wrote:
| 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.
| gruez wrote:
| >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?
| marticode wrote:
| In the case of Uber, the service they provide is highly
| dependent on where you are.
| eptcyka wrote:
| Whats the point? I will still want to know the price in
| both my and the local currency in the language I know.
| gruez wrote:
| 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
| SOLAR_FIELDS wrote:
| 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
| mavelikara wrote:
| 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.
| kolme wrote:
| Localisation means in this context the translations, date
| and number formatting, currency, etc.
|
| So no, that doesn't change depending on where you are.
| eddyfromtheblok wrote:
| I still get a few ads and configuration settings in
| Spanish I believe because I created an Uber account at an
| airport in Mexico.
| lifthrasiir wrote:
| 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.
| vladxyz wrote:
| I mean, does it matter for an app like Uber? It's not a
| document editor, you'd never use it without an internet
| connection.
| lifthrasiir wrote:
| 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_.)
| mavelikara wrote:
| 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.
|
| I believe they optimized for that usecase.
| adwn wrote:
| > _Turns out localization takes a lot of space._
|
| 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.
| namrog84 wrote:
| In the case of uber. Maybe they have a local list of every
| city and street of thr world localized on device?
| canucker2016 wrote:
| 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.
|
| Testing matrix must be complex...
| rad_gruchalski wrote:
| Here is the hn comment you are most likely referring to
| https://news.ycombinator.com/item?id=25376346.
| emestifs wrote:
| Related: (19 days ago) Leaving LinkedIn -
| https://news.ycombinator.com/item?id=39612443
| new_user_final wrote:
| From the reply
|
| >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
| jshchnz wrote:
| Here's a detailed answer (using ThreadReader so no Twitter login
| necessary):
| https://threadreaderapp.com/thread/1772350918534582525.html
| dang wrote:
| Ok, we'll change the link to that from
| https://twitter.com/t3dotgg/status/1772328210900074786 above.
| angiosperm wrote:
| TIL there is a Linkedin app.
|
| For me the question is why anyone would even consider installing
| it.
|
| The other is easy: It's Microsoft,
| jondwillis wrote:
| It's required for messaging on a mobile phone. And probably
| other user hostile patterns.
| computerfriend wrote:
| It's not, you can send messages on the website on mobile.
| bitwize wrote:
| Last time I tried, I was given a "download the app to use
| this feature" screen.
| sgt wrote:
| 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.
| happymellon wrote:
| That's weird, I am able to message on my phone through the
| linkedin.com page.
| antonyh wrote:
| For me, if I click into a post it dims grey and refuses to do
| anything. It's very user-hostile.
| ValentineC wrote:
| I just don't use LinkedIn on mobile, and view anyone who
| wants to connect only via LinkedIn as generally not useful. I
| think it's a good sheep filter.
|
| (I'm also not a career developer, so maybe my priorities are
| different.)
| exabrial wrote:
| Yall just don't understand what innovation looks like..... Mmk?
|
| That's what I've been told when I also question these things.
| zogrodea wrote:
| I'm probably not the only person who misinterpreted "gig" in the
| title as "job", as in "side gig", instead of "gigabytes" as was
| intended.
|
| (Makes sense considering LinkedIn is about jobs, but "half a side
| gig" makes no sense which should have been a clue.)
| murkt wrote:
| 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.
| YouWhy wrote:
| 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.
| gertop wrote:
| > 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?
| emj wrote:
| 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.
|
| https://news.ycombinator.com/item?id=39612443
| rob74 wrote:
| 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?
| ungreased0675 wrote:
| 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.
| rob74 wrote:
| 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...
| RyanHamilton wrote:
| 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.
| iggldiggl wrote:
| Although "Desktop version" is also tied to a desktop
| viewport, so you have to deal with either too tiny font
| sizes or lots of scrolling.
| gravescale wrote:
| 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.
| rvba wrote:
| Id argue that the people who pay for linkedin are the ones
| who use the app.
|
| 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.
| LudwigNagasena wrote:
| You need at least 100 developers to produce such an app. If
| there were only 5 or 10 devs, it would be much more
| performant and less bloated.
| phillipcarter wrote:
| > 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.
| eddd-ddde wrote:
| 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.
| rvba wrote:
| 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?
| ninkendo wrote:
| 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.
| LAC-Tech wrote:
| 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.
| bcaxis wrote:
| > 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.
| infomaniac wrote:
| Galaxy brain business model: shame the app developers and offer a
| tool to help them fix their mistakes.
| Apocryphon wrote:
| Monetizing timac.org app analyses is developer catnip
|
| https://news.ycombinator.com/from?site=timac.org&next=175530...
| ericlewis wrote:
| I've used it since close to day one and it's great. You can get
| some detailed information and action items and it's super easy
| to use.
| derefr wrote:
| A.k.a. The Jepsen model.
| paxys wrote:
| 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).
| paulddraper wrote:
| What makes it galaxy brain vs normal brain?
| kazinator wrote:
| I would start by looking at what junk is linked in.
| teekert wrote:
| I like the deep "Time flies like an arrow; fruit flies like a
| banana" multi-interpertness of this remark, very clever.
| _fw wrote:
| Reminds me of
|
| > Knowledge is Power - France is bacon.
| chongli wrote:
| 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!
|
| [1] https://en.wikipedia.org/wiki/Dangling_modifier
|
| [2] https://en.wikipedia.org/wiki/Garden-path_sentence
| klabb3 wrote:
| 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.
| OtomotO wrote:
| > 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 :)
| thrnkkm wrote:
| 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.
| rand846633 wrote:
| > And spinning up secondary dev instances is not permitted
| due to high AWS cost.
|
| Time for a new employment opportunity.
| ToucanLoucan wrote:
| > 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.
| m463 wrote:
| > the grumpy ones
|
| 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.
| vasco wrote:
| 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".
| mjburgess wrote:
| What attitude is the appropriate one if everything _will_
| collapse?
|
| 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.
| DaiPlusPlus wrote:
| > What attitude is the appropriate one if everything will
| collapse?
|
| Short the stock.
| m463 wrote:
| Sorry, should have been more clear.
|
| 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.
| klabb3 wrote:
| 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.
| usrusr wrote:
| 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.
| DanielHB wrote:
| 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.
| ako wrote:
| 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.
| sotix wrote:
| > 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.
| ngrilly wrote:
| 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.
| klabb3 wrote:
| 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.
| passwordoops wrote:
| >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
| johnzimmerman wrote:
| What career did you transition to?
| passwordoops wrote:
| 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
| ngrilly wrote:
| 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
| osrec wrote:
| 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.
| signaru wrote:
| It's like Parkinson's law, but extended to other resources
| besides time, like capital.
| signaru wrote:
| Some of my friends who work in similar situations call this
| "job security".
| DanielHB wrote:
| 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.
| itsoktocry wrote:
| > _go on a PM-centric feature frenzy_
|
| 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!
| wildrhythms wrote:
| 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...
| ninkendo wrote:
| 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 -\\_(tsu)_ /-" 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.)
| foobarxyzzy wrote:
| 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?
| salamander014 wrote:
| > 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.
| silent_cal wrote:
| Especially when everything's on 2 week sprint cycles, and all
| of those new features are rushed. We can refactor later!
| feverzsj wrote:
| Why not pick a popular third-party app and buy it or employ its
| developer, which should be much cheaper than employing hundreds
| of subpar developers.
| dacryn wrote:
| it's how microsoft does it's business. They have to lead by
| example.
|
| 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
| crotchfire wrote:
| Telemetry.
| qsi wrote:
| The LinkedIn app on Android clocks in at using 351 MB on my
| phone, but 187 MB of that is cache and 13 MB is data. The app
| itself is "only" 151 MB.
| mikhael28 wrote:
| I remember, like, three years ago looking at the LI app and
| wondering, why was it almost 200MB. Bloat breeds bloat.
| zerr wrote:
| This happens due to the absence of feature completeness in the
| world of employment.
| teekert wrote:
| Bloat expands to meet the growing needs of the bloat ;)
| Traubenfuchs wrote:
| 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.
| DanielHB wrote:
| 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.
| gnicholas wrote:
| 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.
| jfernandezr wrote:
| 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.
| reportgunner wrote:
| It probably breaks if you go back and it doesn't reload.
| pie420 wrote:
| The answer is that A/B testing found that reloading the
| website/app drove more user engagement.
| drooopy wrote:
| Must be all those wonderful and oh-so-important "you are getting
| noticed" or "your profile was viewed" notifications piling up.
| tap-snap-or-nap wrote:
| Deleted that toxic app since the covid. I just had it, it is
| working great for me so far.
| EVa5I7bHFq9mnYK wrote:
| 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.
| m0llusk wrote:
| Ironically, that is simple business logic and a handful of
| simple strings for translation. Bloat must remain unseen to be
| reliably preserved.
| bagels wrote:
| The size is correlated to the number of engineers working on it.
| LAC-Tech wrote:
| give each engineer a budget of 256 bytes
| rchaud wrote:
| "There's a website for that"
| oferzelig wrote:
| 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.
| actionfromafar wrote:
| How would they know, though? If the download times out, does
| LinkedIn care or notice?
| WJW wrote:
| Surely they'd at least notice a decrease in installations of
| the new "too big to download" version?
| actionfromafar wrote:
| 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
| danpalmer wrote:
| 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.
| jasode wrote:
| _> , 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?
|
| 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?
| gruez wrote:
| 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.
| gcr wrote:
| 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.
| danpalmer wrote:
| 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.
| ninkendo wrote:
| 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.
| paxys wrote:
| 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.
| JeremyNT wrote:
| 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.
| eddd-ddde wrote:
| 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!
| SkyPuncher wrote:
| 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.
| llmblockchain wrote:
| Where else would you store your dark patterns, tracking code and
| contact stealing logic?
| mnw21cam wrote:
| 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.
| xyst wrote:
| 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.
| mnw21cam wrote:
| 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.
| naveen99 wrote:
| Once LLM's start getting packaged with apps, we'll see half a
| terabyte. And then you can say "linked in was only half a gig in
| my day".
| dangus wrote:
| 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.
| hbn wrote:
| > 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.
| 1vuio0pswjnm7 wrote:
| Because it's necessary? Microsoft is trustworthy, aren't they?
| ilrwbwrkhv wrote:
| 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.
___________________________________________________________________
(page generated 2024-03-26 23:02 UTC)