Twitter ontslaat onbekend aantal contentmoderators en andere ingehuurde krachten

Socialemediabedrijf Twitter heeft afgelopen weekend een onbekend aantal contentmoderators ontslagen. Dat zijn mensen die niet in dienst zijn van Twitter, maar die Twitter heeft ingehuurd om ongewenste content van zijn platform te houden.

Het gaat mogelijk om duizenden contentmoderators, claimt persbureau AP. Platformer-auteur Casey Newton zegt dat het gaat om ongeveer 4400 van de 5500 ingehuurde mensen. Daarbij zijn de ontslagen niet alleen gevallen in de VS, maar ook daarbuiten. Veel van die mensen werkten aan contentmoderatie, waarbij ze gerapporteerde content bekeken en besloten of die online moest blijven of van het platform moest verdwijnen. Mensen kwamen erachter of ze ontslagen waren, doordat ze geen toegang meer hadden tot hun e-mail of werk-app Slack.

Als het cijfer klopt, is het aantal ontslagen bij ingehuurde krachten hoger dan het aantal ontslagen bij Twitter zelf. Bij die ontslagronde anderhalve week geleden verdwenen 3700 mensen uit het bedrijf. Het bedrijf heeft niet gereageerd op vragen over de ontslagen en heeft geen toelichting gegeven.

Intussen heeft Musk zijn excuses aangeboden aan gebruikers voor de trage werking van de Android-app. Volgens Musk komt dat door de vele remote procedure calls van de app. Daarin werd Musk tegengesproken door een van zijn eigen ontwikkelaars, die zegt dat het aantal rpc's 0 is en dat de traagheid andere oorzaken heeft. Zo zou de app teveel functies hebben en kampen met tech debt.

Reacties (163)

[Chiwn]

Wat is een tech debt ?

[wildhagen]

Dat is een gevolg van het toepassen van quick fixes ipv meer nette en structurele oplossingen, waardoor de code vervuild raakt, en later moeilijker bij te houden is:

In software development, technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

Analogous with monetary debt, if technical debt is not repaid, it can accumulate "interest", making it harder to implement changes. Unaddressed technical debt increases software entropy and cost of further rework. Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g. as a proof-of-concept) is required to move projects forward. On the other hand, some experts claim that the "technical debt" metaphor tends to minimize the ramifications, which results in insufficient prioritization of the necessary work to correct it.

Zie https://en.wikipedia.org/wiki/Technical_debt

[DdeM]

" Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g. as a proof-of-concept) is required to move projects forward."

Maar een PoC is per definitie geen Technical Debt. Probleem is alleen dat ontwikkelaars er vaak voor kiezen om de PoC niet te gebruiken als "Proof on Concept", maar meer als "Productie onder Constructie". Ofwel, ze gebruiken de code van de PoC in de productie code.

En techincal debt is ook altijd slecht, het is alleen niet te voorkomen. Ook we interessant dat die zin in het wiki artikel compleet uit context lijkt te zijn gehaald in verhouding met de bron. En daar in de conclusie wordt dat ook wel duidelijk:

"Originally the debt metaphor meant “You shouldn’t skip this refactoring step any more than you should default on a debt.” But over time, the term has been reinterpreted to mean “system alignment that is deferred to buy time." - https://www.linkedin.com/...risis-part-1-doug-knesek/

[Verwijderd]

"technical debt" is heel simpel uit te leggen: Een product is dan een KipKanarieFant Moloch geworden.

[gorgi_19]

Dat is een bloated stuk software, met veel te veel functies, waarbij het doel / visie van een product is losgelaten en alles wordt toegevoegd "omdat het kan", "iemand dacht dat het handig is" of "omdat iemand het vroeg".

Dat staat los van technical debt, waarbij de staat van de code onderhoud nodig heeft.

[kuurtjes]

Gaat niet alleen over fixes maar vooral over features. Klant wilt een knop voor dit, een knop voor dat, etc...

[Paul C]

Het is het software equivalent van een lekker dineer koken, maar niet de afwas doen. Je kunt prima even de vaat opstapelen in de keuken en snel terug gaan naar je vrienden die aan tafel op je zitten te wachten, maar je moet dat wel een keer opruimen anders kun je niet meer fatsoenlijk werken in de keuken.
Je kunt het best nog een dag uitstellen door meer schoon servies uit de kast te halen en daarna kun je het nog verder uitstellen door een paar dingen af te wassen die je nodig hebt, maar naarmate je keuken een troep wordt begint het koken en afwassen ook minder efficiënt te worden.

Het alternatief is om de boel bij te houden door terwijl je de troep maakt ook meteen op te ruimen. Maar dat kost nu iets meer tijd en als je vrienden op bezoek hebt, dan wil je je tijd nu liever daar besteden en morgen de afwas doen en op de koop toenemen dat het vuil dan aangekoekt en moeilijker schoon te maken is. Maar net als de meeste software ontwikkelaars heb je een druk leven en loop je het risico dat je morgen weer andere nieuwe prioriteiten hebt en het afwassen langer uitstelt... Tot de troep nog verder toeneemt, nog meer aankoekt, uiteindelijk zelfs gaat schimmelen en de hele keuken onbruikbaar wordt om nog eten te bereiden.

Sommige bedrijven laten de technical dept zelfs zover oplopen dat de "keuken" niet meer te redden valt en alleen nog door de hele keuken te vervangen een veilige efficiënte plek voor voedselbereiding gecreëerd kan worden.

[rko4u]

Je gaat hier wel aan voorbij dat je ook zonder de vaat te laten staan tot problemen kan komen omdat bijvoorbeeld ooit de standaard was dat een aanrechtblad de hoogte van een meter had, maar je tweemeter lange kok daardoor op zijn knieen moet om voor je te koken.

[zwartpet]

Veranderende requirements vallen niet echt onder technical dept. De technical dept die er op dat moment al is kan er wel voor zorgen dat die requirements niet kunnen worden doorgevoerd of veel meer tijd in beslag nemen.

[joker1977]

Het is wel wat verwarrend als je dept schrijft - omdat dat een gangbare afkorting is voor department. Ofwel, je schrijft technical department - maar je bedoelde technical debt te schrijven. Dat is 'een schuld'

Normaal ben ik niet zo van de grammar-nazi, maar ik moest je reactie 2x lezen om precies te begrijpen wat je zei.

[markoverklift]

Debt = Schuld.
Dept = Department (afk, Engels)

Echt een enorm goede uitleg van Tech Debt. Kudos en bedankt

[kodak]

Zo zou de app teveel functies hebben en kampen met tech debt.

Zelfs al zou je debt verwarren met de afkorting dept, het is niet logisch dat er zomaar zou staan dat een app last heeft van een afdeling.

[david-v]

Ik denk dat wat @rko4u bedoeld is dat je in de loop der tijd een aanscherping kan krijgen, maar ik zou dat niet onder technical debt willen scharen. Als je vroeger bijvoorbeeld een functie had met 25 regels code was dat prima, tegenwoordig is al meer dan 15 regels code in een functie al niet ok en kan de onderhoudbaarheid van je code daardoor lager scoren. Score voor onderhoudbaarheid code is niet hetzelfde als technical debt.

[Mayonaise]

Veranderende requirements kunnen er ook voor zorgen dat er een tech debt wordt opgebouwd.

Uit eigen ervaring weet ik dat er vaak shortcuts genomen wordt, om de veranderende requirements werkend te krijgen zonder tijd te verspillen aan refactoring.

[rko4u]

Op het moment dat je je systemen moet aanpassen aan een nieuwe versie van je programmeertaal of bijvoorbeeld een nieuw communicatieprotocol. betekent dat een boel technisch onderhoud, niet waardevermeerderheid. Alle systemen die nog op de oude versie draaien kan je dan rekenen (en het gebeurd ook bij veel bedrijven) onder technical debt, terwijl dat niet komt uit nalatigheid, maar uit de voortgang van de tijd.

[Reactie gewijzigd door rko4u op 22 juli 2024 20:57]

[estej]

Beste uitleg die ik tot nu toe heb gehoord! Die ga ik stelen adopteren

[Tweakez]

Best explanation ever!

Waarvoor dank! Deze ga ik van je stelen

[scholtnp]

Zie wikipedia. In spreektaal zou ik zeggen 'achterstallig onderhoud'.

[Keypunchie]

Maar niet alleen een gebrek aan onderhoud.

Het gaat ook om keuzes die je beperken.

Je kiest voor een architectuur met een simpel enkelvoudige database, want “zo veel drukte verwacht je niet”. Een paar jaar later is die database je bottle-neck en kan hij het niet meer aan op piekuren.

En zo kan ‘tech debt’ overal zitten: het niet uitvoeren van onderhoud aan code (dependencies!), het niet implementeren van automatische deployment methodes (“het is weinig werk”), het niet investeren in hardware (“de nieuwe omgeving zal deze binnenkort vervangen”), het niet updaten van de architectuur (“als we tegen een grens aanlopen zien we dan wel weer”).

Tech debt is op zich niet erg, maar je moet hem wel tijdig “terugbetalen”, anders dan loopt het te veel op en dat geeft de echte problemen.

In een volwassen IT omgeving wordt er daarom regelmatig actief maatregelen getroffen om de “schulden” niet te hoog te laten oplopen. Dat betekent wel dat je tijd en geld besteed aan iets dat je niet direct waarde oplevert, wat het zakelijk management altijd vervelend vind, maar het zorgt wel dat de boel goed draait op de lange termijn, met name als de boel “onder druk” komt te staan: een kritieke patch-ronde, een onverwachte piek-belasting, een storing op een kritieke plek.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 20:57]

[OMX2000]

Da's geen technical debt, wat mij betreft. Je hebt requirements en specificaties (oh shit, dit klink very old skool ), en daar maak je een architectuur voor. Als die architectuur na een paar jaar niet meer aansluit bij de nieuwe requirements, zul je de architectuur moeten wijzigen.

Bij technical debt gaat het om vaak om "hacks" om iets zo snel mogelijk te realiseren. Als je dat bewust doet, en ook zorgt dat je de goede oplossing op een backlog zet, hoeft dat niet erg te zijn nee. Dan maak je de keus om de technical debt op te lossen onderdeel van het Agile development proces.

[Keypunchie]

Je hebt requirements en specificaties (oh shit, dit klink very old skool ),

Haha, ik denk dat het hem daar wringt, maar misschien ook wel specifiek is aan de IT waar ik in zit. Die is niet meer old-skool, maar heel erg 'new-skool'.

We zitten in een wereld van 'continuous'. Uiteraard zijn architecturen net iets langer houdbaar dan een pak melk, maar ook op dat vlak zal er doorlopend dingen aangepast moeten worden. Requirements hebben de neiging om een eigen leven te leiden en de requirements van een jaar of 2 terug, zijn niet meer de requirements van vandaag.

