Leaving LinkedIn
corecursive.com
corecursive.com
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.
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.
I think your argument is that 'it worked for him' because he is still there while the managers are not, but reality may be the managers were there to have that effect in the first place and the 50/50 turnover was because they were in the thick of it.
That'd be my cynical take, anyway.
Correct
"I'm an effort to get engineers like the senior staff engineer to pull heroic feats"
I think this gives them too much credit. The reality, imo, is that the org had a pathological emphasis on "impact" and ran performance reviews so tight that everyone, managers included, were so scared of being PIPd and losing their grants that they were extraordinarily risk averse in planning and picking projects to bet on. And leadership in general undervalued "infra-y" changes as mostly make-work.
The turnover was partly because of this general effect - people scared, not betting big or smart enough, and optimizing for holding on / not getting fired. And to their credit, most of these people vested 2-3 years of their 4-year grant before it all fell over, so they made out decently lucratively, so maybe they're the real winners in all this after all.
What you are saying is that sometimes a senior engineer manages to make good things happen?
Did this person get rewarded for this huge effort they put in? You say they already have prodigious yearly compensation, was it at least doubled given that they saved it several times over?
When you're getting paid $500k-$1m/year or more as a staff engineer, putting in huge effort and getting organization-wide impactful results is part of the job description. I'm sure it had a good effect on their yearly comp review, but suggesting that their comp should be doubled because they did their job is silly.
"Did the person get rewarded for this huge effort" Money-wise? Haha. No. Only in the sense that they further solidified their soft power as someone you shouldn't bet against. And of course the sense of pride that comes with shipping something (that further enriches some capitalist and maybe yourself to 0.0013% of the effect, since that's how much of the company your grant commands shares of).
Wtf is an IC? Internal consultant? Individual contributors (what does that even mean? One person team?)
Using abbreviations to explain something is a bad way to explain...
Staff level developers are trusted to figure out what needs to be done without direction. When they are given direction it is figure out how the other engineers break this problem up and do it - typically not do it themselves.
If staff engineers are doing something it is not important to any project. So nobody feels bad about interrupting them if they need help or something urgent comes up. (this also means you are developing your senior developers into staff engineers by giving them responsibility)
https://yosefk.com/blog/people-can-read-their-managers-mind....
In particular:
"Corollary 1. Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. Someone who finds the forks, crashes, etc. a personal offense, and will repeatedly risk annoying management by fighting to stop these things."
In other cases you chose to 'pick a battle' and find the best way to navigate and get buy in. Because again being right -and getting buy in- is the important part. Not later giving everyone an 'I told you so'.
BOFHs suck.
Your career lesson is correct.
Doing the right thing isn't a known characteristic of a BOFH.
--
linus, not so much.
That said, in this case, the person telling me “You’re too idealistic” literally meant it in the sense of “You should not care about anything unless it directly moves the bottom line,” and I reject that to my bones. The bottom line matters. So, though, do things like user experience, developer experience, and for that matter just basic ethics about what we build (though happily the latter wasn’t in view here).
I have a lot of empathy for that feeling. I've come across this often in my career and I have not enjoyed it. I enjoy building software that I'm proud off. Thank you for sharing your story!
Not only that, but your own definition of 'right' may or may not align with what is 'right' for the people paying your salary - pretending otherwise is just silly.
In any organization, you advocate for what you believe is 'right' the best you can, someone else (or a consensus of others) will likely decide if they agree - you get to decide if you are willing to live with it/compromise, or move on - I have done both in my career.
Do you want to wax the wheels of a title-winning race car or of a 1990 Toyota Camry that happens to be in mint condition? A lot of LinkedIn engineers I’ve met are the latter, and Microsoft is trying to push them into being the former. If you are The One True Master Wheel Polisher then sure maybe you get to choose your car, but don’t soapbox it. The audience is smarter than that (I hope).
We don't really have enough context to make a judgement here IMO. I've been in places large enough to have fairly complex politics where people would manouver themselves into better jobs as much as they could, including performing a hostile takeover of another department. They might not have had the best ideas or the best plans, but they did have the right connections, go to lunch with the right people and say the right words.
I've seen bad decisions made because more persuasive and better connected people were attempting to climb the ladder and managed to talk management into it.
"You’re too idealistic. You don’t care enough about the bottom line. You should change your values." could just be something someone says when they're trying to smear someone in the way, especially if that's how they've sold themselves and their ideas to upper management.
Personally I've seen and done a number of large scale changes/upgrades (mostly Ruby/Rails/Postgres things) in orgs smaller than Facebook but still with hundreds of engineers and large codebases, both stop the world, and where the work was streamed seamlessly into regular feature etc. work and the methodology outlined by Chris seems incredibly sensible and aligns with what I have found to be the most successful way of doing these things.
As the host says, we ony have one side of the story here, but at least a lot of the things Chris is saying seem to make sense.
> 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 agree, leadership positions require trust and respect to be effective. You still have to be right for that to be useful of course. Progress in the wrong direction isn't really progress.
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.
5 year plan is sounding really bad, though
And React itself has not remained a stable API (rise and fall of hooks).
Well, that sounds horrible, and will definitely take more years than rewriting it to React.
It's more FUN though!
the person that comes along next is going to moan about how much of a mess of compromises and hacks your, now, legacy codebase is
> It was completely what another colleague of mine once described as being in finger guns mode, meaning like, yeah, yeah, yeah, this is going to be awesome, man, kind of finger gunning at each other without answering any of the kinds of questions about what does it look to like to operate this when we’re trying to support hundreds and hundreds of engineers…
It’s given me an idea for a two-way portal where on one side, technical developers join the platform, self-organize into independent, transparent teams (not just developers but any role in development e.g. UX designer, project manager, etc) and on the other, companies join, post their potentially cross-functional work requests which are then distributed to the relevant teams. Another important concept is that these instances can be federated(?) so existing consulting firms can integrate this new kind of work allocation into their pipelines (only their consultants/their invited companies). There are a bunch other concepts I’ve thought through but that’s where I’m at now.
I feel that a system like this provides better value to a company vs. traditional consulting. First, the responsibility of team formation, networking, and allocation is moved to the service. These three things are hard for humans to do themselves and are responsible for so much consulting admin bloat/inefficiency and companies have no choice but to play. Second, it in theory improves the quality of work teams. With this focus on smaller, self-organized teams and a UX that allows for transparency I.e. companies can view teams, their members, and track record, companies know what they’ll get and not need to roll the dice to see what available resource gets assigned to them. Moreover, I’ve read that consultancies have a tendency to throw certain resources on a large work item where they exist to just to cash in budget and write bad code. This problem is completely mitigated with this approach. Finally, it’s a decentralized work environment (I think). Besides OSS, I don’t know what other platform allows for developers to have so much autonomy and self-determination. You could argue sites like Upwork or Freelancer but these platforms seem more focused on small, individual jobs rather than larger work items which justify having larger, more competent teams.
Being a principal engineer, my major value is not in my technical capacity, but rather my ability to shape the technical solution to the best fit for the business - be it to do with existing tooling, processes, systems, etc. Though I can do the technical solutions (probably more efficiently, too), my value is much stronger when I steer multiple junior engineers doing the technical work whilst setting the guideposts so they align the solution to what best fits the business.
I would therefore suggest that one major hurdle would be that these self-organising teams might not be able to bring to bear their full capacity insofar as they are not familiar with the businesses to which they pair. Though you can sometimes see parallels between company processes, understanding the nuance and detail that makes them different is where so many consultancy projects fall over. Think about the canonical meme of a team of consultants coming in and spending millions developing a solution that turns out to be a lemon. It’s not for their lack of capability, it’s that it’s devilishly hard to really, truly fully understand a business’s processes, systems and cruft in a sufficient level of detail to truly shape a solution such that it remains maintainable and fit for purpose in a long-term sense.
That’s the real reason why veteran employees are worth their weight in gold. It’s that they are the custodians of the institutional memory and can bring that forward when it is needed.
This of course has the important counterpoint of the necessity of seeding new ideas into a business, and that’s an entirely different essay in itself, however suffice it to say that new ideas need to be integrated in a sustainable and controlled fashion - protected and nurtured from being driven out by the existing ways, but also moulded to integration where it’s necessary. Failure to do either is a speedrun to pain.
Edit to add: If you think that IT is somehow immune from this relative to traditional meatspace engineering disciplines, I’d say two things: 1) tech still goes through this, just sometimes operates on different timescales, and 2) go see if a COBOL greybeard collecting FU consultant wages to maintain old OT systems agrees with you.
I always want to have a sense that the plan gives us realistic options for dealing with the obstacles. And that doesn’t just mean technical options - we’ll need to have the people to tackle it too. Eg it’s not great if the plan involves a bunch of teams running servers, and while technically there are obviously ways for all those teams to operate and scale those servers, if they don’t have the time or skills to do so then that option of having the teams run stuff is not really realistic.
But on the other hand planning a careful course that navigates round every obstacle is just as bad because
1) the obstacles will likely have moved by the time you get there (eg we spend ages figuring out how teams on legacy JS will be affected by the project only to find by the time we get there everyone has already moved to typescript and all that prep was YAGNI).
And 2) there are probably obstacles right in the path you’ve carefully chosen that you don’t know about yet and when you hit them your plan will grind to a halt because there was only one way planned and this was it.
We’re reading a cartoon podcast description of a complex architectural debate here though, so who knows which of these straw men was actually close to what was happening in LinkedIn.
The tradeoff around “do we migrate to TS?” is a great example here, by the way. A huge part of our decision-making last year around the big app at LinkedIn was on exactly that question: If you are going to stop and throw the entire thing away, you should waste exactly zero time migrating any of it. On the other hand, if the thing is going to be migrated incrementally, you should accelerate the TS effort because it will make it so much easier to code-mod the code base.
(I don’t agree that it’s a “cartoon” podcast description, but it is definitely extremely compressed and Adam and I chose to focus on the personal dynamics over the technical details, because diving into the latter would have made for a 5-hour episode. Also: it’s really tricky to do any of this kind of public discussion in a way that doesn’t just end up reading as a one-sided self-defense!)
Most places I've worked at, this ends up being the case because the most experienced are needed to fire fight and to keep things running.
By that account the most experienced started out as the least experienced who built a mess, accrued more technical debt, and built up their experience keeping their ball of mud from crumbling.
They are also more resistent to change because this underlines all the crap they did. It's their baby, and their reputation is pinned on how successful it is.
New is not necessarily better, but old and stable also doesn't mean fine engineering.
THIS
"experienced doesnt always mean good. This is why you build teams.
The CFO is your enemy as an engineer.
I talked to someone who was leaving his job because he did this in order to meet a critical date for a product launch. The fact that his group of 3-4 people did what the company could not in a year ruffled so many feathers he said the board told the entirety of engineering that under no circumstance would anyone be allowed to dictate any detail of future projects.
It's like being paid in exposure. We'll pay you in cool tech and learning!
Then you see the 20 go devs around you making the same money writing grpc services 8 hours a day home at 5 relaxing.
Anyway:
I will see that I always worry about super teams because super teams tend to get free rein, so of course they can be faster and more successful. But sometimes that's about the bureaucracy and not even the team members.
I've started projects with a team and due to time factors decided "I'll just take all of this." and it worked out great. That's not because I'm amazing... it's just the old adage about "What one programmer can do in one month, two programmers can do in two months".
Unfortunately, I've seen places where these super teams / people are setup and endlessly praised and it goes on and on and it becomes very clear it isn't them, it's the structure.
1. team A developed some really nice looking graphs from customer data we already collected
2. a member of team A pointed out he is colorblind and the palette did not work for him
3. product manager took the time to research this and figure out how we might make the palette configurable for those who are colorblind
4. CEO got wind of this and called everyone involved into a meeting. The decision of the CEO was no one would ever use colors for any data presentation. The only allowable color was a shade of gray
I'd like to point out that using only a shade of gray for "colors" effectively makes the entire planet colorblind
I don't disagree with this approach. But one thing I find is:
Sometimes those veteran teams are heavily invested in existing concepts, tools, and approaches. It makes sense, they have seen these things work and they're proven to some extent.
But it's always not the best choice.... and while the veteran teams often start these projects they often aren't the people to "finish" them as they get pulled away. And it is oh so easy to start projects and make decisions if you never see the outcome / have to deal with the fallout.
I think it comes down to the personality of the veteran. If they're the "i've seen some shit, so I'll 'architect' the fuck out of this to handle any type of change" type veterans, then it's likely to fail. But if they take their knowledge of how the system has grown over time and architect to handle the types of changes they've seen, then there is likely a greater chance of success.
Personally, I think a having some junior and mid-level engineers on the rewrite is good because it's a good way to see how the system is all put together (as opposed to just one area) and they'll be able to have conversations with the veterans about how the system has evolved as it grew and that is valuable information.
If I could edit the post I'd insert a qualifying "expert" before veteran, where the expert veteran meets my definition of the 10x developer :D
Any veterans who aren't gonna get the project done quickly _and_ properly aren't the kind of veterans I have in mind.
This is very closely related to why these veteran teams end up successful. Existing concepts, tools and approaches should be the default; if your company uses Python with MySQL you better have a really, really good reason for your new project to use Rust and CockroachDB.
> while the veteran teams often start these projects they often aren't the people to "finish" them as they get pulled away.
I disagree with this. The veterans are veterans because they've already spent time maintaining the existing systems. They've handled oncall, major bugs, and seen all kinds of stupid shit that happens with software. They'll get pulled onto other projects eventually, sure, but they have a higher chance of getting a system into production in front of users, IMO.
Following through with something from start to "finish" is far far more valuable than fixing one off bugs and then doing something else, and then something else.
If anything I think it can lead to a lot of poor assumptions based on very skewed experience.
per some sibling comments though, years of experience != veteran, to be clear. There's certainly people who have been working for 10+ years, sometimes even at the same company, and don't really understand what they're working on.
If your main product is C or C++ then you should be learning about things like rust. Maybe you decide modern C++ is good enough, but if so you should be working with the C++ committee to push safe C++ (as a C++ developer I'm hoping this comes in C++26... I'm looking at how I can put rust into my code for now).
The point is you should know what the good next steps to investigate are and what are not. Rust and Python are both great tools, but it is never okay to choose between the two on any project - the choice is obvious before you get to choosing. Both tools have other competitors that you perhaps should be looking at though (Rust - ada, C++. Python: ruby, go)
I actually really disagree with this. Python and Ruby are extremely similar in the problem they solve. If you're using MySQL as a basic OLTP database, and you need a basic OLTP database, you shouldn't use Postgres.
I'm talking organizationally here, not just on a single project. You gain nothing by introducing Ruby to your company that's filled with Python experts. Instead, you introduce a bunch of friction and overhead as developers have to relearn things like syntax, how to set up their development environment, how to do dependency management, testing frameworks, etc...
The time to introduce new tech is when it is fundamentally different enough that it could matter. Maybe you have a bunch of Python code, but there's a certain area that's very performance sensitive: you could look at using Rust, Go or C++. Maybe you have MySQL, but you need a database that's used for complex OLAP queries rather than low-latency OLTP work. There you could look at Redshift, Snowflake or the various Postgres OLAP configurations.
Where experience comes in is knowing when these new tools are worth the overhead they cause. Less experienced engineers vastly underestimate the overhead that comes with introducing new tooling. This even applies internally; for example, if you've used Flask for every project you've done at your company for the past 5 years is it really worth switching to Django?
I think you agree more than you realize. GP is essentially saying there are few situations where you will be deciding between Python and Rust on account of organization and technical reasons. However, sometimes you should consider introducing new technologies, but only when you identify that the problem being addressed is much better solved by a new technology, fully aware that this will cause various sorts of friction within your organization.
Fully agree with this for all scopes of projects. Larger projects are compositions of this principle with functional communications between focus areas.
There's no financial incentives for Maintenance though, which means "leaders" have less and less incentive to fix what they have versus building from scratch. In my experience in these cases it comes down to (like most things) whomever the least flexible person in a power position decides to do.
Fundamentally the problem with all large organizations is that desires and incentives become diffuse the more people are a part of it and the "alignment" of what should happen drifts, until eventually nobody cares to maintain the original purpose.
You can argue this is good or bad or inevitable, but either way it's a structural issue between the broader world changing, and a organization that seeks consistency
To me, it's all about energy. If the energy is behind "fuck it, rewrite it", then that's what you should do. If the energy is behind, "preserve the valuable IP in the existing code" then that's what you should do. Actually I don't think it's even "should"; I think it's "will".
> Would be really nice to hear the symmetrical interview from a finger-gunner.
I found the initial framing of like "expediency vs. the right thing" not quite right. My read was that Chris just found fault with the finger-gunners' bad engineering. Here's a really good excerpt:
---
Why doesn’t Code Review just solve this? That was a direct quote from Jim. And my answer was, well it didn’t, and it won’t again in the future because people are going to make mistakes and just be better. Again, it’s not an answer, because what happens when it’s some junior on the rotation who thinks, yeah, that seems reasonable, and this PR was made by a very senior SRE?
Why am I going to question whether that value is reasonable? Like, yeah, there’s a bunch of boxes. That seems fine. Those kinds of things happen. And to that question of engineering systems, one of the things I think about a lot is, does our system only work or does this process only work? Or does this tool only succeed?
If I’m acting like a senior engineer, on his or her very best day or, or does it work if I’m a super junior engineer who’s having a bad day and we really want our systems to be workable for the latter case. And that helps all of us because sometimes, even though I’m a very senior engineer, sometimes I have bad days.
Sometimes my brain doesn’t feel like it’s working at all. Does the system still support me on those days or does it punish me? I really would like to not be punished.
---
I'm gonna try to be polite here, but Jim's "why doesn't Code Review just solve this" take here is shockingly naive to me. If he doesn't know that defects slip by even the best engineers with the best code review processes, I have to question his experience and judgement. Chris' response of "well it didn't" is all that needs to be said: we empirically can't rely on this system. Failing to recognize that is malpractice. The length Chris goes to to explain why it's malpractice speaks to his professionalism and patience, but yeah it's clear he was in a situation where someone pretty incompetent was now calling the shots.
[0]: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
After (fairly) long time in the industry, it seems to come down to:
- understanding what one's clients need (not what they ask for)
- understanding what's in the realm of the possible (technically, politically, organizationally)
- understanding what are the possible futures (good, great, and abject disaster)
If, after answering all those questions, one still advocating for a rewrite, you've shown the maturity needed to undertake the effort.
"Finger-gunning" is usually related to skipping those steps, not the ultimate decision.
(edit for formatting)
This sounds plausible and is consistent with my experience, but I'm curious if you have a reason for why this is? Is it just that the experienced folks are already working on the established systems, and we don't know what the next big one will be? Or is management doing something intentionally that causes this? Or something else?
The inexperienced folk will be more "cool yeah let's do it". You can't blame them, it's how to become experienced.
With my “fingers guns mode” phrase, I really had in mind a blithe disregard for any of the real-world engineering problems and constraints that we knew we would hit (because they just inhered in what we knew the solution needed to do). You don’t have to solve those right up front, but you do need to (a) acknowledge that they exist and (b) have some notion of what your approach to them will be.
I’m extremely in favor of taking a small team of veterans (who are open to doing something novel!) on a new system, as you say—let them leverage all their expertise, while being careful to avoid Second System Syndrome, to build something by using all of the knowledge about those pitfalls/problems/etc. to avoid them. (The risk there is that you can end up overfitting on previous experience! That’s real!)
- 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.
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...."
If you’re technical, you can get a paycheck just by doing the work. Sure, you can play politics and tech, but is it worth it? Unless you are rewarded as a stakeholder, I’d say it’s not worth it.
More frustratingly, this works the other way. You might skunkworks Elasticsearch into your org. You might have cost-saving metrics up the wazoo; you might have multiple engineer testimonials; you might have satisfied customers or growing sales; you might have better velocity metrics; you might have built profitable services on top of it. An Elasticsearch-hating engineer can convince your boss that it's a ticking time bomb--with no evidence whatsoever--and your boss can say, "hey I found out you're using Elasticsearch for all this, which is a big no-no. I love what you're doing here, but you need to migrate to Postgres".
(I know Elasticsearch flunked Jepsen; it's just an example)
You might think a few things:
- can't I show all my successes and change hearts and minds?
- isn't this how we evolve as a company? we skunkworks things, see if it works, build more on top of it, repeat?
- if we don't take risks, won't another company out-compete us at some point?
- won't some manager take notice of the inefficiency and do something about it?
Sometimes the answer is yes! But it's almost never yes for the right reasons; it's merely the case that you found a manager who hates the PostgreSQL team, or hates one particular PostgreSQL advocate, or finds it advantageous to be seen as a manager who's spearheading new initiatives, or thinks that a homogeneous tech stack is a vulnerable tech stack, etc.
This is the way we all work. We all have our irrational heuristics built up of lifetimes of experience that we hate interrogating; we naturally gravitate to others with the same irrational heuristics because they spare us that interrogation; we assault others who force that interrogation upon us because it's painful. You'll see this dynamic in political tribes, in technology choices at work, on reality TV, everywhere. You can watch us tie ourselves into knots in real time, selectively forget events or facts, or wildly misinterpret things, all to defend our aesthetic preferences. This is the psychological disorientation you're experiencing. It's not common to find people who are aware of these tendencies and--successfully--employ strategies to compensate, and it's even less common to find groups of people who do that. The probability is inverse to the number of people.
Like you (and I guess OP), I've fallen victim to this over and over again on both sides. There is no justice, because there is no God and nothing even approaching perfect competition. Some of those groups are doing great, others are deceased. I've only relatively recently figured this out, so I've now added some things to my interview questions like "tell me about a time you were very wrong" and "how do you reevaluate decisions or longstanding beliefs you have". I also try to check myself whenever I react a little too positively or negatively to something, because that's usually an indication that it's aligned or across my aesthetics and something I need to dig into.
The good news is I've had success instilling this into people I've worked with. It's sort of "a minute to learn; a lifetime to master", but it starts creating a culture of psychological safety where everyone relies on the others to help them be the best they can be.
- Propose a 5-year-plan: yeah, “lol” is about right. It was never going to win any hearts or minds. It was also our least favorite plan. But it was also the only one we felt we could actually bring to our executive leadership given what they were telling us prior to that, which was basically “Even for a migration we are asking you for, do not slow down product iteration velocity at all.” How do you do that? Welllll…
- I’m not really sure what you’re referring to about leading the incident with blame instead of leadership. It’s possible something got lost in translation with the amount we cut, but I actually aimed very much to do the opposite. We didn’t blame the people who lowered the memory thresholds, the people who typo’d a bad value in YAML, or anyone else. I just insisted that we actually solve the root issues instead of leaving them to fester for the next poor person who happened to be around when it inevitably blew up again.
- “Speaking about problems more than solving problems”: really not sure what you mean here. I didn’t spend a ton of time bragging about what I had pulled off on the show because wow would that ever have been in poor taste, but… I did pretty well in the problems I solved there.
- Lack of relationship building: yeah, I called that out on the episode! It was my weakest area. I had a really good rapport with engineers, and failed pretty miserably at building cachet with management, especially with management above me.
I wouldn’t say in the end that it was just down to not knowing how to perform in the environment, though. Some of it was also a choice, in the end, not to perform in ways that I could see would be successful in the environment but which I simply did not believe in. I think a lot of the engineers I respect most are like this: can and will do the political dance for something they believe in… but not for things they don’t believe in.
Unfortunately, 17min to build is pretty good. 17min without a transient infra failure is very good.
Anyways, AMA
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.
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.
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.
Theyre still using python 2 and centOS in tons of systems.
They just started using github last year.
Their tech stack is easily over a decade old.
There's 1 service on py2, with a plan to migrate because of the move off of centos. centos deprecation is in progress.
Are you sure about that?
CentOs migration has been in progress for years lol
its a great learning experience though despite what people say about the inability to learn the new hot hot tech. the nuance of software development is the decisions that other people make, that is inescapable and is a skill worth developing. i'm not buying the "just do a startup" because i think its a cop out.
My biggest pet peeve with this is that a lot of people see these values as immutable, and because building/testing/running every single push takes too long, we should not do that.
As opposed to making builds faster, or build infra faster/cheaper.
* Ship less code (Very hard to get a large org to do)
* Rebuild the same things less often. Requires using build tooling that supports this org wide, Still hard to do but not as hard as shipping less code.
* Build more pieces in parallel. Also requires using build tooling that supports it org wide as well as structuring the code in such a way that it is amenable to parallel building.
These are all expensive investments that will pay off huge if you do them but can be quite difficult to justify until you reach a certain size.
Nonetheless, leadership will never give it priority.
Sometimes doing the same thing with simpler components and fewer components is just better.
What precisely is LinkedIn trying to be?
Seems like it's turning into 2007 Facebook. Is that intentional?
I suspect the user base has largely driven it. From the beginning it seemed that regardless of the stated purpose users wanted to use LinkedIn as a "different facebook". Personally I hate that, but a lot of people have been doing it for many years.
Like, LinkedIn only needs MAUs who are trying to sell something or looking for a job, they 100% don't need people to log in every day (as their ads business is only a small proportion of revenue).
Other users (almost everyone I know) absolutely loathe it. It is hands-down the worst service I have an account with, but it's also practically required to get a job if you don't have lucky personal connections. I was hoping TFA was actually about leaving as a user, that it might be inspiration for me to free myself.
But I think users just love / gravitate towards a more facebook style feed.
LinkedIn has slightly different style of spammer, but it's basically the end game for anything.
In what way? Users/customers do not generally drive development. Indirect measurements of users do, such as measuring "engagement".
At best, what likely happened was A/B testing showed "what users want", which rarely and only by chance intersected with what users actually want, and instead showed over and over that socials media patterns (light and dark) hijacking attention drives engagement.
If people didn't want to use twitter, they wouldn't and it would be gone. But users do use it, and even the folks who tell me they're upset ABOUT Twitter, most choose to be there.
Whatever the reason they make that choice, at some point that's on them.
That's not the same thing as wanting to use the platform.
I can't imagine letting a service like that define things for me like that.
Yes, that's very clear. Everyone is super impressed with how free your thinking is.
However, you completely missed the point of my comment by interpreting my hyperbole so literally.
Oh, you meant what are they trying to be that's helpful to the user? Doesn't matter.
The initiative Chris refers to is still alive but likely hasn’t made any meaningful progress. These things tend to have a lot of fan fair and then suddenly leave the front conscious of the company as we get a new GDPR/DMA fire to put out. at that point it will be dead. Or, it will stay alive for 2+ years as slowly but surely 50% of clients migrate to it and see even poorer performance.
There was a blog here a few months ago about migration from restli to grpc. It’s still going on, and nearly every app i see is still restli.
you realize stylometry exists, right? even the phrase 'fan fair' is a strong signal.
There was significant emphasis on code quality at least on the team I was on, and an ever improving culture.
I did work on one voyager task though and I remember it being a nightmare
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.
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!
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.
I learned that the hard way, only the other way around.
If you want to seek meaning in your work, then yes, cubicle farms will not give you fulfilment. But if you're just after a steady paycheque, and don't give a damn about the business, your work nor its purpose, then this is fine. And it gives you free time to live outside of work too.
You can change something, like how an engineering team works and how an organisation does DevOps and other things that management doesn’t really know anything about and trust their employees on. But moving an organisation into something like team topologies which is a more modern expansion on Conway, is virtually impossible from the bottom up in my experience. Change management in general is very hard both directions, but it’s much harder going upwards because going upwards means you don’t really have the support of management above you. Maybe they’ll humour you but to make an actual impact you’re going to need them onboard. You’ll even have to reach pretty far up top if you want to inflict lasting culture changes as things carried by a single (or few) managers often dies with them.
My career has sort of put me in a role where I help non-tech startups transition from that to medium or enterprise size. I solely focus on the tech journey though, as I know I won’t have too much impact on culture or work processes on the grander scale. Often this leads to a semi-team topologies approach as the tech teams divide systems into independent business related services, but as a whole I don’t expect any changes to reach outside of the development departments.
The key is having a champion who can tie change in with higher level desires.
In these orgs there's often an external (as in stakeholders external to prod eng) perception that "engineering is slow, product doesn't deliver, they're preventing us delivering our OKRs", and that can be used as leverage for change.
You can't go dark and stop delivery, but you can usually carve out a 10 - 20% allowance for change (that doesn't sound much, but is 1 - 2 days every 2 weeks, which quickly adds up). Start small, show success in impacting metrics that external stakeholders care about, then next quarter push for more.
I've focused myself in a similar area as you, but actually lean into processes and people, whilst still guiding tech - maybe we should chat!
Fair warning though, you'll lose all hope that companies like Microsoft will ever manage to produce anything that they don't then ruin.
you are implying that we still had any hope left in such endeavors.
This video explains everything I've seen in the enterprise IT of a huge government org that was the result of a long series of back-to-back mergers and splits.
It's exactly this!
Conway's law, but over time.
Dysfunction not just because of the large hierarchy, but also because of the built up layers of history. Some elements still limping along, some essentially amputated and mere phantom limbs of the org tree now, some outright dead and spreading miasma and corruption from their decay.
I knew or suspected most of this, but to hear it said out loud so clearly has crystallised my understanding of it.
Even if you know this, there is nothing you can do - you have to organize yourself somehow and how you do that can't be left up to just mirror whatever this piece of software that was brought in happens to be organized - because _that too_ doesn't reflect an actual org chart but is an integration over time of all org charts that have touched it.
I don't even know how to think about the implications this has for the use of open source software and how open source is developed, like... I think there are huge opportunities for research into Conway's law and how it relates to software development practices, software quality, etc.
We humans can’t effectively communicate with groups larger than about 7 people, but AIs have no such limits. We could all simply talk to one manager that can integrate everything and everyone into a unified whole.
It’s like the ship Minds in the Culture series having hundreds or even thousands of conversations at once.
"Not Just Bikes" has a good few videos, including https://www.youtube.com/watch?v=n94-_yE4IeU and a couple more that talk about problems that larger roads effectively cause more traffic ("induced demand", "traffic generation"). Organizational structures are like roads, and like roads they can get overloaded, which in turn means traffic needs to be reduced. There is even communication jam, and to combat that something like enforced communication reduction (lower information throughput), etc. to keep this manageable. That also causes decision making being done with less and less information the more steps are included in a communication chain (like upwards/downwards in a hierarchy), which in turn means the quality of decision making is severely hampered by it.
This whole mess is also the reason why the agile manifesto puts humans before processes and other such things, in fact it implies you change even the organizational setup to fit the project, not the other way around. But in the space of "managerial feudalism" (David Graeber) this is pretty much impossible to pull off.
Once again, seizing the term AI to mean LLMs and other current generative techniques has poisoned clear thinking. When we think "AI", we are thinking about HAL and Cortana and C3PO, which is not what we actually have.
Casey's example is focused on a (frankly, ridiculously) large organisation but I've seen the same thing in numerous small companies with just 20-30 developers, and it's hard not to imagine that this is universal, which is a pretty depressing thought.
Recently I've been involved in a new project where teams were set up to be 'domain-specific' with the idea that this somehow avoided the issues of Conway's Law, but this just feels like exactly the same problem because team structures and the software that they end up producing is siloed in exactly the same way as the organisation structures that existed at the time.
Casey's point that the final design is inherently limited by the lack of high-bandwidth communication between the groups of people that need it most is also fairly demotivating, personally.
Tangentially, having been writing more Golang recently this made me think of Golang's mantra (or was it Rob Pike's quote) of "Don't communicate by sharing memory; share memory by communicating.". Go/CSPs concurrency and sharing model is interesting, but I wonder if it's a fair analogue to compare sharing memory by communicating as low-bandwidth communication, and communication by sharing memory as the high-bandwidth communication that seems to be needed for effective designs.
Literally the opposite of LinkedIn. I’m approximately user 5000 on linkedin, and since I joined almost nothing useful has been added, despite a huge increase in complexity
I partially disagree. IIRC their search is broken, and their job alerts are pretty lousy at de-duplicating advertised positions.
And IIRC they hijack the back button, which I find pretty offensive.
I sometimes wonder what would happen if a company hired 100 software engineers, gave them all the same task to program the entire thing independently on their own, and then paid them as a monotonic function of the ranking of their output against their peers. (Obviously, there are limits on what type of product could be developed here, but I think this still encompasses far more company products than you would suspect.)
On the topic of Microsoft/Linkedin, aren't they the ones who used to or maybe still assign the same task to multiple teams and let the teams compete for who can deliver? That does sound vaguely like what you propose.
So he asked me to write my own queries as well to see who was right. Lo and behold, my numbers didn’t match either of theirs at all.
Most teams I've been on or managed were at their optimal efficiency with three people. Just enough to keep any one person from making too many poor decisions, but not to many to spend half a day in meetings.
It’s creative work, like anything else. 1 is not necessarily always the right size, but 100 certainly isn’t. If you look at musical bands usually a sweet spot is between 1-6. You can add more in eg an orchestra or choir but everyone’s not involved in the creative work.
Then it depends on how well you vibe with people. If you have extremely unique ideas and thoughts, you may be better off alone. If you find peers with similar values, preferences and experiences, you might be fine with 5 people.
How do you hold the middle together? Especially under such turbulence? "Strong" leadership isn't enough.
Reflective practice [0] is one way to build that. It's common in medical and some safety-critical civil/military spheres but strangely missing from many corporate structures. I talk about it here with regard to a more mature cybersecurity stance [1]. It intersects with Agile ideas but doesn't make much noise in software engineering project management as much as it should? Anyone have this in their org?
If you want excellence set high standards defined by rules that to hold people accountable and impose ownership (liability/reward). It’s not complicated but it requires not being terrified of assertiveness and confrontation from the top down.
It requires the professional communication skills that are not taught in a STEM education. That's why this is all so difficult: we are not taught how to communicate effectively with one another, and the entire tech landscape has poor communicators misinforming and misleading one another.
interesting if endeavors with nlp and llm's can help to spread nuance or commodify motivation and control.
I'm calling this work 'human comprehension support'.
On one hand my expectations for excellence in software are alien to my peers who just want to complete a JIRA task by any means possible. Yes, it is possible to deliver superior results for an entire day's effort in about 2 hours provided you aren't framed by all kinds of institutional roadblocks and unnecessary abstractions. I am scared to death to actually communicate my opinions regarding software because people tend to whine about how hard life is. For this reason I have abandoned my JavaScript career.
Then on the military side I have to unlearn the high agreeableness that is so necessary for not getting fired in software. By high agreeableness I mean keeping your opinions to yourself, not voicing concerns, treating everything with kid gloves, and making everything as easy as possible. The military side is a much safer environment that expects brutal honesty. Nobody there believes themselves to be god's gift to the universe and they are always in a learning mode, which means they are coach-able and will not whine about corrections and mentorship.
sounds refreshing but debatable whether an environment of honest brutality can be considered safe
On the other hand, the non-squeacky wheel gets to collect their salary for a long long time.
It is interesting to think about, but there is this tendency to invoke "Conway's Law" as some simple method of fixing the extraordinary complex problem of developing and evolving complex software over time.
Really what it is is that organizations from the 70s, 80s, and 90s were built around building physical things, for the most part. Manufacturing and construction, mostly. And taking those organizations and applying them to software development fundamentally was a terrible match. We had to find new structures that were better suited, and we have gotten a lot better, but we are still working on it. Management was taught by those that managed manual laborers, who's output was easy to measure, and whom you could force to work a certain amount without a significant drop in their output. The same isn't true for knowledge workers. And so new management had to be created, a process we still are working on as well, but many managers these days are way better than managers from 30 years ago.
Read Conway's original paper, it is interesting, but it isn't a physical Law that cannot be violated!
These aren't counterexamples because Conway's law makes no comment on how the teams will choose to deploy what they build. It talks about the overall design of the system, the solution space that was explored. Windows is a monolithic application if the alternative is microservices, but anyone who gives it more than a cursory glance can see the org chart (both past and present!) reflected in the disjointed UX.
> And so new management had to be created, a process we still are working on as well, but many managers these days are way better than managers from 30 years ago.
I'm not sure why this makes Conway's law not applicable anymore—what you're describing is that new management does a better job of creating communication structures that lend themselves well to creating software. That may well be correct, but the resulting improvements validate Conway's law! If we're getting better at software, it may well be because people are talking about and accounting for the impact that communication structures have on the output.
...like ?
I'm not sure how public they've been about all this, but you certainly can teach an old dog new tricks, provided there is management buy-in (which we certainly had - at one point, our teams were moved between GBUs to save us from budget cuts).
I recommend watching the talk! He specifically addresses the very points you bring up. Of course reality is messy and people especially so, but Conway’s law is one of very few theories within CS that has held up in replication studies.
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.
IMO more about growth of the engineering teams that lead to any specific culture deteriorating.
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.
https://queue.acm.org/detail.cfm?id=2567673
Summary: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
LinkedIn migrated to Node early 2010.
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.
Here's a write up from the LI engineering blog briefly detailing a history of their architecture (up to 2015): https://engineering.linkedin.com/architecture/brief-history-...
Platform lock in is certainly intended (even though it sucks for users)
I haven’t tried this on LI but it’s my dirty trick for exporting conference attendee lists when they’re made public on websites. YMMV.
Been there, done that, no thanks.
I'd love to see what makes it so large. That's like 1/15th the size of Linux.
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.
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.
Ex. https://stripe.com/blog/migrating-to-typescript
Which talks about 3.7m lines at Stripe.
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.
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.
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.
Am I spoiled for thinking 17 minutes is too much, even if it's 2 million LOC? I guess LinkedIn can afford it
Answer could well be yes since build time impacts everyone, but also have to factor in complexity of the CI system they use.
Long build times are an operational risk - it's very hard to apply patches to solve incidents with a 20 minute build time.
I agree though, definitely a factor
Because THAT'S the hard problem to solve in any bigger organization. Not hacking the code.
Maybe, or just a knowledgable person to dig in for a bit and solve it. On one of my teams when I was back at Microsoft was working on a similarly huge codebase with build times twice as long. We had a senior engineer who was really into build optimizations from a previous job who wrote a tech design, implemented better project splitting in our monorepo, better local caching, and finally cloud caching, all within 3 months. When I left, our builds ranged from 30 seconds to 3 minutes.
It's not guaranteed that it'll be this simple, but I also don't think it's guaranteed it'll be 3 years and several people.
Aside: I don't understand the obsession people have with throwing out LOC. It's a completely meaningless number unless you're familiar with the codebase, in which case you don't need to be told the stats.
Agreed. A better metric is how much of it you need to interact with on a daily basis in order to perform any meaningful work.
If the code is sane, you'd only ever need to interact with and understand a fraction (a subset of the public APIs) of the entire codebase. You could have millions of lines of code and be productive when knowing only a couple of hundred of those.
If the code is insane, the risk is that you'd need to interact with most of it when introducing any non-trivial functionality. Worst case scenario there isn't any clear rules of what is public and supposed to be used, and what is private and isn't supposed to be used, and people have used "whatever from where ever" to solve their problems.
The second one is always bad, but also significantly worse the more lines of code there are. Perhaps those who throw LOCs around also implicitly tell us that they are dealing with the second variety of code.
LOC is the metric I get to remain employed or fired on.
This is why build systems like buck/pants/bazel are good in larger codebases. You can trust your incremental builds in a way that you can't in any build system that isn't hermetic.
Happy for that person, wherever they are now.
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.
LinkedIn is a solved problem but you can’t have that any more.
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.
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.
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.
It does require some organizational changes, and a slightly different set of skills, and some fail to realize they lack both.
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.
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.
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!
My advice, leave LinkedIn.
Edit: Or, continue to enjoy taking it in the shorts, for an entity that could not care less.. lol
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
Seriously? You getting more "engagement" because someone is a good actor?
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.
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.
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."
> 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.