HN-reacties zijn onderschat

Ik heb mensen zien terugvechten tegen die houding; wanneer ze onder druk worden gezet, zeggen mensen vaak dat het onmogelijk of inefficiënt is om iemand iets te leren zonder gemeen te zijn, alsof iemand vertellen dat hij stom is, somehow helpt bij het leerproces. Het is alsof mensen hebben geleerd hoe ze dingen moeten uitleggen door naar Simon Cowell te kijken en het concept van een uitleg die niet bezaaid is met persoonlijke beledigingen niet kunnen bevatten. Paul Graham heeft gezegd: "Je zou nooit Hacker News-reacties moeten lezen over iets wat je hebt geschreven." De meeste negatieve dingen die je over HN-reacties hoort, zijn waar.

En toch heb ik geen openbaar internetforum gevonden met betere technische commentaren. Bij onderwerpen waar ik bekend mee ben, is het zeldzaam dat een thread zelfs maar één goed geïnformeerde reactie heeft, maar wanneer die reacties verschijnen, drijven ze meestal naar de top. Op andere forums zijn goed geïnformeerde reacties ofwel afwezig, of worden ze begraven door redelijk klinkende maar totaal onjuiste reacties wanneer ze wél verschijnen; en ze verschijnen daar nog zeldzamer dan op HN.

Qua volume zijn er waarschijnlijk meer interessante technische "posts" in de reacties dan in de links. Dat hangt natuurlijk af van wat je interessant vindt, maar voor mijn interesses is dat waar. Als ik een commentaar over low-level optimalisatie van nkurz zie, een commentaar over business van patio11, of een commentaar over hoe bedrijven opereren van nostrademons, weet ik bijna zeker dat ik een interessant bericht ga lezen. Er zijn misschien 20 tot 30 mensen die ik ken die niet veel bloggen, maar geweldige reacties schrijven op HN, en ik betwijfel of ik zelfs de helft van de mensen ken die geweldige reacties schrijven op HN.

Ik heb een zeer beknopte lijst samengesteld van reacties die ik leuk vind, omdat reacties vaak verloren gaan. Als je een blogpost schrijft, verwijzen mensen daar jaren later nog naar, maar reacties verdwijnen grotendeels. Ik vind dat zonde — er staat veel geweldig materiaal op HN (en ja, nog meer materiaal dat minder geweldig is).

***

Wat is er aan de hand met het bestandsformaat van MS Word?

In feite is het Word-bestandsformaat een binaire dump van het geheugen. Ik maak geen grap. Ze namen gewoon alles wat er in het geheugen stond en schreven dat naar de schijf. We kunnen proberen te beredeneren waarom (misschien was het sneller, misschien maakte het de code kleiner), maar ik denk dat de doorslaggevende reden is dat de oorspronkelijke ontwikkelaars het simpelweg niet beter wisten.

Later, toen ze probeerden functies toe te voegen, moesten ze proberen het achterwaarts compatibel te maken. Hier ligt veel van de complexiteit. Er zijn veel krankzinnige omwegen voor zaken die simpel zouden zijn als je jezelf zou toestaan het bestandsformaat opnieuw te ontwerpen. Het is vrij duidelijk dat dit door het management is opgelegd, want geen enkele softwareontwikkelaar zou zichzelf zonder reden door die hel slepen.

Later voegden ze een 'fast-save' functie toe. Dit voegt wijzigingen toe aan het bestand zonder het oorspronkelijke bestand te wijzigen. De manier waarop ze dit implementeerden was echt vernuftig, maar compliceert de bestandsstructuur enorm.

