Ik kijk naar een stukje code. Dit is misschien wel de slechtste code die ik ooit heb gezien. Om slechts één record in de database bij te werken, haalt het alle records in de verzameling op en verzendt vervolgens een updateverzoek naar elke record in de database, zelfs de records die niet hoeven te worden bijgewerkt. Er is een kaartfunctie die eenvoudigweg de waarde retourneert die eraan wordt doorgegeven. Er zijn voorwaardelijke tests voor variabelen met schijnbaar dezelfde waarde, alleen genoemd in verschillende stijlen (firstName и first_name). Voor elke UPDATE stuurt de code een bericht naar een andere wachtrij, die wordt afgehandeld door een andere serverloze functie, maar die al het werk doet voor een andere collectie in dezelfde database. Had ik al gezegd dat deze serverloze functie afkomstig is van een cloudgebaseerde “servicegerichte architectuur” die meer dan 100 functies in de omgeving bevat?
Hoe was het überhaupt mogelijk om dit te doen? Ik bedek mijn gezicht en snik zichtbaar door mijn lach. Mijn collega's vragen wat er is gebeurd, en ik vertel het opnieuw in kleuren Slechtste hits van BulkDataImporter.js 2018. Iedereen knikt meelevend naar mij en is het er mee eens: hoe kunnen ze ons dit aandoen?
Negativiteit: een emotioneel hulpmiddel in een programmeurscultuur
Negativiteit speelt een belangrijke rol bij programmeren. Het is ingebed in onze cultuur en wordt gebruikt om te delen wat we hebben geleerd (“jij niet je zult het geloven, hoe zag die code eruit!”), om medeleven te uiten door middel van frustratie (“God, WAAROM zou je dat doen?”), om met jezelf te pronken (“Ik zou nooit zo hebben het niet gedaan”), om de schuld op iemand anders te schuiven (“we hebben gefaald vanwege zijn code, die onmogelijk te handhaven is”), of, zoals gebruikelijk is in de meest “giftige” organisaties, om anderen te controleren via een gevoel van schaamte ("Waar dacht je überhaupt aan?"? Correct").
Negativiteit is zo belangrijk voor programmeurs omdat het een zeer effectieve manier is om waarde over te brengen. Ik heb ooit een programmeerkamp bijgewoond, en de standaardpraktijk om studenten een industriecultuur bij te brengen was het genereus aanbieden van memes, verhalen en video's, waarvan de meest populaire werden uitgebuit . Het is goed om emotionele hulpmiddelen te kunnen gebruiken om het goede, het slechte, het lelijke, doe dat niet, helemaal nooit te identificeren. Het is noodzakelijk om nieuwkomers voor te bereiden op het feit dat zij waarschijnlijk verkeerd begrepen zullen worden door collega’s die verre van IT staan. Dat hun vrienden hen app-ideeën voor miljoenen dollars gaan verkopen. Dat ze door eindeloze labyrinten van verouderde code zullen moeten dwalen met een stel minotaurussen om de hoek.
Wanneer we voor het eerst leren programmeren, is ons begrip van de diepte van de 'programmeerervaring' gebaseerd op het observeren van de emotionele reacties van anderen. Dit is duidelijk te zien aan de berichten in , waar veel beginnende programmeurs rondhangen. Veel humoristische films zijn tot op zekere hoogte gekleurd met verschillende tinten negativiteit: teleurstelling, pessimisme, verontwaardiging, neerbuigendheid en andere. En als dit je niet genoeg lijkt, lees dan de reacties.
Ik merkte dat naarmate programmeurs ervaring opdoen, ze steeds negatiever worden. Beginners, die zich niet bewust zijn van de moeilijkheden die hen te wachten staan, beginnen met enthousiasme en de bereidheid te geloven dat de oorzaak van deze moeilijkheden eenvoudigweg een gebrek aan ervaring en kennis is; en uiteindelijk zullen ze geconfronteerd worden met de realiteit der dingen.
De tijd verstrijkt, ze doen ervaring op en kunnen goede code van slechte onderscheiden. En als dat moment aanbreekt, voelen jonge programmeurs de frustratie van het werken met duidelijk slechte code. En als ze in teamverband werken (op afstand of persoonlijk), nemen ze vaak de emotionele gewoonten over van meer ervaren collega’s. Dit leidt vaak tot een toename van de negativiteit, omdat jonge mensen nu nadenkend over code kunnen praten en deze in slecht en goed kunnen verdelen, waardoor ze laten zien dat ze ‘op de hoogte zijn’. Dit versterkt het negatieve nog verder: uit teleurstelling kun je gemakkelijk met collega’s omgaan en deel uitmaken van een groep; het bekritiseren van Bad Code verhoogt je status en professionaliteit in de ogen van anderen: .
Het vergroten van de negativiteit is niet noodzakelijk een slechte zaak. Discussies over programmeren zijn onder andere extreem gericht op de kwaliteit van de geschreven code. Wat de code is, definieert volledig de functie waarvoor deze bedoeld is (hardware, netwerken, enz. daargelaten), dus het is belangrijk dat u uw mening over die code kunt uiten. Bijna alle discussies komen neer op de vraag of de code goed genoeg is, en op het veroordelen van de manifestaties van slechte code in termen waarvan de emotionele connotatie de kwaliteit van de code kenmerkt:
- "Er zitten veel logische inconsistenties in deze module, het is een goede kandidaat voor aanzienlijke prestatie-optimalisatie."
- “Deze module is behoorlijk slecht, we moeten hem refactoren.”
- "Deze module heeft geen zin, hij moet herschreven worden."
- “Deze module is waardeloos, hij moet worden gepatcht.”
- “Dit is een stukje ram, geen module, het hoefde helemaal niet geschreven te worden, wat de auteur in hemelsnaam dacht.”
Het is trouwens deze "emotionele release" die ervoor zorgt dat ontwikkelaars de code "sexy" noemen, wat zelden eerlijk is - tenzij je bij PornHub werkt.
Het probleem is dat mensen vreemde, rusteloze, emotionele wezens zijn, en dat de perceptie en expressie van welke emotie dan ook ons verandert: eerst subtiel, maar na verloop van tijd dramatisch.
Een onrustig hellend vlak van negativiteit
Een paar jaar geleden was ik informeel teamleider en interviewde ik een ontwikkelaar. Wij vonden hem erg leuk: hij was slim, stelde goede vragen, was technisch onderlegd en paste goed bij onze cultuur. Ik was vooral onder de indruk van zijn positiviteit en hoe ondernemend hij overkwam. En ik heb hem aangenomen.
Ik werkte toen al een paar jaar in het bedrijf en vond dat onze cultuur niet erg effectief was. We probeerden het product twee keer, drie keer en nog een paar keer te lanceren voordat ik aankwam, wat leidde tot grote kosten voor herbewerking, waarbij we niets anders te zien hadden dan lange nachten, strakke deadlines en producten die werkten. En hoewel ik nog steeds hard aan het werk was, was ik sceptisch over de laatste deadline die ons door het management was toegewezen. En hij vloekte terloops toen hij bepaalde aspecten van de code met mijn collega's besprak.
Het was dus niet verrassend (hoewel ik wel verrast was) dat diezelfde nieuwe ontwikkelaar een paar weken later dezelfde negatieve dingen zei als ik (inclusief vloeken). Ik besefte dat hij zich in een ander bedrijf met een andere cultuur anders zou gedragen. Hij heeft zich gewoon aangepast aan de cultuur die ik heb gecreëerd. Ik werd overmand door een schuldgevoel. Vanwege mijn subjectieve ervaring heb ik pessimisme bijgebracht bij een nieuwkomer die ik als totaal anders beschouwde. Zelfs als hij echt niet zo was en alleen maar een optreden deed om te laten zien dat hij erbij hoorde, drong ik hem mijn slechte houding op. En alles wat gezegd wordt, zelfs als grap of terloops, heeft de slechte manier om te veranderen in wat men gelooft.
Negatieve manieren
Laten we terugkeren naar onze voormalige nieuwe programmeurs, die wat wijsheid en ervaring hebben opgedaan: ze zijn beter vertrouwd geraakt met de programmeerindustrie en begrijpen dat slechte code overal is en niet kan worden vermeden. Het komt zelfs voor bij de meest geavanceerde bedrijven die zich richten op kwaliteit (en let op: blijkbaar biedt de moderniteit geen bescherming tegen slechte code).
Goed draaiboek. Na verloop van tijd beginnen ontwikkelaars te accepteren dat slechte code een realiteit van software is en dat het hun taak is om deze te verbeteren. En dat als slechte code niet kan worden vermeden, het geen zin heeft om er ophef over te maken. Ze volgen het pad van zen en concentreren zich op het oplossen van problemen of taken waarmee ze worden geconfronteerd. Ze leren hoe ze de kwaliteit van software nauwkeurig kunnen meten en communiceren met bedrijfseigenaren, goed gefundeerde schattingen kunnen schrijven op basis van hun jarenlange ervaring en uiteindelijk royale beloningen ontvangen voor hun ongelooflijke en voortdurende waarde voor het bedrijf. Ze doen hun werk zo goed dat ze $10 miljoen aan bonussen krijgen en met pensioen gaan om de rest van hun leven te doen wat ze willen (beschouw het alsjeblieft niet als vanzelfsprekend).
Een ander scenario is het pad van de duisternis. In plaats van slechte code als iets onvermijdelijks te accepteren, nemen ontwikkelaars het op zich om al het slechte in de programmeerwereld aan te kaarten, zodat ze het kunnen overwinnen. Ze weigeren de bestaande slechte code te verbeteren om vele goede redenen: “mensen zouden meer moeten weten en niet zo dom zijn”; "het is onaangenaam"; “dit is slecht voor het bedrijfsleven”; “dit bewijst hoe slim ik ben”; “Als ik je niet vertel wat voor een waardeloze code dit is, zal het hele bedrijf in de oceaan vallen”, enzovoort.
Deze mensen zijn beslist niet in staat de gewenste veranderingen door te voeren omdat het bedrijf zich helaas moet blijven ontwikkelen en geen tijd kunnen besteden aan het zich zorgen maken over de kwaliteit van de code. Hierdoor krijgen deze mensen een reputatie als klagers. Ze worden behouden vanwege hun hoge competentie, maar worden naar de marges van het bedrijf geduwd, waar ze niet veel mensen zullen irriteren, maar nog steeds de werking van kritieke systemen zullen ondersteunen. Zonder toegang tot nieuwe ontwikkelingsmogelijkheden verliezen ze vaardigheden en voldoen ze niet meer aan de eisen van de industrie. Hun negativiteit verandert in bittere bitterheid, en als gevolg daarvan voeden ze hun ego door met twintigjarige studenten te discussiëren over de reis die hun favoriete oude technologie heeft afgelegd en waarom deze nog steeds zo populair is. Ze gaan uiteindelijk met pensioen en leven hun oude dag uit terwijl ze tegen vogels vloeken.
De realiteit ligt waarschijnlijk ergens tussen deze twee uitersten.
Sommige bedrijven zijn buitengewoon succesvol geweest in het creëren van extreem negatieve, geïsoleerde, wilskrachtige culturen (zoals Microsoft daarvoor). ) – vaak zijn dit bedrijven met producten die perfect aansluiten bij de markt en de behoefte om zo snel mogelijk te groeien; of bedrijven met een hiërarchie van commando en controle (Apple in de beste jaren van Jobs), waar iedereen doet wat hem wordt opgedragen. Modern bedrijfsonderzoek (en gezond verstand) suggereert echter dat maximale vindingrijkheid, die leidt tot innovatiekracht in bedrijven en hoge productiviteit bij individuen, een laag stressniveau vereist om voortdurend creatief en methodisch denken te ondersteunen. En het is buitengewoon moeilijk om creatief, op discussies gebaseerd werk te doen als je je voortdurend zorgen maakt over wat je collega's over elke regel van je code te zeggen zullen hebben.
Negativiteit is de drijvende kracht achter de popcultuur
Tegenwoordig wordt er meer aandacht besteed aan de houding van ingenieurs dan ooit tevoren. In technische organisaties geldt de regel “". Op Twitter verschijnen steeds meer anekdotes en verhalen over mensen die dit beroep hebben verlaten omdat ze de vijandigheid en kwade wil jegens buitenstaanders niet konden (zouden) blijven verdragen. Zelfs Linus Torvalds Jarenlange vijandigheid en kritiek jegens andere Linux-ontwikkelaars - dit heeft geleid tot discussie over de effectiviteit van deze aanpak.
Sommigen verdedigen nog steeds het recht van Linus om zeer kritisch te zijn – degenen die veel moeten weten over de voor- en nadelen van ‘giftige negativiteit’. Ja, beleefdheid is buitengewoon belangrijk (zelfs fundamenteel), maar als we de redenen samenvatten waarom velen van ons toestaan dat het uiten van negatieve meningen in ‘giftigheid’ verandert, lijken deze redenen paternalistisch of puberaal: ‘ze verdienen het omdat ze idioten zijn. ', 'hij moet er zeker van zijn dat ze het niet nog een keer zullen doen', 'als ze dat niet hadden gedaan, hoefde hij niet tegen ze te schreeuwen', enzovoort. Een voorbeeld van de impact die de emotionele reacties van een leider hebben op een programmeergemeenschap is het acroniem MINASWAN van de Ruby-gemeenschap: "Matz is aardig, dus wij zijn aardig."
Ik heb gemerkt dat veel fervente voorstanders van de 'kill a fool'-benadering vaak veel waarde hechten aan de kwaliteit en juistheid van de code, en zichzelf identificeren met hun werk. Helaas verwarren ze hardheid vaak met stijfheid. Het nadeel van deze positie komt voort uit het eenvoudige menselijke, maar onproductieve verlangen om zich superieur aan anderen te voelen. Mensen die ondergedompeld raken in dit verlangen, komen vast te zitten op het pad van de duisternis.
De wereld van het programmeren groeit snel en duwt tegen de grenzen van zijn container – de wereld van het niet-programmeren (of is de wereld van het programmeren een container voor de wereld van het niet-programmeren? Goede vraag).
Terwijl onze industrie zich steeds sneller uitbreidt en programmeren toegankelijker wordt, wordt de afstand tussen ‘techneuten’ en ‘normale mensen’ snel kleiner. De programmeerwereld wordt steeds meer blootgesteld aan de interpersoonlijke interacties van mensen die zijn opgegroeid in de geïsoleerde nerdcultuur van de vroege tech-hausse, en zij zijn het die de nieuwe programmeerwereld vorm zullen geven. En ongeacht sociale of generatieargumenten zal efficiëntie in naam van het kapitalisme tot uiting komen in de bedrijfscultuur en de wervingspraktijken: de beste bedrijven zullen simpelweg niemand aannemen die niet neutraal met anderen kan omgaan, laat staan goede relaties kan hebben.
Wat ik heb geleerd over negativiteit
Als je toestaat dat te veel negativiteit je geest en interacties met mensen beheerst en in toxiciteit verandert, dan is dat gevaarlijk voor productteams en duur voor het bedrijfsleven. Ik heb talloze projecten gezien (en gehoord) die uit elkaar vielen en volledig opnieuw werden opgebouwd tegen hoge kosten omdat een vertrouwde ontwikkelaar wrok koesterde tegen de technologie, een andere ontwikkelaar of zelfs een enkel bestand dat werd gekozen om de kwaliteit van de hele codebase te vertegenwoordigen.
Negativiteit demoraliseert en vernietigt ook relaties. Ik zal nooit vergeten hoe een collega me uitschold omdat ik CSS in het verkeerde bestand had geplaatst, het maakte me van streek en liet me een aantal dagen niet toe om mijn gedachten te ordenen. En in de toekomst is het onwaarschijnlijk dat ik zo iemand in de buurt van een van mijn teams zal laten komen (maar wie weet veranderen mensen).
Tenslotte het negatieve .
Ik denk dat dit is hoe een masterclass over glimlachen eruit zou moeten zien.
Dit is natuurlijk geen argument om te stralen van geluk, tien miljard emoticons in elke pull-request te stoppen, of naar een masterclass over glimlachen te gaan (nee, nou, als je dat wilt, dan is er geen twijfel mogelijk). Negativiteit is een uiterst belangrijk onderdeel van programmeren (en van het menselijk leven), dat kwaliteit aangeeft, waardoor iemand gevoelens kan uiten en medelijden kan hebben met medemensen. Negativiteit duidt op inzicht en voorzichtigheid, de diepte van het probleem. Ik merk vaak dat een ontwikkelaar een nieuw niveau heeft bereikt wanneer hij zijn ongeloof begint te uiten in iets waar hij voorheen timide en onzeker over was. Mensen tonen redelijkheid en vertrouwen met hun mening. Je kunt de uiting van negativiteit niet negeren, dat zou Orwelliaans zijn.
Negativiteit moet echter worden gedoseerd en in evenwicht worden gebracht met andere belangrijke menselijke eigenschappen: empathie, geduld, begrip en humor. Je kunt iemand altijd vertellen dat hij een fout heeft gemaakt, zonder te schreeuwen of te vloeken. Onderschat deze aanpak niet: als iemand je zonder enige emotie vertelt dat je het ernstig hebt verprutst, is dat echt eng.
Die keer, enkele jaren geleden, sprak de CEO met mij. We bespraken de huidige status van het project en vervolgens vroeg hij hoe ik me voelde. Ik antwoordde dat alles in orde was, het project vorderde, we werkten langzaam, misschien heb ik iets gemist en moest het worden heroverwogen. Hij zei dat hij mij meer pessimistische gedachten had horen delen met collega's op kantoor, en dat anderen dit ook hadden opgemerkt. Hij legde uit dat als ik twijfels had, ik deze volledig aan het management kon uiten, maar ze niet ‘weg kon nemen’. Als hoofdingenieur moet ik er rekening mee houden hoe mijn woorden anderen beïnvloeden, omdat ik veel invloed heb, ook al besef ik het niet. En hij vertelde me dit allemaal heel vriendelijk, en zei uiteindelijk dat als ik me echt zo voelde, ik waarschijnlijk moet nadenken over wat ik wil voor mezelf en mijn carrière. Het was een ongelooflijk zachtaardig gesprek, 'kom maar op of kom uit je stoel'. Ik bedankte hem voor de informatie over hoe mijn veranderde houding gedurende zes maanden anderen onopgemerkt beïnvloedde.
Het was een voorbeeld van opmerkelijk, effectief management en de kracht van een zachte aanpak. Ik besefte dat ik alleen het volste vertrouwen leek te hebben in het bedrijf en zijn vermogen om zijn doelstellingen te bereiken, maar dat ik in werkelijkheid op een heel andere manier met anderen sprak en communiceerde. Ik besefte ook dat zelfs als ik sceptisch was over het project waaraan ik werkte, ik mijn gevoelens niet aan mijn collega's moest tonen en pessimisme niet als een besmetting moest verspreiden, waardoor onze kansen op succes kleiner werden. In plaats daarvan kon ik op agressieve wijze de werkelijke situatie aan mijn management overbrengen. En als ik het gevoel had dat ze niet naar mij luisterden, kon ik mijn onenigheid uiten door het bedrijf te verlaten.
Toen ik de functie van hoofd personeelsbeoordeling op mij nam, kreeg ik een nieuwe kans. Als voormalig hoofdingenieur ben ik heel voorzichtig met het uiten van mijn mening over onze (steeds beter wordende) oude code. Om een verandering goed te keuren, moet je je de huidige situatie voorstellen, maar als je je overgeeft aan gezeur, aanvallen en dergelijke kom je nergens. Uiteindelijk ben ik hier om een taak te voltooien en mag ik niet klagen over de code om deze te begrijpen, te evalueren of te repareren.
Hoe meer ik mijn emotionele reactie op de code onder controle houd, hoe beter ik begrijp wat het zou kunnen worden en hoe minder verwarring ik voel. Als ik mij terughoudend uitte (“er moet hier ruimte zijn voor verdere verbetering”), maakte ik mezelf en anderen blij en nam ik de situatie niet al te serieus. Ik besefte dat ik negativiteit bij anderen kon stimuleren en verminderen door volkomen (irritant?) redelijk te zijn (“je hebt gelijk, deze code is behoorlijk slecht, maar we zullen hem verbeteren”). Ik ben blij om te zien hoe ver ik kan gaan op het zenpad.
In wezen leer en leer ik voortdurend een belangrijke les: het leven is te kort om voortdurend boos te zijn en pijn te lijden.
Bron: www.habr.com