Twitter engineer calls out Elon Musk for technical BS in unusual career move When Elon Musk promised to improve Twitter's technical performance at the weekend, it was one of the company's own engineers who rubbished the new CEO's claims. Then a stampede of software engineers rushed in to support their comrade. The famed SpaceX and Tesla entrepreneur posted a tweet on Sunday "to apologize for Twitter …
I've had a fair bit of experience working at startups and I've found that CEO's actually like their information straight. (One told me that he liked me being in meetings because he needed to know what was really going on and not what people thought he wanted to hear.) There's no excuse for being impolite, though. Musk isn't a programmer and it would be highly unlikely that he'd know all the ins and outs of Twitter's code base but given his profile he's probably got a very good idea about what's going on along with an extremely sensitive BS detector.
I've had programmers tell me I don't know what I'm talking about like this fellow. When I hear this I tend to think of it as a red flag, an indication that there is a problem. I've lost count of the number of times I've been told something to the effect of "Its all very complicated, you see, so its never quite finished, its almost but never quite working 100% but with these extra resources we might be able to make a schedule." (Usually accompanied by goals labelled "Phase 1" which are nothing like what the project was intended to deliver.) Twitter sound like one of these only much, much, bigger than the situations I've been dumped in. Something will need to change -- from a business perspective its just not sustainable.
(BTW -- Given the bloodletting now is probably not a good idea to be an investor in Bay Area real estate...)
The programmer did mention several problems. This wasn't attempting to hide bugs or inefficiencies, as they didn't seem to mind suggesting large overhauls. It was a fight about a specific technical issue, namely how many RPCs are there to perform the operation. Musk has a claim, and the programmer has a claim. I'm more likely to believe the programmer, given that, as you said yourself, "Musk isn't a programmer and it would be highly unlikely that he'd know all the ins and outs of Twitter's code base".
CEO, CIO, managers etc., Don't know things, and sometimes say stupid things, If you correct them in a polite and non-condiscending mannor you are most likely to make them understand that what they are complaining aboiut is not essentially what they are describing but a condition caused by something different that is creating the same result. They really didn't know WHY its happening but just want it fixed.
If you call them out in conference room, make them look stupid, come off as a pompus ass! Well then, sucks to be you! I have known some very intellegent people find themselves unemployed for just such actions, Were they right? Yes. Did it get fixed the way they said it should? Yes, but without them!
OK you are the captain of a ship. Someone on the bridge starts insulting your personality or ability to command the vessel because of a disagreement, maybe even during a crisis.
What do they call that again... MUTINY? INSUBORDINATION?
Yeah. from the perspective of the CEO, it is like THAT. UNDERMINING the leadership at the top to that extent can damage the company structure in ways you cannot imagine, if you think "feeling stupid" has anything to do with this.
This needs to pass the "shoe on the other foot" test.
It comes down to respect.
If I call my buddy an asshat in the pub, there are no consequences.
If I drop a Teams message to the CEO, to politely inform him that he made an error in a statement and what the situation really is - this is OK.
Heck, I even thought Musk took the comment in his stride - to be fair he did ask to be corrected?
You never quite know after this point, if Musk fired him, or if his local manager/PR department has realised what a clusterf*** has been created, and they fired him because he had created a mild social media storm (optics are always good within a company, so anyone causing a ruckus on social media must considerable themselves expendable).
Personally, I wouldn't correct my line manager on Linkedin, yet alone a CEO of a billion dollar corporation on his own platform.
"Personally, I wouldn't correct my line manager on Linkedin, yet alone a CEO of a billion dollar corporation on his own platform."
If your manager or anybody above you has trashed you or your team and they've made the only way to reach them is via a public forum, them's da brakes. Somehow I suspect that Elon is parsing Twitter posts more than any of his email accounts.
"If someone feels stupid because someone corrects them then that is a failure of personality."
I feel a complete fool when I'm correctly called out on something. That's doesn't mean I don't own up if they've done a good job at explaining why I'm wrong. If they just say "you're wrong", "you're an idiot", they are going to find their new office is in the basement, is lit by one bare bulb and their new task list is going to keep them there until they quit.
And if you insult the workers based on your wrong understanding, they get defensive. You're right that the less respectful way you inform someone they're wrong, the more likely they are to punish you for it. My guess was that the person in this case was already planning on leaving and wasn't going to take any more public insults. Had he wanted to stay, his response might have been different. In neither case was he wrong nor was Musk justified in his statements (or in my opinion actions).
it is also possble that the term "RPC" in Elon's mind means something different in their programmers' minds, like "we do not do RPCs we do "remote API requests" or something equally tedious and irritating [so typical of people trying to hide things, or maybe Simon the BOFH when he wants the boss to leave him alone].
Musk understands enough to know the *kinds* of questions to ask. He expects (as was pointed out earlier) straight answers, and NOT territorial spats and blame on "10 years of coding".
Some time ago I was working on an application that collected data and sent it to a server by phone. Circumstances being what they were, the person who designed the server side left the company (maybe because I asked too many questions). But it was taking MINUTES to do uploads from an iPhone... and it was due to server-side kludginess! Needless to say I went in and improved the upload efficiency by a factor of 10 by re-writing significant parts in C instead of python. But for some reason that was NEVER considered until I did it. of course my reward was to have my contract NOT renewed, and now the company no longer exists due to the INCOMPETENCE of those who ran the show. I think one of the people behind it simply liked Python and did not want to see an EFFICIENT solution replace the Django one, even when being called by DJango as external utilities to process things. [he even went so far as to re-re-design the hardware for the only product using features the rest of us had abandoned years before because it was proven to fail catastrophically in a short amount of time, but who am I, I am not a college professor, just an engineer... academic arrogance, nuff said. project and company DIED]
And THAT example is kinda where I think Musk wants to go - he has discovered an obvious bottleneck, he wants to know why it is being done that way, and he wants to re-do things to address the worst of the efficiency problems first. if it has to round-trip to the server several [thousand?] times, you have performance problems. I bet that's what he means.
That is pretty much what *I* would do, too.
(this sort of lines up with how AGILE is FRAGILE, why you do NOT make everything 'object oriented', and why falling back to a well established standard compiled language like C instead of 'new, shiny' is not necessarily a bad thing...)
Elon makes a mistake a lot of IT end users make.
Describing a problem not as a problem, but as the solution they imagine it requires to solve it.
Please leave the solution to the IT experts.
Just describe the problem as explicitly as possible. State facts not conjectures.
"it is also possble that the term "RPC" in Elon's mind means something different in their programmers' minds,"
If Elon wants to use the specific nomenclature, he needs to learn what it means. It's not pedantry to insist on using the correct terms. If you don't, it can cause all sorts of confusion. If Elon has said that the app is making far too many calls to the server and that's what's slowing things down, it's less buzzwordy and isn't pinning the issue on one type of action.
I get the feeling that the recently unemployed person has been trying to get approval to address the issues he sees with the codebase under his care and wasn't getting any positive response from management. Knowing Elon's type, it was probably E. Musk that would have to personally give that approval and he's been too busy to look into it will all of the time he's been spending trying to loft a grain silo.
The problem isn't that Musk doesn't know, but that he likes everyone to think that he knows everything. That's why he sued the board of Tesla declare him a founder even though he really wasn't, and declared himself "Chief Engineer" at SpaceX even though any time he gets asked a direct, specific engineering question his answers suddenly get super vague.
He takes credit for other people's hard work and then gets mad at them when they don't proclaim him Tech Jesus.
I've had bosses like this in the past. OK, not billionaire CEOs, but the kind that have a minimal understanding of the systems in use, that try and argue with the people who actually have a good understanding of the systems in use. They tend to be dangerous long term because they will do, or decide, something based on what they "know" about the system which is invariably either wrong, or incomplete.
Slightly off topic but I have a odd urge to say it. I can't stand bosses like this but would, in some ways, love the chance to be in that billionaire position he is in. As someone who suffers anxiety, I always strive to make new employees not feel that way. Its a shit feeling and people like Musk don't make it easy. Only reason is I'd quite like to make work an enjoyable place for people, not an anxiety ridden place. Hearing people on a Sunday "Oh its' back to work on Monday, I hate it" Its never great. But I guess its a difficult one as then you end up like David Brent. But there's also no need to treat people as shitty as Musk apparently does. I remember years ago now seeing a documentary on recruitment and the manager pointing out what attracts him to looking at a CV etc. But he also said he has a relaxed dress code. He wanted people to feel comfortable at work and he said it works. They are more productive and he said there sick days decreased because of it. And as something as simple as a relaxed dress code.
I've had bosses like this in the past. OK, not billionaire CEOs, but the kind that have a minimal understanding of the systems in use, that try and argue with the people who actually have a good understanding of the systems in use.
Now you know why I tend to root out politics where I can, and don't work with politicians.
I built some major infrastructures, and the amount of money involved attracts the clueless like flies.
> I've had bosses like this in the past. OK, not billionaire CEOs, but the kind that have a minimal understanding of the systems in use, that try and argue with the people who actually have a good understanding of the systems in use.
There was a time when our division found itself stuck with a CEO who'd been parachuted in. And while things initially looked good - he was charasmatic and made lots of promises - it soon became clear that he was incompetent at his job. As indeed, were the cronies who he brought in to support him.
Eventually, the board began to get a bit annoyed about the various disasters he'd caused, so he decided to implement some grandstanding actions to "improve" things - or at least give the impression thereof. Such as demanding that we clean up the customer database, to make it faster and more efficient.
Despite the fact that the database was already nicely optimised and indexed, so all that this exercise resulted in was several weeks of faffing around, before turning around and confirming that it had made absolutely no difference to the day-to-day performance of our platform.
I can't remember if he jumped or was pushed when things finally came to a head, but it was mildly entertaining to watch his suddenly exposed cronies desperately ringing around their contacts in an effort to find a new job before the baleful eye of HR turned towards them...
I'm with you here. It's not long ago I kept being shouted at in meetings and told to back-off on technical issues where the boss suddenly flipped from being quite reasonable to a complete prat. Afterwards I would be summoned to his office where he would apologise but never in front of others. It didn't bother me as I was confident in my stance and knowledge (and old...).
In the end, I stopped being invited to the meetings. Then, the meetings were abandoned altogether. Eventually, I and several others left, leaving him to sort out his own mess. Of course, he too moved on a bit later.
So have I, but it's you job to make them undertsand as best you can. Some you can, some you can't. The ones you can't it is best to move along and find another position.
But I've also had teammates and managers complain about how the Executive is the root cause of all the problems. When these people leave and we get competant managers we find out that it was not the executive that was the root cause, it was the imcompetant teammates and managers using the Executive to cover thier incompetance!
The road travels both ways!
"it's you job to make them undertsand as best you can"
It really, really isn't. If they don't understand the technical aspects of the job then it's their responsibility to either hire someone actually competent to manage it and leave it alone or educate themselves.
This is why I've never understood the CEO pay "price the market will bear" crap. They're not smarter, they don't work harder, and they don't have special innovation juices flowing out of bodily orifices.
I think just about everyone in the technical world understands what RPCs are. They're not a new concept. They're one of those things that are really useful but if used to excess can really slow down system performance.
Remember, although he personally hasn't reviewed the code base but (according to reports I'd read) he'd introduced some moles seconded from Tesla and SpaceX to do that job. They would have been in contact with him. These programmers are likely to have significant real time and safety critical experience (no snide remarks about Autopilot, please) and so they may have a completely different view of how code should be structured compared to an applications oriented environment.
Although I think he's been a) taken and b) has a really tough nut to crack I still think you should take note of the "Do Not Underestimate" label.
> Although I think he's been a) taken and b) has a really tough nut to crack I still think you should take note of the "Do Not Underestimate" label.
Musk is just the latest in a series of speculators and "robber barons", from the businessmen who dominated the USA telegraph network [*], to Frank T Crowe and the Hoover Dam, the guys who founded Youtube, Uber, etc.
Their strengths don't lie in their technical skills, but instead tend to be around the fact that they have enough financial and/or political backing to both outspend their rivals and to effectively be above the law.
Which in turn means that they can ride roughshod into a industry while using a shield of lawyers to obfuscate and confuse things long enough to become firmly entrenched before the relevant political and legal mechanisms have gotten up to speed.
Because that then means that you can force them to accept a compromise dictated entirely on your terms.
And that's something which can work for a startup, especially one in the USA where hustles and crunch time are seemingly baked into the work ethos, especially for the IT industry.
However, where Youtube romped to victory, things haven't been as rosy for Uber, and for all that Tesla is doing well in many ways, it's definitely been stumbling when it comes to things like autonomous driving, new battery tech, quality control and their cybertrucks.
As such, I have my doubts as to whether it's something which can work when trying to take over an existing company with an existing userbase. Since they're generally not as enthused about the inherent instability of the "move fast and break things" ethos.
[*] https://arstechnica.com/tech-policy/2011/05/how-the-robber-barons-hijacked-the-victorian-internet/
YouTube were successful, yes, but pretty much all the other video streaming services from that time are gone now. Netflix I think is the only other one from that time that is still around in a big way.
Video streaming was a new thing at the time. Operating taxis is not a new thing, sure the app is a nice improvement, but that's a slight improvement to an existing product offering rather than something completely new. Electric cars are not new at all, they've been around longer than petrol or diesel cars.
> YouTube were successful, yes, but pretty much all the other video streaming services from that time are gone now. Netflix I think is the only other one from that time that is still around in a big way.
Youtube and netflix have different business models; Youtube aggregates user-created content while Netflix streams licenced or in-house IP.
And it's the former which is "disruptive", since a lot of the content uploaded to Youtube involves IP which is owned by someone else. Songs, films, TV shows: Youtube was getting lots of high quality media for free while sitting behind the Section 230 "content provider" defence.
And Youtube arguably only managed to survive where other UCC websites didn't thanks to the fact that it was bought out by Google before the content industry could fully gear up to challenging it.
> Operating taxis is not a new thing, sure the app is a nice improvement, but that's a slight improvement to an existing product offering rather than something completely new.
As far as I know, Uber's core business plan revolved around the following:
1) a booking app would let them work around the fact that many countries only let licenced taxis do street pickups
2) taxi drivers could be classed as contractors rather than employees
3) autonomous vehicles were due to launch Real Soon Now
I.e. they could drive out existing taxi services by drowning them in a wave of gig workers, and then drop the gig workers as well with self-driving cars.
And that'd give them a monopoly with practically zero labour overheads, barring a few mechanics and cleaners for their AI taxis.
And that was enough of a compelling enough business plan to get over $25 billion in funding, much of which went into subsidising their services in order to further undercut the competition.
In practice, self-driving cars proved to be a hard problem, and the delays this caused has meant both that other companies have had time to adjust their business models, and that their classification of their "contractor" taxi drivers has been successfully challenged in multiple countries.
> Electric cars are not new at all, they've been around longer than petrol or diesel cars
True, but electric cars were generally seen as a novelty and in general, the vehicle industry is pretty moribund, complacent and very labour intensive. So it was ripe for disruption.
And as with Uber, electric drive trains were only a small part of Tesla's plans. Which revolved around:
1) being first to market with autonomous vehicles
2) a push towards a fully automated assembly process
(To be fair, they've also had some novel new designs - e.g. vastly simpler and lighter wiring cradles, revolutionary battery technologies, etc. But these are arguably just inputs to their business plan. And for the most part, it seems like so far Tesla hasnt actually been able to deliver most of the benefits promised by these designs)
So again, it was all about getting a market monopoly and eliminating labour costs.
But again, self-driving cars have proved to be hard, as has the goal of having fully automated assembly processes. And the former has given their rivals time to catch up, while the latter had kept their costs higher and given their employees the opportunity to demand more rights, better pay, unions, etc.
"> Electric cars are not new at all, they've been around longer than petrol or diesel cars
True, but electric cars were generally seen as a novelty and in general, the vehicle industry is pretty moribund, complacent and very labour intensive. So it was ripe for disruption."
The early electric vehicles weren't a novelty as petrol wasn't stocked in tins by every chemist and it was dangerous to hand crank petrol engines with people getting injured and killed. The distance one might travel was short compared to today as there wasn't the well maintained motorways we have now and many goods were transported by train and sold in shops on the high street. If a product wasn't available, you did without or worked around it. Luxuries you might buy if you visited a city on the train and brought those goods home with you. You wouldn't get in the car and drive miles.
EV's aren't a disruption, it's just another powerplant and drive train. They are also very expensive with very little in the way of a used market. It remains to be seen how a used market shapes up and how much resale value is left at the end of the battery warranty. There aren't the third party replacement companies for battery packs on BEV's. For hybrids such as the Prius, there are companies with new replacements as well as rebuilt and refurbished packs. One can even swap out an old NiMh Prius pack for a higher capacity Li pack at a reasonable price.
"YouTube were successful, yes, but pretty much all the other video streaming services from that time are gone now."
YouTube is also solidifying their position by getting governments to institute laws that require any similar service to have copyright controls that only an operation as big as YouTube can implement. That just raises the bar so high that only somebody coming in with billions they can risk has any sort of chance.
Exactly, it's so bloody cringe worthy. He uses them in such an embarrassingly transparent way. He's desperate to appear a tech genius but demonstrates exactly the opposite. Like me lecturing my 16 year old daughter on tiktok's top teenage fashion influencers.
Its pathetic and smacks of a desperate need for recognition and adulation. I have no expertise in rockets, but I do in computing and it's obvious he doesn't know what he's talking about. He knows enough to embarrass himself though, and long may he do so. It's hilarious.
He's a complete toss pot, an angry spoiled baby in the body of a man. I really don't know how any one could work for him, I'd rather be unemployed.
I suspect your anectdote assumes that respect goes both ways. The problem here is that musky boy has no respect for his engineers. His answer to complications on deliverables is "work harder or GTFO of here". He doesn't trust them to work from home. Just ask all the former Twits looking for a new job right now.
Of course, I'm a biased observer. Twitter is cesspool and I half expect that ol musky is letting this dumpster fire rage on purpose. Either way I'm enjoying the show. Let it burn.
Martin,
that might be your experience in startups, but in mature IT companies I have survived in, the top PHBs like their BS hot, served with chilled champers and a side of snark and caviar. Telling them anything they dont want to know is a career terminating mood. Mind you, I was told before my last severance that I was protected a bit by middle manglement because as a mild aspie, I asked the obvious questions that no-one dared ask, being impervious to social not niceties. However in this incident, it does sound like the techies are telling their employer that he is mis-informed. I did think better of Musk until now. Being a SpaceX star is bad for his stability methinks
You say:
"...I've had a fair bit of experience working at startups and I've found that CEO's actually like their information straight. (One told me that he liked me being in meetings because he needed to know what was really going on and not what people thought he wanted to hear.)...
And then:
I've had programmers tell me I don't know what I'm talking about like this fellow. When I hear this I tend to think of it as a red flag, an indication that there is a problem
Which is it? You want it straight or not? Sounds like the programmer - the guy actually responsible for writing the code in the Android app pointed out what was actually wrong. No BS, but a straight answer to a straight question of "what is the problem, then?"
You can't have it both ways. If you want straight answers to straight questions, then don't get pissy and scream "ah red flags here" when you get it.
Hahaha! Yeah, right. If he had the time and the authority to clear what he refers to as the technical debt. I'm confident that you don't work in IT systems. A complex system has interconnected dependencies that often makes it difficult to just "solve the problem" in isolation, especially where the problem is architecture. That's not something that a coal face dev can tackle on his own.
> I'm confident that you don't work in IT systems.
Now what is it that they say about assuming?
What the post above was trying to convey, albeit admittedly with poor wording and defective grammar, is that if you're (partially or fully) responsible for a component, admitting to your boss that it is indeed shit, is not exactly going to impress anyone, with one exception: when you take personal responsibility for its defects.
he did qualify why it was not optimal - the tech debt being present because all efforts always put onto new features and not the required resources assigned to said removl of debts and dead features. this is SO very common in tech , heck, there are thousands of blogs written about the issue. and yet managers (at all levels, project managers, product managers, team managers etc) still fail to grasp this and the result to output , efficiency, drag etc - tech debt = features take longer, more issues hit a basic 'this is a quick job' (it used to be quick! sure, it aint now!) - so you actually want to avoid that situation rather than force X new things onto the platform.
I see you've never worked as a programmer. That's not how it works.
Here's an example. I have a task to do. The code we have that is involved is terrible. Nobody disagrees with this; we all think it's bad. I could overhaul this for a better version, completing the task some time in January. I could also patch around the problem that prevents the completion of my task, write the new stuff, and complete that next week. We're doing the next week plan.
It's not about needing the task completed. This isn't time-sensitive. It's not about disagreement about the overhaul being useful. However, they want me to be able to work on different things in December, and by patching, I'm not introducing any really big problems (no risk to safety, security, sensitive data, just the code being harder to maintain and significantly uglier. I don't have the freedom to tell them that I'm ignoring them and starting a redesign on my own, and if I did, there's always the risk that I discover around the beginning of January that there's a problem and it's going to take longer than we guessed, which wouldn't go down well. I have had lots of things I thought were good ideas, but when there's a team working on something, that idea has to be sold to them and to management before you can just do it. Even if you're in a senior position where smaller ones don't need anyone's approval, you still can't take out large chunks of time or make massive changes without notification and some kind of oversight.
A good manager (whatever level from lower management up to CEO) *should* like to get information straight. After all, if you have a problem in the company, you need to ensure nothing is being hidden. Sadly, not all managers are like that. I've said on here about how in a previous career, I was an admin assistant. That was my job title. My responsibilities were ensuring our suppliers got paid, and that a workbook of spreadsheets was completed and submitted to finance monthly. Finance used this sheet to charge the other departments for our services, and at £60k a month, it was our primary source of income. As such, it was important it was correct. It frequently wasn't. Not because I did anything wrong (I did triple check everything I did). It was wrong because I was often given incorrect or incomplete data. I reported this repeatedly to my manager, who did nothing to tackle the staff who was were submitting incorrect data. Probably because the main culprit was the Union rep.
"Musk isn't a programmer and it would be highly unlikely that he'd know all the ins and outs of Twitter's code base"
It is worse than that. Musk started as a programmer and therefore believes that he has enough understanding to fix issues. However there is a big difference however from starting something from scratch, and changing an established domain.
In those situations you really need to trust and gain the trust of the domain experts, because they understand the route taken and why there are no easy wins.
Elon's attitude was however that any twitter failure was because the work force was incompetent and just required his special sauce to fix. I am not doubting his intelligence just his ego. I have been there before when consultants are bought in with no domain experience. They spout some industry buzz words, disrupt the work, find the problem was far harder, blame the present staff for holding them back, then 6 months leave with a fat check and chaos in their wake
Your final sentences describe every "management consultant" I've ever had the misfortune to meet. They swan in, tell everybody they're doing it wrong (often without taking any time to understand why the current process is the way it is), and when it all goes to hell as it inevitably will, it's everybody else's fault.
They get people laid off (or pushed to resign) when they march in. More people leave when the blame game starts. And once they've left with their impressive paycheque, the company struggles because they believe the existing (possibly suboptimal) method is wrong, they know the new and improved method is wrong, and the people who could have brought some sort of control to the chaos are working elsewhere by this point.
Simple rule: if your employer brings in a management consultant, get your CV up to date...
You've got to admire someone who openly admits to his CEO, in public, that the app he's worked on for six years sucks.
Also:
> Frohnhoefer replied flatly: "Zero. The apps don't make RPC calls."
???
Technically correct, I suppose, as the app itself does not "make" the calls, it rather causes them to be made. The RPCs being referred to presumably happen server side?
However, at that point he appears to have been gratuitously confrontational rather than try to understand the problem being complained about.
> The RPCs being referred to presumably happen server side?
This would seem to confirm my guess:
https://nitter.net/elonmusk/status/1592460984534597632?cursor=LBnmgsDTubCYyJkshIDUpcCtyJksgIDU2bDpx5ksgIDUycbzx5ksgMDRvZCByJksgsDUtb79x5ksgoDUpdbwx5ksgsDQjZfSx5ksioCpoee%2Fx5ksgoDT3fzxx5ksgMDRpc%2FEx5ksgoCgsbrlx5ksgoDTkeHpx5ksgMDRreX%2Bx5ksJQISAAA%3D#r
Btw, the linking via nitter itself is a testimony to how shit their web page is.
Unusable without JavaScript, unbearably slow with, and it asks you to login (for which you need an account) if you want to see a whole "thread" (or it did last I checked perhaps a year ago).
Frohnhoefer replied flatly: "Zero. The apps don't make RPC calls."
Technically correct, I suppose, as the app itself does not "make" the calls, it rather causes them to be made. The RPCs being referred to presumably happen server side?
arguments over terms and semantics. exactly what I think was happening.
This probably means that territorial boundaries are getting stepped on, and those in charge of the territories are getting nervous and a bit defensive...
(so maybe Elon wants to integrate and probably consolidate, a thing that a new CEO is likely to want to do)
The programmer pointed out what the real problem was - years and years of stuff being added on at random, much of it that never gets used, that to speed things up they really should embark on a major rebuild and the other issue is waiting for networks to transfer data.
Its basically saying "thats not the issue, the problem is the previous owners oversaw a half baked lashup that if we did a total rebuild it would be faster, more efficient and less resource intensive along with more secure.
However Musk like a certain former Prez can't stand critcism of any sort and throws a tantrum, so if it wasnt for the requirement to be born in the USA (Which I'm shocked hasnt been overruled by the courts......yet (just wait till the repubs for example have a fantastic candidate blocked only by not being a "natural born citizen" and then see how fast the conservatives on the supreme court strike it down)
Wrong! If he'd have explained that in private, even though Musk put it out publicly, he'd have most liekly got a better response.
Embarassing your boss in public, no matter how wrong they are is never a good idea!
Anyone who has spent time in the military, where officers are put in charge of you who have zero knowledge of what you do, would know this.
The person who said he didn't know what he's talking about wasn't a Twitter employee. The fired employee wasn't impolite.
Musk tried to bullshit, he was corrected. He fired people. Musk isn't a programmer so why is he trying to act like one. Don't be apologetic for bellends.
>Musk isn't a programmer so why is he trying to act like one.
Musk has dug himself a financial hole, that could force him to dilute or loose his control over Tesla and SpaceX. He needs to convince Bankers and private investors that he is in control and knows how to fix things so he does not have to sink more of his own capital into twitter or be forced to write it off as a total loss. Musk does not care what an RPC is or even what the real problem is, he just needs jargon to feed his backers.
> Musk tried to bullshit, he was corrected.
That's what happens when reading the news without being aware of editorialising.
If you head over to the actual discussion (there's a nitter link above) you'll see that there was an actual issue, which this guy appears to have misinterpreted (fair enough) but then he jumped into the discussion with his mouth well ahead of his brain. They were likely talking about different things: he'd be venting his frustration with the component he was familiar with (the android app) while Musk was talking about what happens server side in order to serve the app's requests.
At that point, it would have been good to stop and ask questions about what the other party was talking about (which incidentally is what Musk did).
Frankly, as someone else said in another comment, to anyone with military experience this man's outburst screamed "I have a shovel, and I'm intending to use it".
Probably good intentions, but spectacularly wrong approach.
Well, he never told Musk it was too complicated, he explained the number Musk was looking for (RPC call count), and then provided Musk the reasons why the app was slow. CEOs thinking it is red flag when told by engineers at their company that things are too complicated for said CEO to understand should consider it a red flag, a red flag that the CEO is at the wrong place in the company.
Musk probably has a Cessna Citation....
As a result, he's probably declaring himself to be a former airline pilot who knows how to fly Concorde, all X-series from Boeing, an A380....
He'll also claim that all aircraft have REST APIs, that he control the flight via Postman or Insomnia
Musk is really amazing me - he has time to look into the system architecture at the same time as reorganizing the company after getting rid of most of the former leaders and half the staff; not to mention that he's doing all the CEO work at Tesla as well.
Even if he should turn out to be a brilliant system engineer and programmer (haven't seen any evidence of this part of his skills) he should have other priorities than the performance of the twitter app at this time.
I don't usually get that from a Brexit post.
Ho ho.
So I guess there's lots of you out there in Registerland that can relate.
That's nice.
I would note a) Musk started by starting a software company. b) I suspect he has quite a well honed BS detector.
Are his prioritisation and social skills questionable? Certainly. A certain fondness for hyperbole. Well quite a lot of what he's planned to make happened has happened.
But then again he did decide to buy the whole company and I guess that means you get to decide what you reckon is most important to the success of the business..
IOW the Golden Rule applies. He with the gold makes the rules.
Keep in mind if he actually does have Aspergers then we know can safely assume he has a)Limited (non existent?) empathy b)Limited inferencing skills.
So how he expresses himself could be pretty blunt.
You may think of him as another PHB. But I think you'd be very stupid in thinking of him in those terms.
As the parent of an autistic child, let me correct you on Asperger's: there is no particular reason why someone with this syndrome should be expected to have "limited (non existent?) empathy". They may have trouble understanding other people's feelings, but only because their feelings don't work the same way. When they understand that someone is troubled or hurting, their reaction is absolutely warm and empathic.
Musk may or may not be a sociopath. But if he is, Asperger's is a poor excuse for why.
Thank you.
Over decades in the computing business, I have had many, many friends, classmates, managers and co-workers with various Autism-ish neurodivergencies over the years. You can’t spend any time in this field and not do. Of all of those people, only one was an asshole. For reference, that's actually far lower than the rate of assholes in the non-AS cohort I’ve known.
Basically, Elon Musk acts like an asshole primarily because he is an asshole. Aspergers has not made him an asshole, it’s an orthogonal, and very much secondary, personality trait to the more prominent “is an asshole” axis.
But, Elon doubles down on being a fucking asshole in the way he’s happy to ascribe being an asshole to having Aspergers, as if common fucking decency is somehow fundamentally incompatible with neurodivergency. That is, to use the technical term, horseshit. But by perpetuating this lie, he’s landing another king-size bucket of shit over everyone else with AS who has the decency to try do right by their fellow humans despite having their well-meaning actions frequently misunderstood by us “normies”.
tl;dr? He's a prick.
"Correcting a factual error is not insubordination."
Indeed. Why did Musk think this person was on the payroll if it wasn't because they had expertise that the company owner didn't? Correcting factual errors is literally his frigging job.
Update: ...until it isn't. Truly Musk is a grade A plonker, Twitter is doomed and I'd start to worry about his other companies too becaue he seems to be getting unhinged. (Probably the 168-hour weeks he's putting in.)
Still, at least when Musk goes bankrupt I'll have the ultimate rejoinder to "If you're so smart, why aren't you rich?".
Or you could stay, confident in your career as a deckchair hand on the Titanic. Insubordination, followed by dismissal, is the golden opportunity to say "Told you" to the shower of body parts that were previously the boss who did not listen. There is no shortage of new jobs for good techies.
This post has been deleted by its author
Look up "velocity factor".
It's the ratio between the speed of an electromagnetic wave in a conductor compared to c.
The speed of an EM wave in a conductor can be very significantly slower than c. The speed of an EM wave in some coax cables can be down to 2/3rds that of light in a vacuum. It becomes very relevant for those that are involved in amateur radio and are building their own antennas, as the velocity factor changes the physical lengths that antenna elements resonate at.
It also comes into play with those working with multiple antennas where the signals are combined via phasing lines (sections of coax of carefully chosen length) so that there's appropriate constructive interference seen by the receiver. That concept is taken to the extreme with electronic steering of arrays like the radars in most current warplanes.
Derek at Veritasium has done two videos on how electricity works. Here's the second: www.youtube.com/watch?v=oI_X2cMHNe0
This post has been deleted by its author
Re bending network cables
Funnily enough there’s some truth to it; depending on the length of the portion before the bend (its electrical rather than physical length if we want to be exact about it) we can set up a standing wave and even see a reflection leading to attenuation (destructive interference) of the signal (or constructive, if lucky…). That’s the principle behind various types of antenna including J-pole and some more eclectic varieties …
I now someone who used to be in the army and had a right pain of a quartermaster running the stores, and decided some payment was due.
One night, he and a couple of others broke into the stores to "update some paperwork". The fun started the following morning when he went to the stores with a signed requisition for 5-sided nuts.
"Don't be silly!" bellowed the quartermaster, only for his face to turn a funny shade when he was presented with the entry in his parts file. He spent most of the next three days trying to source them...
"We once had a new apprentice who had been forewarned about long weights etc. "
I used to work in a job where there were long and short weights, depending on what model of manual telephone switchboard you were changing a faulty cord on.
IIRC it was short weights for the more modern British Post Office 300-type PABX boards (some very nice oak to be salvaged when they were scrapped) and long weights for the much older Western Electric style main exchange switchboards - I have a lovely mahogany coffee table made from an end panel of one of those.
When I got sent for a long weight as an engineering apprentice, I came back a few mins later and then disappeared back to the stores shortly afterwards.
That's where my supervisor found me drinking a cup of tea and chatting with the stores guys.
When asked what I thought I was doing... I told him that they didn't have any long weights, so I thought 2 short ones would suffice.
They had to get creative with their attempts at pranks after that.... 99% of them failed.
My father (yes, around 1960) told me a story of how as a young apprentice he was on a building site. People were indeed sent for Long Weights - and this was kosher, since they were the cucumber-shaped weights that (used to) go inside of sash windows, not that anyone really has those nowadays.
He was once sent to stores for a hairdryer, and balked at it thinking it hazing. Turned out to be totally true, they used then to quick-dry paint when finishing work was required.
The computer room at my first job had its own hairdryer; I still have it lying around somewhere. It has P7000 written on the side as its job was to make the eponymous computer's cold start a bit less cold: it was apparently quite grumpy when it was first woken up. An interesting and quite odd machine, though I don't remember much about it other than its wood panelling; sadly not oak nor mahogany as someone described PABXs a few posts back but still genuine chipboard!
At my old school the science teachers had a long running gag of sending the troublesome kids on errands. On one memorable occasion a lad was sent to the lab tech to receive a "long stand" and returned briefly with a very tall lab support stand. Mrs Hutchinson (best lab tech ever) had been waiting for this opportunity and had placed it just inside the door.
You may find that those companies specialising in repairing large clocks, Grandfather and bigger (eg towers clocks), are the best places to find a long weight :-)
Some sash windows suppliers, especially of traditional types may also hold stocks of long weights.
Since being sent for a long weight is something given by "an officer of the company", the trip can probably be expensed if there isn't one locally :-)
Our favourite was to give the apprentice one end of a ball of string and asked to hold it against an equipment rack (or other suitable point) to measure the length of a cable run... in the days before digits were everywhere, Video connecting cables were timed to a nanosecond or so; call it a foot in a line that might be half a mile or more long.
Of course, once round the corner and out of sight, the string would be tied to a convenient door handle...
Ah yes, the old "stretcher" gag. We had many of those in the building trades. However, my wife said confidently one day, she actually knew what a board stretcher was, and could even draw me a picture? Well, this I had to see, and she did indeed draw me a picture of a board stretcher! The kind emergency medical response personnel would employ! Lol so, I next ask her to go to the paint store for some polkadot paint.
I had a PA complaining that she couldn't print. I told her that the font was too big for the cable and that she needed to disconnect the cable and shake the characters out, which she promptly did.
Then there was a drinks machine that had been configured so that you could order a "strong" water - so I had a few people trying to tell the difference.
Then fairly recently a friend had a standalone recirculating water feature as a present so set it up but thought it was too loud. So I suggested that the water was too hard and that it needed soft water to reduce the noise.
I've also got a squint where one eye goes off on a wander - I tell people that it's good because I can see around corners.
In the code the REST call activates? It's still passing parameters to a remote process, activate some code in the remote process and getting the result back. How you pack the data, and how you activate that code, is totally irrelevant from this point of view.
It's funny how many "modern" developers have no clue about their code actually works. The problem is probably the use of too many libraries downloaded from the many repository and StackOverflow cut&paste coding...
Representational State Transfer (aka REST) is very definitely not RPC by intent and design, RTFM ... https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Clue: If you are viewing/using REST as a RPC in drag you are almost certainly doing it wrong and you almost certainly will not see any of the benefits of REST.
One is CRUD on a data orientated view, the other is calling functions by name and passing parameters.
If you wanted a generic way of calling REST APIs and RPC APIs, you could use the term... API.
None of us here have any idea whether it's a SQL database or flat files or in-memory storage behind the scenes, and it would make not a blind bit of difference to the REST interface, the web frontend or the Android app as REST is data orientated.
Now Musk's claim was the app was poorly batching > 1000 RPCs to render the home timeline. The app guy said it was bollocks and other guy confirmed it and a minute of thought would tell you that if an app were batching > 1000 REST calls then that would be a spectacularly bad design that would have been thrown out right near the start of the development process.
Then Musk went on to pull microservices and stopped people who were using SMS authentication from logging in. In a complicated service such as Twitter you do actually need microservices or Twitter would have to go down every time a new feature was deployed.
It seems Musk is the Stack Overflow programmer.
This post has been deleted by its author
No, it's a rather important technical difference. An RPC and a networkk response aren't the same thing. If you have both, then you need to see whether they're both slow or whether only one is. If only one is and you do a significant amount of work to reduce the instances of the other, you've wasted a significant amount of work.
If Musk wants to play this game, he can amend his statement and start fighting with them about the number of requests they make on some other system. It won't stop his original complaint from having been wrong, and his second one might also be wrong if he doesn't try figuring out how it actually works. If he hasn't fired them, there are probably people whose entire job is profiling the system and understanding what causes delays.
I think what actually happens (and this is a very common architecture) is a few REST requests over HTTP from the app to an API aggregator, server-side, that then uses RPC to call the microservices. So the Android guy is correct from his POV but there may well be many RPC (or infra REST) calls to microservices that he doesn't know about. However Musk is well known to have been an appalling developer so is probably out of his comfort zone here..
Because apparently he can't talk to his employees without getting a wrong answer, misunderstanding them, and/or firing them, so now he's asking random people who use Twitter how it works.
Musk explicitly stated it took >1000 batched RPC calls to for a timeline to load. Frohnhoefer pointed out in a subsequent tweet that the app makes 2-3 requests for a timeline to load, ergo the performance problem (which was never disputed) is not due to the number of calls (RPC or otherwise) but what the app is doing (e.g. "rarely used features") and/or waiting on (aka network response).
Think I've mentioned this on here before, but I did something similar for a presentation I has to give to a few hundred people.
I needed a word for a shape that was basically a parallelogram, but with curved sides - I came up with "ellimidical paralipse", and made much use of it. Not one person asked what it was.
I once advertised a sponsored walk to help raise money to train support animals for CVDS sufferers, with a description of the hardships and difficulties they face, and expressed my hope that a number of them would be able to participate in the event. What I did not spell out in detail was that CVDS stands for Chronic Vitae Deficiency Syndrome and the "sponsored walk" was to take place at a cemetery at midnight on Halloween.
In this way, I got several people to pledge their support to a fundraiser for Guide Dogs for the Dead.
Quite some time back now, some physicists tried to sneak their new unit, the "hoover" into a paper. They wanted a unit of vacuum noise, a colloquial way of expressing the random-noise analog to the quantum uncertainty in a single mode.
Unfortunately, the journal spotted this and made them change it.
Yeah, I don't quite get this either.
AJAX, WebSockets, SSL, TCP, UDP and all the different layers, methods of transport, etc are all used to make RPC calls.
I am not much of a web developer but I am sure they must just be calling RPC something different these days. Unless of course the Android Twitter app is 100% offline or makes no communication to any servers?
This post has been deleted by its author
The reason is the new crowd of developers desperately need to believe they are using the most advanced technologies and not some old ones, so they keep in making up new words just to look fashionable, sometimes just shortening some because they can no longer pronounce more than two syllables - look at the use of "infra", which is a prefix, not a word in itself. Infra-what??? Oh yes, they don't call "procedures", it's so Pascal!!! Of course they need to call it in a different way, yet it's exactly the same thing...
My team and I has been just called in to save a project that was going down the sink. It was staffed with this kind of developers - lots of buzzwords, all the fashionable checkmark checked - dreadful architecture, low quality code. Even some basic OOP concepts were not understood properly (code is in Python).
Unluckily in the past years IT became fashionable enough it attracted a lot of clueless people - the kind who feel the need to change everything because they are creating a brave new world, of course. Yet, usually the can change names at best - change everything to change nothing, really.
Or Musk has fired the wrong developers (or the good one already flew away), or Twitter has far bigger problems....
A Remote Procedure Call is a very specific from of inter-process communications, where a client system calls a procedure locally, and the underlying framework marshalls the arguments and sends the resulting packet to the server. The server unpacks the info, calls the procedure, and uses a similar marshalling process to return the arguments. To the client, it looks like a local function call.
There are many variants of it, such as Java's RMI, but it is only one of many ways that processes can communicate, locally or via a network.
OK, I do get that. But if not RPC, can you give an example of what the Android app might be using? I always thought REST and things were a type of RPC. Or at least they can be made just the same as calling a function.
Surely an AJAX or most other web-like pull, push can be described as forms of RPC. Proper streams are unlikely because they won't scale with that (admittedly shrinking!) volume of users.
RPC doesn't mean anything where you ask another machine to do something. RPC has a narrow meaning, where you call a function which is executed remotely. Calling a function that retrieves data from a remote location but runs locally is not an RPC. Next, you'll be saying that the 1000 count was right because look at how many RPCs were called to transfer the network request along its path. RPC has a specific meaning, and if you want to use it in discussion, it's useful to know what it means. The same way that "database request" and "database record" are not the same, that "byte code" and "machine code" aren't the same, that "Linux" and "Unix" and "Posix" aren't the same, and that "disk" and "partition" and "volume" aren't the same applies here as well. If you don't want to be wrong, you have two options: don't use technical terms you don't understand or learn enough that you do understand them.
The key thing about RPC is that it appears to the client program just as a procedure call. It doesn't know, or care, if that is really calling a local procedure elsewhere in the same program, or in another process on the same host, or on a server at the other side of the world. The RPC framework and configuration abstracts that. It may be client-server under the hood, but to the client it's just calling a function which returns data.
A RESTful interface is very different, the client is well aware that it's talking to a server. It asks a server for a resource, and the server sends back a "Representation" of that resource, which can be appropriately manipulated by the client, leading to further exchanges between client & server as they step though the states of the state machine (hence REpresentational State Transfer). The client-server model is fundamental to the architecture of the interaction.
And the RPC library is free to decide whether you even need to leave the boundaries of your current thread, process, machine or network; and whether any arguments and return values need to be footled with to be compatible with the function provider.
Your code just makes a simple function call, you compile it into your own library and the support decides the efficient way to satisfy it. Hopefully.
Yes. There are people in this thread (and other similar ones) who want to use "RPC" to mean any distributed execution. That might be acceptable in informal use, but as a term of art "RPC" was coined to refer to a specific architecture for distributed execution.
Musk make a technical claim, and that claim was not precisely correct in its terminology. Since it was a technical claim, Frohnhoefer was justified in calling him out on it. Musk was also wrong in various other ways, of course. He's quite efficient at being wrong in a small amount of text, which is why he's perfect for Twitter.
The specific architecture is the one called RPC - with the behaviour that has been described in many comments here, but put as simply as possible: your code invokes a procedure/function wibble() and it works (or returns a failure code). Your code has no idea if the function is satisfied locally or by invoking network traffic to a remote server: your code simply waits for the function to return. All data conversions required are hidden by RPC library.
This is very different in terms of how your code would use a different architecture, such as triggering an explicit request to a server - and expecting back a response that need not be handled by code anywhere near the code that caused the request to be sent.
I've not spotted anyone claiming that only one specific implementation should be considered *the* means of satisfying that architecture - can you say which one(s) you're thinking of?
Which code today triggers an explicitly request to a server but low-level libraries? Applications do have layers built atop that that perform some kind of RPC. If you had to code the real explicit request to a server - or worse, access what you need directly - you won't go far. After all, that's why RPC was born. Let processes communicate among them as needed to exchange data, to avoid the need of monolithic applications, allow distributed systems, control data access, and better reuse code and applications.
Do you remember "file-based" database systems (i.e. dBase)? They did not use RPC - all applications directly accessed data files and tried to coordinate writing locks into shared files. **R**DBMS introduced RPC - you don't access the file - you call a remote procedure with some data (i.e. the SQL statement) and the server returns the data in some format. Usually you will have a client library which hides the communication protocol - which might be quite complex - so you call some procedure in the library, it performs the setup for the call, executes the call and returns the result. That's the difference. It today it makes a REST calls, literally nothing changes from the conceptual point of view. There's just some additional layers.
The interaction between a web browser and a web server is the same - the web browser doesn't access HTML files (or whatever) directly - it needs to call a procedure in the web server with the proper parameters to get the result. The fact that the procedure call is then formatted into an HTTP request and sent to a specific port on the webserver is an implementation detail.
The fact that a call has a URL in it doesn't mean it's making a "direct request". That's simply a parameter you're passing to a local function to actually return something based on that URL - which can trigger a remote call or not. Where it gets the data the application might never know really.
If people are believing they are not using their grandfather's or grandmother's RPC concept, but some outstanding new technology never seen before, well, they are wrong. The implementation may differ, the concept is the same.
To get a call across processes you always need something locally to pack the data (the "marshaling" in some frameworks), send them to the remote process with some identifier telling what code to activate, and on the other end the data are unpacked ("unmarshalled") and the code run and back.
The fact that you use a binary format, XML, JSON whatever you like to transmit data is irrelevant. The fact that you use DCOM, HTTP, message queue, is irrelevant. They are all forms of RPC - then there are specific RPC frameworks like DCE-RPC, DCOM, CORBA, Java RMI, they are **implementations** of the RPC concept, they are not the RPC concept itself. Calling a URL and getting some HTML or whatever back is a form of RPC anyway. Is SOAP RPC (using XML and HTTP) and REST is not RPC (using JSON and HTTP)? Why?
The fact that you can hand-code a REST call is just because it uses a textual representation of most elements that does allow you to handle it by hand, something you can't do with DCOM which requires a binary format for calls one wouldn't be able to do without code support. But to well-written application REST calls look exactly like local calls - there will be a class of whatever implementing it allowing to replace the underlying RPC mechanism easily if needed.
After all even accessing a database is a form of RPC - you call the local database client library, it will perform all the required operations to send the data to the database server, invoke the operation, and return back with the result.
You may call the RPC concept with different names if you like, but the concept is exactly the same. Give funny names to old things to differentiate - i.e. Rust "crates" and "cargos" - but if one forgets where those concepts came from, one doesn't understand what they really doing...
One day someone will tell that an app is not an application which is not a program... I'm afraid.
RPC and "stuff over network" are not drop-in replacements.
RPC generally wire efficiency and ease of encode/decode matters. Adding another protocol in that layer when it must be discarded almost entirely, is a hard steer against that technical choice.
The protocol layering is unhelpful in the REST case - > TCP -> TLS -> HTTP -> YOLO JSON - vs TCP -> TLS -> ASN.1 (SNMP) or TCP -> TLS -> thift/protobuf/capn-proto etc.
You might argue that using a WS transport and implementing an RPC over that gives you HTTPs ubiquity and good enough framing, but that's not a REST API that represent the transfer of state from the client to the server in the urls and headers of requests/responses freeing the server from holding state.
RPC almost by definition are stateful. the server is explicitly the repository of state. When people say RPC, they generally refer to some system in which a set of messages are defined in an interface description language(IDL) [1].
A generator will read the IDL to produce client stubs and server stubs, which need not be in the same language. The client and server networking code is part of the generated stubs in some schemes, not in others. Client stubs convert client side type (e.g. python string) into the wire encoding, usable mostly as is.
Server stubs invoke the underlying "procedure" in an RPC after decoding a server side type (e.g. golang string) from the wire encoding, then encoding response for transport. You could implement something that looks like RPC using an JSON wire encoding of messages over a WS/HTTP transport, using open-api as the IDL.
What stops this from being real RPC? Well leaving aside the wire encoding, does my RPC have a protocol that helps, for example Java RMI or GRPC. Not really in the JSON/HTTP/WS case, I generally want from small amounts of data (tens of bytes) to large (tens of MB) over a long lived connection in the RPC case. For REST, likely that each request will be a new connection, with little interest in the payload size, probably to a different server.
[1] thift/protobuf/capn-proto/asn.1/SUN XDR
You are again messing up with the RPC concept and some specific RPC implementations. IDL was designed to describe interfaces in an independent way - it was adopted for some RPC **implementations** because it was a handy way to describe procedures calls without being tied to a single language. From this perspective, it's not different from any other specification that describe a software interface.
Nor RPC is stateful by definition - no "procedure" needs to be stateful by definition.
That said, many old RCP implementations were far better designed that the actual fashion of sending text blobs around - without any real checks at the compiler or execution stage of what is going around - because many of them lack a formal definition of the interfaces - it would require far better skills.
Code today is much more brittle than it was - probably because developers no longer understand the concepts - narrow minds don't help.
You are conflating points, perhaps I'm unclear - RPC as an architectural style is not REST.
Does using HTTP means REST? - no.
Can you make a RPC over HTTP? (FCGI?) - yes but i claim that a protocol designed with RPC in mind, would provide a better experience, hence why FCGI/CGI over HTTP is required.
REST is agnostic to the usage, it's resource centric and as such contains no specific assistance to RPC compared to say content-negotiation or caching both of which are contained within HTTP as a supporting protocol to the REST architectural style.
IDL - Either both sides are the same language so you can share a common wire description or you manually maintain each side.
RPC protocols generally contain supporting features to the task, while I agree you can (and I have) implement RPC with plain sockets and a shared header file - that's not REST either and most people use IDL.
REST is stateless by design, based around self describing resource representations.
You can indeed call a stateless RPC. I agree.
Elon has repeatedly confounded industry "experts" and people embedded in legacy systems. I'm sure he has no idea how to design and build cars or rockets. What he does do is listen to disruptive engineers, who typically come from outside the industry and then give them the authority to tear-up the "rulebook"
I wait with baited breath for the DoJo AI chip, which apparently is the first chip NOT based on von Neuman architecture.
(And I can't conceive how twitter would work without Remote Procedure Calls, my guess is one is talking about a narrow definition and the other a broad one.)
And yes, as the legacy engineer, I'd be worried about Elon throwing out all your code. You'd be better advised to offer a new architecture to Elon.
> the first chip NOT based on von Neuman architecture.
Except for anything based on Harvard Architecture, like, say, the AVR family [1] - Arduino ring a bell?
How about all your current x86-64 CPUs, with their Data Flow Architecture that allows out-order-execution to take place?
[1] yes, I know, it is a modified Harvard, but can you name a more well-known example?
I don't know how Twitter's backend is architected, but it's conceivable that non-parameterised queries and queries with predictable parameters (such as the one specifically referred to, whose only parameter is the user ID) could be fetches of pre-generated documents.
Elon has repeatedly confounded industry "experts" and people embedded in legacy systems. I'm sure he has no idea how to design and build cars or rockets. What he does do is listen to disruptive engineers, who typically come from outside the industry and then give them the authority to tear-up the "rulebook"
Which may or may not work. Depending on whether the industry consensus is in fact correct, or whether his disruptive engineer from outside actually has a clue what they're talking about.
So, for example, Tesla's big failing for the last few years has been in manufacturing. Which they've been shit at, and had consistent problems of bottle-necks and slow production. Hence they've had long waiting lists of customers, which means they're leaving profit on the table that they should have had. Long waiting lists are inefficient, because they show that either your price is too low, or your manufacturing process is too shit. Either raise prices to capture that extra profit, or ramp up production, or both.
And that's possibly because he got in outside experts - when actually the motor industry has done pretty well at solving the problem of efficient manufacturing. The problem in the current industry is probably complexity of supply chain and lack of stock - which makes the system very efficient/cheap, but highly vulnerable to governments (and political/diplomatic events) changing what they're allowed to do - as well as economic shocks.
The car industry has also produced many perfectly acceptable electric cars. So in the case of Tesla, the triumph has been much more about good marketing and hype management than about technology.
And some of that hype has gone into the so-called "Autopilot" - where I don't care how many fucking disruptive outsiders you call in - self-driving cars are still not possible and will still kill people if allowed under anything other than highly controlled conditions.
SpaceX however have done genuinely innovative things. In an industry that had become so focused on mining government pork, to the exclusion of almost anything else, that they were ripe for a damned good kicking from an outsider.
Had Musk had the cash to buy ULA he could have done a lot of the SpaceX stuff, but maybe not all, as his customers were also likely to be risk-averse. And less incentive, because of all the lovely profits rolling in from fat government contracts. Had he bought a functioning car company though, he probably could have had Tesla producing a million cars a year ten years ago - if he'd been able to do the marketing effectively enough to sell them. Whereas I think they only achieved a million produced last year and it took them from 2008-2020 to build their first million cars.
> the motor industry has done pretty well at solving the problem of efficient manufacturing.
Lest we forget, Musk also "knows more about manufacturing than any other person on the planet" [1]
[1] sorry, haven't got a URL for that clip, but go watch Thunderf00t's latest YT video...
Apparently the medical profession, at least used to, have some excellent acronyms. Apparently doctors have spotted using them for fear of having to explain them in court.
Things like:
For an obese person - DTS - Danger To Shipping
ABITHAD - Another Bloody Idiot, Thinks He's A Doctor
GOK - God Only Knows
LOBNH - Lights On But Nobody Home
NFS - Normal For Swindon
SNEFS - Sub Normal Even For Suffolk
O2T - Oxygen Thief
It's such a shame to see the old ways die out... ;)
My cousin is a (former now) A&E Consultant, she used NFN (Normal for Norfolk) instead of NFS.
CTD (Close to Death / Circling the Drain) became popular apparently as it was often used by Dr. Cox on Scrubs, so too did GOMER (Get out of my Emergency Room) for their frequent flyers. The rather dark BUNDY (But Unfortunately Not Dead Yet) was apparently often used in geriatric care for the patients with long term issues (E.g. Alzheimers) that meant they had zero quality of life.
GOMER hearks back to Samuel Shem's The House of God, essential reading for anyone embarking on a career in hospital medicine.
Last thing we did the night they closed our old Emergency Department before they demolished it was to write the 10 Commandments on the wall...
My personal favourite is 6. THERE IS NO BODY CAVITY THAT CANNOT BE REACHED WITH A 14G NEEDLE AND A GOOD STRONG ARM.
I once worked with a lady whose partner was a Registrar at the local Accident & Emergency (as they were known in those days). Of the acronyms that were used two remain in my memory (both usually called in to the A&E by ambulance on a late Friday night)
PFO - P*ssed and feel over
PALAF - P*ssed and Lost a Fight
Colac, sort of famous ( if that's the right word ) among the older ultra running community for hosting a 1000 mile foot race around the town square iirc. Just had a look online and see that in the last event "Only finisher Siegfried Bauer set new 1000 mile world record of 12d 12hr 13min 20sec "
Is this the right crowd to go all pedant and point out that only some of the above are acronyms? If you can pronounce it, e.g. NATO, then it's an acronym. If you can't, NFN (Normal for Norfolk), and just say the letters, then it's an initialism.
[checks post for inevitable spelling and grammatical errors]
This is great. He's actually using public tweets to manage the company. So the rest of the world can see what an awful manager he is, and discover all the problems he missed after neglecting due diligence at the same time that he does. Today he and we learn that there's 10 years of technical debt in the codebase. And that the techies are prepared to answer back to him.
Can't wait for tomorrow's episode of "I was so impressed I bought the company!".
You are standing at a doorway leading to a vault of gold, guarded by Smaug the dragon. You have two choices.
1. Send your explanation privately in a polite e-mail, clearly stating the problems and some solutions in plain English.
2. Make your CEO look like a twat in public.
Type your choice (1/2)
© Melbourne House 1982.
This post has been deleted by its author
Life is rich with choices...
You are the CEO standing at a doorway leading to a vault of gold, guarded by Smaug the dragon. You have two choices.
1. Send your message polite internal group e-mail, clearly stating what you think are the problems and ask for suggested solutions in plain English.
2. Make yourself look uninformed and slag your employees in a public Tweet.
Type your choice (1/2)
Seeing as you mention Melbourne House, it seems only fair to remind anyone who may have missed it about The Register's lovely article about that venerable software house!
(Thorin sits down and starts singing about gold.)
App is doing >1000 poorly batched RPCs just to render a home timeline!
It is pretty hard not to interpret "batched RPCs" as remote shell script calls. If Musk doesn't know that then he should ask for advice before tweeting - but that's his weakness isn't it?
Interpreting broadly, the app is dispatching database base calls via a REST API and waiting for and processing the replies to form the displayed result.
Surely there are terrible ways to that. The worst way would be emitting the requests in serial, blocking the next request until the previous reply has been received.
Musk phrasing loosely invokes that image. I really doubt that it is true. Even if Musk was not an expert, he could have expressed himself clearly if that was he meant
and he had confirmed that was true.
There is more than one way for the app to handle the replies "correctly" - there are tradeoffs to different strategies - mostly how to display partial data versus updating the display once so it doesn't appear to jump around. As the engineer stated, trimming the unnecessary requests would be a good idea - in his opinion. That must be the 1000+ count - so it appears the engineer agrees with that much anyway.
Why would Musk converse with employees via a public conversation in Twitter - and slag them while doing so?
Incorrect. Per Wikipedia, "a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction"
https://en.wikipedia.org/wiki/Remote_procedure_call
Do you code every bit sent on the network yourself using plain sockets, or do you rely on higher-level libraries to make the remote calls? And does every piece of your application explicitly do that, instead of calling some procedure/function/method that hides where the data actually come from?
When you call http.get() you are calling the local get() function that in turn will trigger whatever is need to invoke the remote get() one to deliver what you have requested - or do you code the whole HTTP protocol by hand over a socket?
Wrong question. It's not whether you wrote http.get but where it runs. Does http.get connect to another computer for that to do the HTTP work, or does it do it on your computer? If the former, it's an RPC and your program is not like anyone else's. If it's the latter, it's still a local procedure. No, an HTTP request does not count as getting that server to run your procedure. It may run some of its own, but it will not accept arbitrary calls and may not be performing a computation, for example if it simply returns you preexisting data.
I see people really have no clue what the RPC concept is. It's separating an application into different processes that can communicate among them, but without going down the rabbit hole of having each application code the underlying communication protocol or access data directly for each call. Application keeps on calling "procedures", and if they are executed inside the local process or a remote one (on the same machine or a separate one) becomes irrelevant - of course you need some sort of common protocol to achieve that, hence the many protocols built on the concept.
Even if you call an http.get() function inside your library, the fact that it is answered inside the same process, another process on the same machine, or a remote machine becomes irrelevant to the code. You have a procedure "get" that returns something depending on what parameters you pass to it. Of course, one of the parameters (or a configuration) will tell where the call goes, but from the caller point of view it simply calls a procedure locally that is then translated - using the HTTP protocol - into a remote call inside the web server process.
More even so if you have a layer that abstract more the communication mechanism - and you don't know if your call goes via HTTP or AMQP or whatever - or it's even executed locally.
I understand why a lot of recent applications look much worse than those written years ago - new developers lack real knowledge of what they are doing and believe the libraries they download perform some incredible, wonderful magic like never before and they are wizards because they can master that. You might put layers atop layers, put new acronyms of whatever you use, but since what's at the lower levels is still the same the real concepts are exactly the same.
Beware of hubris... I guess the environment in many software company became really toxic, with this kind of people around. More the kind you can find in marketing and fashion, than in a real tech environment.
Confirmation here; not sure what the "saluting" emoji in Frohnhoefer's response to Musk's "He’s fired" is getting at, unless- as I suspect- it's sarcastic or mocking?
(Quite possible- if not probable- that he anticipated this retribution and went ahead with the Tweet regardless because he already had something else safely lined up).
Not sure why he'd use it towards himself and/or Musk though...?
(Also, while I'm here, I note that Musk's Tweet that Frohnhoefer was replying to has now apparently been deleted ("This Tweet was deleted by the Tweet author."). Edit; *now* it looks like Frohnhoefer's Tweet itself has been removed ("This Tweet is unavailable.").)
There's a lot of protocols. Twitter presumably uses a different one.
Or several different ones.
I also very much doubt the app uses 1000 of whatever. Some earlier posts claimed 20, which seems far more probable.
It's also pretty much irrelevant. Even if it was true, management-by-public-tweet is a rather effective way to burn $44 billion for nothing.
My guess is some leadership wank at twitter had a meeting with Elon and told him the "1000 RPC calls to" whatever comment. That person's days are numbered. Elon didn't pull that statement out of his ass. Someone specifically told him that and he repeated it. You don't hang someone out to dry with that level of misinformation if it isn't true.
Theres also another possibility. RPC calls are primarily back end communication. An Android GUI engineer is going to know the microservices he calls. He may have no idea of the back end communication involved in deliverry of microservices data.
The fact theres a RPC performance toopl and a whole set of finagle related RPC tools written in Scalia on Twitter's opensource site (https://opensource.twitter.dev/projects/?q=RPC) , Im guessing there may be some fire associated with the comment Musk has repeatred.
The proof will be in whether the person who passed musk the information or the engineer trying to shame him gets perp walked in the next couple of days.
In the end he may still be right. A graphql request for a Twitter timeline probably fans out god knows how many remote requests to resolve the final result. It's to be expected the engineers working on this hot pile of garbage (not their fault) feel a need to defend their (life's) work vehemently, who wouldn't.
People used to talk about how bad Jobs could be to work for, but all he'd do is scream at people. He didn't fire them for giving him bad news, let alone publicly fire them.
Musk may take the prize for World's Worst Boss, unless there is one who publicly executes employees.
One of my first "real world" jobs was doing some work for a small private college. I was working for a contracting company and was their on-site rep. Little did I know, walking in, that my boss and my on-site supervisor hated one another and this dislike stretched back over a decade. My on-site supervisor would, as a matter of routine, set me up into no-win situations just so she would have an excuse to call and yell at my boss. My boss knew his counterpart was just looking for an excuse, so he didn't really sweat it much. When the on-site supervisor was in the office, the whole place was just completely quiet and everyone just kind of stared at their screens. One day, the on-site supervisor took a week off, and the change was immediate. Everyone in the office was standing around talking to one another in a friendly sort of way while waiting for something to come in that needed our attention. It was like it was a company holiday party or something. No one else in the entire company liked the on-site supervisor either. I quickly learned that any time I was a little late getting to a customer on the other side of campus or something like that, I could just bring up the name of my on-site supervisor and everyone would give me this "you poor bastard" look and immediately be quite accommodating.
I used to think that person was an example of the worst boss a person could have. Then came the Trump presidential campaign and Musk's recent meltdowns. Now I realize that I had it pretty good by comparison.
> unless there is one who publicly executes employees.
It wasn't an execution, he was just scheduled to polish the Falcon fairing and happened to be given an unfortunate timeslot. The straps? Oh, all our window cleaners use them, H&S you know. On backwards? Oh dear, such a klutz.
Now, whilst we talk about your code, could you just grab that chamois...
Musk is a typical (self-proclaimed) "Libertarian" in that- when push comes to shove- it's obvious that the only "liberty" and "free speech" he cares about is his own and anything he agrees with.
Peter Thiel is the epitome of this- a "Libertarian" who cares nothing about democracy or anyone else's (i.e. the non-"elite's") right to choose and could be described variously as a fascist or a neo-feudalist, i.e. someone who is happy for- and indeed wants- others to be oppressed to stop them getting in the way of doing what *he* wants.
(Oh, and notice how Musk- whose position is that it's more important to spread mankind to other worlds than "waste" time solving poverty on earth- is someone who was born into privilege and the elite and has never- and never likely will- suffer poverty himself. No wonder he can safely indulge his right-wing sci-fi ideology.)
"People used to talk about how bad Jobs could be to work for, but all he'd do is scream at people. He didn't fire them for giving him bad news, let alone publicly fire them."
Jobs despite his obvious talents could be an asshole too. People would avoid getting in an elevator with him, in case he started questioning them and he did not like their answers. He was renowned for firing people who bored him, or disagreed with him.
Of course then as now, people would make excuses how he was a perfectionist, a genius, had to trim the fat to make a great company etc.
The truth was sometimes Apple succeeded despite, instead of because of Jobs, and there was a layer trying to protect the workforce for his excesses. There is a belief in the US that you have to be a tyrant to be great technology manager. In truth there are many great managers who respect their workforce and lean without the histrionics
"Part of today will be turning off the “microservices” bloatware. Less than 20% are actually needed for Twitter to work!"
https://twitter.com/elonmusk/status/1592177471654604800
Followed by a load of replies claiming folks with 2FA enabled can no longer log into Twitter if they had previously logged out...
Unless it's a freshly rebuilt system, I'm sure that the correct and concise answer to every question is, "It's complicated."
How many RPCs for the home page?
- At which point or points in the system do you want them counted? What is or isn't an RPC? Tell me what number you want to hear.
Walk me through exactly what happens when...
- Are we talking about shapes and arrows on a whiteboard or stepping through source code spanning multiple systems?
How much resources are wasted?
- A lot, but the easy stuff is already fixed.
How long will it take to fix everything?
- Do you mean replace everything?
working with twitter's api... I'd say saying a REST call is not an RPC call is splitting hairs. It's not a true internet standard RPC (as is used by virtually nothing except NFS), but you're making a remote call and getting a response, it is a remote procedure call in that sense. That said, getting info from twitter from GraphQL involves *one* request (two if you're not logged in first), not hundreds.
Which is exactly what happens when you invoke a get/post/put/etc. HTTP function locally and the underlying local library codes the real HTTP calls for you, sends it on the wire managing the TCP/IP connection, and then parses the result back for you.... you are not sending and accessing the data directly over the wire.
RPC is too broad a term for what it means exactly but I imagine in Twitter's world that when someone fires up the app, it has to call home and then and make a bunch of calls to build the activity that has happened recently. For someone who folllows a lot of feeds, maybe there is a call per feed to build the response up. It doesn't mean it is slow or inefficient to do it this way, or that there is a magical fast other way to do it..
It's still pretty stupid for Musk to throw out this random statement without understanding what it means, whether it is efficient or not, or anything about it really. And then to fire a guy who does know what it means is just him being a petulant bitch.
It's actually hard to see how he could be a worse boss than he is now. It's hard to see how his intent is anything but to run the company into the ground. I wouldn't be surprised if he is such deep financial trouble that this is his intent to escape creditors by burning it to the ground and seeking chapter 11.
TCP contains multiple round-trips (ping delays) just to set up and maintain a stream, and then SSL needs a few more to set up the encrypted channel.
If the number of serial request-responses is small, the setup cost will drown out the application traffic, but it'll still appear to take ages unless you have a good understanding of what's actually going on in all the layers.
Committed 17000 commits last week[1], top engineer, keep him.
Only committed twice last month[2], fire her butt.
[1] search and replace to update the date on all the (C) notices in the source
[2] after 3 weeks poring over logs and wireshark dumps, found the chain of events that created a circular reference that prevented memory bring released and caused a key service to restart and reload its data every 3 hours.
"Twitter software engineer Eric Frohnhoefer decided to embark on a bit of career roulette"
It's not really a gamble when there's a high probability you're going to get canned anyway. Might as well go out in style and showing that the CEO is an ignorant idiot.
I'll be surprised if Twitter lasts six months at this rate. The vast debt that Musk has now saddled the business with and the haemorrhaging income stream that only looks set to get worse by the week may well result in a queue of angry bankers stripping the company for parts.
Still, the silver lining of Musk being sued to pennilessness by shareholders for destroying their investments will be an entertaining spectacle.
IIRC, the only other remaining Twitter shareholders are the Saudi Prince Alwaleed bin Tahal ($2 billion) and Binance ($500 million)
Not sure what they'd do, but on the bright side, burning Twitter sufficiently brightly might burn what's left of cryptocurrency.
Was an employee right to prove his boss was a nut online? No.
Was a boss right to despise his staff online? No.
However, only one of the two has the right to fire the other one.
I understand the software developer. After what the staff experienced, their uncertain future, the harsher working conditions promised to them and the insults they get from their new boss in front of World + Dog, they must be really upset.
For Musky, he just prove once again than a genius can be a sociopath and a fucking idiot.
== Bring us Dabbsy back! ==
If you're right it's a power move, but be right and make a good argument. Not a fan of GQL myself but people swear by it. [Not an attack on GQL but a more general point] we reached Peak Software some years back where we suddenly gained zero-cost infinite compute power and nobody had to think of things like performance because servers could just instantly produce the data and we didn't have to pay for that CPU time, latency wasn't a thing and data bandwidth was totally free - and thank god because you no longer needed competent software engineers.
Lets be real: Twitter has been one software engineering fail after another since day 0. At some point it became vaguely stable because they figured out how to horizontally scale it but it just shouldn't need the compute resources it does, this one of the many reasons why it was a money eating machine above all else: it's a very simple piece of software at it's core and it just shouldn't be that way, it's orders of magnitude simpler than say Facebook, this is why they had trouble doing easy things like editing tweets. They also struggled to monetise the platform too but if you have a base platform that doesn't eat money that becomes way less of a pressure.
I'd go back to first principles and rebuild (yes, from scratch) the thing to be efficient as a first priority and make good choices that allow it to be extended in useful ways in future, but apparently I'm not down with the kids and live in the olden times when we had to actually pay for resources. But no seriously come up with some good torture tests and make people pay for slowing down the system and expenditure with finding savings elsewhere.
I think you are being unfair, it does what is quite a simple problem with large amounts of data, it implements a cache for the followers.
The massive amount of compute is from regenerate the cached timelines for each of your followers every time you post an inane cat pic.
There is obviously a need to feed the updates through an enrichment pipeline for all the "value add" stuff, but the scale of it and the generally responsiveness is a solid bit of engineering.
Real world stuff is not pretty, but that as a basic design is scaleable, they may have moved away from that design since the talk, but it's a neat idea.
AFAIK, the idea of "free" speech is that you can say sensible but controversial things* without fears of reprisal. Musk's definition seems more "anything that I personally don't disagree with with", which also explains his witch hunt on parody accounts (read: anything and anyone making fun of him) - which demonstrates just what a snowflake he really is. A very rich (but at least $44B lighter) snowflake, true, but a snowflake nevertheless.
But hey, it's his black hole now.
* Still doesn't mean one should abandon civility and engage in hate speech and all the other twaddle that Twatter became known for and which has seen an aggressive, advertisers-removing revival since Musk bought it.
It seems that a large number of people believe that 'Freedom Of Speech' also magically comes with 'Freedom From Consequences'. *
The realisation that it doesn't can often be somewhat of a surprise...
* (edit - not that I am in any way defending Musk's actions. The man's a tool.)
Musk has explicitly referred to the US First Amendment when talking about "free speech", so let's keep the discussion within his terms - just makes thing easier. So:
The First Amendment provides that Congress make no law respecting an establishment of religion or prohibiting its free exercise. It protects freedom of speech, the press, assembly, and the right to petition the Government for a redress of grievances.
https://www.whitehouse.gov/about-the-white-house/our-government/the-constitution/
There you go - Right to Free Speech is purely about whether the US government is allowed to stop you.
It's a different deal when you're calling out your boss about the business, in public.
Not for nothing but yes, turnabout sucks, maybe certain political classes should have stopped and thought when they were cheering it on and being warned about consequences.
Free speech does NOT mean you do not face consequences. If you take out a newspaper advert calling your boss a **** then you can expect to be fired. It's unprofessional.
Freedom of speech means you have the right to say it, not that you get to insult your boss to the public and avoid any reprisal. Surely anyone can see this. If you tell your boss they are a **** at work you can expect to be fired, and that's far less public.
It depends how reachable Musk is internally.
Decades ago, I had to stop the company I worked for from making a major mistake in responding to something that had been made public via an emag which was then still in its infancy. Despite being a mere worker bee then, I did have a route into the team that managed the C level and publicity, and I managed to stop them from calling lawyers - partly because I knew some people in that emag, and the article didn't fit within their normal editorial approach.
As a result, to the outside my employer appeared far more reasonable than their original reaction would have been, and the emag got to save its face instead of being buried under lawyers. That would have been correct but even then (before Twitter et al) it would have maybe won the company a court case, but produced bad PR. It also allowed an emag to save face (and learn a lesson without too much damage), so win win.
Given that Musk is fresh into Twitter it is quite possible that that channel didn't exist. Not that that is an excuse, but it may have been a contributing factor. Add to that that most staff isn't stupid, and I suspect that the protagonist here was already on his way out anyway.
All that said, I agree. As long as you work for a company you also have to consider your impact on the company's reputation. That a CEO is sinking it doesn't mean you should help it along..
The important point is that a lot of that pocket money was lent to him by other people.
Unless the principal condition of the loans was "Musk, you've got one month to permanently destroy Twitter's value, userbase and ability to function as an ongoing business", I imagine that Musk's secretaries are rather busy at the moment answering the phonecalls of some very angry bankers and oil sheikhs.
It is far worse than just being thick. Elon Musk is on the level of incompetence that result in whole countries suffering economic damage and recession in that same process.The question is always when the collapse happen in this type of incompetence. I am sure that at this point, all of Elon Musk companies and wealth start to unravel. It starts slowly and then gains speed until everything is bankrupt that Elon Musk has touched in last few years (when it comes to companies. All of his ex-girlfriends don't want to talk to him, best of my understanding of that situation).
Turns out Elon was not joking... https://twitter.com/EricFrohnhoefer/status/1592287037805441024
I think both Elon and the Programmer are wrong here. I don't know the technical details of Twitter, so am not judging either on the technical side (although if I had to, I'd side with the programmer who has been working with system for years, rather than Elon, who, even if he got his engineers to look at the code, won't have more than a few weeks experience with it).
But Elon should not have criticised how the system is setup publicly. By doing that, he is telling his staff he thinks they are idiots, and telling the entire world they are. That will (rightly) anger the staff. The programmer should not have called out his CEO so publicly. This entire conversation should have happened on an internal system.
The most Elon should have said in public is a generic "There is a problem. We are working on it" tweet.
I'm a long in the tooth Project Manager who came up through the dev, tech support and then tech management route
I'm often invited to meetings with very senior stakeholders as the 'translator' between tech teams and non tech managers.
Part of the process is to brief the senior exec running the meeting, normally they will hand over to me to actually describe the issue, options and costs etc but there have been several occasion when less than tech managers have decided they can manage the meeting without me and proceed to incorrectly describe the issue, and the potential solutions then propose the wrong solution to the board.
I can usually take control before this goes to far bit one particular manager constantly talked over me underplaying the seriousness of the issue and overstating what could be delivered. He was finally told to let me speak and I gave the true position and the (not terribly good) recovery options, which did mean dropping some nice to have functionality, leaving the meeting he declaimed 'well you made me look like a right d*ck in there' and gave me a veiled threat that I'd be sacked if it happened again.
In reality of course I had saved his hide and prevented our tech teams being given a task that was impossible to deliver.
For those of you wondering if a PM should have been the one presenting this rather than the actual debs and tech specialists, firstly none of them were prepared to attend the meeting as they knew they would be bullied into silence, secondly. I couldn't really rock up with 5 people and finally, we had agreed exactly what I would be saying, that it was accurate and that if I got them the additional time they could deliver. I did my bit for them, they delivered for me and it all ended well but that culture is why I ended up contracting
I'm sure that Elon's strategy of firing anybody who proves that they know what they are doing is going to work out just fine. [/sarcasm, for the hard of thinking in the back of the room]
And for all those people saying "don't be insurbordinate": none of this would happen if Elon had not criticized their work *very publicly* while at the same time being *very wrong*. Whenever somebody wrongly criticized my work to an audience, I always defended it to the same audience. Instead of proclaiming nonsense from the top of the mountain Elon should have asked privately and internally what the issue was; and then tweeted something like "According to my head of infra, the slowness is caused by ... and we are looking into fixes."
As for employability: hell yes I would absolutely hire these people. Deferring to job titles and the Highest Paid Person in the room (aka the Hippo) is how projects die.
We don't actually know the developer knows what they are talking about, only that they have poor decision making.
"there's lots of unused features" is not a reason code is slow. Code you don't call makes the design messy but doesn't take any cycles.
There are not zero RPC calls, there are lots of API calls going on (presumably REST but could be websockets or something else). The technical distinction is pretty slim at best and the developer would know this.
There's lots of ways of finding out what the real situation is.
One is to say something which may or may not be true - but which sounds inflammatory. Then the idiots come out from cover and show themselves.
What we learned from this exchange is that apparently-senior tech people in Twitter are eejits.
And that the software's rubbish.
Good return on a quick tweet, I'd have thought.
Disagree with the boss. Fine. Do it in private. And do it through proper channels.
Disagree with the boss in public, especially the top boss, yeah you get fired.
This has nothing to do with Twitter, Musk, or anything else. This is just good corporate citizen behavior.
That also get people fired according to latest reports. Elon Musk is a person that can't take any criticism and everything he touches goes bad in the end (when all the people that can do stuff leave him). He's just a different version of Donald Trump. Both are equally awful and bad in their nature. Elon Musk just has a better image creation department (for now).
https://twitter.com/CaseyNewton/status/1592539948745650176
Sorry Marty, I've downvoted you. I agree with the "Do it in private" concept, but when your boss uses a _very_ public medium to castigate you and your colleagues then "good corporate citizen behaviour" has gone out of the window. If the boss has trouble with the staff, the dressing down should be done in private. _THAT_ is good corporate behaviour.
Musk put the developers into a no-win position with his claim (assuming that there was a level of hyperbole). If nobody called him out, then he would probably carry on badmouthing them and telling the world that twitter code sucks. Mud sticks, and all that. So one of them took the brave step of calling him out. Musk's response of sacking the person brave enough to contradict him shows us that he's the world's richest bully.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