Eén ding dat ik moet benadrukken, is dat een wederzijdse bestandsconversie bijna onmogelijk is voor tekstverwerkers. Dat komt omdat de bestandsformaten niet genoeg informatie bevatten om het document op te maken. De meest voor de hand liggende plek om dit te zien is de paginering. Het bestandsformaat geeft niet aan waar een tekststroom moet worden gepagineerd (tenzij dit expliciet door de gebruiker is ingevoerd). Het vertrouwt op de formatter om dit te doen. Elke tekstverwerker formateert tekst volledig anders. Word pagineert bijvoorbeeld beroemd incorrecte voetnoten. Ze kunnen dit niet veranderen, want dan zou de achterwaartse compatibiliteit worden doorbroken. Dit is een van de enige redenen waarom Word Perfect vandaag de dag nog overleeft — het is de enige tekstverwerker die juridische documenten pagineert op de manier die het Amerikaanse Ministerie van Justitie vereist.

Alleen al bij het overwegen van het pagineringsprobleem zie je wat het probleem is. Bij het lezen van een Word-document moet je het pagineren zoals Word dat doet — alleen vertelt het bestandsformaat je niet wat dat is. Als iemand vervolgens het document wijzigt en je moet het opnieuw opslaan, moet je somehow markeren dat het gepagineerd moet worden zoals Word (ook al heeft het nu functies die niet in Word zitten). Als het alleen om paginering ging, zou je het misschien kunnen redden, maar praktisch alles is zo geregeld.

Ik raad geïnteresseerden aan om (een deel van) het XML Word-bestandsformaat te lezen. Je zult grote aantallen vlaggen zien voor zaken als "Formateer als Word 95". Het formaat zegt niet wat dat is — omdat het vrij duidelijk is dat de auteurs van het bestandsformaat dat zelf ook niet weten. Het is verloren gegaan in een hopeloze puinhoop van legacy-code en niemand kan nu nog uitvinden wat het precies doet.

***

Plezier met NULL

Hier is een voorbeeld van deze eigenschap:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define LENGTH 128

int main(int argc, char **argv) {
    char *string = NULL;
    int length = 0;
    if (argc > 1) {
        string = argv[1];
        length = strlen(string);
        if (length >= LENGTH) exit(1);
    }
    char buffer[LENGTH];
    memcpy(buffer, string, length);
    buffer[length] = 0;
    if (string == NULL) {
        printf("String is null, so cancel the launch.\n");
    } else {
        printf("String is not null, so launch the missiles!\n");
    }
    printf("string: %s\n", string);  // ongedefinieerd voor null maar werkt in de praktijk
#if SEGFAULT_ON_NULL
    printf("%s\n", string);          // segfaults on null wanneer bare "%s\n"
#endif
    return 0;
}

Uitvoer: nate@skylake:~/src$ clang-3.8 -Wall -O3 nullcheck.c -o nullcheck nate@skylake:~/src$ null_check String is null, so cancel the launch. string: (null)

nate@skylake:~/src$ icc-17 -Wall -O3 nullcheck.c -o nullcheck nate@skylake:~/src$ null_check String is null, so cancel the launch. string: (null)

nate@skylake:~/src$ gcc-5 -Wall -O3 nullcheck.c -o nullcheck nate@skylake:~/src$ null_check String is not null, so launch the missiles! string: (null)

Het lijkt erop dat Intel's ICC en Clang nog steeds niet hebben kunnen bijbenen met de optimalisaties van GCC. Pijnlijk als je op die optimalisatie rekende voor de prestaties die je nodig hebt! Maar voordat we GCC te veel afzeiken, overweeg dat alle drie deze compilers een segfault geven bij printf("string: "); printf("%s\n", string) wanneer string NULL is, ondanks dat ze geen probleem hebben met printf("string: %s\n", string) als één enkele statement. Kun je zien waarom het gebruik van twee aparte statements een segfault zou veroorzaken? Zo niet, kijk dan hier voor een hint: https://gcc.gnu.org/bugzilla/showbug.cgi?id=25609

***

Hoe zorg je ervoor dat de reserve-autopilot oplet?

Goed engineering elimineert zoveel mogelijk de mogelijkheid voor gebruikers om het verkeerde te doen. Je ontwerpt geen functie die uitnodigt tot misbruik om vervolgens instructies te gebruiken om dat misbruik te proberen te voorkomen.

