5 ms·

> My previous company had what I thought at the time was a pretty decent sized app, like 150,000 lines of code. And the LinkedIn front end, when I got there had

> My previous company had what I thought at the time was a pretty decent sized app, like 150,000 lines of code. And the LinkedIn front end, when I got there had 2 million, it’s just like, I’m, did you say million? Uh, that’s, that’s a lot. I'd love to see what makes it so large. That's like 1/15th the size of Linux.

deleted 3y ago
[deleted]
apimade 3y ago
Including boilerplate code? ASP and JS is far more verbose in those areas.
PreachSoup 3y ago
Think js+html+css, that's a lot
dilyevsky 3y ago
Have you ever worked on projects (particularly java suffers from this) where there is generational bloat because most people have very narrow understanding of the codebase so they can only add things and not remove/refactor without breaking it? That’s how
- deleted 3y ago
  [deleted]
- CapsAdmin 3y ago
  Usually if you peek at the first few commits it all seemed nice and clean. The turning point is usually as soon as the original author/'s leave and new people come in.
- Cthulhu_ 3y ago
  That's not likely to be the issue here tbh, or, that's focusing on low-hanging fruit. You get large codebases from having many features. No amount of coding and refactoring will bring a codebase's size down in a significant and measurable way unless features are ruthlessly removed.
  - dilyevsky 3y ago
    I mean sure, I could understand Figma's frontend or something having millions of lines but what does linkedin frontend do that would reasonably require this?
    - crooked-v 3y ago
      My guess is that it's because there are 800 different versions of everything because none of the company's 13,000 UI/UX designers are willing to use the same component libraries.
      - superhuzza 3y ago
        Blaming 2,000,000 lines of code on UX designers, and not the developers, is certainly a new one.
  - bluetomcat 3y ago
    These high-profile apps are elaborate spying devices. Besides the UI code, they probably have thousands of classes, some of which abandoned as dead code, with names like ProfileViewActivityLocationTracker...
- realusername 3y ago
  Orgs never value engineers that improve the overall codebase so I can't blame them. You're only getting promoted and compensated by delivering the next big feature which is part of the owners vision and being visible.
- The_Colonel 3y ago
  > particularly java suffers from this Correlation, not causation. Java is often used on large projects, it doesn't itself make things brittle. It's like the bomber survivorship fallacy - the fact you see such messed up projects mostly in Java is that they would not survive in languages like Python, where even a simple method rename can easily lead to big regressions.
tayo42 3y ago
That quote is why you can't take anything seriously on the internet about running software or software engineering seriously. There are to many people that just don't know what they don't know and act they have things solved. I think the software world has like two bubbles of people around the scale they work with and they don't understand each other or run into each other, except in interviews and on the internet.
- esprehn 3y ago
  It's funny you say that because as someone in the large scale bubble when I read 2 million lines that didn't seem that large. Other companies of similar size are dealing with 2-10x larger web apps. Ex. https://stripe.com/blog/migrating-to-typescript https://stripe.com/blog/migrating-to-typescript Which talks about 3.7m lines at Stripe.
  - chriskrycho 3y ago
    Yeah, and I have it on good authority that there are JS/TS apps more than 10 times larger than that at Google. Scale is relative.
diarrhea 3y ago
The site makes me sad whenever I visit. On my beefy desktop, load times for the home page are at around three seconds. On my feeble (but still enormously expensive: a Microsoft Surface) laptop, it’s well in excess of 10 seconds. Both tests run on the very same network, so my conclusion is that load times are CPU bound, aka there’s huge amounts of JavaScript running, for one reason or another.

deleted 3y ago

[deleted]

apimade 3y ago

Including boilerplate code? ASP and JS is far more verbose in those areas.

PreachSoup 3y ago

Think js+html+css, that's a lot

dilyevsky 3y ago

Have you ever worked on projects (particularly java suffers from this) where there is generational bloat because most people have very narrow understanding of the codebase so they can only add things and not remove/refactor without breaking it? That’s how

deleted 3y ago
[deleted]
CapsAdmin 3y ago
Usually if you peek at the first few commits it all seemed nice and clean. The turning point is usually as soon as the original author/'s leave and new people come in.
Cthulhu_ 3y ago
That's not likely to be the issue here tbh, or, that's focusing on low-hanging fruit. You get large codebases from having many features. No amount of coding and refactoring will bring a codebase's size down in a significant and measurable way unless features are ruthlessly removed.
- dilyevsky 3y ago
  I mean sure, I could understand Figma's frontend or something having millions of lines but what does linkedin frontend do that would reasonably require this?
  - crooked-v 3y ago
    My guess is that it's because there are 800 different versions of everything because none of the company's 13,000 UI/UX designers are willing to use the same component libraries.
    - superhuzza 3y ago
      Blaming 2,000,000 lines of code on UX designers, and not the developers, is certainly a new one.
- bluetomcat 3y ago
  These high-profile apps are elaborate spying devices. Besides the UI code, they probably have thousands of classes, some of which abandoned as dead code, with names like ProfileViewActivityLocationTracker...
realusername 3y ago
Orgs never value engineers that improve the overall codebase so I can't blame them. You're only getting promoted and compensated by delivering the next big feature which is part of the owners vision and being visible.
The_Colonel 3y ago
> particularly java suffers from this Correlation, not causation. Java is often used on large projects, it doesn't itself make things brittle. It's like the bomber survivorship fallacy - the fact you see such messed up projects mostly in Java is that they would not survive in languages like Python, where even a simple method rename can easily lead to big regressions.

tayo42 3y ago

That quote is why you can't take anything seriously on the internet about running software or software engineering seriously. There are to many people that just don't know what they don't know and act they have things solved. I think the software world has like two bubbles of people around the scale they work with and they don't understand each other or run into each other, except in interviews and on the internet.

esprehn 3y ago
It's funny you say that because as someone in the large scale bubble when I read 2 million lines that didn't seem that large. Other companies of similar size are dealing with 2-10x larger web apps. Ex. https://stripe.com/blog/migrating-to-typescript https://stripe.com/blog/migrating-to-typescript Which talks about 3.7m lines at Stripe.
- chriskrycho 3y ago
  Yeah, and I have it on good authority that there are JS/TS apps more than 10 times larger than that at Google. Scale is relative.

diarrhea 3y ago

The site makes me sad whenever I visit. On my beefy desktop, load times for the home page are at around three seconds. On my feeble (but still enormously expensive: a Microsoft Surface) laptop, it’s well in excess of 10 seconds. Both tests run on the very same network, so my conclusion is that load times are CPU bound, aka there’s huge amounts of JavaScript running, for one reason or another.