18 ms·

Leaving LinkedIn

473 points by wyclif 3y ago

bugbuddy 3y ago
[flagged]
- deleted 3y ago
  [deleted]
willcipriano 3y ago
> 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...
- 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.
LightFog 3y ago
Oh boy, been there. This is Conway’s law in action - they are about to go and create the same code soup again - because the org won’t have changed. Having been in the same boat my lesson is positive engineering initiatives can only come top down - through some very senior champion. You can’t change an organisation from the bottom up - and it’s the organisation that produces the code base.
- zer00eyz 3y ago
  >> This is Conway’s law in action Not just one layer, look at the stack: Type script is MS's Conways law. API/microsevice everything is more of a google thing (vs FB monolith)... So you have two other major product of Conways Law that your trying to jam into your own org. On top of that a 5 year plan is never going to digestible by (almost) any company. How many people stay in one place for that long? How much has the front end changed in 5 years? Is any choice you make in the JS world relevant in 5 years? Though sell there too!
- antupis 3y ago
  I think it is more nuanced, you can also change the organization bottom up, but it needs to be new stuff that does not exist or has it infancy. Changing existing stuff is very hard even top-down.
  - LightFog 3y ago
    Indeed, and greenfield projects are a great way to move upward in the org - as Jim in the story recognises.
  - chii 3y ago
    > new stuff that does not exist or has it infancy. If it was new stuff, then the people doing it must not be very low at the bottom (by virtue of the org being quite shallow - such as a startup). Even new stuff in a big company with lots of layers of management cannot make new stuff with excellence. Eventually, probably sooner rather than later, it gets polluted. Not to mention that in a big org, the people at the bottom do not get rewarded for making excellence in engineering, if the top doesn't appreciate it. SO why go that extra mile, when a mediocre job will earn you the same salary? You'd be more incentivized to move jobs to grow your pay instead, and use this as a stepping stone.
bobterryo 3y ago
I was really impressed with how open Chris Krycho was about his struggles without playing the blame game. CoRecursive is one of my favorite podcasts because it explores the complex context behind the code.
- Lyngbakr 3y ago
  Agreed. And I also think Adam is a great host. He asks good questions and lets the guest talk.
- yellow_lead 3y ago
  He seems like the kind of guy I'd like to work with, personally.
issafram 3y ago
[flagged]
- snowfield 3y ago
  Engineer angry with leadership
- xwat 3y ago
  "Chris Krycho, a well-known software engineer and blogger, shared his experience working on a large codebase at LinkedIn. He discussed how much velocity was valued over engineering excellence, which led to burnout and the decision to leave the company. Chris also mentioned the concept of "Ratchets," small, incremental changes that can be made to improve software development processes and tools. He is currently looking for a new role that aligns with his personal values and priorities." https://tldrai.com/result/?conversion=cded34924aa147999c6f3f87a55fd459 https://tldrai.com/result/?conversion=cded34924aa147999c6f3f...
- yodon 3y ago
  >TL;DR please Dev goes to work for his first large company, sees his first large legacy codebase, says "wat?! Yuck!!" Also, he explains he was the savior of the entire enterprise and did everything and is super amazing but other people kept having different opinions and his boss didn't like his idea for a project that would take 5 years to achieve the immediately needed change, so he left the large company. Bonus: It only took him 5 years to decide he didn't want to be at a big company with a legacy codebase.
joshhart 3y ago
I spent 12 years at LinkedIn. Sadly, it's not even close to the engineering org it used to be. The era where Kevin Scott led engineering was a really good one in comparison.
- hasty_pudding 3y ago
  Ryan Rolansky said LinkedIn is essentially feature complete.
  - Redoubts 3y ago
    Isn't it?
    - pcloadletter_ 3y ago
      They seem to be trying to jam AI into a bunch of things now. As an aside, I work on a product that should be considered feature complete, but PMs keep dreaming up features so they can get promoted. I wish we could just take some time to clean up the horrendous tech debt accrued over the past 10 years of feature proliferation.
    - gardenhedge 3y ago
      If you consider lots of features that don't work "complete" then I guess
    - ab209 3y ago
      [dead]
- MisterPea 3y ago
  Every engineer of a company of this size says the same exact thing. IMO more about growth of the engineering teams that lead to any specific culture deteriorating.
mkl95 3y ago
> That's 20 times almost the size of my, how, how do you even build that? How long to build? Oh, 17 minutes for a new build. That's, that's not bad. We should probably make that better, but that’s not bad. Am I spoiled for thinking 17 minutes is too much, even if it's 2 million LOC? I guess LinkedIn can afford it
- esprehn 3y ago
  Yeah, they could definitely optimize it quite a lot further. With investment in code structure and caching I bet they could get below 5min at that scale. But also for edit/refresh that should be on the order of a second or two, never minutes.