Er was een ontsporing in Australië, de Waterfall-ontsporing. Deze gebeurde omdat de machinist een hartaanval kreeg, wat verantwoordelijk was voor 7 doden (een wonder dat het zo laag was, eerlijk gezegd). De grondoorzaak was het falen van de dode-mans-schakelaar.

In het geval van Waterfall had de machinist twee dode-mans-schakelaars die hij kon gebruiken:

  1. De gashendel moest tegen een veer in een kleine rotatie worden gehouden.
  2. Een balk op de vloer kon worden ingedrukt.

Je moest één van deze dingen doen; het idee was dat je pols- of voetkrampen voorkomt door de machinist te laten afwisselen tussen de twee. Het niet doen van beide activeert een noodrem.

Het bleek dat deze machinist dik genoeg was dat wanneer hij een hartaanval kreeg, zijn been het pedaal genoeg kon indrukken om het noodsysteem uit te schakelen. De dode-mans-installatie werd dus nooit geactiveerd, terwijl er een dode man in de stoel van de machinist zat.

Ik herinner me de details van het systeem bij Waterfall niet precies, maar één methode om dit te bestrijden is om te vereisen dat het pedaal halverwege tussen 'losgelaten' en 'volledig ingedrukt' wordt gehouden. Het idee is dat een slap been het pedaal volledig zou indrukken, wat een rem zou triggeren, en een volledig losgelaten pedaal zou ook een rem triggeren. Ik weet niet of ze dat systeem hadden, maar dat is zeker een benadering die in de spoorwegsector wordt gebruikt.

Hoe dan ook, het probleem is evenzeer mogelijk in auto's. Als je het bewustzijn verliest en je voet slap wordt, kan een zwaar genoeg been het pedaal een beetje ingedrukt houden, afhankelijk van waar het zich bevindt ten opzichte van het pedaal en de hefboomwerking die het heeft op de vloer.

Het andere belangrijke systeem dat ik ken om ervoor te zorgen dat machinisten aan het roer leven, wordt 'vigilance' (waakzaamheid) genoemd. Het werkt als volgt: periodiek begint er een lampje op het dashboard te knipperen en moet de machinist dat bevestigen. Doen ze dat niet, dan gaat er een zoemer af. Als ze het nog steeds niet bevestigen, worden de tremremmen geactiveerd en wordt de machinist als buiten bewustzijn beschouwd.

Laat me je wat verhalen vertellen over mijn betrokkenheid hierbij. Toen we begonnen, hadden we een simpel vigi-systeem. Elke 30 seconden (bijvoorbeeld) moest de machinist op een knop drukken. Dat was prima, behalve dat machinisten zo gewend raakten aan het elke 30 seconden indrukken van de knop, dat we gevallen hadden van machinisten die in slaap vielen/doorzakten en nog steeds precies elke 30 seconden op de knop drukten, omdat het zo diep in hen ingesleten was dat het letterlijk een onbewuste actie was.

Dus introduceerden we waakzaamheid met willekeurige timing, waarbij de tijd varieert tussen 30-60 seconden en je alleen binnen een korte periode kon bevestigen zodra het lampje begon te knipperen. Opnieuw begonnen machinisten in slaap te vallen/half te slapen en drukten ze op de knop zodra de alarmbel ging, elke keer weer.

Daarna introduceerden we waakzaamheid met willekeurige timing die gekoppeld was aan een taak, en dat heeft het probleem eindelijk opgelost. Nu moet de machinist op een knop drukken, of aan een knop draaien, of een aantal verschillende activiteiten uitvoeren, en ze moeten die willekeurig gekozen activiteit op een willekeurig gekozen tijdstip uitvoeren om hun bewustzijn te bevestigen. Pas op dat punt hadden we de alertheid van de machinist echt onder controle.

***

Prestige

Benieuwd waarom hij naar een prestigieuzere positie zou moeten verhuizen? De meeste mensen beseffen tegen hun 30ste dat prestige een spel voor naïvelingen is; het is een manier om mensen ertoe aan te zetten dingen te doen die niet erg leuk zijn en die ze zelf niet echt zouden willen doen, door hen te prijzen met accolades van mensen om wie ze eigenlijk niet geven.