Dan maak je de keus om de technical debt op te lossen onderdeel van het Agile development proces.

Helemaal mee eens. Maar dan daar dus ook bovenop dat Agile denken&werken niet alleen iets voor ontwikkelaars is, maar voor iedereen, inclusief architecten,.

[Reactie gewijzigd door Keypunchie op 22 juli 2024 20:57]

[wiseger]

Agile werken voorkomt geen technical debt. De debt zal in de backlog belanden en daar heel lang in blijven zitten.
Het is uiteindelijk een mindset, tech debt moet je inlossen voordat de schuld te groot wordt.

[Keypunchie]

Het voorkomt het niet, maar hopelijk wel dat degene die de backlog beheert (product owner) het de juiste prio’s geeft.

[wiseger]

In de praktijk is dat erg lastig aangezien de product owner vaak dicht tegen de business aan schuurt. Tech debt is vaak lastig uit te leggen, het is om toekomstige problemen en kosten te voorkomen terwijl er in de backlog ook altijd actuele problemen en belangrijke wensen van de business zitten.

Business kansen missen omdat er prio gegeven wordt aan het oplossen van tech debt, het is lastig om dat erdoor te krijgen bij een product owner.

Dus zijn bij Twitter het blauwe vinkje, grijze vinkje belangrijker dan de Android app performance want abo's leveren snel geld op.

[DdeM]

De grap is dat je in een wereld van 'continuous' dus ook continue technical debt wilt opruimen, wat voor mij betekend dat je nieuwe code altijd direct zo netjes mogelijk maakt (enige beperking hierin zou jou kennis moeten zijn) zodra je een werkende oplossing hebt (TDD werkt hier heel goed bij) én dat je eventuele verbeteringen in andere onderdelen van de codebase ook continue doorvoert. Oftewel de "campsite rule" of Opportunistisch Refactoren: https://martinfowler.com/bliki/OpportunisticRefactoring.html

Als je dat doet, en je voor jezelf, of als team, de verbeterpunten die je ziet maar niet direct kan verbeteren bijhoud in een simpel lijstje, hoef je nooit techincal debt op je backlog te zetten. En als er qua architectuur iets veranderd, en je code is in goede staat, is het relatief simpel om je code daarvoor aan te passen.

[DdeM]

"Als je dat bewust doet, en ook zorgt dat je de goede oplossing op een backlog zet, hoeft dat niet erg te zijn nee. Dan maak je de keus om de technical debt op te lossen onderdeel van het Agile development proces."

Hier ben ik het persoonlijk pertinent niet mee eens. Als je bewust Technical Debt inbouwt om iets gevoelsmatig zo snel mogelijk te realiseren, dan ben je in mijn ogen echt op geen enkele manier meer bezig met Agile development, maar dan ben je gewoon aan het rotzooien (en helaas vaak geforceerd door managers die niets snappen van de Agile filosofie).

Echt agile werken betekend dat je altijd je code die je net heb geschreven refactored (makkelikst te doen via TDD), en je codebase in zijn geheel altijd in een iets betere staat achter laat dan dat je begon. Dit betekend uiteraard niet dat je Technical Debt volledig voorkomt, maar wel zeker dat je tot het best van jou kennis de code zo knap mogelijk schrijft en daarmee dus zo min mogelijk Technical Debt introduceerd.

Zo snel mogelijk is dan ook altijd: "Continuous attention to technical excellence and good design enhances agility." - https://agilemanifesto.org/principles.html

[OMX2000]

Ik zeg niet dat je bewust Technical Debt creeert. Maar er zijn gevallen dat je er niet omheen kunt. Misschien heb je op dit moment niet de juiste skills/kennis in huis om iets te realiseren, maar weet je het wel in elkaar te "hacken". Dat bespreek je met je team, en dan kun je het besluit nemen om de oplossing in elkaar te hacken. Maar dan dus wel met een item op je backlog om het te verbeteren zodra je de kennis wel in huis hebt. Maar door iets op een quick & dirty way te realiseren, kun je er ook feedback op krijgen. Want wat misschien wel een van de belangrijkste dingen is binnen Agile development. Zie ook: "Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software."

Niks opleveren levert meestal ook niks op. Een hack opleveren, levert waarschijnlijk business waarde op. Misschien blijkt die hele feature niet nodig geweest te zijn.

Dus leuk dat je Agile manifesto erbij haalt

"Individuals and interactions over processes and tools
Working software over comprehensive documentation"

Die 1e regel vertaal ik als "praten". Communiceer met elkaar, en neem een besluit. Dus in dit geval bespreek je met elkaar of het bewust veroorzaken van Technical Debt wenselijk is. En daar heeft zowel de "business" kant als de developer kant invloed op. Als een ander voorbeeld. Stel dat je door een quick hack bepaalde privacy concerns overtreedt, en het bedrijf heeft privacy hoog in het vaandel. Dan lijkt me niet dat je die hack gaat implementeren, ook niet als je daar achteraf een fix voor kunt implementeren.

De 2e. Zorg dat de software werkt. En je kunt heeeel lang discussiëren over wat "werkende software" inhoudt. Maar je doel is werkende software. Hoe je dat realiseert is door de middelen en kennis die je voor handen hebt, zo goed mogelijk te gebruiken. Ik geloof niet in dogmatisch ergens aan vasthouden. Maar wel dat keuzes die gemaakt worden beargumenteerd zijn en dat je die samen maakt.

Dus als je zegt "echt Agile", tja. Het gaat ook enorm om vertrouwen. De organisatie moet er vertrouwen in hebben dat het team haar werk goed doet. En dat afspraken ook nagekomen worden. Dus je doet wat je zegt, dus vooral door er transparant over te zijn. Als dat vertrouwen er is, dan is "we doen het nu even zo, maar laten we afspreken dat we later de tijd om het goed te doen" helemaal niet gek.

[DdeM]

Bij dat eerste denk ik vooral aan praat met je klant, verwacht niet dat ze alle details in tool als Jira kunnen neerzetten, wil je echt weten wat ze willen, praat met ze, niet alleen tijdens geplande meetings, maar gewoon gedurende de dag. Zorg dat je ten alle tijden een klant (naast eventuele PO!) beschikbaar hebt.

En bij dat tweede denk ik vooral aan besteed niet onnodig veel tijd aan bijvoorbeeld een architectuur plaat, maar zorg dat wat je hebt ook daadwerkelijk doet wat de klant wilt.

Wat betreft wanneer je de kennis/skills niet hebt dan moet je dat zeker met het team en de klant bespreken, wellicht dat iemand anders die kennis wel heeft, of je de juiste richting in stuurt, maar daarbuiten zou je imo ook aan moeten sturen naar leren ipv, maar iets in elkaar hacken, dat levert namelijk, zeker op de langere termijn, veel meer waarde op voor het product.

Daarnaast kan je je afvragen of je, als je door gebrek aan kennis het in mekaar moet 'hacken', het werk niet in kleinere stories kunt knippen.
Een voorbeeld daarvan die er recent zelf heb doorgemaakt is werken met elasticsearch.
De klant had een story op het board gezet voor een overzicht inclusief filters en een full-text search. Nu weet ik zeker dat ik wel in een week iets in elkaar had kunnen trappen wat functioneel had gewerkt, maar wat een draak zou zijn geweest om aan te passen zodra een filter iets anders zou moeten werken of er een extra filter bij zou moeten komen.

Maar door eerst die story in een aantal losse stukken te knippen: een overzicht, een zoekveld en een paar stories met daarin de filters van meest belangrijke naar nice-to-haves, kon de klant stapsgewijs de progressie zien (en feedback geven), konden we aan het eind een aantal filters negeren omdat die toch niet nodig waren (maximize the work not done) en kon de kennis van het systeem stapgewijs groeien waardoor we zowel kwalitatief goede code konden opleveren en we snel business value konden opleveren (alleen een overzicht heeft ook waarde).

Betekend dat dat we geen Technical Debt hadden. Nee, dat hadden we zeker. Maar opzich beperkte zich dat tot een paar functions die nog in een aparte module konden, wat loopjes die we konden encapsulaten en dat soort dingetjes. Maar geen stinkende hoop die je met een 10 meter lange stok nog niet aan durfde te raken.

En wat betreft wat werkende software is. Ik weet dat mensen daar graag over discussiëren, maar de ondertekenaars van het manifest hadden daar een best goed idee over. Werkende software is software welke is getest, doet wat de klant wil en kwalitatief hoogstaand is.
Enige waar ze niet helemaal over uit waren is wat kwaliteit dan weer inhoud

Overigens moet je uiteraard niet dogmatisch ergens aan vast houden, dat zou niet erg agile zijn Maar er zijn wel een aantal zaken waar je naar mijn mening nooit op zou moeten bezuinigen, en kwaliteit is daar 1 van. Uiteindelijk zorgt het altijd weer voor kopzorgen.

[robenroute]

Hoewel tech debt in mijn ogen inderdaad meer inhoudt dan achterstallig onderhoud, duidt jouw voorbeeld eerder op een architectuurkeuze die destijds een juiste was, maar gezien recente ontwikkelingen minder praktisch is nu. Architectuurkeuzes zijn vaak lastig, omdat je naar best practices en common sense ook vaak een kristallen bol nodig hebt…

Tech debt gaat meer over quick & dirty, vaak tegen beter weten in.

[Travelan]

We praten in dat geval dan ook vaak over 'architectural debt'. Zie https://www.sciencedirect...cle/pii/S0164121221000224

[OMX2000]

Precies hoe ik het zou zeggen, ja. Natuurlijk is het veel mooier en uitgebreider te omschrijven, maar in essentie is het achterstallig onderhoud.

Enige wat ik zou willen toevoegen is dat het niet altijd consequenties heeft op de werking van de software. En dat maakt de discussie om het op te lossen altijd zo fijn. “Ja maar het werkt toch gewoon”

[The Zep Man]

Enige wat ik zou willen toevoegen is dat het niet altijd consequenties heeft op de werking van de software. En dat maakt de discussie om het op te lossen altijd zo fijn. “Ja maar het werkt toch gewoon”

Het probleem wanneer software voldoet aan functionele eisen, maar er nooit andere soorten eisen zijn gesteld. Denk aan financieel, organisatorisch, technisch...

[Reactie gewijzigd door The Zep Man op 22 juli 2024 20:57]

[albatross]

Nee, 'achterstallig onderhoud' betekent dat iets in principe voltstaat, maar enkel wat onderhoud behoeft na een aantal jaren. Een huis, bijvoorbeeld. 'Tech debt', daarentegen, zoals keypunchie al aangaf, is alsof ik hier een database zou schrijven die maar 1 query tegelijktijd kan bedienen, voor mijn eenmansbedrijfje, en dan later, als we flink groeien, er opeens achter kom dat een design van 1 query tegelijkertijd hopeloos vast gaat lopen wanneer je de zaak opschaalt. Dat heeft met 'achterstallig onderhoud' niks te maken.

