Complex internet services fail in interesting ways as they grow in size and complexity. Twitter's recent issues show how failures emerge slowly over time as relationships between components degrade. Meta's quick launch of Threads demonstrates how platform investments can compound over time, allowing them to quickly build on existing infrastructure and expertise. While layoffs may be needed, companies must be strategic to maintain what matters most - the ability to navigate complex systems and deliver value. Twitter's inability to ship new features shows they have lost this expertise, while Threads may out-execute them due to Meta's platform advantages. The case of Twitter and Threads provides a lesson for companies on who they want to be during times of optimization.
My favorite phrase in coding is "9 women can't make a baby in a month, but 9 women can make 9 babies in 9 months".
Elon took over and fired so so so many talented engineers saying they were lazy, or incompetant, or whatever excuse he had when he really meant "they cost a lot". Now he's seeing the downside of that.
The phrase means you can't take a project and throw more people at it to make it go faster because there is institutional knowledge that needs to be learned first. You can't take a 9 month long project that 1 person is in the middle of and throw 8 more people at it and demand it gets done in a month, something Elon is really trying to push. Those 8 other people need time to onramp, to learn how the thing is being built, to learn how systems and subsystems all interact. In fact, usually this is a sign of a terrible leader because most of the time projects will slow down while you're trying to onramp all of those other people when at that point it would have just been faster to let the one person finish.
What you can do, as Facebook obviously did, is actually project plan. They said "we need 9 babies, what do you need to get that done?" and they replied "9 people and 9 months". and look how it paid off.
I hope Elon's twitter tanks because of his impulsive short sighted decisions that he thinks are "projects"
@scrubbles My favorite early moment was him firing people based on lines of code written... which of course meant he fired all of his best because the worst programmers write many lines that do less while great programmers write few lines that do more.
That doesn't sound exactly right. Readability is IMO the most important code quality followed by things like maintainability. Conciseness is a lot further down the list. If I have to use more lines of code or even leave out a little performance optimization for readability, I generally do.
Great programmers aren't playing code golf.
Their code is naturally smaller because they recognize patterns and understand what should be turned into functions/classes/etc and what should not. There absolutely is a point where cutting out lines of code is a negative, but well structured code just takes so much less code than a mess that that's not what really moves the needle on the metrics.