> Twitter's back-end is written in Scala, but they used "better Java" style so an average developer should have no problems making changes
You sound like someone completely oblivious to software development practices who somehow felt compelled to post opinions on software engineering.
Your choice of language is irrelevant if your goal is to maintain software. What matters is systems architecture and institutional knowledge of how things are designed to work. If you fire your staff, you lose institutional knowledge. Your choice of programming language does not bring it back.
“Your choice of language is irrelevant if your goal is to maintain software.”
It may not be the most important choice, but it’s not irrelevant. And whether the staff he fired had useful institutional knowledge is an open question. Didn’t he fire a lot of non-technical, recent hires and people likely to leave eventually due to his muskism? I’m not convinced that his initial firings are the wpest move he made. Sadly, being overconfident, he assumed the same model could be applied to government, a mistake that will take a long time to fix if it is even fixable given America’s overall trajectory and the fate of the dollar.
I generally agree with you but I think you were a little strong in your view that the OP was "oblivious." I only say this because an enormous percentage of companies hiring software engineers specifically with requirements of X years with Y language and W years with framework with silly name Z. I think they are also misguided in that but I think it is is too prevalent to say they are all oblivious but honestly that may actually be more of an apt description.
From what we gathered on the kitchen side he fired the most infrequent committers. Which statistically speaking would not affect the institutional knowledge much.
Or alternatively (assuming that's true) he fired the people who thought about what they commit and kept those whose commit logs look like: "push feature WiP", "fix", "more fixes", "push", "maybe this works?"...
Ironically, those may have been the staff with the most institutional knowledge. Seeing people argue, here of all places, that loc or commit frequency == institutional knowledge is … unexpected. New hires committing “whitespace cleanup” != institutional knowledge.
Someone had to actually write all that code and it inevitably shows up in the stats. People who work on the code most tend to know it the most. Although people in non-coding roles sometimes prefer to deny it.
Sure there had so be some frequent but low impact committers. But implying that people with lowest amount of code contribution must have more impact is ridiculous.
I mean, a staff engineer who stopped committing couple years ago? Yeah could be burnout, or could be some major contribution that's not in the stats. OTOH an IC on their second year in position who hadn't pushed a single line? Nah the institutional knowledge is safe without.
> From what we gathered on the kitchen side he fired the most infrequent committers. Which statistically speaking would not affect the institutional knowledge much.
This take is, quite bluntly, stupid and clueless. Do you think each commit reflects the volume of institutional knowledge of any individual? Unbelievable.
Twitter had thousands of coders, each certainly with varying cadence and style of committing. But variation goes only so much and taken in aggregate yes, the amount of commits/diff size is correlated to contributor prominence. It's kinda hilarious the "my -2000 lines" types deny the obvious.
Hey man, just wanted to let you know, I had to downvote a bunch of your comments in this thread, not because I disagree with you, but because your commenting style is unnecessarily hostile and abusive. You can politely disagree with someone without calling their take "stupid and clueless", or any of the other mean-spirited things you've said elsewhere in the thread.
You sound like someone completely oblivious to software development practices who somehow felt compelled to post opinions on software engineering.
Your choice of language is irrelevant if your goal is to maintain software. What matters is systems architecture and institutional knowledge of how things are designed to work. If you fire your staff, you lose institutional knowledge. Your choice of programming language does not bring it back.