Jeg ser på et stykke kode. Dette kan være den verste koden jeg noen gang har sett. For å oppdatere bare én post i databasen, henter den alle postene i samlingen og sender deretter en oppdateringsforespørsel til hver post i databasen, også de som ikke trenger å oppdateres. Det er en kartfunksjon som ganske enkelt returnerer verdien som er sendt til den. Det er betingede tester for variabler med tilsynelatende samme verdi, bare navngitt i forskjellige stiler (firstName и first_name). For hver OPPDATERING sender koden en melding til en annen kø, som håndteres av en annen serverløs funksjon, men som gjør alt arbeidet for en annen samling i samme database. Nevnte jeg at denne serverløse funksjonen er fra en skybasert "tjenesteorientert arkitektur" som inneholder over 100 funksjoner i miljøet?
Hvordan var det i det hele tatt mulig å gjøre dette? Jeg dekker ansiktet og hulker synlig gjennom latteren min. Kollegene mine spør hva som skjedde, og jeg gjenforteller det i farger Verste treff fra BulkDataImporter.js 2018. Alle nikker sympatisk til meg og er enige: hvordan kunne de gjøre dette mot oss?
Negativitet: et emosjonelt verktøy i en programmererkultur
Negativitet spiller en viktig rolle i programmering. Det er innebygd i vår kultur og brukes til å dele det vi har lært («du gjør det ikke du vil tro det, hvordan var den koden!"), for å uttrykke sympati gjennom frustrasjon ("Gud, HVORFOR gjøre det?"), for å vise seg frem ("Jeg ville aldri så ikke gjorde det"), for å legge skylden på noen andre ("vi mislyktes på grunn av koden hans, som er umulig å opprettholde"), eller, som det er vanlig i de mest "giftige" organisasjonene, å styre andre gjennom en følelse av skam ("Hva tenkte du på?" ? riktig").
Negativitet er så viktig for programmerere fordi det er en veldig effektiv måte å formidle verdi på. Jeg deltok en gang på en programmeringsleir, og standardpraksisen for å innprente en industrikultur hos studenter var å sjenerøst levere memer, historier og videoer, hvorav de mest populære ble utnyttet . Det er godt å kunne bruke følelsesmessige verktøy for å identifisere det gode, det dårlige, det stygge, ikke gjør det, aldri i det hele tatt. Det er nødvendig å forberede nykommere på at de sannsynligvis vil bli misforstått av kolleger som er langt unna IT. At vennene deres vil begynne å selge dem app-ideer for millioner dollar. At de må vandre gjennom endeløse labyrinter av utdatert kode med en haug med minotaurer rundt hjørnet.
Når vi først lærer å programmere, er vår forståelse av dybden av "programmeringsopplevelsen" basert på å observere andre menneskers emosjonelle reaksjoner. Dette kan tydelig ses av innleggene i , hvor mange nybegynnerprogrammerere henger ut. Mange humoristiske er, i en eller annen grad, farget med forskjellige nyanser av negativitet: skuffelse, pessimisme, indignasjon, nedlatenhet og andre. Og hvis dette ikke virker nok for deg, les kommentarene.
Jeg la merke til at etter hvert som programmerere får erfaring, blir de mer og mer negative. Nybegynnere, uvitende om vanskelighetene som venter dem, begynner med entusiasme og en vilje til å tro at årsaken til disse vanskelighetene rett og slett er mangel på erfaring og kunnskap; og til slutt vil de bli konfrontert med tingenes virkelighet.
Tiden går, de får erfaring og blir i stand til å skille god kode fra dårlig. Og når det øyeblikket kommer, føler unge programmerere frustrasjonen over å jobbe med åpenbart dårlig kode. Og hvis de jobber i et team (eksternt eller personlig), adopterer de ofte de følelsesmessige vanene til mer erfarne kolleger. Dette fører ofte til en økning i negativitet, fordi unge mennesker nå kan snakke gjennomtenkt om kode og dele den inn i dårlig og god, og dermed vise at de er «vitende». Dette forsterker det negative ytterligere: av skuffelse er det lett å komme overens med kolleger og bli en del av en gruppe; å kritisere Bad Code øker din status og profesjonalitet i andres øyne: .
Økende negativitet er ikke nødvendigvis en dårlig ting. Diskusjoner om programmering er blant annet ekstremt fokusert på kvaliteten på koden som er skrevet. Hva koden er, definerer helt funksjonen den er ment å gjøre (maskinvare, nettverk osv. til side), så det er viktig å kunne si din mening om den koden. Nesten alle diskusjoner dreier seg om hvorvidt koden er god nok, og å fordømme selve manifestene av dårlig kode i termer hvis emosjonelle konnotasjon karakteriserer kodens kvalitet:
- "Det er mange logiske inkonsekvenser i denne modulen, den er en god kandidat for betydelig ytelsesoptimalisering."
- "Denne modulen er ganske dårlig, vi må refaktorisere den."
- "Denne modulen gir ikke mening, den må skrives om."
- "Denne modulen suger, den må lappes."
- "Dette er et ramstykke, ikke en modul, det trengte ikke å skrives i det hele tatt, hva i helvete tenkte forfatteren på."
Forresten, det er denne "emosjonelle utgivelsen" som får utviklere til å kalle koden "sexy", noe som sjelden er rettferdig - med mindre du jobber på PornHub.
Problemet er at mennesker er rare, rastløse, følelsesmessige skapninger, og oppfatningen og uttrykket av enhver følelse forandrer oss: først subtilt, men over tid, dramatisk.
En urolig glattbakke av negativitet
For noen år siden var jeg en uformell teamleder og intervjuet en utvikler. Vi likte ham veldig godt: han var smart, stilte gode spørsmål, var teknisk kunnskapsrik og passet godt inn i vår kultur. Jeg ble spesielt imponert over hans positivitet og hvor driftig han virket. Og jeg ansatte ham.
På den tiden hadde jeg jobbet i selskapet i et par år og følte at kulturen vår ikke var særlig effektiv. Vi prøvde å lansere produktet to ganger, tre ganger og et par ganger til før jeg kom, noe som førte til store utgifter til etterarbeid, der vi ikke hadde noe å vise til bortsett fra lange netter, stramme tidsfrister og produkter som fungerte. Og selv om jeg fortsatt jobbet hardt, var jeg skeptisk til den siste fristen som ble tildelt oss av ledelsen. Og han sverget tilfeldig når han diskuterte noen aspekter av koden med kollegene mine.
Så det var ikke overraskende – selv om jeg var overrasket – at noen uker senere sa den samme nye utvikleren de samme negative tingene jeg gjorde (inkludert banning). Jeg innså at han ville oppføre seg annerledes i et annet selskap med en annen kultur. Han tilpasset seg kulturen jeg skapte. Jeg ble overveldet av en skyldfølelse. På grunn av min subjektive opplevelse, innpodet jeg pessimisme hos en nykommer som jeg oppfattet som helt annerledes. Selv om han egentlig ikke var sånn og bare stilte opp for å vise at han kunne passe inn, påtvunget jeg ham den dritkule holdningen min. Og alt som er sagt, selv i spøk eller i forbifarten, har den dårlige måten å bli til det man tror.
Negative måter
La oss gå tilbake til våre tidligere nybegynnere programmerere, som har fått litt visdom og erfaring: de har blitt mer kjent med programmeringsindustrien og forstår at dårlig kode er overalt, den kan ikke unngås. Det forekommer selv i de mest avanserte selskapene med fokus på kvalitet (og la meg merke: tilsynelatende beskytter ikke modernitet mot dårlig kode).
Bra manus. Over tid begynner utviklere å akseptere at dårlig kode er en realitet for programvare og at jobben deres er å forbedre den. Og at hvis dårlig kode ikke kan unngås, så er det ingen vits i å lage oppstyr om det. De tar veien til Zen, og fokuserer på å løse problemer eller oppgaver som møter dem. De lærer hvordan de nøyaktig måler og kommuniserer programvarekvalitet til bedriftseiere, skriver velbegrunnede estimater basert på deres mange års erfaring, og mottar til slutt sjenerøse belønninger for deres utrolige og kontinuerlige verdi for virksomheten. De gjør jobben sin så bra at de får utbetalt 10 millioner dollar i bonuser og trekker seg tilbake for å gjøre det de vil resten av livet (vær så snill å ikke ta det for gitt).
Et annet scenario er mørkets vei. I stedet for å akseptere dårlig kode som en uunngåelig, tar utviklere på seg å kalle ut alt som er dårlig i programmeringsverdenen slik at de kan overvinne det. De nekter å forbedre eksisterende dårlig kode av mange gode grunner: "folk burde vite mer og ikke være så dumme"; "det er ubehagelig"; "dette er dårlig for virksomheten"; "dette beviser hvor smart jeg er"; "hvis jeg ikke forteller deg hvilken elendig kode dette er, vil hele selskapet falle i havet," og så videre.
Sikkert ute av stand til å implementere endringene de ønsker fordi virksomheten dessverre må fortsette å utvikle seg og ikke kan bruke tid på å bekymre seg for kvaliteten på koden, får disse menneskene et rykte som klager. De beholdes for sin høye kompetanse, men presses til marginene til selskapet, hvor de ikke vil irritere mange mennesker, men likevel støtte driften av kritiske systemer. Uten tilgang til nye utviklingsmuligheter mister de kompetanse og slutter å møte bransjens krav. Negativiteten deres blir til bitter bitterhet, og som et resultat mater de egoet sitt ved å krangle med tjue år gamle elever om reisen deres gamle favorittteknologi har tatt og hvorfor den fortsatt er så varm. De ender opp med å trekke seg tilbake og leve ut sin alderdom med å banne til fugler.
Virkeligheten ligger sannsynligvis et sted i mellom disse to ytterpunktene.
Noen selskaper har vært ekstremt vellykkede med å skape ekstremt negative, insulære, viljesterke kulturer (som Microsoft før sin ) - ofte er dette selskaper med produkter som passer perfekt til markedet og behovet for å vokse så raskt som mulig; eller selskaper med et hierarki av kommando og kontroll (Apple in the best years of Jobs), der alle gjør det de får beskjed om. Moderne forretningsforskning (og sunn fornuft) tyder imidlertid på at maksimal oppfinnsomhet, som fører til innovativitet i bedrifter, og høy produktivitet hos enkeltpersoner, krever lave nivåer av stress for å støtte pågående kreativ og metodisk tenkning. Og det er ekstremt vanskelig å gjøre kreativt, diskusjonsbasert arbeid hvis du hele tiden bekymrer deg for hva kollegene dine vil ha å si om hver linje i koden din.
Negativitet er konstruksjon av popkultur
I dag rettes det mer oppmerksomhet mot ingeniørers holdning enn noen gang før. I ingeniørorganisasjoner er regelen "". Flere og flere anekdoter og historier dukker opp på Twitter om mennesker som forlot dette yrket fordi de ikke kunne (ville) fortsette å tåle fiendtlighet og dårlig vilje overfor utenforstående. Til og med Linus Torvalds år med fiendtlighet og kritikk mot andre Linux-utviklere - dette har ført til debatt om effektiviteten til denne tilnærmingen.
Noen forsvarer fortsatt Linus sin rett til å være svært kritisk – de som burde vite mye om fordeler og ulemper med «giftig negativitet». Ja, høflighet er ekstremt viktig (til og med grunnleggende), men hvis vi oppsummerer årsakene til at mange av oss lar uttrykk for negative meninger bli til "toksisitet", virker disse grunnene paternalistiske eller ungdommelige: "de fortjener det fordi de er idioter ", "han må være sikker på at de ikke vil gjøre det igjen," "hvis de ikke hadde gjort det, ville han ikke behøve å kjefte på dem," og så videre. Et eksempel på innvirkningen en leders emosjonelle reaksjoner har på et programmeringsfellesskap er Ruby-fellesskapets akronym MINASWAN – «Matz is nice so we are nice».
Jeg har lagt merke til at mange ivrige tilhengere av "kill a fool"-tilnærmingen ofte bryr seg veldig mye om kvaliteten og riktigheten til koden, og identifiserer seg med arbeidet deres. Dessverre forveksler de ofte hardhet med stivhet. Ulempen med denne posisjonen stammer fra det enkle menneskelige, men uproduktive ønsket om å føle seg overlegen andre. Mennesker som blir fordypet i dette begjæret blir sittende fast i mørkets vei.
Programmeringsverdenen vokser raskt og presser seg mot grensene for sin container - verden av ikke-programmering (eller er verden av programmering en container for verden av ikke-programmering? Godt spørsmål).
Ettersom industrien vår ekspanderer i et stadig økende tempo og programmering blir mer tilgjengelig, nærmer avstanden mellom "teknikere" og "normale" raskt. Programmeringsverdenen blir i økende grad utsatt for mellommenneskelige interaksjoner mellom mennesker som vokste opp i den isolerte nerdekulturen fra den tidlige teknologiboomen, og det er de som vil forme den nye programmeringsverdenen. Og uavhengig av sosiale eller generasjonsmessige argumenter, vil effektivitet i kapitalismens navn vise seg i bedriftskultur og ansettelsespraksis: de beste selskapene vil rett og slett ikke ansette noen som ikke kan samhandle nøytralt med andre, enn si ha gode relasjoner.
Hva jeg lærte om negativitet
Hvis du lar for mye negativitet kontrollere sinnet ditt og interaksjoner med mennesker, og blir til toksisitet, så er det farlig for produktteam og dyrt for virksomheten. Jeg har sett (og hørt om) utallige prosjekter som falt fra hverandre og ble fullstendig gjenoppbygd med store kostnader fordi en pålitelig utvikler hadde et nag til teknologien, en annen utvikler, eller til og med en enkelt fil valgt for å representere kvaliteten til hele kodebasen.
Negativitet demoraliserer og ødelegger også forhold. Jeg vil aldri glemme hvordan en kollega skjelte meg ut for å ha lagt CSS i feil fil, det gjorde meg opprørt og tillot meg ikke å samle tankene mine på flere dager. Og i fremtiden vil jeg neppe tillate en slik person å være i nærheten av et av lagene mine (men hvem vet, folk forandrer seg).
Til slutt det negative .
Jeg tror det er slik en mesterklasse om smil skal se ut.
Selvfølgelig er dette ikke et argument for å stråle av lykke, sette inn ti milliarder uttrykksikoner i hver pull-forespørsel, eller gå på en mesterklasse på smil (nei, vel, hvis det er det du vil, så ingen tvil). Negativitet er en ekstremt viktig del av programmering (og menneskeliv), signaliserer kvalitet, lar en uttrykke følelser og medfølelse med medmennesker. Negativitet indikerer innsikt og klokskap, dybden av problemet. Jeg merker ofte at en utvikler har nådd et nytt nivå når han begynner å uttrykke vantro til det han tidligere var redd og usikker på. Folk viser rimelighet og selvtillit med sine meninger. Du kan ikke avfeie uttrykket av negativitet, det ville være orwellsk.
Negativitet må imidlertid doseres og balanseres med andre viktige menneskelige egenskaper: empati, tålmodighet, forståelse og humor. Du kan alltid fortelle en person at han har skrudd opp uten å rope eller banne. Ikke undervurder denne tilnærmingen: Hvis noen forteller deg uten noen følelser at du har rotet til alvorlig, er det virkelig skummelt.
Den gangen, for flere år siden, snakket konsernsjefen med meg. Vi diskuterte den nåværende statusen til prosjektet, så spurte han hvordan jeg hadde det. Jeg svarte at alt var bra, prosjektet beveget seg, vi jobbet sakte, kanskje jeg gikk glipp av noe og måtte revurderes. Han sa at han hadde hørt meg dele mer pessimistiske tanker med kolleger på kontoret, og at andre også hadde lagt merke til dette. Han forklarte at hvis jeg var i tvil, kunne jeg fullt ut uttrykke dem til ledelsen, men ikke «ta dem ned». Som ledende ingeniør må jeg være oppmerksom på hvordan ordene mine påvirker andre fordi jeg har mye innflytelse selv om jeg ikke er klar over det. Og han fortalte meg alt dette veldig vennlig, og sa til slutt at hvis jeg virkelig følte det slik, så må jeg nok tenke på hva jeg vil for meg selv og min karriere. Det var en utrolig mild, få-det-eller-kom-ut-av-setet-samtale. Jeg takket ham for informasjonen om hvordan min endrede holdning over seks måneder påvirket andre ubemerket av meg.
Det var et eksempel på bemerkelsesverdig, effektiv ledelse og kraften i en myk tilnærming. Jeg innså at jeg bare så ut til å ha full tro på selskapet og dets evne til å nå sine mål, men i virkeligheten snakket og kommuniserte jeg med andre på en helt annen måte. Jeg innså også at selv om jeg følte meg skeptisk til prosjektet jeg jobbet med, burde jeg ikke vise følelsene mine til kollegene mine og spre pessimisme som en smittefare, noe som reduserer sjansene våre for å lykkes. I stedet kunne jeg aggressivt formidle den virkelige situasjonen til ledelsen min. Og hvis jeg følte at de ikke hørte på meg, kunne jeg uttrykke min uenighet ved å forlate selskapet.
Jeg fikk en ny mulighet da jeg tiltrådte stillingen som leder for personalvurdering. Som tidligere sjefsingeniør er jeg veldig forsiktig med å uttrykke mine meninger om vår (stadig bedre) arvekode. For å godkjenne en endring må du forestille deg den nåværende situasjonen, men du kommer ingen vei hvis du velter deg i stønn, angrep eller lignende. Til syvende og sist er jeg her for å fullføre en oppgave og bør ikke klage på koden for å forstå den, evaluere den eller fikse den.
Faktisk, jo mer jeg kontrollerer min følelsesmessige reaksjon på koden, jo mer forstår jeg hva den kan bli og jo mindre forvirring føler jeg. Når jeg uttrykte meg selvbehersket ("det må være rom for ytterligere forbedringer her"), gledet jeg meg selv og andre og tok ikke situasjonen for alvorlig. Jeg skjønte at jeg kunne stimulere og redusere negativitet hos andre ved å være perfekt (irriterende?) rimelig ("du har rett, denne koden er ganske dårlig, men vi vil forbedre den"). Jeg er glad for å se hvor langt jeg kan gå på Zen-banen.
I hovedsak lærer og lærer jeg hele tiden en viktig leksjon: livet er for kort til å være konstant sint og ha det vondt.
Kilde: www.habr.com