***

Waarom is FedEx gevestigd in Memphis?

We merkten dat we het volgende nodig hadden:

  1. Een geschikte, bestaande luchthaven op de hub-locatie.
  2. Goed weer op de hub-locatie, bijv. relatief weinig sneeuw, mist of regen.
  3. Toegang tot goede platformruimte, waar vliegtuigen geparkeerd en geserviced kunnen worden en pakketten gesorteerd kunnen worden.
  4. Een goed aanbod van arbeidskrachten, bijv. voor het sorteercentrum.
  5. Relatief lage kosten van levensonderhoud om de prijzen laag te houden.
  6. Een vriendelijke regelgevende omgeving.
  7. Een kandidaat-luchthaven die niet te druk is, zodat aankomende vliegtuigen niet te lang hoeven te cirkelen voordat ze kunnen landen.
  8. Een luchthaven met relatief weinig zijwind en met meer dan één landingsbaan om uit te kunnen kiezen in geval van wind.
  9. Een landingsbaanhoogte die niet te hoog is, zodat het maximale totale startgewicht niet wordt beperkt (bijv. Denver uitsluiten).
  10. Geen hoge obstakels, zoals bergen, nabij het einde van de landingsbanen.
  11. Goede voorraden straalkerosine.
  12. Goede toegang tot wegen voor vrachtwagens van 18 wielers voor de uitwisseling van pakketten tussen vrachtwagens en vliegtuigen.

Er waren ongeveer drie kandidaat-locaties: Memphis, Cincinnati en Kansas City. De luchthaven van Memphis had enkele oude WWII-hangars naast de landingsbaan die FedEx kon gebruiken voor het sorteercentrum, vliegtuigonderhoud en het hoofdkantoor. Deal gedaan — het werd Memphis.

***

Waarom Etherpad bij Wave kwam, en waarom het niet werkte zoals verwacht

De beslissing om aan Google te verkopen was een van de zwaarste beslissingen waar ik en mijn mede-oprichters ooit mee worstelden. We waren enthousiast over de visie van Wave, hoewel we de gebreken in het product zagen. Het Wave-team vertelde ons dat ze onze hulp wilden om Wave simpeler te maken en meer als Etherpad, en we dachten dat we daarbij konden helpen, hoewel we uiteindelijk niet succesvol waren in het simpeler maken van Wave. We waren bang voor Google als concurrent: ze hadden meer ingenieurs en meer geld achter dit project, maar ze runden het veel meer als een onafhankelijke startup dan als een normale afdeling van een groot bedrijf. Het Wave-kantoor was in Australië en had bijna totale autonomie. En tot slot, na 1,5 jaar op de rand van het faillissement te hebben gestaan met AppJet, was het verleidelijk om ons avontuur als een succes te kunnen verklaren en een fatsoenlijk rendement te bieden aan al onze investeerders.

Uiteindelijk werkte onze beslissing om bij Wave te komen niet uit zoals we hadden gehoopt. De grootste lessen waren dat meer ingenieurs en geld achter een project eigenlijk schadelijker kan zijn dan behulpzaam, dus we hadden ongelijk dat we bang waren voor Wave als concurrent om die reden. Achteraf gezien lijkt dit overduidelijk, maar op dat moment was dat niet zo. Ten tweede onderschatte ik totaal hoe moeilijk het zou zijn om te itereren op de Wave-codebase. Ik was gewend om grote delen van software in één nacht door te schrijven. Vanwege het softwareontwikkelingsproces dat Wave gebruikte, was het praktisch onmogelijk om op het product te itereren. Ik had meer onderzoek moeten doen naar hun specifieke software-engineering-processen, maar in plaats daarvan nam ik aan dat omdat ze opereerden als een startup, ze ook zouden kunnen itereren als een startup. Veel van de productproblemen waren bekend bij het hele Wave-team, maar we werden gehinderd door een grote, complexe codebase gebouwd op slechte technische keuzes en een omslachtig engineering-proces dat snelle iteratie verhinderde.

***