[DdeM]

Maar datje database maar 1 query tegelijkertijd kan bedienen is ook geen Technical Debt wanneer dat voor je eensmansbedrijfje toendertijd voldoende was.

Als het zeer ingewikkeld is om je code uit te breiden om met meer queries om te gaan dan is dat wel een teken van Technical Debt.

[page404]

Technical debt, simpel gezegd verwaarlozing van basaal onderhoud aan je code. Zie het als wel een nieuwe serre aan je huis bouwen (nieuwe features) maar geen onderhoud aan je cv plegen.

[mac1987]

Ik zou het meer vergelijken met je nieuwe huis uit oogpunt van snelheid of kostenbesparing met goedkoop behang afwerken, wetende dat je nog een keer wil stuccen. Hoe meer je aan de muur hangt, hoe lastiger het wordt om dat behang te vervangen.

[Wraldpyk]

En in het extreme geval, de fundering was nog niet af, en isolatiemateriaal was nog niet aangebracht in de muren, maar er is alwel vast gips overheen geplaatst zodat de TV aan de muur kan hangen.

[kftnl]

De andere antwoorden kloppen, maar in de praktijk is het vaak een woord zonder betekenis dat je het beste kunt negeren, zeker in de context van grote tech bedrijven. Iedereen vindt weer iets anders tech debt. Het is beter om over specifieke issues te praten.

Edit: Het idee van technical debt is dus dat je bij een implementatie of wijziging het nu even simpeler doet dan het beste zou zijn. Het kan bijv. zo zijn dat je niet eens weet of je code uberhaupt gebruikt gaat worden of succesvol is. Om alles dan gelijk perfect te doen is niet erg efficient. Dat is dan de 'schuld' die je opbouwt, om het later nog eens goed te kunnen doen en die schuld weer in te lossen. In veel gevallen wordt die schuld nooit ingelost, ook voor razend succesvolle systemen.

Echter is 'technical debt' een soort scheldwoord geworden dat je gebruikt om aan te geven dat je vindt dat het systeem om wat voor reden dan ook niet goed in elkaar zit. Vanuit dat perspectief is het meestal echt beter om te kijken wat er precies bedoeld wordt.

[Reactie gewijzigd door kftnl op 22 juli 2024 20:57]

[jbdeiman]

Ben ik het niet helemaal mee eens, ik vind dat @mac1987 het wel mooi beschrijft eigenlijk:
echnical debt is namelijk niet puur achterstallig onderhoud, maar beschrijft vaak een situatie waarbij (onderandere door achterstallig onderhoud, maar ook door 'hotfixes' snelle oplossingen voor een issue zijn gemaakt) door gemaakte keuzes in het verleden (denk hierbij aan die hotfixes, of snelle oplossingen ergens voor zonder dat dit goed is uitgedacht, tot en met het niet (actief) onderhouden van gebruikte packages, waardoor die jaren oud zijn), waardoor het enorm veel tijd kost om dit alsnog recht te trekken. En daarbij 'werkt het toch' dus de winst voelt heel erg klein.

Ik werk zelf ook bij een softwarebedrijf (wel relatief klein, maar de applicatie is nu 7 jaar in ontwikkeling), ook hier hebben we best last gehad van Technical debt (nog steeds wel, maar dit wordt steeds een beetje opgepakt), waardoor onderhoud onevenredig veel tijd kost. We hebben na 4 jaar (de gebruikte packages, ingeladen code van andere partijen werden niet bijgewerkt) een enorme kluif gehad aan het rechttrekken van de ingeladen packages bijvoorbeeld, omdat dit nooit werd gedaan (achterstallig onderhoud), waarbij je eigenlijk continu rondom dit onderhoud heen aan het werken bent, waarna het onderhoud ineens veel meer tijd kost.

Het is bij veel bedrijven ook echt geen woord zonder betekenis, alleen verschilt hetgeen ontwikkelaars ermee bedoelen nog wel eens, in alle gevallen komt het erop neer dat:
1. Door het niet aan te pakken, het probleem in de toekomst alleen maar groter wordt om het alsnog te doen;
2. Door het niet aan te pakken de werking van de applicatie niet optimaal is en onderhouden en/ of het uitbreiden van de applicatie ervan extra tijd kost t.a.v. wanneer deze technical debt wel was weggewerkt.

[indymaat]

Hoeveel ontwikkelschuld je nog hebt; wat moet ik allemaal nog bouwen en welke bugs moet ik fixen voordat mijn product "af" is

[Repelsteelke]

Tech debt is dat iedere keer dat je gaat klussen in je schuur, je gereedschap niet terug legt en de rommel niet weg gooit. Op een gegeven moment wordt het onmogelijk om normaal te klussen, kost alles meer tijd en is alles steeds zoek

[Netrunner]

Technical Debt, is het prioriteren en ontwikkelen van een makkelijkere oplossing die nu werkt versus extra tijd en rework die je moet investeren om dezelfde oplossing later beter te maken. En dat laatste zou dan hoe dan ook plaats moeten vinden omdat je anders technische achterstand blijft behouden. Right? Dat is wat ik me er van kan herinneren.

[Croga]

En de kaalslag gaat verder....

Meer en meer blijken er slechts 2 mogelijke scenarios te zijn;
Optie 1. Elon Musk heeft altijd tot doel gehad Twitter van de wereldbol te doen verdwijnen.
Optie 2. <understament>Elon Musk is geestelijk niet helemaal in orde. </understament>

Iedereen die ook maar enig idee heeft van IT snapt dat Elon met zijn acties Twitter volledig kapot aan het maken is.
- Developers ontslaan op basis van aantal gecommitte regels code. Ofwel: De kwaliteits/privacy/security developers zijn er onmiddelijk uit gekegeld.
- Enorme druk leggen op ontwikkelaars. Ofwel: Quality/privacy/security be damned, wij willen features!
- Content moderators er uit gooien. Ofwel: ook de kwaliteit/privacy/security van de inhoud boeit niets meer.

En dan hebben we het nog niet over de vinkjes-farce die door deze laatste actie alleen nog maar explosief zal stijgen.

[Reactie gewijzigd door Croga op 22 juli 2024 20:57]

[simplicidad]

Musk heeft altijd kunnen terugvallen op goeie mensen op de achtergrond die de leiding nemen, maar neemt al te graag de credits op zich. Als je echter bij Twitter kijkt wie hij er heeft binnen gehaald dan lijkt het vooral een groepje techbro's

Garandeert ga je nu mensen hebben die gaan wijzen op PayPal, maar vergeet niet dat ze Musk hebben buitengebonjourd toen hij op huwelijksreis was (heette toen nog x.com) en het vooral onder Peter Thiel is dat dit schip is rechtgetrokken.

Als het is op vlak van software tech ben ik nooit echt onder de indruk geweest van Musk. Ik lees (en geloof oprecht) dat het een goeie ingenieur is die veel weet over raketten en wagens, maar dat is toch iets anders dan een software platform.

[dok33]

Zijn projecten zijn vooral software afhankelijk. Die elektrische auto moest zelf rijden, weet je nog? Dat is software. Die raketten moeten tergukeren en op een bootje landen, dat is ook heel veel software. Paypal, software (ook al is dat schip vooral door iemand anders in de haven gebracht, hij werkte er toch echt zelf aan, ooit)

Ok, tunnels boren misschien iets minder software-achtig?

Maar die man bemoeit zich overal mee, dus ook met software.

[CAPSLOCK2000]

Als het is op vlak van software tech ben ik nooit echt onder de indruk geweest van Musk. Ik lees (en geloof oprecht) dat het een goeie ingenieur is die veel weet over raketten en wagens, maar dat is toch iets anders dan een software platform.

Volgens mij dat ook niet, dat is niet zijn achtergrond.
Volgens mij is Elon Musk de Kim Kardashian van de zakenwereld.. Kardashian is bekend omdat ze bekend is. Musk is goed in aandacht scheppen, geld binnen halen en mensen enthousiast maken én er vervolgens goed gebruik van te maken, als is het maar door anderen de uitvoering te laten.
Ik bedoel dat niet kleinerend want hij is er magisch goed in. Deel van de magie is dat hij met veel wegkomt dat anderen de kop zou hebben gekost. Wat dat betreft heeft hij ook wel wat van Trump (ook dit bedoel ik op de meest positieve marnier mogelijk), die weet ook altijd de aandacht vast te houden én af te leiden, desnoods met het volgende schandaal.
Als laatste geloof ik dat hij een goede neus heeft voor welk leuk idee verkoopbaar en uitvoerbaar is (in die volgorde ).

[RogerWilco2]

Ik heb het idee dat Musk vooral goed is in mensen om zich heen verzamelen die kunnen doen wat hij wil. Hij regelt het geld en komt met de grote ideeën.
Daarnaast heb ik het idee dat hij best slim is en graag open en eerlijk en dat ook van de mensen om hem heen vraagt.

Het succes van Tesla en SpaceX kan alleen met een organisatie die heel effectief is in het intern communiceren en zowel goed als slecht nieuws snel en accuraat naar het management krijgen.

Ik denk dat Musk net zoals Steve Jobs een vreselijke vent is, maar in staat is een bedrijfscultuur te creëren die erg effectief is in snel innoveren, zolang de leiding maar een duidelijke visie heeft waar het naar toe moet.

[Genosha]

Hele goede omschrijving van Musk.

[Blokker_1999]

Heel die discussie rondom dat vinkje heeft anders enorm veel problemen veroorzaakt voor Twitter. Ineens had zelfs Jesus een vinkje. En Tesla begon grappen te maken over het ontbranden van hun wagens. Maar wat erger is, is dat ook een hoop bedrijven die hier helemaal niets mee te maken hebben getroffen zijn geweest door heel dat voorval. Er zijn miljarden aan beurswaarde verdwenen voor die bedrijven. Gaat Twitter die aandeelhouders compenseren?

En dan mag je wel zeggen dat mensen niet zomaar alles mogen geloven wat ze op internet zien en wat meer onderzoek zelf zouden moeten doen. Maar daar bestond in het verleden net dat vinkje voor. Dat vinkje dat ineens iedereen kan kopen die even 8 dollar betaalt.

Bedrijven lopen daarom weg van Twitter, gevolgd door adverteerders en als bedrijven en andere grote accounts weglopen omdat het vertrouwen weg is, dan ga je ook minder gebruikers krijgen. En als grote adverteerders weglopen, dan gaat de prijs van advertenties ook omlaag moeten. Je toont minder advertenties en die advertenties die je toont brengen minder op.

