Twitter, Threads, and the misunderstood nature of engineering
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.
like this
Scrubbles
in reply to trashhalo • • •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"
like this
BeyondTheBreakers, trashhalo, Guilty Tangent, entropicdrift, insideoutside, meteorswarm, stinky613, Viper_NZ, timappel, Grimpen, AccountForStuff, Deestan, chris., Ocean, Atiran, Xepher, bassdruminphonebox, dr_catman, NmUn, keltaris, cygnus, samn, dirkgentle, colournoun, funtimeHat, finally debunked, Anony Moose, artificial_unintelligence, yourfacehaha, Olon97, LuckyLemor, Kleinbonum, schown, intensely_human, HalJor, ArcticDagger, renard_roux, dxcz, Deez, caelife, freamon, stock, Aycaramba, linoor, zen_symian, AutomaticJack, I eat words, solariplex, Gsus4, Eccitaze, Kerb, hamiltonicity, Titan, luciole, jpv, HobbitFoot, pitl, Johanno, uplink, defiant, Cuttlersan, diffaldo, festus, thepaperpilot, archaeoraptor, Sonori, tackykcat, sanols, FelineForward, OfficialThunderbolt, Mars and Ryan like this.
Shiri Bailem
in reply to Scrubbles • •like this
Scrubbles, The Quuuuuill, Grimpen, AccountForStuff, Deestan, Ocean, TheFriendlyArtificer, Xepher, VerbTheNoun95, keltaris, dirkgentle, colournoun, SmashingSquid, Anony Moose, evolatic, not_an_egg, Olon97, LuckyLemor, Kleinbonum, t3rr, ArcticDagger, renard_roux, dxcz, Nesuniken, stock, linoor, AutomaticJack, solariplex, Eccitaze, Kerb, hamiltonicity, pitl, HobbitFoot, uplink, Cuttlersan, Sonori, Mars, OfficialThunderbolt and Kanda_Miki like this.
Scrubbles
in reply to Shiri Bailem • • •like this
Shiri Bailem, Grimpen, AccountForStuff, VerbTheNoun95, Xepher, dirkgentle, Anony Moose, Olon97, Eccitaze, HobbitFoot, pitl, Cuttlersan, Sonori, FelineForward and OfficialThunderbolt like this.
Grimpen
in reply to Scrubbles • • •Wasn't that an old example of perverse incentives? IBM ranked or paid bonuses based on lines of code. In short order, all their code became bloated and inefficient.
This was an old example in the 90's and maybe the 80's, so could have been over of the other OG computer companies (Digital, Sun, HP, etc). Could also be apocryphal. Point is, it's a classic example of dumb management ideas.
like this
keltaris, dirkgentle, Olon97, caelife, Eccitaze, hamiltonicity, Titan, HobbitFoot, pitl, Cuttlersan and Sonori like this.
Scrubbles
in reply to Grimpen • • •i remember a corporate rule came down that we needed something like 70% of all code unit tested for stability.
Damn were our getters and setters rock solid. No errors there. Business logic however...
like this
dirkgentle, Eccitaze, hamiltonicity, pitl, defiant, Cuttlersan and OfficialThunderbolt like this.
uberrice
in reply to Shiri Bailem • • •Meh, the best programmers are probably somewhere in the middle.
This also depends on what kind of work you're doing.
Writing some frontend with lots of Boilerplate? That's lots of lines.
Writing efficient code that for example runs on embedded systems? That's different. My entire master's thesis code project on an embedded system consisted of around 600 lines of C code, and it did exactly what it should, efficiently.
A better metric to that effect would be the git activity graph. People that do important changes don't commit 20 times a day - they push a commit usually once a day tops to once every 2 weeks
like this
dxcz, naeap, linoor, AutomaticJack, Kerb, hamiltonicity, pitl, uplink and Sonori like this.
Shiri Bailem
in reply to uberrice • •@uberrice
It's the fact that from what I saw he didn't differ by project, and the fact that better programmers do more with less.
He literally had them print out their code to judge off of. Security engineer tracking down vulnerabilities? Well, since that's just a couple lines of code (if not just characters) after long stretches of testing? Fired for "productivity"
conciselyverbose
Unknown parent • • •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.
Shiri Bailem likes this.