De nauwkeurigheid van technieuws

Wanneer ik binneninformatie heb gehad over een verhaal dat later in de tech-pers verschijnt, ben ik altijd geschokt door hoe anders het wordt waargenomen door lezers van het artikel versus hoe ik het heb ervaren. Bij startups en grote productlanceringen waar ik deel van uitmaakte, heb ik het volgende gezien:

  • Executives die platweg zeggen dat ze niet aan een productcategorie werken, terwijl er al een jaar een hele afdeling aan gewijd is.
  • Startups die 1,5 jaar vóór de data in Crunchbase/Wikipedia zijn opgericht.
  • Verslaggevers die het aantal mensen tellen dat ze ontmoeten tijdens een bezoek en dat rapporteren als de "teamgrootte", omdat het bedrijf weigert die informatie vrij te geven.
  • Financieringsrondes die nooit in de pers komen.
  • Overnames die worden gerapporteerd als "voor een niet-bekendgesteld bedrag", maar die eigenlijk minder zijn dan wat de oprichters hadden verdiend als ze een betaalde baan bij het bedrijf hadden aangenomen.
  • Startdata van projecten die eigenlijk aangeven wanneer het project bemand werd tot zijn huidige omvang, en het jaar of zo negeren dat een klein team aan het probleem werkte.
  • Algoritmen of andere technologieën die breed worden gerapporteerd als de kern van het succes van het bedrijf, maar die eigenlijk niet eens door het bedrijf worden gebruikt.

***

Zelfvernietigende luidsprekers van Dell

Als hoofdontwikkelaar van VLC kennen we dit verhaal al lang; dit is gewoon Dell die troepcomponenten in hun machines stopt en anderen de schuld geeft. Discussie met hen was onmogelijk. Laat me het uitleggen...

In dit geval gebruikt VLC gewoon de Windows API's (DirectSound) en stuurt 16-bits signed integers (s16) naar de Windows Kernel. VLC staat toe dat de INPUT wordt versterkt boven het geluid dat is gedecodeerd. Dit is net als replay gain, defecte codecs, slecht opgenomen bestanden of post-amplificatie, en kan leiden tot verzadiging.

Maar dit is precies hetzelfde als wanneer je je mp3-bestand door Audacity haalt, het volume verhoogt en het afspeelt met WMP, of als je een DirectShow-filter gebruikt die het volume versterkt na de output van je codec.

In het ergste geval zal dit de dynamiek verminderen en veel verzadigen, maar dit gaat je hardware niet kapot maken. VLC kan het OUTPUT-volume niet wijzigen om de luidsprekers te vernietigen. VLC is software die gebruikmaakt van de OFFICIËLE platform API's.

Het probleem is dat Dell-geluidskaarten een vermogen leveren dat Dell-luidsprekers niet kunnen verwerken. Simpel gezegd: de geluidskaart levert maximaal 10W, en de luidsprekers kunnen slechts 6W aan, en noch hun BIOS noch hun drivers blokkeren dit. En omdat VLC op veel machines aanwezig is, is het makkelijk om VLC de schuld te geven. "Correlatie betekent niet causaliteit" is iets dat te complex lijkt voor de goedkope support van Dell...

***

Leren tijdens het werk: startups versus grote bedrijven

Door voor de startup van iemand anders te werken, leerde ik hoe ik snel oplossingen in elkaar kon knutselen. Ik leerde over onzekerheid en het kiezen van een richting, ongeacht of ik zeker wist dat het zou werken. Ik leerde dat de meeste startups falen, en dat wanneer ze falen, de mensen die uiteindelijk goed terechtkomen degenen zijn die al die tijd voor hun eigen belangen zorgden. Ik leerde veel basis technische vaardigheden, hoe ik snel code kon schrijven, nieuwe API's snel kon leren en software naar meerdere machines kon deployen. Ik leerde hoe snel problemen met het schalen van een developmentteam naar boven komen, en hoe vroeg je moet beginnen met investeren in automatisering.