En hoe wil je Twitter winstgevend maken? Je moet heel veel vinkjes verkopen om die verliezen goed te maken.

[Milanobrotchen]

En hoe wil je Twitter winstgevend maken?

Veel meer reclames en adverteerders? Misschien deals met de bedrijven die nu aan het weglopen zijn?

[stijn014]

Verdampte beurswaarde is wat Eli Lily en Lockheed Martin zien.

[Iblies]

En dit is nu ineens nieuwswaardig?
https://en.m.wikipedia.org/wiki/Section_230
Platformen zijn niet verantwoordelijk voor de inhoud en hebben alleen een inspanningsplicht als het uit de bocht vliegt (cq wettelijk strafbaar).


Als ze daar in de VS nu ineens anders tegenaan kijken,
terwijl talloze mensen letterlijk vermoord zonder dat dat het artikel veranderd, dan is dat misplaatst sentiment.
nieuws: Facebook-moederbedrijf Meta is door Rohingya gedaagd voor 150 miljard...


Als jij de beurswaarde van een paar aandelen wel prioriteit geeft dan heb je ook de prioriteiten niet helemaal op orde.

[MSalters]

Wat jij beschrijft is vooral dat platformen niet strafbaar handelen als users content plaatsen. Maar als Lockheed Martin en Eli Lilly een civiele zaak aanspannen, dan gaat het over het blauwe vinkje.

Dat faalt dus om twee redenen: de bescherming die 230 biedt in civiele zaken is de bescherming waardoor Twitter gebruikers niet kunnen klagen over redelijke moderatie (maar deze klacht gaat niet over doorgeschoten moderatie), en het beschermt Twitter tegen acties van Twiter gebruikers (maar het vinkje zet Twitter zelf, zonder fatsoenlijke verificatie)

[mjtdevries]

Ook dan een lastige civiele zaak.
Twitter geeft namelijk aan dat het blauwe vinkje tegenwoordig betekent dat iemand een betaalde gebruiker is en niet perse geverifieerd hoef te zijn. Zo staat het op hun website.
In de VS geldt nogal sterk dat wat op papier staat geldig is.

Dan moet een rechter heel erg op je hand zijn om dat in deze situatie te negeren en van het standpunt uit te gaan dat gebruikers niet weten dat de situatie veranderd is. Terwijl dat juist nogal breed in het nieuws is geweest.
En dan nog beschermt 230 inderdaad tegen de tweet zelf. En de tweet is wat de schade veroorzaakt.
En rechters passen 230 bovendien veel breder toe. De kans dat een rechter dan een grote schadevergoeding toewijst op alleen het vinkje lijkt me extreem klein.

[MSalters]

"Wat op papier staat is geldig" is een typische regel in het contractrecht. Het geldt tussen de contractpartijen.

Het probleem hier is dat de "fake" Eli Lilly en Twitter weliswaar een contract hadden, maar de klager is de echte Eli Lilly die z'n beurskoers heeft zien dalen. En dan kan Twitter zich niet verschuilen achter een contract met die fake-news poster.

De advocaat van Twitter zal ongetwijfeld aanvoeren dat de inhoud het probleem was, maar daar heeft Musk zichzelf in de voet geschoten. De nieuwe eis dat het in de handle al duidelijk moet zijn dat het om parodie gaat, maakt duidelijk dat Twitter inmiddels zelf ook beseft dat het blauwe vinkje zonder die mededeling een probleem was.

Een tweede reden waaruit blijkt dat het niet om de specifieke inhoud gaat, is dat het twee bedrijven binnen een paar uur trof (Eli Lilly en Lockheed Martin), waaarbij de inhoud verschilde maar het vinkje de gemeenschappelijke factor was.

Ik vermoed dat de onzekerheid van de rechtzaak reden voor de partijen zal zijn om te schikken, maar dit gaat Twitter sowieso geld kosten.

[hegenious]

Juist ja. Wie herinnert zich nog Radio Mille Collines?
https://en.wikipedia.org/..._Libre_des_Mille_Collines

[Iblies]

Daarom inspanningsplicht maar dan is de schade al geleden.

Twitter heeft de desbetreffende account al afgesloten.

[Neruo]

Ik weet niet of die beursdalingen echt toe te schrijven zijn aan de fake accounts (bijv van Lockheed Martin) die nu blauwe vinkjes hebben. Al is het bizar dat eigenlijk verificatie van accounts nu weg is bij Twitter, leken die berichten me wat overtrokken.

De persoon waar je trouwens dit tegen zei lijkt je opmerking niet te snappen, of te denken dat Twitter naast wat social media ook kruisraketten fabriceert.

[Milanobrotchen]

of te denken dat Twitter naast wat social media ook kruisraketten fabriceert.

Dan zouden ze wel veel geld verdienen als ze wapen handel in gaan

[scholtnp]

- Developers ontslaan op basis van aantal gecommitte regels code.

Dat nieuws heb ik gemist, heb je er een linkje van?

[RefriedNoodle]

Dit is waar het vandaan komt. Is nooit officieel naar buiten gebracht.

Ik weet niet helemaal wat ik ervan moet denken. Het lijkt me zelfs voor Musk te ver gezocht, maar ik kijk helemaal nergens meer van op. Maar het helpt mij niet om vertrouwen in Twitter en het nieuwe management terug te winnen.

[MrMonkE]

Musk is coder.
Hij weet kwantiteit != kwaliteit.

[CAPSLOCK2000]

Musk is coder.
Hij weet kwantiteit != kwaliteit.

Als ik z'n levensverhaal zo lees heeft hij als kind leren programmeren. Als 12 jarige verkocht hij blijkbaar al een spelletje aan een of ander tijdschrift voor 500 dollar. Dat handelen zat er dus ook al vroeg in.

Eerlijk gezegd denk ik dat een betere verklaring voor Musks houding is dat hij nog steeds denkt als programmeur van 12.

Ik kan me helemaal voorstellen dat hij zich een totale programeergod voelde toen hij als kind van twaalf z'n software voor geld kon verkopen, want zo voelde ik me (en mijn verhaal is minder mooi dan dat van Musk). Maar ik kan me ook voorstellen dat zijn gevoel voor IT en programmeren daar een beetje is blijven steken en hij een ouderwets, naief en romantisch beeld heeft van programmeren. Je weet wel, jonge mannen met blikjes energy drink die nacht na nacht doorrausen in een donkere kelder om dan in één keer een meesterwerk op te leveren. Rationeel zal hij vast wel beseffen dat programmeurs ook moeten debuggen, ontwerpen, debuggen, vergaderen, debuggen en debuggen maar van wat afstand gaat het pijnlijk langzaam. (Er is een statistiek/vuistregel/mythe(?) die zegt dat programmeurs op lange termijn 10 regels goede code per dag produceren waarvan er maar één in het uiteindelijke product komt, de rest wordt geschrapt of veranderd). Dat valt nogal tegen als je als hobbyprogrammeur een paar duizend regels code in een weekendje schrijft. En het is niet meer dan menselijk om je eigen gevoelens zwaarder te laten tellen dan de professionele ervaring van een hele afdeling.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 20:57]

[LeonM]

FWIW, Musk heeft ook de eerste versies van Zip2 samen met zijn broer geprogrammeerd. Dit bedrijf is later verkocht voor 305 miljoen aan Compaq. bron.

Om te zeggen dat Musk nog steeds denkt als een programmeur van 12, alleen om hij ooit op 12 jarige leeftijd succesvol geld heet weten te verdienen met het schrijven van games, is echt wel heel kortzichtig. Deze man is CEO (huidig, of geweest) van enkele van de meest succesvolle technologiebedrijven ter wereld (PayPal, SpaceX, Tesla), hij weet heus wel het een en ander van software ontwikkeling.

[CAPSLOCK2000]

FWIW, Musk heeft ook de eerste versies van Zip2 samen met zijn broer geprogrammeerd. Dit bedrijf is later verkocht voor 305 miljoen aan Compaq. bron.

Ik zie eerlijk gezegd niet heel veel software, het wikipedia artikel zegt alleen dat hij twee bestaande databases heeft verbonden. Ik weet werkelijk niet wat Zip2 precies deed, hoeveel software er voor geschreven is en wat de rol van Musk is. Maar behalve dat hij zichzelf heeft leren programmeren zie ik weinig dat er op wijst dat hij zich heeft ontwikkelt als programmeur. Hij heeft in ieder geval geen IT gestudeerd.

Om te zeggen dat Musk nog steeds denkt als een programmeur van 12, alleen om hij ooit op 12 jarige leeftijd succesvol geld heet weten te verdienen met het schrijven van games, is echt wel heel kortzichtig.

Dat is dus ook niet wat ik zeg, je draait het om. Hij gedraagt zich als een arrogante puber die net z'n eerste eigen programma heeft geschreven. Vandaar dat ik zeg dat het er op lijkt dat zijn inzicht op dat vlak een beetje is blijven steken.

Deze man is CEO (huidig, of geweest) van enkele van de meest succesvolle technologiebedrijven ter wereld (PayPal, SpaceX, Tesla), hij weet heus wel het een en ander van software ontwikkeling.

Als ik lees hoe hij met z'n personeel omgaat heb ik daar toch zo m'n twijfels over. Hij is dan ook CEO, niet hoofd developement.

Misschien heb ik het helemaal verkeerd he. Je zal mij niet horen ontkennen dat Musk ontzettend succesvol is en dus een paar dingen erg goed heeft gedaan. Maar de indruk die ik krijg is dat hij (wat dit betreft) vooral goed is in programmeurs helemaal op te branden met een combinatie van beloftes, dreigementen en charisma. Een echte CEO dus. Dat is ook een talent he, maar een ander soort talent.

[LeonM]

Again, FWIW, Musk beschrijft zichzelf als 'lead engineer' bij SpaceX, hij is CTO. Zijn dagelijkse bezigheden daar zijn voornamelijk engineering. Gwynne Shotwell is de directeur van SpaceX, zij is COO en maakt de zakelijke beslissingen. Musk is technisch gezien wel CEO, maar dat is logisch sinds het een private-owned entity is.

[CAPSLOCK2000]

Again, FWIW, Musk beschrijft zichzelf als 'lead engineer' bij SpaceX, hij is CTO. Zijn dagelijkse bezigheden daar zijn voornamelijk engineering. Gwynne Shotwell is de directeur van SpaceX, zij is COO en maakt de zakelijke beslissingen. Musk is technisch gezien wel CEO, maar dat is logisch sinds het een private-owned entity is.

Hij heeft meerdere bedrijven om zich mee te bemoeien. Ik geloof gewoon niet dat hij de tijd heeft om zelf hele dagen achter de tekentafel te zitten. Ik geloof direct dat hij zich met veel dingen bemoeit maar niet dat hij zelf actief ontwerpt. Misschien heb ik het verkeerd hoor, ik ken hem niet persoonlijk en moet het doen met wat in/via de media over hem horen.

