Mă uit la o bucată de cod. Acesta poate fi cel mai prost cod pe care l-am văzut vreodată. Pentru a actualiza doar o înregistrare din baza de date, preia toate înregistrările din colecție și apoi trimite o solicitare de actualizare fiecărei înregistrări din baza de date, chiar și celor care nu trebuie actualizate. Există o funcție de hartă care returnează pur și simplu valoarea transmisă acesteia. Există teste condiționale pentru variabile cu aparent aceeași valoare, doar numite în stiluri diferite (firstName и first_name). Pentru fiecare UPDATE, codul trimite un mesaj la o altă coadă, care este gestionată de o funcție diferită fără server, dar care face toată munca pentru o colecție diferită în aceeași bază de date. Am menționat că această funcție fără server este dintr-o „arhitectură orientată spre servicii” bazată pe cloud, care conține peste 100 de funcții în mediu?
Cum a fost chiar posibil să faci asta? Îmi acopăr fața și plâng vizibil prin râs. Colegii mei întreabă ce s-a întâmplat, iar eu îl povestesc în culori Cele mai grave succese ale BulkDataImporter.js 2018. Toți dau din cap cu simpatie spre mine și sunt de acord: cum ne-au putut face asta?
Negativitatea: un instrument emoțional într-o cultură a programatorului
Negativitatea joacă un rol important în programare. Este încorporat în cultura noastră și este folosit pentru a împărtăși ceea ce am învățat ("tu nu vei crede, cum era acel cod!”), pentru a-și exprima simpatia prin frustrare („Doamne, DE CE să faci asta?”), pentru a se arăta („Nu aș face niciodată astfel nu a făcut-o”), a da vina pe altcineva („am eșuat din cauza codului lui, care este imposibil de menținut”), sau, așa cum se obișnuiește în cele mai „toxice” organizații, să-i controlăm pe alții printr-un sentiment de rușine („La ce te gândeai?”? corect”).
Negativitatea este atât de importantă pentru programatori, deoarece este o modalitate foarte eficientă de a transmite valoare. Am participat odată la o tabără de programare, iar practica standard de a insufla o cultură a industriei studenților a fost de a furniza cu generozitate meme-uri, povești și videoclipuri, dintre care cele mai populare au fost exploatate. . Este bine să poți folosi instrumente emoționale pentru a identifica Bunul, Răul, Urâtul, Nu Fă Asta, Niciodată. Este necesar să-i pregătim pe noii veniți pentru faptul că probabil vor fi înțeleși greșit de colegii care sunt departe de IT. Că prietenii lor vor începe să le vândă idei de aplicații de milioane de dolari. Că vor trebui să hoinărească prin labirinturi nesfârșite de cod învechit, cu o grămadă de minotauri după colț.
Când învățăm pentru prima dată să programăm, înțelegerea noastră a profunzimii „experienței de programare” se bazează pe observarea reacțiilor emoționale ale altor oameni. Acest lucru se vede clar din postările din , unde o mulțime de programatori începători se întâlnesc. Multe dintre cele pline de umor sunt, într-o măsură sau alta, colorate cu diferite nuanțe de negativitate: dezamăgire, pesimism, indignare, condescendență și altele. Și dacă acest lucru nu vi se pare suficient, citiți comentariile.
Am observat că, pe măsură ce programatorii câștigă experiență, ei devin din ce în ce mai negativi. Începătorii, neconștienți de dificultățile care îi așteaptă, încep cu entuziasm și dorința de a crede că cauza acestor dificultăți este pur și simplu lipsa de experiență și de cunoștințe; și în cele din urmă se vor confrunta cu realitatea lucrurilor.
Timpul trece, ei dobândesc experiență și devin capabili să distingă Codul Bun de Rău. Și când vine acel moment, tinerii programatori simt frustrarea de a lucra cu cod evident prost. Iar dacă lucrează în echipă (de la distanță sau în persoană), adoptă adesea obiceiurile emoționale ale colegilor mai experimentați. Acest lucru duce adesea la o creștere a negativității, deoarece tinerii pot vorbi acum în mod gânditor despre cod și îl pot împărți în rău și bun, arătând astfel că sunt „în cunoștință”. Acest lucru întărește și mai mult negativul: din dezamăgire, este ușor să te înțelegi cu colegii și să devii parte dintr-un grup; criticarea Bad Code îți crește statutul și profesionalismul în ochii celorlalți: .
Creșterea negativității nu este neapărat un lucru rău. Discuțiile despre programare, printre altele, sunt extrem de concentrate pe calitatea codului scris. Ceea ce este codul definește complet funcția pe care este intenționat să o îndeplinească (hardware, rețea, etc.), deci este important să vă puteți exprima părerea despre acel cod. Aproape toate discuțiile se rezumă la dacă codul este suficient de bun și la condamnarea chiar manifestelor codului rău în termeni a căror conotație emoțională caracterizează calitatea codului:
- „Există o mulțime de inconsecvențe logice în acest modul, este un bun candidat pentru optimizarea semnificativă a performanței.”
- „Acest modul este destul de prost, trebuie să-l refactorăm.”
- „Acest modul nu are sens, trebuie rescris”.
- „Acest modul este nasol, trebuie corectat.”
- „Aceasta este o bucată de berbec, nu un modul, nu trebuia deloc scrisă, la ce naiba se gândea autorul ei.”
Apropo, această „lansare emoțională” este cea care îi face pe dezvoltatori să numească codul „sexy”, ceea ce este rareori corect - cu excepția cazului în care lucrezi la PornHub.
Problema este că oamenii sunt creaturi ciudate, neliniştite, emoţionale, iar percepţia şi exprimarea oricărei emoţii ne schimbă: la început subtil, dar în timp, dramatic.
O pantă alunecoasă tulbure de negativitate
În urmă cu câțiva ani, am fost un lider de echipă informal și am intervievat un dezvoltator. Ne-a plăcut foarte mult: era inteligent, punea întrebări bune, cunoștea tehnologia și se potrivea bine cu cultura noastră. Am fost deosebit de impresionat de pozitivitatea lui și de cât de întreprinzător părea. Și l-am angajat.
În acel moment, lucram în companie de câțiva ani și simțeam că cultura noastră nu era foarte eficientă. Am încercat să lansăm produsul de două ori, de trei ori și de încă două ori înainte de a sosi eu, ceea ce a dus la cheltuieli mari de reluare, timp în care nu aveam nimic de arătat decât nopți lungi, termene strânse și produse care au funcționat. Și deși încă munceam din greu, eram sceptic în privința ultimului termen care ni-a fost atribuit de conducere. Și a înjurat dezinvolt când a discutat unele aspecte ale codului cu colegii mei.
Așa că nu a fost surprinzător – deși am fost surprins – că, câteva săptămâni mai târziu, același dezvoltator nou a spus aceleași lucruri negative pe care le-am făcut eu (inclusiv înjurături). Mi-am dat seama că se va comporta diferit într-o companie diferită, cu o cultură diferită. S-a adaptat la cultura pe care am creat-o. Am fost copleșit de un sentiment de vinovăție. Datorită experienței mele subiective, am insuflat pesimismul unui nou venit pe care îl percepeam ca fiind complet diferit. Chiar dacă chiar nu era așa și își făcea doar o apariție pentru a arăta că se poate potrivi, mi-am impus atitudinea de rahat asupra lui. Și tot ceea ce este spus, chiar și în glumă sau în treacăt, are maniera proastă de a se transforma în ceea ce se crede.
Cai negative
Să revenim la foștii noștri programatori începători, care au câștigat puțină înțelepciune și experiență: s-au familiarizat mai mult cu industria de programare și înțeleg că codul rău este peste tot, nu poate fi evitat. Apare chiar și în cele mai avansate companii axate pe calitate (și permiteți-mi să remarc: aparent, modernitatea nu protejează împotriva codului rău).
Bun scenariu. De-a lungul timpului, dezvoltatorii încep să accepte că codul prost este o realitate a software-ului și că sarcina lor este să-l îmbunătățească. Și că, dacă codul prost nu poate fi evitat, atunci nu are rost să faci tam-tam în legătură cu asta. Ei iau calea Zen, concentrându-se pe rezolvarea problemelor sau sarcinilor cu care se confruntă. Ei învață cum să măsoare și să comunice cu precizie calitatea software-ului proprietarilor de afaceri, să scrie estimări bine fundamentate pe baza anilor de experiență și, în cele din urmă, primesc recompense generoase pentru valoarea lor incredibilă și continuă pentru afacere. Își fac treaba atât de bine încât sunt plătiți cu 10 milioane de dolari în bonusuri și se retrag pentru a face ceea ce își doresc pentru tot restul vieții (te rog să nu o iei de la sine înțeles).
Un alt scenariu este calea întunericului. În loc să accepte codul prost ca pe o inevitabilitate, dezvoltatorii își asumă responsabilitatea să spună tot ce este rău în lumea programării, astfel încât să-l poată depăși. Ei refuză să îmbunătățească codul prost existent din multe motive întemeiate: „oamenii ar trebui să știe mai multe și să nu fie atât de proști”; „este neplăcut”; „acest lucru este rău pentru afaceri”; „asta dovedește cât de inteligent sunt”; „Dacă nu vă spun ce cod prost este acesta, întreaga companie va cădea în ocean” și așa mai departe.
Cu siguranță, incapabili să implementeze modificările pe care le doresc, deoarece afacerea, din păcate, trebuie să continue să se dezvolte și nu poate petrece timp îngrijorându-se de calitatea codului, acești oameni câștigă o reputație de reclamanți. Aceștia sunt păstrați pentru competența lor ridicată, dar sunt împinși la marginile companiei, unde nu vor enerva mulți oameni, dar vor sprijini totuși funcționarea sistemelor critice. Fără acces la noi oportunități de dezvoltare, ei își pierd competențele și nu mai satisfac cerințele industriei. Negativitatea lor se transformă în amărăciune amară și, ca urmare, își hrănesc ego-urile, certându-se cu studenții de douăzeci de ani despre călătoria pe care a parcurs-o vechea lor tehnologie preferată și de ce este încă atât de fierbinte. Ei ajung să se pensioneze și să-și trăiască bătrânețea înjurând păsări.
Realitatea se află probabil undeva între aceste două extreme.
Unele companii au avut succes în crearea unor culturi extrem de negative, insulare, cu voință puternică (cum ar fi Microsoft înainte de ) - de multe ori sunt companii cu produse care se potrivesc perfect pieței și nevoia de a crește cât mai repede; sau companii cu o ierarhie de comandă și control (Apple în cei mai buni ani de Jobs), unde fiecare face ce i se spune. Cu toate acestea, cercetările moderne în afaceri (și bunul simț) sugerează că ingeniozitatea maximă, care duce la inovație în companii și la productivitate ridicată la indivizi, necesită niveluri scăzute de stres pentru a susține gândirea creativă și metodică continuă. Și este extrem de dificil să faci o muncă creativă, bazată pe discuții, dacă îți faci în mod constant griji cu privire la ceea ce vor avea de spus colegii tăi despre fiecare linie a codului tău.
Negativitatea este ingineria culturii pop
Astăzi, se acordă mai multă atenție atitudinii inginerilor decât oricând. În organizațiile de inginerie, regula „". Din ce în ce mai multe anecdote și povești apar pe Twitter despre oameni care au părăsit această meserie pentru că nu au putut (nu ar continua) să suporte ostilitatea și rea voință față de cei din afară. Chiar și Linus Torvalds ani de ostilitate și critici față de alți dezvoltatori Linux - acest lucru a dus la dezbateri despre eficacitatea acestei abordări.
Unii îi apără în continuare dreptul lui Linus de a fi foarte critic – cei care ar trebui să știe multe despre avantajele și dezavantajele „negativității toxice”. Da, civilitatea este extrem de importantă (chiar fundamentală), dar dacă rezumăm motivele pentru care mulți dintre noi permitem ca exprimarea unor opinii negative să se transforme în „toxicitate”, aceste motive par paternaliste sau adolescentine: „merită pentru că sunt idioți. „, „trebuie să fie sigur că nu o vor mai face”, „dacă nu ar fi făcut asta, nu ar fi trebuit să țipe la ei” și așa mai departe. Un exemplu al impactului pe care reacțiile emoționale ale unui lider îl au asupra unei comunități de programare este acronimul comunității Ruby MINASWAN - „Matz este drăguț, așa că suntem drăguți”.
Am observat că mulți susținători înfocați ai abordării „ucide un prost” de multe ori țin foarte mult de calitatea și corectitudinea codului, identificându-se cu munca lor. Din păcate, ele confundă adesea duritatea cu rigiditatea. Dezavantajul acestei poziții provine din dorința umană simplă, dar neproductivă de a se simți superior celorlalți. Oamenii care devin cufundați în această dorință devin blocați pe calea întunericului.
Lumea programării este în creștere rapidă și se împinge împotriva limitelor containerului său - lumea non-programarii (sau este lumea programării un container pentru lumea non-programare? Bună întrebare).
Pe măsură ce industria noastră se extinde într-un ritm din ce în ce mai mare și programarea devine mai accesibilă, distanța dintre „techieni” și „normali” se închide rapid. Lumea programării este din ce în ce mai expusă interacțiunilor interpersonale ale oamenilor care au crescut în cultura izolată a tocilarului a începutului boom-ului tehnologic și ei sunt cei care vor modela noua lume a programării. Și indiferent de orice argument social sau generațional, eficiența în numele capitalismului va apărea în cultura companiei și practicile de angajare: cele mai bune companii pur și simplu nu vor angaja pe nimeni care nu poate interacționa neutru cu ceilalți, darămite să aibă relații bune.
Ce am învățat despre negativitate
Dacă permiteți prea multă negativitate să vă controleze mintea și interacțiunile cu oamenii, transformându-se în toxicitate, atunci este periculos pentru echipele de produse și costisitor pentru afaceri. Am văzut (și am auzit de) nenumărate proiecte care s-au prăbușit și au fost complet reconstruite cu o cheltuială mare, deoarece un dezvoltator de încredere a avut o ranchiune față de tehnologie, alt dezvoltator sau chiar și un singur fișier ales pentru a reprezenta calitatea întregii baze de cod.
Negativitatea demoralizează și distruge relațiile. Nu voi uita niciodată cum m-a certat un coleg că am pus CSS într-un fișier greșit, m-a supărat și nu mi-a permis să-mi adun gândurile timp de câteva zile. Și în viitor, este puțin probabil să permit unei astfel de persoane să fie lângă una dintre echipele mele (dar cine știe, oamenii se schimbă).
În sfârșit, negativul .
Cred că așa ar trebui să arate o clasă de master despre zâmbete.
Desigur, acesta nu este un argument în favoarea radiației de fericire, a inserării a zece miliarde de emoticoane în fiecare cerere de tragere sau a merge la o clasă de master despre zâmbete (nu, ei bine, dacă asta vrei, atunci nicio problemă). Negativitatea este o parte extrem de importantă a programării (și a vieții umane), semnalând calitatea, permițând cuiva să-și exprime sentimentele și să se compaseze cu semenii. Negativitatea indică perspicacitatea și prudența, profunzimea problemei. Observ adesea că un dezvoltator a atins un nou nivel atunci când începe să-și exprime neîncrederea în ceea ce era anterior timid și nesigur. Oamenii demonstrează rezonabil și încredere în opiniile lor. Nu poți respinge expresia negativității, asta ar fi orwellian.
Cu toate acestea, negativitatea trebuie dozată și echilibrată cu alte calități umane importante: empatie, răbdare, înțelegere și umor. Poți oricând să-i spui unei persoane că a greșit fără să țipe sau să înjure. Nu subestima această abordare: dacă cineva îți spune fără nicio emoție că ai greșit serios, este cu adevărat înfricoșător.
Acea dată, acum câțiva ani, CEO-ul mi-a vorbit. Am discutat despre stadiul actual al proiectului, apoi m-a întrebat cum mă simt. I-am răspuns că totul este în regulă, proiectul se mișcă, lucram încet, poate am omis ceva și trebuie să fie reconsiderat. A spus că m-a auzit împărtășind gânduri mai pesimiste cu colegii de la birou și că și alții au observat acest lucru. El a explicat că, dacă aveam îndoieli, le-aș putea exprima pe deplin conducerii, dar nu „le dau jos”. În calitate de inginer principal, trebuie să fiu atent la felul în care cuvintele mele îi afectează pe ceilalți, deoarece am multă influență chiar dacă nu îmi dau seama. Și mi-a spus toate astea foarte amabil și, în cele din urmă, a spus că, dacă chiar mă simt așa, atunci probabil că trebuie să mă gândesc la ce vreau pentru mine și cariera mea. A fost o conversație incredibil de blândă. I-am mulțumit pentru informațiile despre modul în care atitudinea mea schimbată de-a lungul a șase luni îi afecta pe alții neobservați de mine.
A fost un exemplu de management remarcabil, eficient și puterea unei abordări soft. Mi-am dat seama că doar părea că am încredere deplină în companie și în capacitatea acesteia de a-și atinge obiectivele, dar în realitate am vorbit și am comunicat cu ceilalți într-un mod complet diferit. De asemenea, mi-am dat seama că, chiar dacă mă simțeam sceptic față de proiectul la care lucram, nu ar trebui să le arăt colegilor sentimentele mele și să răspândesc pesimismul ca pe o contagiune, reducându-ne șansele de succes. În schimb, aș putea transmite în mod agresiv situația reală conducerii mele. Și dacă simțeam că nu mă ascultă, puteam să-mi exprim dezacordul părăsind compania.
Am primit o nouă oportunitate când am preluat funcția de șef evaluare personal. În calitate de fost inginer șef, sunt foarte atent în a-mi exprima părerile despre codul nostru moștenit (în continuă îmbunătățire). Pentru a aproba o schimbare, trebuie să vă imaginați situația actuală, dar nu veți ajunge nicăieri dacă vă bateți în gemete, atacuri sau altele asemenea. În cele din urmă, sunt aici pentru a finaliza o sarcină și nu ar trebui să mă plâng de cod pentru a-l înțelege, a-l evalua sau a remedia.
De fapt, cu cât îmi controlez mai mult reacția emoțională la cod, cu atât înțeleg mai mult ce ar putea deveni și cu atât simt mai puțină confuzie. Când m-am exprimat cu reținere („trebuie să fie loc de îmbunătățiri suplimentare aici”), mă făceam pe mine și pe ceilalți fericiți și nu luam situația prea în serios. Mi-am dat seama că aș putea stimula și reduce negativitatea celorlalți fiind perfect (enervant?) rezonabil („ai dreptate, acest cod este destul de prost, dar îl vom îmbunătăți”). Mă bucur să văd cât de departe pot merge pe calea Zen.
În esență, învăț și reînvăț constant o lecție importantă: viața este prea scurtă pentru a fi în mod constant furios și în durere.
Sursa: www.habr.com