Als deze smaaktekst werkt voor jouw organisatie, geweldig, maar vind een equivalente smaaktekst die werkt voor jouw organisatie.
david rein
david rein13 mrt, 11:08
"WTBU" is een van de meest nuttige communicatietechnologieën die ik ken. Het staat voor "Watch Team Back-Up", ik geloof dat het is ontstaan om fouten op nucleaire onderzeeërs te verminderen. Je plaatst het voor een bericht aan iemand waarin je iets aanwijst dat misschien voor de hand ligt, maar je wilt controleren/bevestigen dat ze het onder controle hebben. Bijvoorbeeld, je zou kunnen zeggen "WTBU: heb je gecontroleerd dat we toestemming hebben om deze info met XYZ persoon te delen?" Het haalt de druk/ego uit het bericht, door je iets te laten communiceren in de trant van "Ik zeg dit niet omdat ik denk dat je incompetent/dom bent, negeer dit als het niet relevant/nuttig is—ik wil gewoon echt zeker weten dat we geen fouten maken/domme fouten maken, en slimme/competente mensen kunnen domme fouten maken!"—behalve dat zodra je hebt gecoördineerd om de letters WTBU te gebruiken om dat te communiceren, je gewoon "WTBU:" kunt zeggen. Dit stelt je nu in staat om basis/voor de hand liggende dingen veel gemakkelijker en met minder ego/emotie met collega's te controleren, wat het veel gemakkelijker maakt om fouten van tevoren op te vangen. Het is de moeite waard om te overwegen dit in je organisatie als een standaard communicatiewijze aan te nemen!
(Japanse salarismannen ingenieurs zijn doordrenkt van een cultuur van bevestigen bevestigen bevestigen en hoewel het even wennen is, zul je het echt waarderen tijdens alle incidenten die je niet hebt.)
(De andere organisatie-technologie die je daar kunt stelen: als een junior engineer een "domme vraag" stelt, moet de meest senior engineer aanwezig de domme vraag herhalen. Het is geen domme vraag als de senior engineer het heeft, tenslotte.)
(25-jarige: "... Is dat prod?" Senior engineer, snel: "IS DAT PROD.")
(Je zou over het algemeen gereedschappen robuust moeten maken tegen deze fout, maar aangezien veel organisaties dat niet doen of leveranciers gebruiken die het niet gemakkelijk maken, is het probleem hier dat soms commando's die bedoeld zijn om tegen ontwikkelings- of testomgevingen te worden uitgevoerd, tegen de productieomgeving worden uitgevoerd.)
(Bijt elk jaar meer dan een paar organisaties, omdat een 25-jarige het woord "productie" in een terminal ziet en denkt "Dat is vreemd, had niet verwacht om prod in deze procedure aan te raken.")
"Je zou ook gewoon geen hiërarchische cultuur kunnen hebben." Veel succes/vaardigheid voor iedereen met betrekking tot het ontwerpen van organisatiecultuur, maar als men niet in ontkenning is dat men feitelijk een hiërarchische cultuur heeft, kan men processen ontwerpen die rekening houden met dat feit en het positief gebruiken.
Trouwens, begin 2026 hebben we synthetische 25-jarigen op een API-aanroep afstand, maar onze terminals hebben nog niet constant passieve anomaliedetectie, wat _lijkt op een kans_ (en/of een fout).
Terminals zijn verre van de enige plek waar operatorfouten zich constant voordoen. Een andere triviale is e-mailserviceproviders. Het zou 95% minder waarschijnlijk moeten zijn dat er een foutieve massamail wordt verzonden, gezien het vermogen van een LLM om elke aanvraag te beoordelen met een tweet-grootte prompt.
"bob heeft zojuist geprobeerd een bericht van 400 bytes te verzenden naar Alle Klanten Herzien Herzien Definitief [500.000 adressen] met als onderwerp 'TEST: Nieuwe privacybeleid.' Beoordeel in één woord of het Bedoeld of Fout was, bekeken vanuit het perspectief van deze gebruiker."
(Als je niet minstens vijf plaatsen in gedachten hebt waar dit triviaal implementeerbaar is, vraag dan je synthetische 25-jarige om de laatste N jaren van actieverslagen te lezen en een gerangschikte lijst voor te stellen. Of een echte 25-jarige! Ook een goede besteding van tijd.)
(Als je je zorgen maakt over de nauwkeurigheid, zet het dan in advies-/canary-modus en begin met het indienen van actieverslagen of de kanarie heeft gezongen of niet. Over zes maanden zou je overweldigend vertrouwen moeten hebben of het nuttig genoeg is om een mens tijdelijk te blokkeren.)
(Alertmoeheid is een echt probleem, maar dat komt omdat de meeste van onze alarmtools *dom* zijn, omdat we niet van hen vereisten dat ze slim zouden zijn.)
102