[Verwijderd]

Musk is een engineer, dat merk je goed als je hem over technische zaken hoort praten. Zijn management stijl is ook op zijn minst ‘agile’ te noemen (korte sprints). De media maakt veel gedoe over hem vanwege politiek en zijn eigen dommigheid (hij is blijkbaar gewoon mens) maar technisch heeft hij een prima ondergrond. Dat hoor je ook van veel (ex) werknemers. Musk werd laatst nog openbaar beschuldigd dat hij waarschijnlijk ook niets van ‘rocket science’ wist. Daar werd hij wel verdedigt door zijn eigen werknemers.

Hoor over hem wat je wilt. Hij zorgt wel voor snelle resultaten.
Twitter groei is sinds de overname ook nog nooit zo groot geweest, volgens mij.

[CAPSLOCK2000]

Musk is een engineer, dat merk je goed als je hem over technische zaken hoort praten. Zijn management stijl is ook op zijn minst ‘agile’ te noemen (korte sprints). De media maakt veel gedoe over hem vanwege politiek en zijn eigen dommigheid (hij is blijkbaar gewoon mens) maar technisch heeft hij een prima ondergrond. Dat hoor je ook van veel (ex) werknemers. Musk werd laatst nog openbaar beschuldigd dat hij waarschijnlijk ook niets van ‘rocket science’ wist. Daar werd hij wel verdedigt door zijn eigen werknemers.

Hij heeft inderdaad een technische achtergrond en een opleiding in Natuurkunde. Hij weet een hoop van raketten, meer dan mij, maar ik geloof nog steeds niet dat hij actief meewerkt aan het ontwerp. Wel dat hij er genoeg van snapt om z'n mensen te begrijpen en zinnige beslissingen te nemen.
Ik weet niet welke hoek van de natuurkunde hij heeft bestudeerd maar natuurkunde lijkt mij een uitstekende basis als je aan raketten werkt. Maar niet als je aan IT werkt.

Mijn opmerking over "denken als een 12 jarige" programmeur is niet bedoelt om Musk te kleineren. Mijn punt is dat hij niet is opgeleid als IT'er. Ik had ook kunnen zeggen dat hij denkt als een natuurkunde-student. Die leren ook programmeren maar ze leren niks over software design en de rest van het IT-vak.

Ik ben bevooroordeeld maar volgens mij is software development moeilijker dan raketwetenschap.

[Verwijderd]

maar ik geloof nog steeds niet dat hij actief meewerkt aan het ontwerp.
Musk is CEO en CTO (de chief designer titel). Begrijp mij niet verkeerd, ik denk echt niet dat hij heel actief in het design proces mee draait maar maakt wel de grote beslissingen. Als je de interviews met Everyday Astronaut bekijkt dan is het ook niet moeilijk om te zien dat hij wel weet waar hij over praat. Hetzelfde gaat op bij AI day (mijn vakgebied), hij laat zien dat hij in ieder geval genoeg technisch onderlegt is, dat hij geen fouten maakt tijdens vragen (QA) of uitleg van de gebruikte technieken. Met de vraag wanneer ze bijvoorbeeld Dojo (hun supercomputer) gaan gebruiken was het antwoord: 'Wanneer mijn engineers de voorkeur hebben / er zelf voor kiezen om op Dojo te draaien in plaats van de normale GPU clusters'. Dat is een heel goed antwoord, zowel uit een engineering oogpunt als vanuit een management oogpunt. Een gemiddelde manager weet niet wat een GPU of een cluster is. En dit was een open vraag.

Mijn opmerking over "denken als een 12 jarige" programmeur is niet bedoelt om Musk te kleineren. Mijn punt is dat hij niet is opgeleid als IT'er.
Snap ik, maar ik heb ook geen opleiding gehad als IT-er en men beschouwt mij als senior IT consultant
Al mij collega's vroeger (dus dotcom tijdperk) hadden ook geen IT opleiding want die bestond simpelweg niet. Ik moest zelf kiezen voor electronica (waar ik tegenwoordig echt niets meer van weet, haha). Een andere gerespecteerde collega van mij was voorheen tuinman en weer een ander was boekhouder. Ik kijk persoonlijk zelf nooit naar opleiding maar naar enthousiasme en wil-om-te-leren. Zeker gezien het gebrek aan mankracht. Een recente 'stagiere' die met mij op pad ging stond voorheen aan een (niet-IT) productielijn... Ik bemoedig juist zijn moed aan dat hij zo'n sprong durft te nemen. Anyway, Musk zou ik daar niet op beoordelen gezien opleidingen toen vrijwel niet bestonden.

Ik had ook kunnen zeggen dat hij denkt als een natuurkunde-student. Die leren ook programmeren maar ze leren niks over software design en de rest van het IT-vak.
De meest krachtigste medewerkers zijn multidisciplinair. Wat betreft spacex:
One SpaceX engineer, Kevin Brogan, stated “I thought at first that he was challenging me to see if I knew my stuff. Then I realized he was trying to learn things. He would quiz you until he would learn 90% of what you know.”

Ik ben bevooroordeeld maar volgens mij is software development moeilijker dan raketwetenschap.
Haha, dat is geen discussie waar ik mij in ga bemoeien. Ik weet wel dat het allebei heel veel wiskunde omvat en dat Musk veel superslimme mensen om hem heen heeft zoals Gwynne Shotwell die wel een 'Bachelor of Science in mechanical engineering, and later a Master of Science degree in applied mathematics' heeft.

[CAPSLOCK2000]

Mijn opmerking over "denken als een 12 jarige" programmeur is niet bedoelt om Musk te kleineren. Mijn punt is dat hij niet is opgeleid als IT'er.
Snap ik, maar ik heb ook geen opleiding gehad als IT-er en men beschouwt mij als senior IT consultant
Al mij collega's vroeger (dus dotcom tijdperk) hadden ook geen IT opleiding want die bestond simpelweg niet.

Met alle respect voor jou en je achtergrond: dan ben jij misschien ook niet de juiste om dit te beoordelen.

Ik zie grote verschillen tussen mensen die een formele IT-opleiding hebben gehad en mensen die het (alleen) zelf hebben geleerd, en dat pakt typisch in het voordeel uit van mensen met een opleiding. Die snappen de achterliggende wiskunde, methodes en patronen waardoor ze betere keuzes maken. (Dit is uiteraard heel kort door de bocht).

Natuurlijk verwijt ik niemand dat ze geen opleiding hebben gehad die nog niet bestond. Maar uiteindelijk telt het resultaat. Het is toch niet heel gek dat iemand die jarenlang gestudeerd heeft onder begeleiding van professionals anders naar zaken kijkt dan hoe een puber met z'n hobby bezig is?

Al is het maar omdat een opleiding mensen dwingt om zich breed te ontwikkelen op gebieden waar ze zelf niet voor gekozen zouden hebben omdat ze niet eens weet dat ze bestaan. Iets als geamortizeerde big O zullen niet veel mensen als hobby bestuderen.

Voor de duidelijkheid: ik wil het ook niet omdraaien, een opleiding is geen garantie voor kwaliteit en er is ook geen absolute grens tussen mensen met en zonder opleiding. In beide groepen zijn er goeden en slechten.

Maar in de software is er heel veel bagger. De lat ligt heel laag en echt goed ontwikkelde software is uitzonderlijk, niet de standaard. Hoeveel dat met opleiding te maken heeft is moeilijk te zeggen (en wederom, het is geen verwijt, heel veel mensen hebben veel goede dingen gedaan zonder een opleiding) maar dat hele hordes de IT zijn ingerold met niet meer dan minimale opleiding heeft ook een hoop problemen veroorzaakt.

Er was niemand anders dus ik snap dat je dan moet roeien met de riemen die je hebt. Maar als verder alles hetzelfde is heb ik liever iemand met een opleiding dan zonder.

Ik kijk persoonlijk zelf nooit naar opleiding maar naar enthousiasme en wil-om-te-leren.

Dat is inderdaad belangrijker, gebrek aan enthousiasme kun je onmogelijk compenseren met welke opleiding dan ook. Alles is te leren, ook zonder opleiding, maar het zelf leren is typisch niet de meest efficiente methode.

Even over mijzelf: ik ben ook iemand die z'n kennis grotendeels te danken heeft aan zelfstudie en enthousiasme. Tegelijkertijd ben ik heel blij met de opleiding die ik heb gehad omdat het me dingen heeft geleerd die ik nooit zelf zou hebben gedaan, zoals een bak saaie wiskunde. 90% van die opleiding gebruik ik nooit, net als de meesten. Maar het heeft me wel gevormd, al is het maar doordat ik weet dat het bestaat en het kan opzoeken als ik het nodig heb.

Ik heb me ook wel eens afgevraagd of ik die opleiding ooit gehaald had als ik niet al 15 jaar met computers bezig was geweest want, zoals je zei, enthousiasme en inzet zijn noodzakelijk.
Grappig genoeg zit ik ook in de situatie dat de opleiding die ik (achteraf gezien) had willen doen nog niet bestond toen ik ging studeren. Kort na mijn afstuderen heb ik een nieuwe opleiding ontdekte waarvan ik dacht "ja, dat is het helemaal, waarom was dat er nog niet toen ik wilde gaan studeren?" en ik heb tot op de dag van vandaag spijt dat ik geen mogelijkheid heb gevonden om die opleiding ook nog te doen.

Zeker gezien het gebrek aan mankracht.

Dat snap ik maar dat heeft dus niks met kwaliteit te maken. Je accepteert juist mindere kwaliteit.

Anyway, Musk zou ik daar niet op beoordelen gezien opleidingen toen vrijwel niet bestonden.

Ik neem hem niet kwalijk dat hij een andere opleiding heeft gedaan. Ik constateer alleen dat hij hier niet voor is opgeleid. Terzijde: Musk is pas 51. Hij studeerden in de jaren 90, toen had zo'n beetje iedere universiteit al een informatica studie. De uni van Pretoria (waar hij studeerde) had in 1982 al een informatica opleiding.

Nogmaal, het is geen verwijt dat hij iets anders heeft gedaan. Prima. Maar hij is niet opgeleid als informaticus of programmeur en heeft ook geen leven lang gewerkt als programmeur om zo die ervaring op

then I realized he was trying to learn things. He would quiz you until he would learn 90% of what you know.”

Musk lijkt dus ook te vinden dat hij er nog niet genoeg van wist (er evn van uitgaande dat die engineer een software-engineer is).

Ik ben bevooroordeeld maar volgens mij is software development moeilijker dan raketwetenschap.
Haha, dat is geen discussie waar ik mij in ga bemoeien.

