Aš žiūriu į kodo dalį. Tai gali būti pats blogiausias kodas, kokį aš kada nors mačiau. Norėdami atnaujinti tik vieną įrašą duomenų bazėje, jis nuskaito visus kolekcijos įrašus ir siunčia atnaujinimo užklausą kiekvienam duomenų bazės įrašui, net ir tiems, kurių nereikia atnaujinti. Yra žemėlapio funkcija, kuri tiesiog grąžina jai perduotą reikšmę. Yra sąlyginiai testai kintamiesiems, kurių reikšmė akivaizdžiai ta pati, tik pavadinta skirtingais stiliais (firstName и first_name). Kiekvieno ATNAUJINIMO metu kodas siunčia pranešimą į skirtingą eilę, kurią tvarko kita be serverio funkcija, bet kuri atlieka visą darbą skirtingam tos pačios duomenų bazės rinkiniui. Ar minėjau, kad ši funkcija be serverio yra iš debesies pagrindu sukurtos „į paslaugas orientuotos architektūros“, kurioje yra daugiau nei 100 funkcijų aplinkoje?
Kaip išvis buvo įmanoma tai padaryti? Uždengiu veidą ir akivaizdžiai verkiu iš juoko. Kolegos klausia, kas atsitiko, o aš perpasakoju tai spalvomis Blogiausi 2018 m. „BulkDataImporter.js“ hitai. Visi užjaučiamai linkteli man galva ir pritaria: kaip jie galėjo mums taip pasielgti?
Negatyvumas: emocinis įrankis programuotojo kultūroje
Negatyvumas vaidina svarbų vaidmenį programuojant. Jis yra įtrauktas į mūsų kultūrą ir naudojamas dalytis tuo, ką išmokome („tu ne tu patikėsi, koks buvo tas kodas!“), išreikšti užuojautą per nusivylimą („Dieve, KODĖL tai daryti?“), parodyti save („Aš niekada nebūčiau“ taip nepadarė“), suversti kaltę ką nors kitam („mes nepavyko dėl jo kodo, kurio neįmanoma išlaikyti“) arba, kaip įprasta „toksiškiausiose“ organizacijose, valdyti kitus per jausmą gėda („Apie ką tu galvoji?“? Teisingai).
Negatyvumas yra toks svarbus programuotojams, nes tai labai efektyvus būdas perteikti vertę. Kartą dalyvavau programavimo stovykloje, o standartinė pramonės kultūros ugdymo praktika studentams buvo dosniai tiekti memus, istorijas ir vaizdo įrašus, iš kurių populiariausi buvo naudojami. . Gerai, kai gali panaudoti emocinius įrankius, kad atpažintų, kas yra gera, bloga, bjauri, nedaryk to, niekada. Naujokus būtina paruošti tam, kad greičiausiai juos nesupras IT toli nusiteikę kolegos. Kad jų draugai pradės jiems pardavinėti milijonų dolerių programėlių idėjas. Kad jiems teks klaidžioti begaliniais pasenusio kodo labirintais su krūva minotaurų už kampo.
Kai pirmą kartą išmokstame programuoti, mūsų supratimas apie „programavimo patirties“ gilumą yra pagrįstas kitų žmonių emocinių reakcijų stebėjimu. Tai aiškiai matyti iš įrašų , kur sėdi daug naujokų programuotojų. Daugelis humoristinių vienokiu ar kitokiu laipsniu yra nuspalvinti įvairiais negatyvumo atspalviais: nusivylimu, pesimizmu, pasipiktinimu, nuolaidžiavimu ir kitais. Ir jei jums to nepakanka, skaitykite komentarus.
Pastebėjau, kad įgydami patirties programuotojai tampa vis neigiamesni. Pradedantieji, nežinodami apie jų laukiančius sunkumus, pradeda entuziazmo ir noro patikėti, kad šių sunkumų priežastis yra tiesiog patirties ir žinių trūkumas; ir galiausiai jie susidurs su dalykų tikrove.
Laikas bėga, jie įgyja patirties ir geba atskirti gerą kodą nuo blogo. Ir kai ateina ta akimirka, jaunieji programuotojai jaučia nusivylimą dirbdami su akivaizdžiai blogu kodu. Ir jei jie dirba komandoje (nuotoliniu būdu ar asmeniškai), jie dažnai perima labiau patyrusių kolegų emocinius įpročius. Tai dažnai lemia negatyvumo padidėjimą, nes jauni žmonės dabar gali apgalvotai kalbėti apie kodą ir skirstyti jį į blogus ir gerus, taip parodydami, kad jie „žino“. Tai dar labiau sustiprina negatyvą: iš nusivylimo lengva sutarti su kolegomis ir tapti grupės dalimi, kritikuojant „Bad Code“ padidėja jūsų statusas ir profesionalumas kitų akyse: .
Didėjantis negatyvumas nebūtinai yra blogas dalykas. Diskusijose apie programavimą, be kita ko, itin daug dėmesio skiriama parašyto kodo kokybei. Tai, kas yra kodas, visiškai apibrėžia funkciją, kurią jis turi atlikti (išskyrus aparatinę įrangą, tinklą ir pan.), todėl svarbu turėti galimybę išreikšti savo nuomonę apie šį kodą. Beveik visos diskusijos kyla dėl to, ar kodas yra pakankamai geras, ir pasmerkti pačias blogo kodo apraiškas, kurių emocinė konotacija apibūdina kodo kokybę:
- "Šiame modulyje yra daug loginių neatitikimų, tai yra geras kandidatas reikšmingam našumo optimizavimui."
- "Šis modulis yra gana blogas, turime jį pertvarkyti."
- „Šis modulis neturi prasmės, jį reikia perrašyti“.
- „Šis modulis bjaurus, jį reikia pataisyti.
- „Tai yra avino gabalas, o ne modulis, jo visai nereikėjo rašyti, ką, po velnių, galvoja jo autorius.
Beje, būtent šis „emocinis leidimas“ verčia kūrėjus vadinti kodą „seksualiu“, o tai retai būna sąžininga – nebent dirbate „PornHub“.
Bėda ta, kad žmonės yra keisti, neramūs, emocingi padarai, o bet kokios emocijos suvokimas ir išraiška mus keičia: iš pradžių subtiliai, bet laikui bėgant – dramatiškai.
Neramus slidus negatyvo šlaitas
Prieš kelerius metus buvau neoficialus komandos vadovas ir kalbinau kūrėją. Mums jis labai patiko: jis buvo protingas, klausinėjo gerų klausimų, išmanė technologijas ir puikiai tiko mūsų kultūrai. Mane ypač sužavėjo jo pozityvumas ir tai, kaip iniciatyvus jis atrodė. Ir aš jį pasamdžiau.
Tuo metu įmonėje dirbau porą metų ir jaučiau, kad mūsų kultūra nelabai efektyvi. Bandėme paleisti produktą du kartus, tris kartus ir dar porą kartų, kol aš atvykau, o tai lėmė didelių pertvarkymo išlaidų, per kurias neturėjome ką parodyti, išskyrus ilgas naktis, griežtus terminus ir produktus, kurie veikė. Ir nors vis dar sunkiai dirbau, į paskutinį vadovybės mums skirtą terminą žiūrėjau skeptiškai. Ir jis atsainiai prisiekė aptardamas kai kuriuos kodekso aspektus su mano kolegomis.
Taigi nenuostabu, nors ir nustebau, kad po kelių savaičių tas pats naujas kūrėjas pasakė tuos pačius neigiamus dalykus, kuriuos ir aš (įskaitant keikimąsi). Supratau, kad kitoje, kitokios kultūros kompanijoje jis elgsis kitaip. Jis tiesiog prisitaikė prie mano sukurtos kultūros. Mane apėmė kaltės jausmas. Dėl savo subjektyvios patirties naujokui, kurį suvokiau kaip visiškai kitokį, įskiepijau pesimizmą. Net jei jis tikrai toks nebuvo ir tik apsirengė, kad parodytų, jog gali tilpti, aš primečiau jam savo šlykštų požiūrį. Ir viskas, kas pasakyta, net juokais ar pro šalį, blogai virsta tuo, kuo tikima.
Neigiami būdai
Grįžkime prie mūsų buvusių naujokų programuotojų, kurie įgijo šiek tiek išminties ir patirties: jie labiau susipažino su programavimo industrija ir supranta, kad blogas kodas yra visur, jo negalima išvengti. Tai pasitaiko net pačiose pažangiausiose į kokybę orientuotose įmonėse (ir atkreipiu dėmesį: matyt, modernumas neapsaugo nuo blogo kodo).
Geras scenarijus. Laikui bėgant kūrėjai pradeda pripažinti, kad blogas kodas yra programinės įrangos realybė ir kad jų darbas yra jį tobulinti. Ir jei nepavyks išvengti blogo kodo, nėra prasmės dėl to kelti triukšmą. Jie eina Zen keliu, sutelkdami dėmesį į problemų ar užduočių, su kuriomis jie susiduria, sprendimą. Jie išmoksta tiksliai įvertinti programinės įrangos kokybę ir perduoti ją verslo savininkams, rašyti pagrįstas sąmatas, pagrįstas ilgamete patirtimi, ir galiausiai gauti dosnų atlygį už neįtikėtiną ir nuolatinę vertę verslui. Jie atlieka savo darbą taip gerai, kad gauna 10 milijonų dolerių premijų ir išeina į pensiją, kad visą likusį gyvenimą dirbtų tai, ko nori (prašau, nelaikykite to savaime suprantamu dalyku).
Kitas scenarijus – tamsos kelias. Užuot priėmę blogą kodą kaip neišvengiamybę, kūrėjai imasi patys išaiškinti viską, kas bloga programavimo pasaulyje, kad galėtų tai įveikti. Jie atsisako tobulinti esamą blogą kodą dėl daugelio gerų priežasčių: „žmonės turėtų žinoti daugiau ir nebūti tokie kvaili“; „tai nemalonu“; „tai kenkia verslui“; „tai įrodo, koks aš protingas“; „Jei nepasakysiu, koks tai bjaurus kodas, visa kompanija nukris į vandenyną“ ir pan.
Tikrai negalėdami įgyvendinti norimų pakeitimų, nes verslas, deja, turi toliau vystytis ir negali skirti laiko nerimauti dėl kodo kokybės, šie žmonės įgyja skundikų reputaciją. Jie išlaikomi dėl aukštos kompetencijos, tačiau nustumiami į įmonės užribį, kur neerzins daugelio žmonių, bet vis tiek palaikys kritinių sistemų veikimą. Neturėdami galimybės naudotis naujomis plėtros galimybėmis, jie praranda įgūdžius ir nustoja tenkinti pramonės poreikius. Jų negatyvumas virsta karčiu kartumu, ir dėl to jie maitina savo ego ginčydamiesi su dvidešimtmečiais studentais apie kelionę, kurią nukeliavo jų mėgstama sena technika ir kodėl ji vis dar tokia karšta. Jie išeina į pensiją ir išgyvena savo senatvę keikdamiesi paukščiais.
Realybė tikriausiai yra kažkur tarp šių dviejų kraštutinumų.
Kai kurioms kompanijoms itin sėkmingai pavyko sukurti itin neigiamas, izoliuotas, stiprios valios kultūras (kaip „Microsoft“ anksčiau ) - dažnai tai yra įmonės, kurių produktai puikiai tinka rinkai ir būtinybei augti kuo greičiau; arba įmonės, turinčios vadovavimo ir kontrolės hierarchiją („Apple“ geriausiais Jobso metais), kur kiekvienas daro tai, ką liepia. Tačiau šiuolaikiniai verslo tyrimai (ir sveikas protas) rodo, kad norint pasiekti maksimalų išradingumą, lemiantį novatoriškumą įmonėse, o aukštą asmenų produktyvumą, reikia nedidelio streso lygio, kad būtų palaikomas nuolatinis kūrybinis ir metodinis mąstymas. Ir nepaprastai sunku dirbti kūrybišką, diskusijomis paremtą darbą, jei nuolat nerimaujate, ką kolegos pasakys apie kiekvieną jūsų kodo eilutę.
Negatyvumas yra popkultūros inžinierius
Šiandien kaip niekad daug dėmesio skiriama inžinierių požiūriui. Inžinerinėse organizacijose galioja taisyklė „“. „Twitter“ tinkle pasirodo vis daugiau anekdotų ir istorijų apie žmones, kurie paliko šią profesiją, nes negalėjo (nenorėtų) ir toliau taikstytis su priešiškumu ir pikta valia pašaliniams asmenims. Net Linusas Torvaldsas metų priešiškumas ir kritika kitų Linux kūrėjų atžvilgiu – tai paskatino diskusijas apie šio požiūrio veiksmingumą.
Kai kas vis dar gina Lino teisę būti labai kritiškam – tie, kurie turėtų daug žinoti apie „toksiško negatyvo“ privalumus ir trūkumus. Taip, mandagumas yra be galo svarbus (netgi esminis), tačiau susumavus priežastis, kodėl daugelis leidžiame neigiamos nuomonės reiškimui virsti „toksiškumu“, šios priežastys atrodo paternalistiškos arba paaugliškos: „jie to nusipelnė, nes yra idiotai. “, „jis turi būti tikras, kad jie daugiau to nepadarys“, „jei jie to nebūtų darę, jam nereikėtų ant jų rėkti“ ir pan. Lyderio emocinių reakcijų įtakos programavimo bendruomenei pavyzdys yra Ruby bendruomenės akronimas MINASWAN – „Matz is nice to we are nice“.
Pastebėjau, kad daugelis karštų „nužudyk kvailį“ metodo šalininkų dažnai labai rūpinasi kodo kokybe ir teisingumu, tapatina save su savo darbu. Deja, jie dažnai painioja kietumą su standumu. Šios pozicijos trūkumas kyla iš paprasto žmogiško, bet neproduktyvaus noro jaustis pranašesniu už kitus. Į šį troškimą panirę žmonės įstringa tamsos kelyje.
Programavimo pasaulis sparčiai auga ir veržiasi prieš savo konteinerio – neprogramavimo pasaulio – ribas (o gal programavimo pasaulis yra konteineris neprogramavimo pasauliui? Geras klausimas).
Kadangi mūsų pramonė plečiasi vis spartesniu tempu, o programavimas tampa prieinamesnis, atstumas tarp „technikų“ ir „normalių“ sparčiai mažėja. Programavimo pasaulis vis labiau susiduria su žmonių, kurie užaugo ankstyvojo technologijų bumo izoliuotoje vėpla kultūroje, tarpusavio bendravimo, ir būtent jie suformuos naująjį programavimo pasaulį. Ir nepaisant jokių socialinių ar kartų argumentų, efektyvumas vardan kapitalizmo atsiras įmonių kultūroje ir samdymo praktikoje: geriausios įmonės tiesiog nepriims į darbą nė vieno, kuris nemoka neutraliai bendrauti su kitais, o ką jau kalbėti apie gerus santykius.
Ką aš sužinojau apie negatyvumą
Jei leisite per daug negatyvo valdyti savo protą ir bendravimą su žmonėmis, virsdami toksiškumu, tai pavojinga produktų komandoms ir brangu verslui. Mačiau (ir girdėjau apie) begalę projektų, kurie subyrėjo ir buvo visiškai atstatyti už dideles išlaidas, nes vienas patikimas kūrėjas pykdė technologijai, kitam kūrėjui ar net vienam failui, pasirinktam, kad atspindėtų visos kodų bazės kokybę.
Negatyvumas taip pat demoralizuoja ir griauna santykius. Niekada nepamiršiu, kaip kolega mane barė, kad įdėjau CSS ne tą failą, tai mane nuliūdino ir kelias dienas neleido rinkti minčių. Ir ateityje vargu ar leisiu tokiam žmogui būti šalia vienos iš savo komandų (bet kas žino, žmonės keičiasi).
Galiausiai, neigiamas .
Manau, kad taip turėtų atrodyti šypsenų meistriškumo klasė.
Žinoma, tai nėra argumentas spindėti iš laimės, įterpti dešimt milijardų jaustukų į kiekvieną traukos prašymą ar eiti į šypsenų meistriškumo klasę (ne, na, jei to norite, tada jokių klausimų). Negatyvumas yra nepaprastai svarbi programavimo (ir žmogaus gyvenimo) dalis, signalizuojanti apie kokybę, leidžianti išreikšti jausmus ir užjausti aplinkinius. Negatyvumas rodo įžvalgumą ir apdairumą, problemos gilumą. Dažnai pastebiu, kad kūrėjas pasiekė naują lygį, kai pradeda reikšti nepasitikėjimą tuo, dėl ko anksčiau buvo nedrąsus ir nepasitikėjęs. Žmonės savo nuomone demonstruoja protingumą ir pasitikėjimą. Negalite atmesti negatyvumo išraiškos, tai būtų orveliška.
Tačiau negatyvumą reikia dozuoti ir subalansuoti su kitomis svarbiomis žmogaus savybėmis: empatija, kantrybe, supratimu ir humoru. Visada galite pasakyti žmogui, kad jis suklydo, nerėkdamas ir nekeikdamasis. Nenuvertinkite šio požiūrio: jei kas nors be jokių emocijų jums pasakys, kad rimtai suklydote, tai tikrai baisu.
Tuo metu, prieš keletą metų, generalinis direktorius kalbėjo su manimi. Aptarėme dabartinę projekto būklę, tada jis paklausė, kaip aš jaučiuosi. Atsakiau, kad viskas gerai, projektas juda, dirbame lėtai, galbūt kažką praleidau ir reikia persvarstyti. Jis sakė girdėjęs, kaip su kolegomis biure dalinuosi pesimistiškesnėmis mintimis, ir kiti tai pastebėjo. Jis paaiškino, kad jei kiltų abejonių, galėčiau jas visiškai išreikšti vadovybei, bet ne „nuleisti“. Kaip vadovaujantis inžinierius, turiu atsižvelgti į tai, kaip mano žodžiai veikia kitus, nes turiu daug įtakos, net jei to nesuvokiu. Ir jis man visa tai labai maloniai papasakojo, o galiausiai pasakė, kad jeigu aš tikrai taip jaučiuosi, tai turbūt reikia pagalvoti, ko noriu sau ir savo karjerai. Tai buvo neįtikėtinai švelnus pokalbis, „pasidėk arba išlipk iš savo vietos“. Padėkojau jam už informaciją apie tai, kaip per šešis mėnesius pasikeitęs požiūris paveikė kitus, kurių nepastebėjau.
Tai buvo nepaprasto, veiksmingo valdymo ir švelnaus požiūrio galios pavyzdys. Supratau, kad tik tarsi visiškai tikiu įmone ir jos galimybėmis siekti savo tikslų, tačiau iš tikrųjų kalbėjausi ir bendravau su kitais visai kitaip. Taip pat supratau, kad net ir skeptiškai vertindamas projektą, kuriame dirbau, neturėčiau rodyti savo jausmų kolegoms ir skleisti pesimizmą kaip užkratą, mažinantį mūsų sėkmės galimybes. Vietoj to galėčiau agresyviai perteikti tikrąją situaciją savo vadovybei. O jei pajusčiau, kad manęs neklauso, savo nesutikimą galėčiau išreikšti išeidama iš įmonės.
Pradėjusi eiti personalo vertinimo vadovo pareigas gavau naują galimybę. Kaip buvęs vyriausiasis inžinierius, labai atsargiai išreiškiu savo nuomonę apie mūsų (vis tobulėjantį) senąjį kodą. Norint patvirtinti pokytį, reikia įsivaizduoti esamą situaciją, bet niekur nepasieksite, jei užsimanysite dejuoti, pulsite ar panašiai. Galiausiai esu čia, kad atlikčiau užduotį ir neturėčiau skųstis kodu, kad jį suprasčiau, įvertinčiau ar ištaisyčiau.
Tiesą sakant, kuo labiau kontroliuoju savo emocinę reakciją į kodą, tuo geriau suprantu, kuo jis gali tapti, ir tuo mažiau jaučiu sumaištį. Kai išreiškiau save santūriai („čia turi būti kur toliau tobulėti“), džiuginau save ir kitus ir per daug nesureikšminau situacijos. Supratau, kad galiu stimuliuoti ir sumažinti negatyvumą kituose, būdamas tobulai (erzinančiai?) protingas ("jūs teisus, šis kodas gana blogas, bet mes jį patobulinsime"). Džiaugiuosi matydamas, kiek toli galiu nueiti Zen keliu.
Iš esmės aš nuolat mokausi ir mokausi svarbią pamoką: gyvenimas per trumpas, kad nuolat pykčiau ir kentėčiau skausmą.
Šaltinis: www.habr.com