- liampulles 3y ago
  It is not too much or too little. The real question is whether the value of X% speedup worth Y hours of developer time to make the improvement. Relative to other work that could be done. Answer could well be yes since build time impacts everyone, but also have to factor in complexity of the CI system they use.
  - bluepizza 3y ago
    No, that's not the real question. Decisions have more factors than just what cash will they bring in. Long build times are an operational risk - it's very hard to apply patches to solve incidents with a 20 minute build time.
    - liampulles 3y ago
      To clarify: when I say value I don't just mean monetary value - though of course everything in a business ultimately does boil down to that, including the total expectation of risks. I agree though, definitely a factor
    - izacus 3y ago
      So reducing this would be a multi-year project of a sizeable team (let's say 5-10 people). How do you get someone to sign off for this kind of expediture and not lay everyone off when the next economic fart comes? Because THAT'S the hard problem to solve in any bigger organization. Not hacking the code.
throwawaaarrgh 3y ago
Poor kid, learning how an enterprise works the hard way. If he stays in software eng long enough he'll be back here eventually, with a little less gumption, but a little more tactics and grit to fight the battles he wants to fight.
- cybrox 3y ago
  Are we belitteling people now because they have intrinsic standards and pride in the quality of their work instead of blindly chasing whatever is best for their replaceable career in a hypercapitalistic environment?
  - yard2010 3y ago
    No. We're just being condescending pricks on the internet
    - JohnL4 3y ago
      Huh, self-aware HN. Don't see that very often.
  - doublerabbit 3y ago
    Hopefully they'll learn that such standards don't exist and that if they do will deteriorate by the second year. If it wasn't for it being some big enterprise corporate company no one would give a stuff about the blog post. Do I care someone left company X, fired from company Y? No. Do I acknowledge it's upsetting? Yes, Pack your stuff and try again. welcome to life.
  - CoastalCoder 3y ago
    Aside from the GP comment calling the guy "kid", it doesn't seem especially condescending to me. I read it more like "Yeah, we've all been there. It's a sucky lesson to learn, but in the end he's likely to be wiser (albeit more jaded) to these things."
  - throwawaaarrgh 3y ago
    Not really bro, but you stay angry
ztratar 3y ago
Sounds to me like he made a couple unfortunate moves: - Propose a 5 year plan (lol) - Don't lead the incident with leadership, but with blame - Speaking about problems more than solving problems (hard to do) - Lack of relationship building On one hand, I empathize with Chris. On the other hand, this sounds to me like he just didn't know how to perform in this environment. And that's totally fine! Not everything should learn how to perform in the bureaucratic knots -- startups are simpler in this way. And there's a reason the big guys lose their edge over time, and then some exec in a board room is faced with -10% YoY loss without any truthful VPs around the table.
- mjburgess 3y ago
  I go back and forth on how to interpret people like Chris (and likewise, myself). I've been in this situation, and it's psychologically disorienting: I seem to be right, but am I? Are the people around me really as incompetent as they seem, as totally disinterested in learning from their colleagues, etc. etc. Then a few years after leaving, you look back and: oh, all those people have been fired or left; they still cannot do X as an org; the agility and competence of teams I then joined really does exist etc. So, on the one hand, it's true that there's a sort of arrogance, political incompetence, and inability to cope with environments with a pathological practice culture --- but, on the other hand, maybe that's the right reaction? Maybe the institution is undergoing a pathological cultural period, and maybe talented, considered, passionate people should be driven mad by it. Maybe the people who arent driven mad by it are either irrelevant to productivity/growth, or worse, net deadweights. Who knows? That's what makes being in this environment such a psychodrama -- is the situation really this bad, or am I over-reacting? "Everyone tells me...."
  - yard2010 3y ago
    Don't gaslight yourself. Believe! Remember that shit floats, and you have to pick your battles.
    - dade_ 3y ago
      Scum rises to the top.
ShadowBanThis01 3y ago
[dead]
lloydatkinson 3y ago
Chris: There we go. Okay, those are running now. Crap. Did I screw up my ability to hear you? Adam: Hello, hello, hello? Chris: I did. Dang it. Hang on. Adam: Hello, hello? Chris: Yeah, yeah, we’re good now. Okay. Let’s try that again. Truly fascinating dialog
- Raed667 3y ago
  It is a fairly common podcast trope to leave some bloopers at the start to humanise the people there.
  - lloydatkinson 3y ago
    And fill the script with that? Wow
- frou_dh 3y ago
  They know you need something to complain about, so are giving it to you upfront.
  - patja 3y ago
    Can I complain about the podcast website that truncated the right side of the content on my phone and won't let me scale it to correct?
- gandutraveler 3y ago
  It's a thing. Like how GenZs start their tiktok videos showing fake urgency.
  - lloydatkinson 3y ago
    It’s awful and unprofessional for a podcast. This is why editing exists.
willvarfar 3y ago
Its interesting because, although I don't know the linkedin codebases nor worked at linkedin, I've seen a few codebases that sound scarily similar and am familiar with a few companies that sound organisationally and politically scarily similar. And I generally advocate 'finger gun' approaches. Finger gun rewrites can be implemented in a good way. Often when you have n clients trying to do the same thing, one of those can be used as a basis for serving the other platforms. Or if you start over, you can do it in a good clean quick concise way. The general success ingredient is putting a small team of veterans on making the new system. Success always comes from a small team of engineers who are both domain experts and technical experts rolled into one. (Controversially, I think that generalises; all success comes from this, even for mundane keep-the-lights-on problems. And everyone else is just slowing them down.) The big problem most tech management everywhere keeps repeating is that the next big system will be built the least-experienced. Would be really nice to hear the symmetrical interview from a finger-gunner.
- shp0ngle 3y ago
  The article is not very specific so I can't really tell one way or other 5 year plan is sounding really bad, though
  - willvarfar 3y ago
    Yeap! We can't predict the future but we can all be very surprised if whatever tech is picked today is still a good fit, or even still exists, in 5 years. Especially in the javascript space.
    - jameshart 3y ago
      This is becoming less true than it once was. React has been ‘this month’s JS framework’ for 10 years now.
      - Andrex 3y ago
        Anecdotally React was not in serious contention (for corporate use) until about 2016 or 2017. And React itself has not remained a stable API (rise and fall of hooks).
cbb330 3y ago
I work at LinkedIn now. Chris’s role and the podcast describes ember and front end web dev. I think the LoC and build he’s referring to could be voyager-web. Our monolith flagship web app. And, there’s more systems at LinkedIn with MM lines of code and long builds example is the mid tiers, the offline data stacks, the metrics systems, KafkaKafkaKafka. Unfortunately, 17min to build is pretty good. 17min without a transient infra failure is very good. Anyways, AMA
- hasty_pudding 3y ago
  I worked at LinkedIn in infra. Their internal tools are a nightmare. The true definition of Jugaad. The entire company has zero concept of testing. No QA at all. Engineers push out half baked initiatives to add to their promotion packet then move on to the next thing. I trouble shot so many issues just in day to day usage of the internal tooling like for some reason, engineers just trying to do their jobs, are QA.
  - cbb330 3y ago
    TIL jugaad haha. Yea, give everything 3x estimate because everything that can break will break along the way. Fresh clone of master won’t build, the local build command is broken, gradle, remote build, GitHub, staging is an inside joke, prod host os upgrades, dependencies bumped in repo, http dependency’s network route changed, etc. etc. etc.
  - makingstuffs 3y ago
    Seeing you use 'Jugaad' make me unreasonably happy. I feel like this sort of flinging shit over the wall mentality is very much becoming de-facto nowadays. Very often I have been required to just 'get shit done quick and dirty' over spending time to come up with a permanent solution. Quick and dirty is never the short term fix it is meant to be. It always ends up being left in place until it inevitably breaks down the line.
    - rrr_oh_man 3y ago
      But are things ever permanent? Isn’t it to be expected that stuff can change in the future?
gedy 3y ago
This sounds like one of those "soft leadership" roles, that almost always suck because you're "responsible" for something, but have little or no authority over the rest of the org. The real tech leadership (if any) are MIA or no longer in touch with the actual problems, even if they've been their forever or are the "system experts" Been there, done that, no thanks.
swader999 3y ago
Really feels like mission impossible to do this kind of role remotely.
- snotrockets 3y ago
  It's very possible, and I've seen a lot of people do it successfully. It does require some organizational changes, and a slightly different set of skills, and some fail to realize they lack both.
AdrianB1 3y ago
Boeing in action. Luckily nobody is flying LinkedIn MAX, so there are no deaths as a result.
callamdelaney 3y ago
It's no surprise that LinkedIn's codebase is a mess if you try to use the website, it's a complete nightmare. Say I see an interesting post, I click on the person who wrote it to learn more about them, then I press back to go back to the post and continue reading it - now the feed refreshed and I've lost the post. Say I want to scroll back through messages I've received, I do that, the entire webpage starts lagging and takes 10-15 seconds to register inputs. Why do I get 30 fake notifications? They are literally not real, made up rubbish to force interactions from people - it's disingenuous. The recommendation algorithm is also completely terrible.
- pm90 3y ago
  The notifications has long been totally useless.
- dade_ 3y ago
  considering they are owned my Microsoft, their windows app app is a technical marvel. It’s a crippled buggy version of their already too buggy web app. I understand why it was made, but I don’t understand why it was released. It doesn’t look good for either brand.
- purist33 3y ago
  The thing about the notifications though, is you can turn off every single one of them in the settings. When I tried to turn it off though, I was hit with 100s of different types of notifications. I generally like it when apps/sites do this. This way I can turn off the garbage i dont need, and keep the ones I want. But 90% of thosr categories were garbage. It is really shocking that one can take a good idea this far and make it frustating.
- higeorge13 3y ago
  Even jobs tab in each company page doesn’t work in ios for me. What’s the point of using it then?
throwaway112996 3y ago
[flagged]
nottorp 3y ago
> Note: This podcast is designed to be heard. If you are able, we strongly encourage you to listen to the audio, which includes emphasis that’s not on the page Seriously? You getting more "engagement" because someone is a good actor?
- raziel2p 3y ago
  what?
_2qb7 3y ago
The introduction sounds very GPTy: > His journey was marked by challenges: from the nuances of remote work to the struggle of influencing company culture, and a critical incident that put his principles to the test against the company’s push for speed. >Chris’s story highlights the tension between the need for innovation and the importance of project health. This all led Chris to a pivotal decision: to stay and compromise his beliefs or to leave in pursuit of work that aligned with his principles. >He chose the latter. Join us as we dive into Chris’s compelling story, exploring the challenges of advocating for principled engineering in a world that often prioritizes quick wins over long-term value.
- CoastalCoder 3y ago
  FWIW, it seems pretty consistent with the style of Adam's other intros.
padjo 3y ago
No shade on ember as a framework but LinkedIn’s decision to use Ember always baffled me. As far as I remember they switched to it long after it was clear react had “won”.
- anytime5704 3y ago
  Some internal stakeholder surely fought for it so they could get promoted. Happy for that person, wherever they are now.
- chriskrycho 3y ago
  LinkedIn actually chose Ember well before React had won, and definitely before it had become the new “no one gets fired for buying IBM.” That all preceded my time there, but the evaluation was late 2014 and the LinkedIn.com web app rebuild in Ember was kicked off in 2015 if I recall correctly. React only came out in 2013, and while it was definitely on a rocket ship it was way less obvious in late 2014 that it was going to be the de facto standard that it was by late 2016–early 2017. Bonus note: One factor that was really not obvious at the point they were doing the evaluation was how much TypeScript and TypeScript-powered tooling was going to matter. TS shipped support for JSX/TSX in TS 1.6, in late 2015, and I contend that while JSX had a lot of pros and cons, the one absolutely unambiguous win it had over everything else from that point forward was that whether you were writing JS or TS, you got outstanding editor support in basically every editor in the world courtesy of the TS language server backing your JS or TS development. Just absolutely massive. The fact that the TS team baked support for JSX into TS itself and that it's not pluggable is (a) totally understandable and reasonable from a maintenance effort POV, especially given that Microsoft uses React extensively, and (b) extremely frustrating for everyone not using JSX. Vue, Angular, Svelte, and Ember all had to build the exact same infrastructure to get that support, and that was a huge productivity hit for devs using those frameworks compared to React in the meantime.
ghostoftiber 3y ago
But I bet he still has his resume on LinkedIn. :)
acqbu 3y ago
LinkedIn comes across as a not-so-great company to work for. I find their product to be very toxic, off-putting and full of life coaches and scammers.
pier25 3y ago
LinkedIn is so awful to use. There's value in the connections you can make and hiring or finding a job... But it's probably one of the worst web apps I use. I'm surprised it ever got this big.
compacct27 3y ago
The big rewrite. Risky even on manageable codebases, and the leftovers never seem to fully go away. Who wants to score points on re-writing a tucked-away settings page several years into these? I've seen so many attempts at these you'd think we'd have a framework for rewriting codebases. We don't. Automated codemods require a consistency that few adhered to. The code patterns evolved so much over time, it's like looking at tree rings. We're basically putting code in boxes, re-arranging the boxes, and rightfully saying some arrangements are more efficient. How come we haven't found a better way? Automations operate at the code level, but not at the box level.
jll29 3y ago
MM lines of JavaScript! That is bloat incarnate. I've been thinking of re-implementing something like LI, or rather implement my own contact database (without the "FB" features, please). The only problem would be how to make my contacts migrate over in bulk. Apart from the bloat, the main problem of Microsoft LinkedIn is that it does not let you export your contacts' infos, which really is a must-have feature of a contact platform.
- game_the0ry 3y ago
  Call me crazy but I did not think that was a surprise. I worked at big bank that had consumer-facing JS web app with 6MM lines of code, though now I am starting to think that that number is false, given the feedback in this thread.