Begrijpelijk want het is nogal een statement. Ik kan er een hele middag over volpraten, maar de korte versie is dat software veel minder natuurlijke beperkingen heeft. Een constructiefout in de staartvin van een raket gaat geen invloed hebben op de neus want er is geen contact tussen die twee. Natuurwetten geven een hoop kaders en grenzen die het makkelijk(er) maken om zaken te compartimentaliseren. In software zijn er veel minder beperkingen waardoor er veel meer (potentiele) interacties zijn tussen verschillende delen die niet noodzakelijk iets met elkaar te makne hebben. Interacties tussen onderdelen (vooral onderdelen ontwikkeld door verschillende mensen) zijn de zwakke punten in alle ontwerpen. Software is daarom een wespennest en een van de moeilijkste dingen die mensen doen.

[Yoshi]

het ene sluit het andere niet uit maw er lopen best coders rond die:
* slecht zijn en toch succes hebben
* geen flauw benul hebben dat kwantiteit != kwaliteit


dus je kan dat er niet uit afleiden (en omgekeerd ook niet trouwens). Verder moet je je de vraag stellen of hij hier winst probeert te maken (en ik gok van wel) en dan kan ik me voorstellen dat dat wel degellijk 1 van de metrics is (één van de ;-) )

[Reactie gewijzigd door Yoshi op 22 juli 2024 20:57]

[MrMonkE]

Elke coder met een beetje ervaring heeft wel eens een dag of langer naar een bug gezocht die code wijziging van 1 karakter vereist om op te lossen. Ook wel gehoord van mensen die voornamelijk de code rondschuiven om zo veel mutaties te veroorzaken. Maar tegenwoordig vallen die gasten bij de code review door de mand.

Er zal zeker gekeken zijn naar metrics van de dev/plan/manage systemen. Maar de hoeveelheid regels .. daar geloof ik echt helemaal niets van.

[Navi]

Exact, hij heeft jaren geprogrammeerd van games tot websites dus kan het me niet voorstellen, is volgens mij gewoon bedacht om headlines te halen.

[Blokker_1999]

Het zou mij niet verbazen als het 1 van de metrics was. Je moet je ergens op basseren en op enkele dagen tijd heb je nooit de mogelijkheid om een goede analyse van je personeelsbestand te maken.

[RefriedNoodle]

Eens, maar het is een metric die niks zegt over de kwaliteit van een programmeur.

Programmeur A:

var c = ((a < b) ? 'kleiner' : 'groter');

Programmeur B:

var check = (a < b);
var c;
if (check) {
c = 'kleiner';
} else {
c = 'groter';
}

Is programmeur B dan 7x zo goed als A? Ik zou liever A aannemen...

Sterker nog: als dit de metric wordt waar je baan van af gaat hangen, dan weet ik wat er met de kwaliteit van de code gaat gebeuren...

[Reactie gewijzigd door RefriedNoodle op 22 juli 2024 20:57]

[Genosha]

Hij is een kapitalist met enorme grootheidswaan. En omdat de Amerikaanse (en vele andere) regering afhankelijk van hem zijn geworden voor uitvoering van klimaatdoelen en ruimtevaart heeft Elon eigenlijk geen tegenspraak. Hij is een vrije vogel met idioot veel geld.

[Blokker_1999]

Niemand is afhankelijk van Elon Musk. Als Tesla en SpaceX morgen verdwijnen staan er andere bedrijven klaar om hun plaats in te nemen.

En je ziet ook dat de FCC en SEC hem echt niet zomaar laten doen. Als hij zijn zin had gekregen, had hij Twitter uiteindelijk niet overgenomen. Het was net het uitzicht dat een rechtbank hem toch zou dwingen dat er voor zorgde dat hij het toch gedaan heeft.

[Reactie gewijzigd door Blokker_1999 op 22 juli 2024 20:57]

[gevoelig]

Developers ontslaan op basis van aantal gecommitte regels code. Ofwel: De kwaliteits/privacy/security developers zijn er onmiddelijk uit gekegeld.

Is er serieus op die basis geselecteerd? Heb je een bron?

Edit: ik heb inmiddels antwoord op mijn vraag in een andere reactie zie ik. Bizar als dat waarheid is.

[Reactie gewijzigd door gevoelig op 22 juli 2024 20:57]

[Snowfall]

Is er serieus op die basis geselecteerd? Heb je een bron?

Gebeurt wel vaker hoor. Ik heb weleens als Jr dev gewerkt voor een bedrijf waar je werd ontslagen als je de wekelijkse minimale aantal regels code niet haalde. Applicatie draaide voor geen meter maar iedereen haalde de wekelijkse Quota aan regels

[DdeM]

Dus elke string werd via een stringbuilder één char per keer opgebouwd?

[albatross]

En de kaalslag gaat verder....

Meer en meer blijken er slechts 2 mogelijke scenarios te zijn;
Optie 1. Elon Musk heeft altijd tot doel gehad Twitter van de wereldbol te doen verdwijnen.
Optie 2. <understament>Elon Musk is geestelijk niet helemaal in orde. </understament>

Iedereen die ook maar enig idee heeft van IT snapt dat Elon met zijn acties Twitter volledig kapot aan het maken is.
- Developers ontslaan op basis van aantal gecommitte regels code. Ofwel: De kwaliteits/privacy/security developers zijn er onmiddelijk uit gekegeld.
- Enorme druk leggen op ontwikkelaars. Ofwel: Quality/privacy/security be damned, wij willen features!
- Content moderators er uit gooien. Ofwel: ook de kwaliteit/privacy/security van de inhoud boeit niets meer.

Elon Musk is als 'Henk en Ingrid' die langs de kant staan te roepen, dat als zij aan de macht zouden zijn, dingen veel beter zouden gaan. Totdat dat soort mensen dan een keer echte verantwoordelijkheden krijgen, en langzaam beginnen te beseffen, dat dingen als content-moderatie niet alleen maar werd gedaan om je pesten, of de mond te snoeren, maar gewoon nodig zijn om gevaarlijke excessen tegen te gaan. Alleen is Musk daar nog niet helemaal achter. En tegen de tijd dat ie dat door begint te hebben, heeft ie Twitter waarschijnlijk al kapot gemaakt.

[TerraGuy]

Dat denk ik ook, hij heeft zich verkeken op hoe je zoiets aanpakt. Hopelijk (voor hem iig) komt het toch nog goed op den duur want het is toch best wel veel geld wat erin gegaan is. Echt door de plee spoelen zou hij ook niet willen, en hij heeft in ieder geval bewezen dat hij van bedrijven een succes kan maken; écht dom is hij in ieder geval niet, hoewel niet altijd handig. Maar hee, wie wel..

[Verwijderd]

Onzin. Alle grotere bedrijven zijn naarstig bezig om alle afhandeling middels AI te laten gaan. Er komt bijna geen mens meer kijken bij de meest gerapporteerde content. Tis gewoon een model dat getrained wordt. En af en toe kritisch naar gekeken wordt.

Live feeds is bijv. wel een reden om moderatie (mensen) toe te passen. Bij FB is dat ook niet anders. Ik denk dat Musk gewoon een soort common sense onder het platform wil gaan kweken. Te lang heeft "links" daar de sceptor kunnen zwaaien als je het mij vraagt.

Bedoel heb accounts voor minder offline zien gaan.

[Mirved]

Optie 1. Elon Musk heeft altijd tot doel gehad Twitter van de wereldbol te doen verdwijnen.

Dan zou die de wereld wel een dienst hebben bewezen.

[Ra5a]

Alternatief: Elon Musk Twitill.

Zie: Churchill. Church-ill.

Edit: ik heb een tijdje geleden van iemand , wie ik absoluut vertrouw, gehoord dat Jack Dorsey een geweldige man is, FYI.

[Reactie gewijzigd door Ra5a op 22 juli 2024 20:57]

[Tintel]

Feitelijk doet hij nog niets vreemds. Een grote investeerder neemt bedrijf A over en haalt de bezem er doorheen. Eerst een groot deel van de ingehuurde krachten eruit (want die zijn misschien relatief duur en makkelijk weg te sturen).
Dat hij dan ogenschijnlijk oneerlijke regels toepast om mensen te beoordelen is ook niet nieuw.

Hij wil dat z'n investering geld gaat opleveren - meer niet. De kans bestaat dat hij het kapot maakt maar ja, ook dat is niet nieuw.

Draai het eens om: was niets doen dan wel een goede optie geweest (in zijn ogen)?

[Croga]

Draai het eens om: was niets doen dan wel een goede optie geweest (in zijn ogen)?

Dat is een reductio ad ridiculum. Er zit heel veel tussen niets doen en wat er nu gebeurt. Bijvoorbeeld eerst eens proberen het bedrijf te begrijpen alvorens er lukraak mensen ontslagen worden (waarvan een redelijk deel een week later weer een "Kom alsjeblieft terug" kreeg omdat er een foutje zat in het ontslagalgorithme).

[Tintel]

Mee eens dat er nog wel degelijk nuances zijn maar dat een groot deel eruit zou gaan was wel een beetje onvermijdelijk. Niet dat dit goed is maar niet ongewoon bij overnames.

[WillySis]

Optie 3. Musk heeft een heel ander idee van wat Twitter zou moeten zijn.

Elon Musk heeft een aparte manier van leiding geven aan een bedrijf. Alles moet gaan zoals hij het in zijn hoofd bedacht heeft. Mensen zijn voor hem niet veel anders dan machines die je gewoon van de ene op de ander dag bij het grofvuil kan zetten. Sociale plannen ... onzin. Netjes een ontslagbrief sturen ... niet nodig, men ontdekt het wel als men het gebouw of de server niet in kan.

Er zullen ongetwijfeld weer nieuwe content moderators worden aangenomen, want ook op internet kan men niet zomaar alles roepen. Als Twitter wel alles toestaat en niet helpt bij opsporing wanneer wetten worden overtreden, dan wordt Twitter al snel in steeds meer landen geblokkeerd.

[Croga]

Optie 3. Musk heeft een heel ander idee van wat Twitter zou moeten zijn.

In feite een combinatie van 1 en 2. De manier waarop hij dat andere idee realiteit wil maken zegt dat 2 waar is, de markt gaat vervolgens bepalen of 1 óók waar is (en daar stevent het op dit moment hard op af)

[WillySis]

Hoeft niet, maar kan wel zo uitpakken.

De manier waarop Musk met medewerkers omgaat is natuurlijk in onze ogen absoluut belachelijk (kan in Europa niet eens). De manier en snelheid waarmee hij zijn visie doordrukt maakt dat velen Twitter verlaten. Zijn visie kan best goed zijn, maar door als een wilde olifant in een stampvolle porseleinkast te keer te gaan maakt hij mogelijk zoveel kapot dat Twitter straks niet mees te lijmen is.