Door voor Google te werken, leerde ik hoe ik problemen definitief kon oplossen en die cultuur in de organisatie kon inbouwen. Ik leerde dat zelfs in succesvolle bedrijven alles tijdelijk is, en dat geweldige producten meestal worden gebouwd door veel hard werk van veel mensen, in plaats van door grote "aha-inzichten". Ik leerde hoe ik systemen voor schaalbaarheid architectureer, en veel praktijken voor robuuste, high-availability, frequent-deployed systemen. Ik leerde de waarde van onderzoek en van het besteden van veel tijd aan één belangrijk probleem: veel startups gebruiken een hagelschot-benadering, waarbij ze de ene na de andere weekend-hackathon proberen en merken dat niemand er iets aan heeft, terwijl er vaak kansen zijn die niemand heeft opgelost omdat niemand het werk wilde doen. Ik leerde hoe ik in teams moet werken en probeer te begrijpen wat anderen willen. Ik leerde welke problemen echt pijnlijk zijn voor grote organisaties. Ik leerde hoe ik de markt grondig kan onderzoeken en data kan gebruiken om productbeslissingen te nemen, in plaats van beslissingen te baseren op wat voor één persoon het beste lijkt.

***

We hebben deze persoon in de steek gelaten; wat gaan we anders doen?

Ik heb in leidinggevende vergaderingen gezeten waar vertrekken werden genoteerd met een simpele 'regret yes/no' vlag; mijn ervaring was dat geen enkel individueel vertrek effect had. Massale vertrekken hadden effect, trends hadden effect, maar één persoon nooit, zelfs niet als die persoon een oprichter was.

De rationalisaties legden het probleem altijd bij de vertrekkende werknemer: "Ze waren opgebrand", "Ze waren niet meer effectief", "Ze zijn verder gegroeid", "Ze zijn niet meegegroeid met het bedrijf". Het was nooit: "We hebben deze persoon in de steek gelaten, wat gaan we anders doen?"

***

Het oorsprongsverhaal van AWS

Op dat moment was de SOA-inspanning in volle gang. Het was een pijnlijke bedoeling en een puinhoop, omdat elk team dingen anders deed, elke API anders was, gebaseerd was op verschillende aannames en geschreven was in een verschillende taal.

Maar ik wil het misverstand corrigeren dat dit heeft geleid tot AWS. Dat is niet zo. S3 werd door zijn eigen team vanaf nul geschreven. Toen ik bij Amazon werkte aan de retailsite, draaide niets van Amazon.com op AWS. Ik weet dat toen AWS werd aangekondigd, ze zeiden: "de diensten die Amazon.com aandrijven kunnen nu uw bedrijf aandrijven!" Dit was een platte leugen. Het enige wat ze deelden waren datacenters en een standaard hardwareconfiguratie. Zelfs toen ik vertrok, terwijl AWS op volle toeren draaide, draaide niets van Amazon.com op AWS, behalve een paar kleine, experimentele en relatief nieuwe projecten. Ik weet zeker dat meer is overgenomen nu, maar AWS was altijd een apart team (en een beter beheerd team, voor zover ik kon zien).

***

Waarom is Windows zo traag?

Ik (en anderen) hebben veel moeite gedaan om de Linux Chrome-build snel te maken. Voorbeelden hiervan zijn meerdere nieuwe implementaties van het build-systeem, experimenten met de gold linker, en het uitpluizen van bugs en andere ongedocumenteerde zaken zoals 'thin' ar-archieven.

Maar het is ook waar dat mensen die meer Windows-wizards zijn dan ik een Linux-leerling ben, hebben gewerkt aan de Windows-build van Chrome. Als je me de oorspronkelijke vraag stelt, zou ik zeggen dat het onderliggende probleem is dat je op Windows alleen krijgt wat Microsoft je geeft en dat je typisch niet beter kunt doen dan dat. Bijvoorbeeld: het Chrome-buildproces weghalen bij Visual Studio zou een enorme onderneming zijn, groot genoeg dat het zelden wordt overwogen. (Een andere manier om dit te verwoorden is het IDE-probleem: je krijgt de hele IDE of je krijgt niets.)

