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.
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.
I don’t think we’re in disagreement here, these are just different indicators and consequences of what makes good software. Lines of code will correlate with software quality to a certain degree, but ultimately they’re a flawed metric when the actual goals are readability and maintainability.
Less code does not equal less readability. Less code comes naturally from SOLID, DRY principles and proper use of design patterns. Every one of those buzzwords emphasizes readability and maintainability. Throw in some DDD, and you have an excellent base for ever changing features.