[phrank]

Optie 3 is natuurlijk dat jij het helemaal verkeerd ziet en af gaat op allerlei onbevestigde roddels uit je eigen bubbel.

Twitter was al op sterven na dood, deze acties lijken vooral noodzakelijk om het bedrijf gezond te krijgen en weer meer relevantie te geven en veilig te maken voor iedere gebruiker.

[RRRobert]

Mensen kwamen erachter of ze ontslagen waren, doordat ze geen toegang meer hadden tot hun e-mail of werk-app Slack

Lekker geregeld, zoiets. Ben ik blij dat werknemers in dit land toch 'iets' meer rechtsbescherming genieten.

Ik heb in Nederland één keer iets soortgelijk voorbij zien komen, dat een collega die vanwege een conflict al thuis zat, er op eenzelfde manier erachter kwam dat -ie niet meer gewenst was. Mijn toenmalige werkgever heeft daar achteraf bij de rechter flink voor stof moeten happen, want waar ze in aanleg een legitieme reden hadden om deze collega op staande voet te ontslaan, moesten ze nu toch een vaststellingsovereenkomst met transitievergoeding slikken.

[eric.1]

Let wel, dit lijkt te gaan om ingehuurde contractors via een soort uitzendbureau. Die zijn in NL ook niet heel goed beschermd, niet in de zin van baanzekerheid.

[RRRobert]

Ook voor payroll medewerkers, tijdelijke contracten en zelfs uitzendkrachten die een langdurig dienstverband hebben opgebouwd, zijn er regels voor aanzegging van een contractbeëindiging. En er is ook nog zoiets als fatsoen, goed werkgeverschap en de menselijke maat.

[beerse]

Bij ingehuurd personeel zou de bescherming bij het ingehuurde bedrijf liggen. Natuurlijk, als dat ingehuurde bedrijf een zzp-er is houdt het snel op. Veel arbeidscontracten bij uitzendburo's en ook detacheringburo's hebben ook creatieve constructies... En ook de contracten tussen de bedrijven hebben constructies voor afbetalen van plotselinge beëindiging van contracten.

[Tirinium]

Lijkt me dat dit meer gaat om de eis van Musk dat al het personeel op kantoor werkt. De contracters die vanuit huis / ander land werken kunnen dat niet en zijn er dus uitgewerkt.

[Groningerkoek]

Het zou onzin zijn om deze functies allemaal op kantoor te willen hebben, kantoorruimte voor 5.500 mensen is duur, erg duur. Juist dit soort banen leent zich super voor thuiswerken. Denk dat de reden weinig meer of minder is dan bezuinigen op vaste lasten en hij ziet wel of er nog genoeg gemodereerd kan worden om aan de wetgevingen te voldoen.

[Tirinium]

Onzin zeker, werkelijkheid wel degelijk: https://www.msn.com/nl-nl...SIx?ocid=FinanceShimLayer en https://businessam.be/per...n-niet-langer-toegelaten/

[Reactie gewijzigd door Tirinium op 22 juli 2024 20:57]

[Groningerkoek]

Die berichten ken ik, maar het zou onzin zijn om functies als content moderators op kantoor te hebben, daarnaast gaan deze nieuwe ontslagen alleen voor outsourced werkzaamheden.

[Zer0]

Toegang tot systemen intrekken hoeft niet direct te betekenen dat je op staande voet ontslagen bent. Men kan alsnog een gewone ontslagprocedure volgen terwijl je non-actief gezet bent.
Het kan zelfs gebeuren dat je op non-actief gezet wordt als je zelf ontslag neemt.

[RRRobert]

In dit specifieke geval was het zeker niet de intentie van de (oud)collega dat -ie ontslag zou nemen. Hij werkte op dat moment vanuit huis. Toen de werkgever hem sommeerde op het werk te verschijnen (in de wetenschap dat dit niet kon, vanwege de aard van zijn ziekmelding) werd de toegang tot het systeemnetwerk en email voor hem geblokkeerd. Juist dát heeft de rechter later de werkgever zwaar aangerekend.

Laat ik het anders stellen: als je op 150+ FTE zo'n 20 man (m/v/x) langdurig thuis heb zitten vanwege werkgerelateerde problemen, wordt het m.i. toch wel eens tijd dat je als werkgever een keertje in de spiegel kijkt (i.p.v. de schuld bij de bedrijfsarts te leggen, wat ze zonder blikken of blozen naar buiten communiceerden). Ik heb een jaar later daar ook de deur van dat bedrijf voorgoed achter me dicht getrokken, omdat ik ook m'n eigen mentale gezondheid boven het welzijn van de werkgever heb gesteld.

[Zer0]

Juist dát heeft de rechter later de werkgever zwaar aangerekend.

Ik ben erg benieuwd naar de uitspraak in deze zaak, zeker gezien ik regelmatig personeel toegang ontzeg tot bedrijfsresources (meestal tijdelijk om beveiligingsredenen), maar ik vermoed dat het niet het ontzeggen van toegang is geweest waar de rechter zwaar aan trok.

[dok33]

De manier waarop het geschreven is doet me eerder vermoeden dat het sommeren op kantoor te verschijnen niet verenigbaar was met de reden van ziekmelden. En iemand die ziek thuis zit de elektronische toegang ontzeggen is ook niet erg gebruikelijk.

[Reactie gewijzigd door dok33 op 22 juli 2024 20:57]

[RRRobert]

@dok33 @Zer0 Zonder in details te willen treden: precies dit.

[Zer0]

En iemand die ziek thuis zit de elektronische toegang ontzeggen is ook niet erg gebruikelijk.

Waarom niet? Als iemand ziek is heeft hij ook geen toegang nodig

Maar er zal meer aan de hand geweest zijn waar de rechter over viel, niet simpelweg het ontzeggen van toegang tot bedrijfsresources.

[Reactie gewijzigd door Zer0 op 22 juli 2024 20:57]

[beerse]

In Nederland is het gebruikelijk dat er een opzegtermijn is. Dat wil zeggen dat je vandaag verteld kan worden dat je nog 2 maanden moet werken en daarna je baan eindigt. In veel buitenlanden is het dat je vandaag aangezegd wordt dat je baan over 2 maanden eindigt en dat je ook niet meer hoeft te komen werken. Natuurlijk is het per land en per contract verschillend hoe lang die aanzeg-periode is.

Het voordeel van de NL situatie is dat je wel je arbeidsethos kan laten zien en dat je ook netjes je werk kan overdragen en zo. Het voordeel van de andere situatie is dat je 2 maanden de vrijheid hebt om een baan te zoeken en ondertussen nog wel inkomen hebt.

En ja, in Nederland zijn er ook arbeidscontracten waarin staat dat zodra je wordt aangezegd of wanneer je zelf je werk opzegt, dat je werk ook meteen stopt maar dat is meestal alleen/vooral bij werk waarbij je te veel malversaties kan doen.

[Arnoud Engelfriet]

Alleen bij het einde van een tijdelijk contract, toch? Iemand met onbepaalde tijd kun je gewoon niet opzeggen, tenzij je een dossier en een gegronde aanleiding hebt.

[beerse]

Juist alleen bij een contract voor onbepaalde tijd is er wel degelijk een opzegtermijn. Als jij een baan voor onbepaalde tijd hebt (dus tot je pensioen) dan is er juist de opzegtermijn en nog meer andere regels over het hoe en waarom de contracten beëindigd kunnen worden. Een werkgever moet een heel goede reden hebben om je te ontslaan, het kan niet zomaar.

Bij een contract voor bepaalde tijd (dus met een eind datum die vanaf het begin al bekend is, meestal een half jaar tot een paar jaar) is er in de regel geen opzegtermijn maar is het eerder een afkoop regeling om eerder onder het contract uit te komen.

Als je dus voor een nieuwe baan gaat: Met een vast contract heb je vaak een proefperiode, de 2 maanden waarin je zonder nadere mededeling nog kan stoppen. Daarna zit je vast aan de opzegtermijn. Als ze je er na 4 maanden weer uit willen werken kan je dus na 6 maanden al weer op straat staan. Begin je echter met een jaarcontract bij wijze van proefperiode en ze willen na 6 maanden van je af, dan moeten ze het afkopen. Een eerste vuistregel voor een bedrag: De helft van het nog te derven inkomen: de helft van de resterende 6 maanden salaris.

[Reactie gewijzigd door beerse op 22 juli 2024 20:57]

[MSalters]

Nee, dat klopt al een paar jaar niet meer. Dat is onderdeel van het beleid van de overheid om de kloof tussen vast en flex te verkleinen. Bij tijdelijke contracten moet er nu tijdig aangekondigd worden dat er geen nieuw contract komt.

En als we nauwkeurig zijn: de contracten voor bepaalde duur zijn meestal voor een bepaalde tijd, maar elk ander objectief criterium mag ook gebruikt worden. "3 maanden, behalve als we een vervolgorder krijgen, dan is het 6 maanden" is legitiem. Alsnog moet je als werkgever tijdig communiceren over wat de einddatum feitelijk wordt.

[beerse]

Daar heb je gelijk in, dat is aan het eind van een tijdelijk contract. Als er aan het begin staat dat het contract eindigt op een bepaalde datum maar er is zicht op verlenging, dan moet die verlenging ook tijdig worden ingevuld. Vaak is het dan zo dat je 2 of soms 3 keer een tijdelijk contract krijgt en daarna recht heb op of automatische overschakeling naar een vast contract.
Maar er kan ook goed in staan dat het een vast contract is zonder zicht op verlenging. Dat is dan meteen de tijdige aankondiging dat het niet wordt verlengt. Waarbij het ook voorkomt dat er alsnog wel een vervolg contract komt...

[Groningerkoek]

Het niet tijdig opzeggen van een tijdelijk contract maakt de afloop niet ongeldig, maat het zorgt er wel voor dat je geen extra vergoeding hoeft te betalen als werkgever.

[Reactie gewijzigd door Groningerkoek op 22 juli 2024 20:57]

[bgsn]

Zeer blij met de regels van Nederland maar heb ook het gevoel dat bedrijven/start-ups niet zo gauw in Nederland (Europa) willen beginnen omdat er zo veel regels en bescherming is voor de werknemer.

[RRRobert]

Mwah, de centrale ligging, goede infrastructuur en het (relatief) hoge kennisniveau van vreemde talen compenseert nog best veel, lijkt me. Getuige ook het aantal expats in de meeste grote steden.

[page404]

