Jeg kigger på et stykke kode. Dette kan være den værste kode, jeg nogensinde har set. For kun at opdatere én post i databasen, henter den alle posterne i samlingen og sender derefter en opdateringsanmodning til hver post i databasen, også dem, der ikke skal opdateres. Der er en kortfunktion, der blot returnerer den værdi, der er sendt til den. Der er betingede tests for variabler med tilsyneladende den samme værdi, blot navngivet i forskellige stilarter (firstName и first_name). For hver OPDATERING sender koden en besked til en anden kø, som håndteres af en anden serverløs funktion, men som gør alt arbejdet for en anden samling i den samme database. Fik jeg nævnt, at denne serverløse funktion er fra en cloud-baseret "serviceorienteret arkitektur", der indeholder over 100 funktioner i miljøet?
Hvordan var det overhovedet muligt at gøre dette? Jeg dækker mit ansigt og hulker synligt gennem min latter. Mine kolleger spørger, hvad der skete, og jeg genfortæller det i farver Værste hits af BulkDataImporter.js 2018. Alle nikker sympatisk til mig og er enige: hvordan kunne de gøre det mod os?
Negativitet: et følelsesmæssigt værktøj i en programmørkultur
Negativitet spiller en vigtig rolle i programmering. Det er indlejret i vores kultur og bruges til at dele det, vi har lært ("det gør du ikke du vil tro det, hvordan var den kode!"), at udtrykke sympati gennem frustration ("Gud, HVORFOR gøre det?"), at vise sig selv ("Jeg ville aldrig så ikke gjorde det"), for at lægge skylden på en anden ("vi fejlede på grund af hans kode, som er umulig at opretholde"), eller, som det er sædvanligt i de mest "giftige" organisationer, at styre andre gennem en følelse af at skam ("Hvad tænkte du overhovedet på?" ? korrekt").
Negativitet er så vigtig for programmører, fordi det er en meget effektiv måde at formidle værdi på. Jeg deltog engang i en programmeringslejr, og standardpraksis for at indgyde en industrikultur hos eleverne var generøst at levere memes, historier og videoer, hvoraf de mest populære blev udnyttet . Det er godt at kunne bruge følelsesmæssige værktøjer til at identificere det gode, det dårlige, det grimme, gør det ikke, slet aldrig. Det er nødvendigt at forberede nyankomne på, at de formentlig vil blive misforstået af kolleger, der er langt fra IT. At deres venner vil begynde at sælge dem app-idéer til millioner dollars. At de bliver nødt til at vandre gennem endeløse labyrinter af forældet kode med en flok minotaurer rundt om hjørnet.
Når vi først lærer at programmere, er vores forståelse af dybden af "programmeringsoplevelsen" baseret på at observere andre menneskers følelsesmæssige reaktioner. Det kan tydeligt ses af indlæggene i , hvor en masse nybegyndere programmører hænger ud. Mange humoristiske er i en eller anden grad farvet med forskellige nuancer af negativitet: skuffelse, pessimisme, indignation, nedladenhed og andre. Og hvis dette ikke forekommer dig nok, så læs kommentarerne.
Jeg bemærkede, at efterhånden som programmører får erfaring, bliver de mere og mere negative. Begyndere, uvidende om de vanskeligheder, der venter dem, begynder med entusiasme og en vilje til at tro, at årsagen til disse vanskeligheder simpelthen er mangel på erfaring og viden; og til sidst vil de blive konfronteret med tingenes virkelighed.
Tiden går, de får erfaring og bliver i stand til at skelne god kode fra dårlig. Og når det øjeblik kommer, føler unge programmører frustrationen over at arbejde med åbenlyst dårlig kode. Og hvis de arbejder i et team (fjernt eller personligt), adopterer de ofte mere erfarne kollegers følelsesmæssige vaner. Dette fører ofte til en stigning i negativitet, fordi unge nu kan tale eftertænksomt om kode og dele det op i dårligt og godt, og derved vise, at de er "vidende". Dette forstærker det negative yderligere: af skuffelse er det nemt at komme overens med kolleger og blive en del af en gruppe; at kritisere Bad Code øger din status og professionalisme i andres øjne: .
Øget negativitet er ikke nødvendigvis en dårlig ting. Diskussioner om programmering er blandt andet ekstremt fokuseret på kvaliteten af den skrevne kode. Hvad koden er, definerer fuldstændigt den funktion, den er beregnet til at udføre (hardware, netværk osv. bortset fra), så det er vigtigt at kunne udtrykke din mening om den kode. Næsten alle diskussioner handler om, hvorvidt koden er god nok, og til at fordømme selve manifestationerne af dårlig kode i termer, hvis følelsesmæssige konnotation karakteriserer kodens kvalitet:
- "Der er mange logiske uoverensstemmelser i dette modul, det er en god kandidat til betydelig ydeevneoptimering."
- "Dette modul er ret dårligt, vi er nødt til at omstrukturere det."
- "Dette modul giver ikke mening, det skal omskrives."
- "Dette modul stinker, det skal lappes."
- "Dette er et stykke ram, ikke et modul, det behøvede slet ikke at blive skrevet, hvad fanden tænkte forfatteren på."
Det er i øvrigt denne "emotionelle udgivelse", der får udviklere til at kalde koden "sexet", hvilket sjældent er fair - medmindre du arbejder hos PornHub.
Problemet er, at mennesker er mærkelige, rastløse, følelsesmæssige skabninger, og opfattelsen og udtrykket af enhver følelse ændrer os: Først subtilt, men over tid, dramatisk.
En urolig glidebane af negativitet
For nogle år siden var jeg en uformel teamleder og interviewede en udvikler. Vi kunne virkelig godt lide ham: han var smart, stillede gode spørgsmål, var teknisk kyndig og passede godt ind i vores kultur. Jeg var især imponeret over hans positivitet og hvor initiativrig han virkede. Og jeg hyrede ham.
På det tidspunkt havde jeg arbejdet i virksomheden i et par år og følte, at vores kultur ikke var særlig effektiv. Vi forsøgte at lancere produktet to gange, tre gange og et par gange mere, før jeg ankom, hvilket førte til store udgifter til efterarbejde, hvor vi ikke havde andet at vise end lange nætter, stramme deadlines og produkter, der virkede. Og selvom jeg stadig arbejdede hårdt, var jeg skeptisk over for den sidste deadline, som ledelsen havde tildelt os. Og han bandede tilfældigt, da han diskuterede nogle aspekter af koden med mine kolleger.
Så det var ikke overraskende – selvom jeg var overrasket – at et par uger senere sagde den samme nye udvikler de samme negative ting, som jeg gjorde (inklusive bande). Jeg indså, at han ville opføre sig anderledes i en anden virksomhed med en anden kultur. Han tilpassede sig bare den kultur, jeg skabte. Jeg blev overvældet af en skyldfølelse. På grund af min subjektive oplevelse indgydte jeg pessimisme hos en nytilkommen, som jeg opfattede som helt anderledes. Selv hvis han virkelig ikke var sådan og bare optrådte for at vise, at han kunne passe ind, påtvungede jeg ham min lorte attitude. Og alt sagt, selv i spøg eller i forbifarten, har den dårlige måde at blive til det, man tror.
Negative måder
Lad os vende tilbage til vores tidligere newbie-programmører, som har fået lidt visdom og erfaring: de er blevet mere fortrolige med programmeringsindustrien og forstår, at dårlig kode er overalt, det kan ikke undgås. Det forekommer selv i de mest avancerede virksomheder med fokus på kvalitet (og lad mig bemærke: tilsyneladende beskytter modernitet ikke mod dårlig kode).
Godt manuskript. Med tiden begynder udviklere at acceptere, at dårlig kode er en realitet inden for software, og at deres job er at forbedre den. Og at hvis dårlig kode ikke kan undgås, så nytter det ikke noget at lave ballade om det. De tager zens vej og fokuserer på at løse problemer eller opgaver, som de konfronteres med. De lærer, hvordan de nøjagtigt måler og kommunikerer softwarekvalitet til virksomhedsejere, skriver velbegrundede estimater baseret på deres mange års erfaring og modtager i sidste ende generøse belønninger for deres utrolige og vedvarende værdi for virksomheden. De gør deres arbejde så godt, at de får udbetalt 10 millioner dollars i bonusser og går på pension for at gøre, hvad de vil resten af deres liv (tak det ikke for givet).
Et andet scenarie er mørkets vej. I stedet for at acceptere dårlig kode som en uundgåelighed, tager udviklere det på sig selv at kalde alt dårligt i programmeringsverdenen, så de kan overvinde det. De nægter at forbedre eksisterende dårlig kode af mange gode grunde: "folk burde vide mere og ikke være så dumme"; "det er ubehageligt"; "det er dårligt for erhvervslivet"; "det her beviser, hvor smart jeg er"; "hvis jeg ikke fortæller dig, hvilken elendig kode dette er, vil hele virksomheden falde i havet," og så videre.
Sikkert ude af stand til at implementere de ændringer, de ønsker, fordi forretningen desværre skal fortsætte med at udvikle sig og ikke kan bruge tid på at bekymre sig om kvaliteten af koden, får disse mennesker et ry som klager. De fastholdes for deres høje kompetence, men bliver skubbet til kanten af virksomheden, hvor de ikke vil genere mange mennesker, men stadig understøtte driften af kritiske systemer. Uden adgang til nye udviklingsmuligheder mister de færdigheder og holder op med at opfylde industriens krav. Deres negativitet bliver til bitter bitterhed, og som følge heraf fodrer de deres egoer ved at skændes med tyve-årige studerende om den rejse, deres yndlings gamle teknologi har taget, og hvorfor den stadig er så varm. De ender med at trække sig tilbage og udleve deres alderdom med at bande til fugle.
Virkeligheden ligger formentlig et sted imellem disse to yderpunkter.
Nogle virksomheder har haft ekstrem succes med at skabe ekstremt negative, isolerede, viljestærke kulturer (som Microsoft før sin ) - ofte er disse virksomheder med produkter, der passer perfekt til markedet, og behovet for at vokse så hurtigt som muligt; eller virksomheder med et hierarki af kommando og kontrol (Apple i de bedste jobs), hvor alle gør, hvad de får besked på. Moderne erhvervsforskning (og sund fornuft) tyder dog på, at maksimal opfindsomhed, som fører til innovativitet i virksomheder og høj produktivitet hos individer, kræver lave niveauer af stress for at understøtte løbende kreativ og metodisk tænkning. Og det er ekstremt svært at lave kreativt, diskussionsbaseret arbejde, hvis du konstant bekymrer dig om, hvad dine kolleger vil have at sige om hver linje i din kode.
Negativitet er ingeniør popkultur
I dag er der mere opmærksomhed på ingeniørernes holdning end nogensinde før. I ingeniørorganisationer er reglen "". Flere og flere anekdoter og historier dukker op på Twitter om mennesker, der forlod dette erhverv, fordi de ikke kunne (ville) blive ved med at affinde sig med fjendtlighed og ond vilje over for udenforstående. Selv Linus Torvalds år med fjendtlighed og kritik over for andre Linux-udviklere - dette har ført til debat om effektiviteten af denne tilgang.
Nogle forsvarer stadig Linus ret til at være meget kritiske – dem der burde vide meget om fordele og ulemper ved "giftig negativitet". Ja, høflighed er ekstremt vigtig (endog grundlæggende), men hvis vi opsummerer årsagerne til, at mange af os tillader udtryk for negative meninger at blive til "toksicitet", virker disse grunde paternalistiske eller teenagere: "de fortjener det, fordi de er idioter "," han skal være sikker på, at de ikke vil gøre det igen," "hvis de ikke havde gjort det, ville han ikke behøve at råbe af dem," og så videre. Et eksempel på den indvirkning en leders følelsesmæssige reaktioner har på et programmeringsfællesskab er Ruby-fællesskabets akronym MINASWAN - "Matz er sød, så vi er flinke."
Jeg har bemærket, at mange ivrige fortalere for "dræb en fjols"-tilgangen ofte bekymrer sig meget om kvaliteten og korrektheden af koden, og identificerer sig med deres arbejde. Desværre forveksler de ofte hårdhed med stivhed. Ulempen ved denne position stammer fra det simple menneskelige, men uproduktive ønske om at føle sig hævet over andre. Mennesker, der bliver fordybet i dette begær, bliver hængende på mørkets vej.
Programmeringsverdenen vokser hurtigt og skubber mod grænserne for sin container - verden af ikke-programmering (eller er verden af programmering en container for verden af ikke-programmering? Godt spørgsmål).
Efterhånden som vores branche ekspanderer i et stadigt stigende tempo, og programmering bliver mere tilgængelig, er afstanden mellem "teknikere" og "normale" hurtigt ved at lukke sig. Programmeringsverdenen er i stigende grad udsat for interpersonelle interaktioner mellem mennesker, der er vokset op i den isolerede nørdekultur fra det tidlige tech-boom, og det er dem, der vil forme den nye verden af programmering. Og uanset sociale eller generationsmæssige argumenter, vil effektivitet i kapitalismens navn vise sig i virksomhedskultur og ansættelsespraksis: de bedste virksomheder vil simpelthen ikke ansætte nogen, der ikke kan interagere neutralt med andre, endsige have gode relationer.
Hvad jeg lærte om negativitet
Hvis du tillader for meget negativitet at kontrollere dit sind og interaktioner med mennesker, der bliver til toksicitet, så er det farligt for produktteams og dyrt for erhvervslivet. Jeg har set (og hørt om) utallige projekter, der faldt fra hinanden og blev fuldstændig genopbygget med store omkostninger, fordi en betroet udvikler havde et nag til teknologien, en anden udvikler eller endda en enkelt fil valgt til at repræsentere kvaliteten af hele kodebasen.
Negativitet demoraliserer og ødelægger også relationer. Jeg vil aldrig glemme, hvordan en kollega skældte mig ud for at have lagt CSS i den forkerte fil, det gjorde mig ked af det og tillod mig ikke at samle mine tanker i flere dage. Og i fremtiden vil jeg næppe tillade sådan en person at være i nærheden af et af mine hold (men hvem ved, folk ændrer sig).
Til sidst det negative .
Jeg synes, det er sådan en mesterklasse om smil skal se ud.
Selvfølgelig er dette ikke et argument for at stråle af lykke, indsætte ti milliarder humørikoner i hver pull-anmodning eller gå til en mesterklasse om smil (nej, ja, hvis det er det, du vil, så er der ingen tvivl). Negativitet er en ekstremt vigtig del af programmering (og menneskeliv), signalerer kvalitet, giver en mulighed for at udtrykke følelser og være medfølende med medmennesker. Negativitet indikerer indsigt og forsigtighed, dybden af problemet. Jeg bemærker ofte, at en udvikler har nået et nyt niveau, når han begynder at udtrykke vantro på det, han tidligere var frygtsom og usikker på. Folk udviser rimelighed og tillid med deres meninger. Du kan ikke afvise udtrykket af negativitet, det ville være Orwellsk.
Negativitet skal dog doseres og balanceres med andre vigtige menneskelige egenskaber: empati, tålmodighed, forståelse og humor. Du kan altid fortælle en person, at han har lavet noget uden at råbe eller bande. Undervurder ikke denne tilgang: Hvis nogen fortæller dig uden nogen følelser, at du seriøst har rodet, er det virkelig skræmmende.
Den gang, for flere år siden, talte den administrerende direktør med mig. Vi diskuterede den aktuelle status for projektet, så spurgte han, hvordan jeg havde det. Jeg svarede, at alt var fint, projektet bevægede sig, vi arbejdede langsomt, måske gik jeg glip af noget og skulle genovervejes. Han sagde, at han havde hørt mig dele mere pessimistiske tanker med kolleger på kontoret, og at andre også havde bemærket det. Han forklarede, at hvis jeg var i tvivl, kunne jeg fuldt ud udtrykke dem til ledelsen, men ikke "tage dem ned." Som ledende ingeniør skal jeg være opmærksom på, hvordan mine ord påvirker andre, fordi jeg har stor indflydelse, selvom jeg ikke er klar over det. Og han fortalte mig alt dette meget venligt og sagde til sidst, at hvis jeg virkelig havde det sådan, så skal jeg nok tænke over, hvad jeg vil for mig selv og min karriere. Det var en utrolig blid, få-det-eller-kom-ud-af-din-sæde-samtale. Jeg takkede ham for informationen om, hvordan min ændrede holdning over seks måneder påvirkede andre ubemærket af mig.
Det var et eksempel på bemærkelsesværdig, effektiv ledelse og styrken af en blød tilgang. Jeg indså, at jeg kun så ud til at have fuld tillid til virksomheden og dens evne til at nå sine mål, men i virkeligheden talte og kommunikerede jeg med andre på en helt anden måde. Jeg indså også, at selvom jeg følte mig skeptisk over for det projekt, jeg arbejdede på, skulle jeg ikke vise mine følelser til mine kolleger og sprede pessimisme som en smittefare, hvilket reducerede vores chancer for succes. I stedet kunne jeg aggressivt formidle den virkelige situation til min ledelse. Og hvis jeg følte, at de ikke lyttede til mig, kunne jeg udtrykke min uenighed ved at forlade virksomheden.
Jeg fik en ny mulighed, da jeg tiltrådte stillingen som personalevurderingschef. Som tidligere maskinchef er jeg meget forsigtig med at udtrykke mine meninger om vores (stadig forbedrede) arvekodeks. For at godkende en ændring skal du forestille dig den aktuelle situation, men du kommer ingen vegne, hvis du vælter dig i at stønne, angribe eller lignende. I sidste ende er jeg her for at fuldføre en opgave og bør ikke klage over koden for at forstå den, evaluere den eller rette den.
Faktisk, jo mere jeg kontrollerer min følelsesmæssige reaktion på koden, jo mere forstår jeg, hvad det kunne blive, og jo mindre forvirring føler jeg. Når jeg udtrykte mig selv med tilbageholdenhed ("her må være plads til yderligere forbedringer"), gjorde jeg mig selv og andre glade og tog ikke situationen for alvorligt. Jeg indså, at jeg kunne stimulere og reducere negativitet hos andre ved at være fuldstændig (irriterende?) fornuftig ("du har ret, denne kode er ret dårlig, men vi vil forbedre den"). Jeg er glad for at se, hvor langt jeg kan gå på Zen-stien.
Grundlæggende lærer og lærer jeg konstant en vigtig lektie: livet er for kort til konstant at være vred og have smerter.
Kilde: www.habr.com