Jag tittar på en kod. Det här kan vara den sämsta koden jag någonsin sett. För att bara uppdatera en post i databasen hämtar den alla poster i samlingen och skickar sedan en uppdateringsbegäran till varje post i databasen, även de som inte behöver uppdateras. Det finns en kartfunktion som helt enkelt returnerar värdet som skickas till den. Det finns villkorliga tester för variabler med uppenbarligen samma värde, bara namngivna i olika stilar (firstName и first_name). För varje UPPDATERING skickar koden ett meddelande till en annan kö, som hanteras av en annan serverlös funktion, men som gör allt arbete för en annan samling i samma databas. Nämnde jag att denna serverlösa funktion kommer från en molnbaserad "tjänsteorienterad arkitektur" som innehåller över 100 funktioner i miljön?
Hur var det ens möjligt att göra detta? Jag täcker mitt ansikte och snyftar synligt genom mitt skratt. Mina kollegor frågar vad som hände och jag återberättar det i färger Värsta träffarna från BulkDataImporter.js 2018. Alla nickar sympatiskt mot mig och håller med: hur kunde de göra så här mot oss?
Negativitet: ett känslomässigt verktyg i en programmerarkultur
Negativitet spelar en viktig roll i programmering. Det är inbäddat i vår kultur och används för att dela det vi har lärt oss ("det gör du inte du kommer att tro det, hur var den koden!"), att uttrycka sympati genom frustration ("Gud, VARFÖR göra det?"), att visa upp sig själv ("Jag skulle aldrig så gjorde det inte”), att lägga skulden på någon annan (”vi misslyckades på grund av hans kod, som är omöjlig att underhålla”), eller, som är brukligt i de mest ”giftiga” organisationerna, att kontrollera andra genom en känsla av skam ("Vad tänkte du ens på?" ? korrekt").
Negativitet är så viktigt för programmerare eftersom det är ett mycket effektivt sätt att förmedla värde. Jag deltog en gång i ett programmeringsläger, och vanlig praxis att ingjuta en industrikultur hos elever var att generöst tillhandahålla memes, berättelser och videor, varav de mest populära utnyttjades . Det är bra att kunna använda känslomässiga verktyg för att identifiera det goda, det onda, det fula, gör inte det, aldrig alls. Det är nödvändigt att förbereda nyanlända på att de förmodligen kommer att missförstås av kollegor som står långt ifrån IT. Att deras vänner ska börja sälja dem appidéer för miljoner dollar. Att de kommer att behöva vandra genom oändliga labyrinter av föråldrad kod med ett gäng minotaurier runt hörnet.
När vi först lär oss att programmera baseras vår förståelse av djupet av "programmeringsupplevelsen" på att observera andra människors känslomässiga reaktioner. Detta kan tydligt ses av inläggen i , där många nybörjarprogrammerare umgås. Många humoristiska är, i en eller annan grad, färgade med olika nyanser av negativitet: besvikelse, pessimism, indignation, nedlåtenhet och andra. Och om detta inte verkar tillräckligt för dig, läs kommentarerna.
Jag märkte att allt eftersom programmerare får erfarenhet blir de mer och mer negativa. Nybörjare, omedvetna om svårigheterna som väntar dem, börjar med entusiasm och en vilja att tro att orsaken till dessa svårigheter helt enkelt är brist på erfarenhet och kunskap; och så småningom kommer de att konfronteras med verkligheten.
Tiden går, de får erfarenhet och kan skilja bra kod från dålig. Och när det ögonblicket kommer känner unga programmerare frustrationen över att arbeta med uppenbart dålig kod. Och om de arbetar i ett team (på distans eller personligen), anammar de ofta mer erfarna kollegors känslomässiga vanor. Detta leder ofta till en ökning av negativitet, eftersom unga människor nu kan prata eftertänksamt om kod och dela upp den i dåligt och bra, och därigenom visa att de är "medvetna". Detta förstärker det negativa ytterligare: av besvikelse är det lätt att komma överens med kollegor och bli en del av en grupp; att kritisera Bad Code ökar din status och professionalism i andras ögon: .
Att öka negativiteten är inte nödvändigtvis en dålig sak. Diskussioner om bland annat programmering är extremt fokuserade på kvaliteten på den skrivna koden. Vad koden är definierar helt och hållet funktionen den är avsedd att göra (hårdvara, nätverk, etc. bortsett från), så det är viktigt att du kan uttrycka din åsikt om den koden. Nästan alla diskussioner handlar om huruvida koden är tillräckligt bra, och att fördöma själva manifestationen av dålig kod i termer vars känslomässiga konnotation kännetecknar kodens kvalitet:
- "Det finns många logiska inkonsekvenser i den här modulen, den är en bra kandidat för betydande prestandaoptimering."
- "Den här modulen är ganska dålig, vi måste omstrukturera den."
- "Den här modulen är inte vettig, den måste skrivas om."
- "Den här modulen suger, den måste korrigeras."
- "Det här är en baggebit, inte en modul, det behövde inte skrivas alls, vad fan tänkte författaren på."
Förresten, det är denna "känslomässiga release" som får utvecklare att kalla koden "sexig", vilket sällan är rättvist - om du inte jobbar på PornHub.
Problemet är att människor är konstiga, rastlösa, känslomässiga varelser, och uppfattningen och uttrycket av alla känslor förändrar oss: till en början subtilt, men med tiden, dramatiskt.
En orolig hal av negativitet
För några år sedan var jag en informell teamledare och intervjuade en utvecklare. Vi gillade honom verkligen: han var smart, ställde bra frågor, var tekniskt kunnig och passade väl in i vår kultur. Jag blev särskilt imponerad av hans positivitet och hur driftig han verkade. Och jag anställde honom.
Då hade jag jobbat i företaget i ett par år och kände att vår kultur inte var särskilt effektiv. Vi försökte lansera produkten två gånger, tre gånger och ett par gånger till innan jag kom, vilket ledde till stora kostnader för omarbetning, under vilka vi inte hade något att visa utom långa nätter, snäva deadlines och produkter som fungerade. Och även om jag fortfarande arbetade hårt, var jag skeptisk till den sista deadline som ledningen tilldelade oss. Och han svor nonchalant när han diskuterade vissa aspekter av koden med mina kollegor.
Så det var inte förvånande – även om jag blev förvånad – att samma nya utvecklare några veckor senare sa samma negativa saker som jag gjorde (inklusive svordomar). Jag insåg att han skulle bete sig annorlunda i ett annat företag med en annan kultur. Han anpassade sig bara till den kultur som jag skapade. Jag blev överväldigad av en skuldkänsla. På grund av min subjektiva upplevelse ingav jag pessimism hos en nykomling som jag uppfattade som helt annorlunda. Även om han verkligen inte var sådan och bara ställde upp för att visa att han kunde passa in, tvingade jag på honom min taskiga attityd. Och allt som sägs, även på skämt eller i förbigående, har det dåliga sättet att förvandlas till vad man tror.
Negativa sätt
Låt oss återvända till våra tidigare nybörjarprogrammerare, som har fått lite visdom och erfarenhet: de har blivit mer bekanta med programmeringsindustrin och förstår att dålig kod finns överallt, den kan inte undvikas. Det förekommer även i de mest avancerade företagen fokuserade på kvalitet (och låt mig notera: uppenbarligen skyddar moderniteten inte mot dålig kod).
Bra manus. Med tiden börjar utvecklare acceptera att dålig kod är en verklighet av programvara och att deras jobb är att förbättra den. Och att om dålig kod inte kan undvikas, så är det ingen idé att göra något väsen av det. De tar Zens väg och fokuserar på att lösa problem eller uppgifter som möter dem. De lär sig hur man korrekt mäter och kommunicerar mjukvarukvalitet till företagsägare, skriver välgrundade uppskattningar baserat på deras år av erfarenhet och får i slutändan generösa belöningar för sitt otroliga och pågående värde för verksamheten. De gör sitt jobb så bra att de får 10 miljoner dollar i bonus och går i pension för att göra vad de vill resten av livet (snälla ta det inte för givet).
Ett annat scenario är mörkrets väg. Istället för att acceptera dålig kod som en oundviklighet, tar utvecklare på sig att ropa ut allt dåligt i programmeringsvärlden så att de kan övervinna det. De vägrar att förbättra befintlig dålig kod av många goda skäl: "folk borde veta mer och inte vara så dumma"; "det är obehagligt"; "det här är dåligt för affärer"; "det här bevisar hur smart jag är"; "om jag inte berättar vilken usel kod det här är, kommer hela företaget att falla i havet" och så vidare.
Säkert oförmögen att genomföra de förändringar de vill ha eftersom verksamheten tyvärr måste fortsätta att utvecklas och inte kan lägga tid på att oroa sig för kvaliteten på koden, får dessa personer ett rykte som klagande. De behålls för sin höga kompetens, men pressas till företagets marginaler, där de inte kommer att irritera många människor, men ändå kommer att stödja driften av kritiska system. Utan tillgång till nya utvecklingsmöjligheter tappar de kompetens och upphör att möta branschens krav. Deras negativitet förvandlas till bitter bitterhet, och som ett resultat av det matar de sina egon genom att argumentera med tjugoåriga elever om resan deras gamla favoritteknik har tagit och varför den fortfarande är så varm. Det slutar med att de går i pension och lever ut sin ålderdom genom att svära på fåglar.
Sannolikt ligger verkligheten någonstans mitt emellan dessa två ytterligheter.
Vissa företag har varit extremt framgångsrika i att skapa extremt negativa, isolerade, viljestarka kulturer (som Microsoft innan dess ) - ofta är dessa företag med produkter som perfekt passar marknaden och behovet av att växa så snabbt som möjligt; eller företag med en hierarki av ledning och kontroll (Apple i de bästa åren av jobb), där alla gör vad de blir tillsagda. Modern affärsforskning (och sunt förnuft) tyder dock på att maximal uppfinningsrikedom, vilket leder till innovationsförmåga i företag, och hög produktivitet hos individer, kräver låga nivåer av stress för att stödja pågående kreativt och metodiskt tänkande. Och det är extremt svårt att göra kreativt, diskussionsbaserat arbete om du ständigt oroar dig för vad dina kollegor kommer att ha att säga om varje rad i din kod.
Negativitet är ingenjörskultur
Idag ägnas mer uppmärksamhet åt ingenjörernas attityd än någonsin tidigare. I ingenjörsorganisationer är regeln "". Fler och fler anekdoter och berättelser dyker upp på Twitter om människor som lämnat detta yrke för att de inte kunde (skulle) fortsätta att stå ut med fientlighet och illvilja mot utomstående. Till och med Linus Torvalds år av fientlighet och kritik mot andra Linux-utvecklare - detta har lett till debatt om effektiviteten av detta tillvägagångssätt.
En del försvarar fortfarande Linus rätt att vara väldigt kritisk – de som borde veta mycket om för- och nackdelar med "giftig negativitet". Ja, hövlighet är extremt viktig (även grundläggande), men om vi summerar anledningarna till att många av oss låter uttrycket av negativa åsikter förvandlas till "toxicitet", verkar dessa skäl paternalistiska eller ungdomliga: "de förtjänar det eftersom de är idioter ", "han måste vara säker på att de inte kommer att göra det igen", "om de inte hade gjort det, skulle han inte behöva skrika på dem," och så vidare. Ett exempel på vilken inverkan en ledares känslomässiga reaktioner har på en programmeringsgemenskap är Ruby-gemenskapens förkortning MINASWAN - "Matz är trevlig så vi är trevliga."
Jag har märkt att många ivriga förespråkare av "kill a fool"-metoden ofta bryr sig väldigt mycket om kodens kvalitet och korrekthet, och identifierar sig med sitt arbete. Tyvärr förväxlar de ofta hårdhet med styvhet. Nackdelen med denna position härrör från den enkla mänskliga, men improduktiva önskan att känna sig överlägsen andra. Människor som blir nedsänkta i denna önskan fastnar på mörkrets väg.
Programmeringsvärlden växer snabbt och tränger sig mot gränserna för sin container - världen av icke-programmering (eller är programmeringsvärlden en container för världen av icke-programmering? Bra fråga).
När vår bransch expanderar i en ständigt ökande takt och programmering blir mer tillgänglig, minskar avståndet mellan "tekniker" och "normala" snabbt. Programmeringsvärlden är alltmer utsatt för interpersonella interaktioner mellan människor som växte upp i den isolerade nördkulturen under den tidiga teknikboomen, och det är de som kommer att forma den nya programmeringsvärlden. Och oavsett sociala eller generationsmässiga argument kommer effektivitet i kapitalismens namn att dyka upp i företagskulturen och anställningsmetoderna: de bästa företagen kommer helt enkelt inte att anställa någon som inte kan interagera neutralt med andra, än mindre ha goda relationer.
Vad jag lärde mig om negativitet
Om du tillåter för mycket negativitet att styra ditt sinne och interaktioner med människor, förvandlas till toxicitet, då är det farligt för produktteam och dyrt för affärer. Jag har sett (och hört talas om) otaliga projekt som föll isär och byggdes om helt till stora kostnader eftersom en pålitlig utvecklare hade ett agg mot tekniken, en annan utvecklare eller till och med en enda fil som valts för att representera kvaliteten på hela kodbasen.
Negativitet demoraliserar och förstör också relationer. Jag kommer aldrig att glömma hur en kollega skällde ut mig för att ha lagt CSS i fel fil, det gjorde mig upprörd och tillät mig inte att samla mina tankar på flera dagar. Och i framtiden kommer jag sannolikt inte att tillåta en sådan person att vara nära ett av mina team (men vem vet, människor förändras).
Slutligen det negativa .
Jag tycker att det är så här en mästarklass om leenden ska se ut.
Naturligtvis är detta inte ett argument för att stråla av lycka, infoga tio miljarder uttryckssymboler i varje pull-förfrågan, eller gå på en mästarklass om leenden (nej, ja, om det är vad du vill, då ingen fråga). Negativitet är en oerhört viktig del av programmering (och människoliv), signalerar kvalitet, låter en uttrycka känslor och umgås med medmänniskor. Negativitet indikerar insikt och försiktighet, djupet av problemet. Jag märker ofta att en utvecklare har nått en ny nivå när han börjar uttrycka misstro mot det han tidigare var blyg och osäker på. Människor visar rimlighet och självförtroende med sina åsikter. Du kan inte avfärda uttrycket av negativitet, det skulle vara orwellskt.
Negativitet måste dock doseras och balanseras med andra viktiga mänskliga egenskaper: empati, tålamod, förståelse och humor. Du kan alltid tala om för en person att han stökat till utan att skrika eller svära. Underskatta inte detta tillvägagångssätt: om någon säger till dig utan några känslor att du på allvar har trasslat till är det verkligen skrämmande.
Den gången, för flera år sedan, pratade vd med mig. Vi diskuterade projektets nuvarande status, sedan frågade han hur jag mådde. Jag svarade att allt var bra, projektet rörde på sig, vi arbetade långsamt, kanske missade jag något och behövde omprövas. Han sa att han hade hört mig dela mer pessimistiska tankar med kollegor på kontoret, och att andra också hade märkt detta. Han förklarade att om jag hade tvivel kunde jag uttrycka dem fullt ut för ledningen, men inte "ta ner dem." Som ledande ingenjör måste jag vara uppmärksam på hur mina ord påverkar andra eftersom jag har mycket inflytande även om jag inte inser det. Och han berättade allt detta väldigt vänligt och sa till slut att om jag verkligen kände så, då måste jag nog tänka på vad jag vill för mig själv och min karriär. Det var ett otroligt mildt, få-det-eller-kom-ur-sätet-samtal. Jag tackade honom för informationen om hur min förändrade attityd under sex månader påverkade andra obemärkt av mig.
Det var ett exempel på enastående, effektiv ledning och kraften i ett mjukt förhållningssätt. Jag insåg att jag bara verkade ha full tilltro till företaget och dess förmåga att nå sina mål, men i verkligheten pratade och kommunicerade jag med andra på ett helt annat sätt. Jag insåg också att även om jag kände mig skeptisk till projektet jag arbetade med så borde jag inte visa mina känslor för mina kollegor och sprida pessimism som en smitta, vilket minskade våra chanser att lyckas. Istället kunde jag aggressivt förmedla den verkliga situationen till min ledning. Och om jag kände att de inte lyssnade på mig kunde jag uttrycka min oenighet genom att lämna företaget.
Jag fick en ny möjlighet när jag tillträdde tjänsten som chef för personalbedömning. Som före detta chefsingenjör är jag väldigt försiktig med att uttrycka mina åsikter om vår (alltid förbättrande) äldre kod. För att godkänna en förändring måste du föreställa dig den aktuella situationen, men du kommer ingenstans om du vältrar dig i att stöna, attackera eller liknande. I slutändan är jag här för att slutföra en uppgift och ska inte klaga på koden för att förstå den, utvärdera den eller fixa den.
Faktum är att ju mer jag kontrollerar min känslomässiga reaktion på koden, desto mer förstår jag vad det kan bli och desto mindre förvirring känner jag. När jag uttryckte mig med återhållsamhet ("det måste finnas utrymme för ytterligare förbättringar här"), gjorde jag mig själv och andra glada och tog inte situationen på alltför stort allvar. Jag insåg att jag kunde stimulera och minska negativitet hos andra genom att vara helt (irriterande?) rimlig ("du har rätt, den här koden är ganska dålig, men vi ska förbättra den"). Jag är glad att se hur långt jag kan gå på Zen-vägen.
I grund och botten lär jag mig och lär mig om en viktig läxa: livet är för kort för att konstant vara arg och ha ont.
Källa: will.com