- miohtama 3y ago
  LinkedIn was originally built in Ruby, containing 60k lines of code https://queue.acm.org/detail.cfm?id=2567673 https://queue.acm.org/detail.cfm?id=2567673 Summary: https://www.pixelstech.net/article/1395463142-Why-does-LinkedIn-migrate-to-NodeJS-from-Ruby https://www.pixelstech.net/article/1395463142-Why-does-Linke... LinkedIn migrated to Node early 2010.
  - jspash 3y ago
    So they claim the change to node reduces the 60k lines of Ruby to only 2k of node. So how did they manage to add 1,998,000 more lines of node in the next 10 years and not think something was amiss?
    - Solvency 3y ago
      Developers love to armchair and then you put a bunch of them together and you inevitably end up with soaking wet bloated festering codebases like LinkedIn
    - foofie 3y ago
      > So how did they manage to add 1,998,000 more lines of node in the next 10 years (...) Does LinkedIn have the same features it had a decade ago? Search is far more powerful. It also shifted to add an entirely new social media dimension to it. God knows what features were made available to recruiters and marketers. The hard part of a web app is not the stuff you see; it's the stuff you don't even know is there.
bgirard 3y ago
> Okay. Well, I can keep butting my head against this wall. 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. To me that's the most interesting quote of the podcast and that's the impression I had gotten before reading this quote. Sounds like they received valuable feedback along the way and ignored it on purpose. My career lesson is that being right isn't the hard part of being a senior staff engineer. Being right isn't enough. It's building alignment across the entire org towards the right solution. That's the hard valuable problem that I'm paid to solve. I worked on the facebook.com rewrite to React in 2019. I find this story particularly interesting.
- atomicnumber3 3y ago
  I mean, yes and no. I find staff engineers, and especially the senior-staff-engineer-type positions, to be the ones most sensitive to the exact specifics of the org they've joined. I've seen a senior staff engineer (at a popular unicorn you've all heard of) who was a very smart, but also friendly and reasonable person (how often are those traits in opposition of each other!). They were very good at the staff engineer game. They were vouching for us to upgrade a framework that we pumped 50M of spend through per year. From v2 to v3. It wasn't a huge change, not like python 2 to 3 at all. Positively trivial compared to py2 to 3. But management just were not up for it at all. Even with research done showing we could expect literally a baseline of 10% improvement in performance (so you do the math on that vs the 50M of spend), they just did not want to "waste time on version upgrades." The staff engineer was told they were being unreasonable in pushing so hard. Their manager tried to ditch them, but again, they're good at the staff eng game, so they switched teams due to being in the good graces (due to an excellent track record) with a middle manager above them. They decided, hey fuck you, I'm going to one man army this effort. They did, they had preview versions ready in less than a month and had migrated some of the bigger-win jobs within 2, saving their annual comp (which was prodigious) several times over just in that. Suddenly everyone was keen on moving their stuff over now that the startup cost (both political and eng-time) was paid. Anyway fast forward a year, the rollout is complete and nearly the entire fucking management chain above him has turned over, a 50/50ish mix of firings vs quittings. But he's still there and the upgrade migration is complete. So sure, sometimes staff engineers have a stick up their bum and can't dislodge it enough to get work done on the bottom line. But sometimes they're the only sane ones in a crazy world, and you can only do so much to try to turn a balky mule around.
queuebert 3y ago
Since when is LinkedIn is fast paced? It hasn't substantially changed in ten years.
- herbturbo 3y ago
  The fast pace comes from product deciding there should be 5 different types of “like” button and goofy AI “takeaways” functionality. LinkedIn is a solved problem but you can’t have that any more.
  - margorczynski 3y ago
    Probably a lot of work that is being done there is inventing useless stuff that makes people, projects and departments look needed. What happened to Twitter shows that in most older orgs with a well established product you can throw out ~50% of the people and it still will go on.
- mardifoufs 3y ago
  LinkedIn learning is pretty new, massively pushed for too. And most of the new features are on the recruitment side I think
uptownfunk 3y ago
In my career I have learned to listen more carefully to engineers. Sometimes it is not about saying yes and no to them but listening to what they are trying to say. Sometimes if you ask a few questions they learned something about the business that makes their case come apart. Sometimes if you listen to them you find a good idea and it opens up a whole new area of the product. So I think it’s a false dichotomy and you have to be good at listening and asking the right questions to get your point across.
sonicanatidae 3y ago
I have no idea why anyone is still a user on LinkedIn. They've had numerous breaches, and give 2 entire shits about it. If your account gets stolen, even with MFA enabled, they will take roughly 2+ weeks to respond to your ticket and they require that you send in even more information that they will callously handle. My advice, leave LinkedIn. Edit: Or, continue to enjoy taking it in the shorts, for an entity that could not care less.. lol
maximinus_thrax 3y ago
Although I do listen to Adam Gordon Bell's podcasts from time to time, I'm not sure if I should invest 40something minutes into hearing about why some rando left BigCorp. This may be an unpopular opinion, but isn't unprofessional to spill the beans about your past employment like this? As an external observer and hiring manager, I wouldn't touch this person with a 10-foot pole if they're in the hiring pool. I personally find this type of content to be mundane, basic and useless. This is the type of stuff most people run into if their engineering career spans more than a couple of years, touches large organizations, they can't handle conflicts and have the luxury of being more affluent than other employees. I don't understand why someone would go out of their way to share something like this.
- chriskrycho 3y ago
  This is, indeed the type of stuff most people run into if their career spans more than a couple years, touches large organizations, etc. That is why I thought it would be useful to share: it is the kind of thing that would’ve been really helpful for me in the first few years of my career to understand some of the dynamics, including what can go well, and what can go less well, and the kind of mistakes one might try to avoid, as well as what it means to stick with one’s convictions, even when that might be costly. Whether it is “unprofessional“ or not is something I thought about quite a bit. I think I walked the line of being fairly politic and avoiding dragging real people’s names through the mud, while still getting into some of what that kind of real world engineering and associated politics is like. At the same time, I can see how someone would take the view that none of this kind of thing should be shared outside the company. Your mileage may vary. I hope at a minimum you can understand why someone might choose to air a little bit of it while trying not to be nasty about it.
  - maximinus_thrax 3y ago
    Thank you for the clarification, it seems you put a lot of thought into this. Let's agree to disagree here. You may find this valuable information that's worth sharing, I do not - I think the risks outweigh the benefits.
jrh3 3y ago
Can't stay in business swapping dollars. Usually, the ones declaring their idealism are going to find a problem with you regardless. Doing the right thing is what you do, but that's not the sort of attitude that works.
anoncow 3y ago
That's a great blogcast/plot.
- anoncow 3y ago
  *plog
zellyn 3y ago
I found the "finger guns" team and their plan fascinating, and I've definitely seen enthusiasm sweep the field many times. I work on an infrastructure / foundational engineering team, and it reminds of something I'm increasingly believing to be true: It's much harder to get headcount/funding for a two-year plan to build/fix an internal tool than to get headcount/funding for a six-month plan to use an external product that ends up taking 3-4 years. In this situation, I'd say it's much harder to get headcount/funding for a five-year plan to perform a well-engineered migration than it is to get approval for a two-year whizz-bang plan to create an amazing replacement that will actually take 3-6 years and/or actually leave 80% of the legacy code migration unfinished basically forever, leading to pure xkcd 927.
- zellyn 3y ago
  As an addendum, I found the episode fascinating. As someone who has spent about five of the last eight years on a foundational engineering team, involved in _many_ long, grinding migrations where the end goal is clearly a win for the company but not particularly useful for product teams in the short term, I thought the plans Chris outlined showed remarkable maturity and good planning in approach. I also enjoyed hearing a public discussion of the nature of that kind of migration. I would not, myself, choose to talk quite so negatively about a former employer and colleagues, but I respect and enjoyed the decision of idealistic folks like Chris to be open about the struggles entailed!
pousseelettre 3y ago
[flagged]
pousseelettre 3y ago
[flagged]
elbear 3y ago
The migration from Ember to React sounds like a good case for a technology a previous client of mine created. He created a language called Unhack which allowed you to do a kind of search-and-replace but at the level of the AST. You would use this language to specify a pattern in the original code, then another pattern that would be the replacement. Unfortunately, I don't know if it still exists, as I stopped working with that client a couple of years ago.
carlysagan 3y ago
I clicked this bc I thought it was about users leaving Linkedin and was excited lol. But I listened and he pitched a 5 year plan solution to fix bad code??! Come on, this guy may never get hired again after that. Listening to this, I felt outrage at the concept of white men feeling like they can just quit when a company doesn't follow their slow engineering model. Huh?? I feel annoyed with stupid software and product decisions all the time and that's just how it is everywhere. All of capitalism and all of tech is do-it-as-fast-and-cheap-as-possible. Hello? Oh right, I looked at his Linkedin and he never had any formal training in software or engineering and has a MS in Divinty, so goodluck bruh, back to the bible for you.
li_engineer 3y ago
I am an engineer at LinkedIn and have been here for a long time. Haven't worked with CK and work on areas unrelated to Finger Gun project. But I agree with the general sentiment of feeling frustrated. Everything is now happening top-down. Execs want AI thrown everywhere even where things don't make sense. Engineers don't have the room to give feedback that they used to. Leaders want everything delivered asap. We are creating lot of tech debt every day and not maintaining any balance between speed and quality. Features are being implemented with missing edge cases and they say we will fix it later but no one has time or motivation to fix it. The execs only know we launched a feature, nobody tells them that the feature is too broken to actually be usable. There's a lot of fear of being managed out for performance so people are sucking it up and implementing what is asked with urgency. No one has time or motivation to fix bugs or clean up the code.

Leaving LinkedIn

473 points by wyclif 3y ago

bugbuddy 3y ago

[flagged]

deleted 3y ago
[deleted]

willcipriano 3y ago

> 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...
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.

LightFog 3y ago

Oh boy, been there. This is Conway’s law in action - they are about to go and create the same code soup again - because the org won’t have changed. Having been in the same boat my lesson is positive engineering initiatives can only come top down - through some very senior champion. You can’t change an organisation from the bottom up - and it’s the organisation that produces the code base.

zer00eyz 3y ago
>> This is Conway’s law in action Not just one layer, look at the stack: Type script is MS's Conways law. API/microsevice everything is more of a google thing (vs FB monolith)... So you have two other major product of Conways Law that your trying to jam into your own org. On top of that a 5 year plan is never going to digestible by (almost) any company. How many people stay in one place for that long? How much has the front end changed in 5 years? Is any choice you make in the JS world relevant in 5 years? Though sell there too!
antupis 3y ago
I think it is more nuanced, you can also change the organization bottom up, but it needs to be new stuff that does not exist or has it infancy. Changing existing stuff is very hard even top-down.
- LightFog 3y ago
  Indeed, and greenfield projects are a great way to move upward in the org - as Jim in the story recognises.
- chii 3y ago
  > new stuff that does not exist or has it infancy. If it was new stuff, then the people doing it must not be very low at the bottom (by virtue of the org being quite shallow - such as a startup). Even new stuff in a big company with lots of layers of management cannot make new stuff with excellence. Eventually, probably sooner rather than later, it gets polluted. Not to mention that in a big org, the people at the bottom do not get rewarded for making excellence in engineering, if the top doesn't appreciate it. SO why go that extra mile, when a mediocre job will earn you the same salary? You'd be more incentivized to move jobs to grow your pay instead, and use this as a stepping stone.

bobterryo 3y ago

I was really impressed with how open Chris Krycho was about his struggles without playing the blame game. CoRecursive is one of my favorite podcasts because it explores the complex context behind the code.

Lyngbakr 3y ago
Agreed. And I also think Adam is a great host. He asks good questions and lets the guest talk.
yellow_lead 3y ago
He seems like the kind of guy I'd like to work with, personally.

issafram 3y ago

[flagged]

snowfield 3y ago
Engineer angry with leadership
xwat 3y ago
"Chris Krycho, a well-known software engineer and blogger, shared his experience working on a large codebase at LinkedIn. He discussed how much velocity was valued over engineering excellence, which led to burnout and the decision to leave the company. Chris also mentioned the concept of "Ratchets," small, incremental changes that can be made to improve software development processes and tools. He is currently looking for a new role that aligns with his personal values and priorities." https://tldrai.com/result/?conversion=cded34924aa147999c6f3f87a55fd459 https://tldrai.com/result/?conversion=cded34924aa147999c6f3f...
yodon 3y ago
>TL;DR please Dev goes to work for his first large company, sees his first large legacy codebase, says "wat?! Yuck!!" Also, he explains he was the savior of the entire enterprise and did everything and is super amazing but other people kept having different opinions and his boss didn't like his idea for a project that would take 5 years to achieve the immediately needed change, so he left the large company. Bonus: It only took him 5 years to decide he didn't want to be at a big company with a legacy codebase.

joshhart 3y ago

I spent 12 years at LinkedIn. Sadly, it's not even close to the engineering org it used to be. The era where Kevin Scott led engineering was a really good one in comparison.

hasty_pudding 3y ago
Ryan Rolansky said LinkedIn is essentially feature complete.
- Redoubts 3y ago
  Isn't it?
  - pcloadletter_ 3y ago
    They seem to be trying to jam AI into a bunch of things now. As an aside, I work on a product that should be considered feature complete, but PMs keep dreaming up features so they can get promoted. I wish we could just take some time to clean up the horrendous tech debt accrued over the past 10 years of feature proliferation.
  - gardenhedge 3y ago
    If you consider lots of features that don't work "complete" then I guess
  - ab209 3y ago
    [dead]
MisterPea 3y ago
Every engineer of a company of this size says the same exact thing. IMO more about growth of the engineering teams that lead to any specific culture deteriorating.

mkl95 3y ago

> That's 20 times almost the size of my, how, how do you even build that? How long to build? Oh, 17 minutes for a new build. That's, that's not bad. We should probably make that better, but that’s not bad. Am I spoiled for thinking 17 minutes is too much, even if it's 2 million LOC? I guess LinkedIn can afford it

esprehn 3y ago
Yeah, they could definitely optimize it quite a lot further. With investment in code structure and caching I bet they could get below 5min at that scale. But also for edit/refresh that should be on the order of a second or two, never minutes.
liampulles 3y ago
It is not too much or too little. The real question is whether the value of X% speedup worth Y hours of developer time to make the improvement. Relative to other work that could be done. Answer could well be yes since build time impacts everyone, but also have to factor in complexity of the CI system they use.
- bluepizza 3y ago
  No, that's not the real question. Decisions have more factors than just what cash will they bring in. Long build times are an operational risk - it's very hard to apply patches to solve incidents with a 20 minute build time.
  - liampulles 3y ago
    To clarify: when I say value I don't just mean monetary value - though of course everything in a business ultimately does boil down to that, including the total expectation of risks. I agree though, definitely a factor
  - izacus 3y ago
    So reducing this would be a multi-year project of a sizeable team (let's say 5-10 people). How do you get someone to sign off for this kind of expediture and not lay everyone off when the next economic fart comes? Because THAT'S the hard problem to solve in any bigger organization. Not hacking the code.

throwawaaarrgh 3y ago

Poor kid, learning how an enterprise works the hard way. If he stays in software eng long enough he'll be back here eventually, with a little less gumption, but a little more tactics and grit to fight the battles he wants to fight.

cybrox 3y ago
Are we belitteling people now because they have intrinsic standards and pride in the quality of their work instead of blindly chasing whatever is best for their replaceable career in a hypercapitalistic environment?
- yard2010 3y ago
  No. We're just being condescending pricks on the internet
  - JohnL4 3y ago
    Huh, self-aware HN. Don't see that very often.
- doublerabbit 3y ago
  Hopefully they'll learn that such standards don't exist and that if they do will deteriorate by the second year. If it wasn't for it being some big enterprise corporate company no one would give a stuff about the blog post. Do I care someone left company X, fired from company Y? No. Do I acknowledge it's upsetting? Yes, Pack your stuff and try again. welcome to life.
- CoastalCoder 3y ago
  Aside from the GP comment calling the guy "kid", it doesn't seem especially condescending to me. I read it more like "Yeah, we've all been there. It's a sucky lesson to learn, but in the end he's likely to be wiser (albeit more jaded) to these things."
- throwawaaarrgh 3y ago
  Not really bro, but you stay angry

ztratar 3y ago

Sounds to me like he made a couple unfortunate moves: - Propose a 5 year plan (lol) - Don't lead the incident with leadership, but with blame - Speaking about problems more than solving problems (hard to do) - Lack of relationship building On one hand, I empathize with Chris. On the other hand, this sounds to me like he just didn't know how to perform in this environment. And that's totally fine! Not everything should learn how to perform in the bureaucratic knots -- startups are simpler in this way. And there's a reason the big guys lose their edge over time, and then some exec in a board room is faced with -10% YoY loss without any truthful VPs around the table.

mjburgess 3y ago
I go back and forth on how to interpret people like Chris (and likewise, myself). I've been in this situation, and it's psychologically disorienting: I seem to be right, but am I? Are the people around me really as incompetent as they seem, as totally disinterested in learning from their colleagues, etc. etc. Then a few years after leaving, you look back and: oh, all those people have been fired or left; they still cannot do X as an org; the agility and competence of teams I then joined really does exist etc. So, on the one hand, it's true that there's a sort of arrogance, political incompetence, and inability to cope with environments with a pathological practice culture --- but, on the other hand, maybe that's the right reaction? Maybe the institution is undergoing a pathological cultural period, and maybe talented, considered, passionate people should be driven mad by it. Maybe the people who arent driven mad by it are either irrelevant to productivity/growth, or worse, net deadweights. Who knows? That's what makes being in this environment such a psychodrama -- is the situation really this bad, or am I over-reacting? "Everyone tells me...."
- yard2010 3y ago
  Don't gaslight yourself. Believe! Remember that shit floats, and you have to pick your battles.
  - dade_ 3y ago
    Scum rises to the top.

ShadowBanThis01 3y ago

[dead]

lloydatkinson 3y ago

Chris: There we go. Okay, those are running now. Crap. Did I screw up my ability to hear you? Adam: Hello, hello, hello? Chris: I did. Dang it. Hang on. Adam: Hello, hello? Chris: Yeah, yeah, we’re good now. Okay. Let’s try that again. Truly fascinating dialog

Raed667 3y ago
It is a fairly common podcast trope to leave some bloopers at the start to humanise the people there.
- lloydatkinson 3y ago
  And fill the script with that? Wow
frou_dh 3y ago
They know you need something to complain about, so are giving it to you upfront.
- patja 3y ago
  Can I complain about the podcast website that truncated the right side of the content on my phone and won't let me scale it to correct?
gandutraveler 3y ago
It's a thing. Like how GenZs start their tiktok videos showing fake urgency.
- lloydatkinson 3y ago
  It’s awful and unprofessional for a podcast. This is why editing exists.

willvarfar 3y ago

Its interesting because, although I don't know the linkedin codebases nor worked at linkedin, I've seen a few codebases that sound scarily similar and am familiar with a few companies that sound organisationally and politically scarily similar. And I generally advocate 'finger gun' approaches. Finger gun rewrites can be implemented in a good way. Often when you have n clients trying to do the same thing, one of those can be used as a basis for serving the other platforms. Or if you start over, you can do it in a good clean quick concise way. The general success ingredient is putting a small team of veterans on making the new system. Success always comes from a small team of engineers who are both domain experts and technical experts rolled into one. (Controversially, I think that generalises; all success comes from this, even for mundane keep-the-lights-on problems. And everyone else is just slowing them down.) The big problem most tech management everywhere keeps repeating is that the next big system will be built the least-experienced. Would be really nice to hear the symmetrical interview from a finger-gunner.

shp0ngle 3y ago
The article is not very specific so I can't really tell one way or other 5 year plan is sounding really bad, though
- willvarfar 3y ago
  Yeap! We can't predict the future but we can all be very surprised if whatever tech is picked today is still a good fit, or even still exists, in 5 years. Especially in the javascript space.
  - jameshart 3y ago
    This is becoming less true than it once was. React has been ‘this month’s JS framework’ for 10 years now.
    - Andrex 3y ago
      Anecdotally React was not in serious contention (for corporate use) until about 2016 or 2017. And React itself has not remained a stable API (rise and fall of hooks).

cbb330 3y ago

I work at LinkedIn now. Chris’s role and the podcast describes ember and front end web dev. I think the LoC and build he’s referring to could be voyager-web. Our monolith flagship web app. And, there’s more systems at LinkedIn with MM lines of code and long builds example is the mid tiers, the offline data stacks, the metrics systems, KafkaKafkaKafka. Unfortunately, 17min to build is pretty good. 17min without a transient infra failure is very good. Anyways, AMA

hasty_pudding 3y ago
I worked at LinkedIn in infra. Their internal tools are a nightmare. The true definition of Jugaad. The entire company has zero concept of testing. No QA at all. Engineers push out half baked initiatives to add to their promotion packet then move on to the next thing. I trouble shot so many issues just in day to day usage of the internal tooling like for some reason, engineers just trying to do their jobs, are QA.
- cbb330 3y ago
  TIL jugaad haha. Yea, give everything 3x estimate because everything that can break will break along the way. Fresh clone of master won’t build, the local build command is broken, gradle, remote build, GitHub, staging is an inside joke, prod host os upgrades, dependencies bumped in repo, http dependency’s network route changed, etc. etc. etc.
- makingstuffs 3y ago
  Seeing you use 'Jugaad' make me unreasonably happy. I feel like this sort of flinging shit over the wall mentality is very much becoming de-facto nowadays. Very often I have been required to just 'get shit done quick and dirty' over spending time to come up with a permanent solution. Quick and dirty is never the short term fix it is meant to be. It always ends up being left in place until it inevitably breaks down the line.
  - rrr_oh_man 3y ago
    But are things ever permanent? Isn’t it to be expected that stuff can change in the future?

gedy 3y ago

This sounds like one of those "soft leadership" roles, that almost always suck because you're "responsible" for something, but have little or no authority over the rest of the org. The real tech leadership (if any) are MIA or no longer in touch with the actual problems, even if they've been their forever or are the "system experts" Been there, done that, no thanks.

swader999 3y ago

Really feels like mission impossible to do this kind of role remotely.

snotrockets 3y ago
It's very possible, and I've seen a lot of people do it successfully. It does require some organizational changes, and a slightly different set of skills, and some fail to realize they lack both.

AdrianB1 3y ago

Boeing in action. Luckily nobody is flying LinkedIn MAX, so there are no deaths as a result.

callamdelaney 3y ago

It's no surprise that LinkedIn's codebase is a mess if you try to use the website, it's a complete nightmare. Say I see an interesting post, I click on the person who wrote it to learn more about them, then I press back to go back to the post and continue reading it - now the feed refreshed and I've lost the post. Say I want to scroll back through messages I've received, I do that, the entire webpage starts lagging and takes 10-15 seconds to register inputs. Why do I get 30 fake notifications? They are literally not real, made up rubbish to force interactions from people - it's disingenuous. The recommendation algorithm is also completely terrible.

pm90 3y ago
The notifications has long been totally useless.
dade_ 3y ago
considering they are owned my Microsoft, their windows app app is a technical marvel. It’s a crippled buggy version of their already too buggy web app. I understand why it was made, but I don’t understand why it was released. It doesn’t look good for either brand.
purist33 3y ago
The thing about the notifications though, is you can turn off every single one of them in the settings. When I tried to turn it off though, I was hit with 100s of different types of notifications. I generally like it when apps/sites do this. This way I can turn off the garbage i dont need, and keep the ones I want. But 90% of thosr categories were garbage. It is really shocking that one can take a good idea this far and make it frustating.
higeorge13 3y ago
Even jobs tab in each company page doesn’t work in ios for me. What’s the point of using it then?

throwaway112996 3y ago

[flagged]

nottorp 3y ago

> Note: This podcast is designed to be heard. If you are able, we strongly encourage you to listen to the audio, which includes emphasis that’s not on the page Seriously? You getting more "engagement" because someone is a good actor?

raziel2p 3y ago
what?

_2qb7 3y ago

The introduction sounds very GPTy: > His journey was marked by challenges: from the nuances of remote work to the struggle of influencing company culture, and a critical incident that put his principles to the test against the company’s push for speed. >Chris’s story highlights the tension between the need for innovation and the importance of project health. This all led Chris to a pivotal decision: to stay and compromise his beliefs or to leave in pursuit of work that aligned with his principles. >He chose the latter. Join us as we dive into Chris’s compelling story, exploring the challenges of advocating for principled engineering in a world that often prioritizes quick wins over long-term value.

CoastalCoder 3y ago
FWIW, it seems pretty consistent with the style of Adam's other intros.

padjo 3y ago

No shade on ember as a framework but LinkedIn’s decision to use Ember always baffled me. As far as I remember they switched to it long after it was clear react had “won”.

anytime5704 3y ago
Some internal stakeholder surely fought for it so they could get promoted. Happy for that person, wherever they are now.
chriskrycho 3y ago
LinkedIn actually chose Ember well before React had won, and definitely before it had become the new “no one gets fired for buying IBM.” That all preceded my time there, but the evaluation was late 2014 and the LinkedIn.com web app rebuild in Ember was kicked off in 2015 if I recall correctly. React only came out in 2013, and while it was definitely on a rocket ship it was way less obvious in late 2014 that it was going to be the de facto standard that it was by late 2016–early 2017. Bonus note: One factor that was really not obvious at the point they were doing the evaluation was how much TypeScript and TypeScript-powered tooling was going to matter. TS shipped support for JSX/TSX in TS 1.6, in late 2015, and I contend that while JSX had a lot of pros and cons, the one absolutely unambiguous win it had over everything else from that point forward was that whether you were writing JS or TS, you got outstanding editor support in basically every editor in the world courtesy of the TS language server backing your JS or TS development. Just absolutely massive. The fact that the TS team baked support for JSX into TS itself and that it's not pluggable is (a) totally understandable and reasonable from a maintenance effort POV, especially given that Microsoft uses React extensively, and (b) extremely frustrating for everyone not using JSX. Vue, Angular, Svelte, and Ember all had to build the exact same infrastructure to get that support, and that was a huge productivity hit for devs using those frameworks compared to React in the meantime.

ghostoftiber 3y ago

But I bet he still has his resume on LinkedIn. :)

acqbu 3y ago

LinkedIn comes across as a not-so-great company to work for. I find their product to be very toxic, off-putting and full of life coaches and scammers.

pier25 3y ago

LinkedIn is so awful to use. There's value in the connections you can make and hiring or finding a job... But it's probably one of the worst web apps I use. I'm surprised it ever got this big.

compacct27 3y ago

The big rewrite. Risky even on manageable codebases, and the leftovers never seem to fully go away. Who wants to score points on re-writing a tucked-away settings page several years into these? I've seen so many attempts at these you'd think we'd have a framework for rewriting codebases. We don't. Automated codemods require a consistency that few adhered to. The code patterns evolved so much over time, it's like looking at tree rings. We're basically putting code in boxes, re-arranging the boxes, and rightfully saying some arrangements are more efficient. How come we haven't found a better way? Automations operate at the code level, but not at the box level.

jll29 3y ago

MM lines of JavaScript! That is bloat incarnate. I've been thinking of re-implementing something like LI, or rather implement my own contact database (without the "FB" features, please). The only problem would be how to make my contacts migrate over in bulk. Apart from the bloat, the main problem of Microsoft LinkedIn is that it does not let you export your contacts' infos, which really is a must-have feature of a contact platform.

game_the0ry 3y ago
Call me crazy but I did not think that was a surprise. I worked at big bank that had consumer-facing JS web app with 6MM lines of code, though now I am starting to think that that number is false, given the feedback in this thread.
miohtama 3y ago
LinkedIn was originally built in Ruby, containing 60k lines of code https://queue.acm.org/detail.cfm?id=2567673 https://queue.acm.org/detail.cfm?id=2567673 Summary: https://www.pixelstech.net/article/1395463142-Why-does-LinkedIn-migrate-to-NodeJS-from-Ruby https://www.pixelstech.net/article/1395463142-Why-does-Linke... LinkedIn migrated to Node early 2010.
- jspash 3y ago
  So they claim the change to node reduces the 60k lines of Ruby to only 2k of node. So how did they manage to add 1,998,000 more lines of node in the next 10 years and not think something was amiss?
  - Solvency 3y ago
    Developers love to armchair and then you put a bunch of them together and you inevitably end up with soaking wet bloated festering codebases like LinkedIn
  - foofie 3y ago
    > So how did they manage to add 1,998,000 more lines of node in the next 10 years (...) Does LinkedIn have the same features it had a decade ago? Search is far more powerful. It also shifted to add an entirely new social media dimension to it. God knows what features were made available to recruiters and marketers. The hard part of a web app is not the stuff you see; it's the stuff you don't even know is there.

bgirard 3y ago

> Okay. Well, I can keep butting my head against this wall. 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. To me that's the most interesting quote of the podcast and that's the impression I had gotten before reading this quote. Sounds like they received valuable feedback along the way and ignored it on purpose. My career lesson is that being right isn't the hard part of being a senior staff engineer. Being right isn't enough. It's building alignment across the entire org towards the right solution. That's the hard valuable problem that I'm paid to solve. I worked on the facebook.com rewrite to React in 2019. I find this story particularly interesting.

atomicnumber3 3y ago
I mean, yes and no. I find staff engineers, and especially the senior-staff-engineer-type positions, to be the ones most sensitive to the exact specifics of the org they've joined. I've seen a senior staff engineer (at a popular unicorn you've all heard of) who was a very smart, but also friendly and reasonable person (how often are those traits in opposition of each other!). They were very good at the staff engineer game. They were vouching for us to upgrade a framework that we pumped 50M of spend through per year. From v2 to v3. It wasn't a huge change, not like python 2 to 3 at all. Positively trivial compared to py2 to 3. But management just were not up for it at all. Even with research done showing we could expect literally a baseline of 10% improvement in performance (so you do the math on that vs the 50M of spend), they just did not want to "waste time on version upgrades." The staff engineer was told they were being unreasonable in pushing so hard. Their manager tried to ditch them, but again, they're good at the staff eng game, so they switched teams due to being in the good graces (due to an excellent track record) with a middle manager above them. They decided, hey fuck you, I'm going to one man army this effort. They did, they had preview versions ready in less than a month and had migrated some of the bigger-win jobs within 2, saving their annual comp (which was prodigious) several times over just in that. Suddenly everyone was keen on moving their stuff over now that the startup cost (both political and eng-time) was paid. Anyway fast forward a year, the rollout is complete and nearly the entire fucking management chain above him has turned over, a 50/50ish mix of firings vs quittings. But he's still there and the upgrade migration is complete. So sure, sometimes staff engineers have a stick up their bum and can't dislodge it enough to get work done on the bottom line. But sometimes they're the only sane ones in a crazy world, and you can only do so much to try to turn a balky mule around.

queuebert 3y ago

Since when is LinkedIn is fast paced? It hasn't substantially changed in ten years.

herbturbo 3y ago
The fast pace comes from product deciding there should be 5 different types of “like” button and goofy AI “takeaways” functionality. LinkedIn is a solved problem but you can’t have that any more.
- margorczynski 3y ago
  Probably a lot of work that is being done there is inventing useless stuff that makes people, projects and departments look needed. What happened to Twitter shows that in most older orgs with a well established product you can throw out ~50% of the people and it still will go on.
mardifoufs 3y ago
LinkedIn learning is pretty new, massively pushed for too. And most of the new features are on the recruitment side I think

uptownfunk 3y ago

In my career I have learned to listen more carefully to engineers. Sometimes it is not about saying yes and no to them but listening to what they are trying to say. Sometimes if you ask a few questions they learned something about the business that makes their case come apart. Sometimes if you listen to them you find a good idea and it opens up a whole new area of the product. So I think it’s a false dichotomy and you have to be good at listening and asking the right questions to get your point across.

sonicanatidae 3y ago

I have no idea why anyone is still a user on LinkedIn. They've had numerous breaches, and give 2 entire shits about it. If your account gets stolen, even with MFA enabled, they will take roughly 2+ weeks to respond to your ticket and they require that you send in even more information that they will callously handle. My advice, leave LinkedIn. Edit: Or, continue to enjoy taking it in the shorts, for an entity that could not care less.. lol

maximinus_thrax 3y ago

Although I do listen to Adam Gordon Bell's podcasts from time to time, I'm not sure if I should invest 40something minutes into hearing about why some rando left BigCorp. This may be an unpopular opinion, but isn't unprofessional to spill the beans about your past employment like this? As an external observer and hiring manager, I wouldn't touch this person with a 10-foot pole if they're in the hiring pool. I personally find this type of content to be mundane, basic and useless. This is the type of stuff most people run into if their engineering career spans more than a couple of years, touches large organizations, they can't handle conflicts and have the luxury of being more affluent than other employees. I don't understand why someone would go out of their way to share something like this.

chriskrycho 3y ago
This is, indeed the type of stuff most people run into if their career spans more than a couple years, touches large organizations, etc. That is why I thought it would be useful to share: it is the kind of thing that would’ve been really helpful for me in the first few years of my career to understand some of the dynamics, including what can go well, and what can go less well, and the kind of mistakes one might try to avoid, as well as what it means to stick with one’s convictions, even when that might be costly. Whether it is “unprofessional“ or not is something I thought about quite a bit. I think I walked the line of being fairly politic and avoiding dragging real people’s names through the mud, while still getting into some of what that kind of real world engineering and associated politics is like. At the same time, I can see how someone would take the view that none of this kind of thing should be shared outside the company. Your mileage may vary. I hope at a minimum you can understand why someone might choose to air a little bit of it while trying not to be nasty about it.
- maximinus_thrax 3y ago
  Thank you for the clarification, it seems you put a lot of thought into this. Let's agree to disagree here. You may find this valuable information that's worth sharing, I do not - I think the risks outweigh the benefits.

jrh3 3y ago

Can't stay in business swapping dollars. Usually, the ones declaring their idealism are going to find a problem with you regardless. Doing the right thing is what you do, but that's not the sort of attitude that works.

anoncow 3y ago

That's a great blogcast/plot.

anoncow 3y ago
*plog

zellyn 3y ago

I found the "finger guns" team and their plan fascinating, and I've definitely seen enthusiasm sweep the field many times. I work on an infrastructure / foundational engineering team, and it reminds of something I'm increasingly believing to be true: It's much harder to get headcount/funding for a two-year plan to build/fix an internal tool than to get headcount/funding for a six-month plan to use an external product that ends up taking 3-4 years. In this situation, I'd say it's much harder to get headcount/funding for a five-year plan to perform a well-engineered migration than it is to get approval for a two-year whizz-bang plan to create an amazing replacement that will actually take 3-6 years and/or actually leave 80% of the legacy code migration unfinished basically forever, leading to pure xkcd 927.

zellyn 3y ago
As an addendum, I found the episode fascinating. As someone who has spent about five of the last eight years on a foundational engineering team, involved in _many_ long, grinding migrations where the end goal is clearly a win for the company but not particularly useful for product teams in the short term, I thought the plans Chris outlined showed remarkable maturity and good planning in approach. I also enjoyed hearing a public discussion of the nature of that kind of migration. I would not, myself, choose to talk quite so negatively about a former employer and colleagues, but I respect and enjoyed the decision of idealistic folks like Chris to be open about the struggles entailed!

pousseelettre 3y ago

[flagged]

pousseelettre 3y ago

[flagged]

elbear 3y ago

The migration from Ember to React sounds like a good case for a technology a previous client of mine created. He created a language called Unhack which allowed you to do a kind of search-and-replace but at the level of the AST. You would use this language to specify a pattern in the original code, then another pattern that would be the replacement. Unfortunately, I don't know if it still exists, as I stopped working with that client a couple of years ago.

carlysagan 3y ago

I clicked this bc I thought it was about users leaving Linkedin and was excited lol. But I listened and he pitched a 5 year plan solution to fix bad code??! Come on, this guy may never get hired again after that. Listening to this, I felt outrage at the concept of white men feeling like they can just quit when a company doesn't follow their slow engineering model. Huh?? I feel annoyed with stupid software and product decisions all the time and that's just how it is everywhere. All of capitalism and all of tech is do-it-as-fast-and-cheap-as-possible. Hello? Oh right, I looked at his Linkedin and he never had any formal training in software or engineering and has a MS in Divinty, so goodluck bruh, back to the bible for you.

li_engineer 3y ago

I am an engineer at LinkedIn and have been here for a long time. Haven't worked with CK and work on areas unrelated to Finger Gun project. But I agree with the general sentiment of feeling frustrated. Everything is now happening top-down. Execs want AI thrown everywhere even where things don't make sense. Engineers don't have the room to give feedback that they used to. Leaders want everything delivered asap. We are creating lot of tech debt every day and not maintaining any balance between speed and quality. Features are being implemented with missing edge cases and they say we will fix it later but no one has time or motivation to fix it. The execs only know we launched a feature, nobody tells them that the feature is too broken to actually be usable. There's a lot of fear of being managed out for performance so people are sucking it up and implementing what is asked with urgency. No one has time or motivation to fix bugs or clean up the code.