Contentmoderatie is altijd een zwak punt geweest van de socials. Ook op Twitter was de hoeveelheid drek niet te overzien en de moderators waren volgens mij al zwaar overbelast. Nu is er bijna niemand meer die dat enigszins kan reguleren, dus de beerput zal nu wel echt opengaan. Ik merk nu al dat ik nog minder behoefte heb om Twitter te bezoeken. Misschien maar goed ook, voor mijn eigen welzijn. Je krijgt daar niet een positief mensbeeld.

[JeroenNietDoen]

Ik zit voornamelijk op Twitter voor voetbal gerelateerde content (Premier League) maar heel af en toe kom ik wel eens voorbij twitterend Nederland. De hoeveelheid complotmeuk en anti-overheid content, ik schrik daar wel eens van wat voor pus bult zich daar ophoudt.

[P_Tingen]

Sinds kort ben ik ook op Mastodon actief en het is daar een verademing tov Twitter. Het eerste negatieve bericht moet ik daar nog zien. Laatst even getimed hoe lang het duurt bij het openen van Twitter voor ik de eerste schadelijke of negatieve tweet tegenkwam. Het was 42 seconden.

[Maurits van Baerle]

Ik ben nu een jaartje of zo echt actief op Mastodon en nog steeds moet ik zeggen dat het een verademing is. Ook nadat zo'n beetje de halve wereld in de laatste twee weken van Twitter naar Mastodon is verhuisd. Had ik tot een paar weken geleden nog wel mensen die ik miste van Twitter, vooral een paar economen, inmiddels lijkt heel 'EconTwitter' zo'n beetje overgestapt te zijn. Wat ik zo lees is dat ook gebeurd bij Historici, Astronomen en nog een hele reeks andere disciplines.

Toch lijkt, ondanks de toestroom, de sfeer op Mastodon hetzelfde gebleven te zijn. Veel fatsoenlijker en vriendelijker dan Twitter. Ik vermoed dat dat voor een groot deel komt door technische keuzes die bij Mastodon anders gemaakt zijn dan bij Twitter. Bij Twitter leek alles te draaien om zoveel mogelijk tweets te genereren door algoritmes confrontatie te laten opzoeken, mensen tegen elkaar op te zetten etc. Alleen al door geen equivalent van QuoteTweets toe te staan is het veel lastiger om 'Pile-ons' te genereren op Mastodon. Ook is full text search niet mogelijk zodat je wel kunt zoeken op hashtags maar niet op gewone woorden zodat je geen bendes krijgt die op zoek gaan naar iemand die terloops een bepaald woord gebruikt om ze daarna aan te vallen. Verder is de opzet van Likes zodanig dat de hijgerigheid van het najagen van Likes er niet is. En dat is een verademing op zich.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 20:57]

[page404]

Ik zit er historisch gezien (gebruiker van het eerste uur) vooral voor wat meer politieke onderwerpen en dan kom je toch al gauw in de verkeerde bubbel terecht. Wat een domme en nare mensen lopen er toch rond.

[Gepetto]

Een veelgehoorde klacht is juist dat Twitter vooral berichten toont die overeen komen met je eigen mening. Dat jij dus veel complotmeuk ziet, zegt meer iets over jou dus.

[JeroenNietDoen]

Haha

Ik heb juist heel veel personalisatie uitgezet en markeer politieke onderwerpen als "niet interessant". Af en toe via een nieuwsartikel dat ik wel eens wat opzoek Maar je hebt wel een goed punt, want juist die mensen versterken zichzelf door hun bubbel waardoor het lijkt alsof iedereen om je heen zo denkt. Het draagt mijn inziens alleen maar bij aan het versterken van dergelijk gedachtegoed.

[nowaychose]

Het hoeft niet helemaal zijn eigen schuld te zijn.
Twitter admits bias in algorithm for rightwing politicians and news outlets

[kftnl]

Daarin werd Musk tegengesproken door een van zijn eigen ontwikkelaars, die zegt dat het aantal rcp's 0 is

Ik denk dat een mobile developer niet de beste bron is voor hoeveel RPC calls er worden gedaan op de backend. Het lijkt me erg onwaarschijnlijk dat het aantal op de backend 0 is voor een homescreen request, gezien er nogal wat info verzameld moet worden. Twitter heeft ook eigen database systemen, god mag weten hoe dat intern werkt. Een andere developer had het over GraphQL, als je vanuit daar invoer haalt uit API servers is het best denkbaar dat je in potentie een hoop calls genereert.

De developer waarnaar Tweakers refereert heeft het over lang wachten op requests. Dat klinkt alsof er dan aardig wat gebeurt op de achtergrond.

Discussie over wat wel en niet RPC is vind ik zelf niet zo interessant. In mijn mening (en daar zal niet iedereen het mee eens zijn) heb je 3 soorten API's:

- Query talen zoals SQL, JSONAPI en GraphQL queries
- State transfer systemen zoals REST
- Functies aanroepen via het netwerk (RPC)

Veel systemen die developers niet direct aanmerken als RPC zijn dat praktisch gezien wel. Ook zie je in tech bedrijven een hoop interne microservice calls afgewerkt worden via GRPC wat echt ondubbelzinnig RPC is.

[Reactie gewijzigd door kftnl op 22 juli 2024 20:57]

[simplicidad]

Dat daar het probleem ligt is ook tegengesproken door een andere dev op twitter, kan de tweet effe niet terugvinden.

Blijkbaar loopt de frustratie ook hard op bij de achterblijvers en is men niet bang om publiekelijk tegenin Musk te gaan... Leuke sfeer daar blijkbaar bij Twitter.

Had je dan ook nog die andere tweet die is uitgelekt waar een van de managers zich laatdunkend uitliet over wie ze hebben terug moeten halen en liet uitschijnen dat het vooral gaat over kennisoverdracht. Als dat gebeurt, is vliegen ze terug buiten.

[dok33]

Als iemand mij ontslaat, en dan komt vragen of ik even terug wil komen voor kennisoverdracht, dan kunnen ze kiezen tussen een dikke vinger of mijn portemonnee ongelofelijk dik maken. Waarom zou je een bedrijf dat je weg wil hebben nog uit de brand helpen?

[LanTao]

Voor zover ik weet is niemand buiten wat management per direct ontslagen. Dat zou namelijk op veel plekken illegaaal zijn. De meeste ontslagen werknemers lijken in dienst te zijn tot begin januari of februari en kunnen tot die tijd dus verwacht worden om indien gevraagd werkzaamheden te verrichten voor het bedrijf.

Of dat wijs is is een tweede, maar ze worden betaald, en om eerlijk te zijn wordt het hele verhaal tot nog toe gedomineerd door dingen die niet bepaald wijs zijn, dus...

[MSalters]

De meeste werknemers zijn inderdaad gevraagd om in dienst te blijven.

Die werknemers mogen daar best voorwaarden aan verbinden, zoals "vandaag loonsverhoging of ik ben morgen weg". Het gebrek aan opzegtermijn werkt twee kanten op.

En aangezien Musk zich ontzettend in de kaart heeft laten kijken, is z'n onderhandelingspositie in deze zwak. Natuurlijk, als je hele afdeling van 17 man ontslagen is, er één iemand nodig is, en iedereen zou teruggevraagd kunnen worden, dan kun je niet veel eisen. Voor jou 16 anderen. Maar weet Twitter hoe sterk hun onderhandelingspositie uberhaupt is? Als ze een beter idee hadden van benodigde versus beschikbare skills, dan hadden ze niet iedereen ontslagen.

[eric.1]

Blijkbaar loopt de frustratie ook hard op bij de achterblijvers en is men niet bang om publiekelijk tegenin Musk te gaan... Leuke sfeer daar blijkbaar bij Twitter

Achja, de geciteerde Android-ontwikkelaar zoekt ook ander werk...aldus zijn eigen profiel.

Maar goed, wat ik dan wel weer mooi vond is dat hij aangaf dat er 10+ jaar aan tech-debt aanwezig is...bij een bedrijf van amper 16 jaar oud. Heel die ontwikkel-procedures moeten toch wel op de schop, dus ik weet eerlijk gezegd niet of je de kennis zou missen...

[Maurits van Baerle]

Ik denk dat je deze screenshot bedoelt. Volgens mij was dat een interne Slack message. Er is veel uitgelekt via Slack omdat ze vergeten zijn bepaalde kanalen privé te maken.

Maar inderdaad, het lijkt er op dat ze sommige mensen weer even terug wilden halen alleen voor de kennisoverdracht om ze daarna alsnog te ontslaan.

[IStealYourGun]

In principe heeft hij tot 2024 om zijn moderatie op orde te brengen, vanaf dan is de Europese Digital Services Act in voege en zal hij wel moeten zorgen dat haat berichten en geverifieerde fake accounts snel genoeg verdwijnen.

[Croga]

Wettelijk gezien wellicht....
Maar als je als gebruiker met lieslaarzen aan door de digitale drek moet struinen om iets zinnigs te vinden dan zoek je heel snel een ander platform.

[Compuchip87]

"Onbekend aantal."
Vraag me af of ze het zelf wel weten.

"Ja, een paar honderd. Of een paar duizend ofzo. Mijn collega Elon heeft de mailing gedaan. Die weet het ook niet? Hmm"

[Reactie gewijzigd door Compuchip87 op 22 juli 2024 20:57]

[Het.Draakje]

Waarom zouden ze het wel moeten weten binnen Twitter? Het werk is uitbesteed aan externe bedrijven. Het maakt daarna voor Twitter niets uit of het werk door één persoon of een tienduizenden gedaan wordt.

[grizzlywilde]

Hoe kunnen die mensen ontslagen worden zonder bericht en het pas merken als ze niet meer kunnen inloggen? Zijn hier geen regels voor?

[Arnoud Engelfriet]

Het zijn ingehuurde zzp'ers als ik het goed begrijp. Die contracten kun je eenzijdig opzeggen, omdat dat een standaardbepaling is in zulke inhuurcontracten.

Ook als het echt werknemers zijn: de ontslagbescherming in Californië is nul, het is een "at will" state wat inhoudt dat je werkgever je op ieder moment zonder enige reden of aanleiding mag ontslaan. Dit komt vaker voor in dat land.

[MSalters]

"At will" is voor individuele contracten. Massa-ontslag valt onder de Californische "WARN" wet. Dat is een aangescherpte variant van de federale wet, waardoor er een aantal loopholes ontbreken. Het doorbetalen van de medewerkers is vermoedelijk noodzakelijk vanwege deze wet.

[jip_86]

Uit de bron:

Contractors did a number of jobs to help keep Twitter running, including engineering and marketing

Het hoeft dus niet alleen maar content moderatie te zijn. Eerder zei Yoel Roth ook al dat het bij hen eerder 15% was dan de 50% in de rest van het bedrijf.

[Reactie gewijzigd door jip_86 op 22 juli 2024 20:57]

[Dj Neo Ziggy]

Voor diegene die niet weten wat tech debt is:

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.