Wanneer de slechte Windows-prestaties werden aangepakt, kochten mensen eerst SSD's, iets wat mij nooit eens zou zijn occurred ("je systeem heeft genoeg RAM zodat de kernel-cache van het bestandssysteem sowieso in het geheugen zou moeten zitten!"). Maar om welke reden dan ook zagen sommige Googlers aan de Linux-kant het als passend om de Linux-linker te herschrijven om deze twee keer zo snel te maken, en alle Linux-ontwikkelaars profiteren daar nu van. Misschien is het verschil dat wanneer mensen geweldige tools voor Windows of Mac schrijven, ze proberen deze te verkopen in plaats van ze gratis weg te geven.

***

Waarom is Windows zo traag? Een blik van binnenuit

Ik ben een ontwikkelaar bij Windows en draag bij aan de NT-kernel. Windows is inderdaad trager dan andere besturingssystemen in veel scenario's, en het gat wordt groter. De oorzaak van het probleem is sociaal. Er is bijna geen verbetering omwille van de verbetering zelf, voor de eer, zoals je dat in de Linux-wereld ziet.

Toegegeven, af en toe ziet men naïeve mensen die dingen proberen te verbeteren. Deze mensen falen bijna altijd. We kunnen prestaties verbeteren voor specifieke scenario's die mensen met de macht om middelen toe te wijzen geloven dat impact hebben op zakelijke doelen, maar dit werk is Sisyfisch. Er is geen formeel of informeel programma voor systemische prestatieverbetering. We begonnen om veiligheid te geven omdat Windows XP vóór SP3 een existentieel risico vormde voor het bedrijf. Onze lage prestaties zijn geen existentieel risico voor het bedrijf.

Kijk, component-eigenaren zijn over het algemeen openlijk vijandig tegenover externe patches: als je een dev bent, maakt het accepteren van een externe patch je lead boos (vanwege de noodzaak om deze patch te onderhouden), maakt het test boos (omdat test verantwoordelijk is voor het zorgen dat de wijziging niets breekt), en de PM is boos (vanwege de implicaties voor de planning). Er is gewoon geen incentive om wijzigingen van buiten je eigen team te accepteren. Je kunt altijd een reden vinden om "nee" te zeggen, en je hebt zeer weinig incentive om "ja" te zeggen.

***

Wat is de kans op een succesvolle exit per stad?

Zie de link voor de gigantische tabel :-).

***

De wervingscrisis

Een herhaling: startups wijzen waarschijnlijk veel engineering-kandidaten af die net zo goed of beter zouden presteren dan iedereen in hun huidige team, omdat wervingsprocessen in de tech-industrie folkloristisch en irrationeel zijn.

Ik co-manage een consultancy in de valley. We zitten in een zeer gespecialiseerde niche die veel vraagt van software-ontwikkelingsvaardigheden. Een paar jaar geleden zaten we in een crisis. We hebben veel verschillende knoppen omgedraaid om het probleem op te lossen. Een tijdje was Hacker News ons belangrijkste wervingsmiddel. We runden advertenties, gingen naar school-events, en schudden onze netwerken en die van ons team door (door steeds grotere wervingsbonussen aan te bieden).

Inmiddels hebben we dit probleem opgelost. Ik schrijf ons succes toe aan een paar dingen:

  • We creëerden langdurige outreach-events (zoals crypto-challenges) die zo zijn ingericht dat grote aantallen mensen kunnen deelnemen, maar mensen die echt geïnteresseerd zijn zichzelf kunnen selecteren om met ons over een baan te praten.
  • We hebben ons interviewproces volledig herzien met drie hoofddoelen: (1) we communiceren overmatig en "verkopen" onze rollen voordat we selectief worden met kandidaten, (2) we gebruiken kwantificeerbare werkmonsters als het belangrijkste gewogen component bij het selecteren van kandidaten, en (3) we standaardiseren interviews zodat we kunnen volgen wat wel en niet voorspellend is voor succes.

Beide benaderingen hebben zich geloond