Egy kódrészletet nézek. Valószínűleg ez a legrosszabb kód, amit valaha láttam. Egyetlen adatbázisrekord frissítéséhez lekéri a gyűjtemény összes rekordját, majd frissítési kérést küld az adatbázis minden rekordjára, még azokra is, amelyeket nem kell frissíteni. Van egy map függvény, amely egyszerűen visszaadja a neki átadott értéket. Vannak feltételes ellenőrzések a nyilvánvalóan azonos értékű változókra, csak különböző stílusokban vannak elnevezve (firstName и first_name). Minden UPDATE (frissítés) esetén a kód egy üzenetet küld egy másik várólistának, amelyet egy másik szerver nélküli függvény dolgoz fel, de amely az összes munkát egy másik gyűjteményhez végzi el ugyanazon adatbázisban. Említettem már, hogy ez a szerver nélküli függvény egy felhőalapú "szolgáltatásorientált architektúrából" származik, amely több mint 100 függvényt tartalmaz a környezetben?
Hogy tehet bárki ilyet? Eltakarom az arcomat, és hangosan zokogva nevetek. A kollégáim megkérdezik, mi történt, én pedig élénken elmesélem. A BulkDataImporter.js legrosszabb slágerei 2018-banMindenki együttérzően bólogat, és egyetért: hogy tehették ezt velünk?
Negativitás: Érzelmi eszköz a programozói kultúrában
A negativitás nagy szerepet játszik a programozásban. Beépült a kultúránkba, és arra használjuk, hogy megosszuk a tanultakat („te nem vagy az el fogod hinni, milyen volt az a kód?"), hogy frusztrációval együttérzést fejezzen ki („Jaj, istenem, MIÉRT csinálod ezt?"), hogy kedvező színben tüntesse fel magát („Soha nem tenném így nem tette meg"), hogy a felelősséget másra hárítsa („az ő kódja miatt vallottunk kudarcot, ami karbantarthatatlan”), vagy – ahogy az a leg„mérgezőbb” szervezetekben gyakori –, hogy a szégyenérzet révén másokat irányítson („mire gondoltál egyáltalán? Javítsd meg”).
A negativitás azért nagyon fontos a programozók számára, mert nagyon hatékony módja az érték közvetítésének. Egyszer részt vettem egy programozói kiképzőtáborban, és a diákok iparági kultúrájának megismertetésére a szokásos gyakorlat a mémek, történetek és videók bőséges kínálata volt, amelyek közül a legnépszerűbbek a következőket használták ki: Jó, ha érzelmi eszközöket tudunk használni a gyakorlatok címkézésére: Jó, Rossz, Csúnya, Ezt soha ne tedd, Soha. Az újonnan érkezőknek fel kell készülniük arra, hogy valószínűleg félreértik őket azok a kollégák, akik nem informatikai szakemberek. Hogy a barátaik millió dolláros alkalmazásötleteket kezdenek el nekik eladni. Hogy a régi kódok végtelen labirintusaiban kell majd eligazodniuk, miközben egy horda minotaurusz leselkedik a sarkon.
Amikor először kezdünk programozni tanulni, a „programozási tapasztalat” mélységéről alkotott felfogásunk mások érzelmi reakcióinak megfigyelésén alapul. Ez egyértelműen megmutatkozik a következő bejegyzésekben: , ahol sok kezdő programozó lóg. A humoros hozzászólások közül sok a negativitás különböző fokú árnyalataival van átitatva: csalódás, pesszimizmus, felháborodás, leereszkedés és így tovább. És ha ez nem elég, olvasd el a hozzászólásokat.
Azt vettem észre, hogy ahogy a programozók tapasztalatot szereznek, a negativitásuk egyre negatívabbá válik. Az újoncok, akik nincsenek tisztában a rájuk váró nehézségekkel, lelkesen és könnyen elhiszik, hogy ezek a nehézségek egyszerűen a tapasztalat és a tudás hiányának tudhatók be; és végül szembesülnek a helyzet valóságával.
Az idő múlásával tapasztalatot szereznek, és kifejlesztik a képességüket, hogy megkülönböztessék a jó kódot a rossztól. És amikor ez a pillanat elérkezik, a fiatal programozók frusztrációt tapasztalnak a nyilvánvalóan rossz kóddal való munka miatt. És ha csapatban dolgoznak (távolról vagy személyesen), gyakran átveszik tapasztaltabb kollégáik érzelmi szokásait. Ez gyakran fokozott negativitáshoz vezet, mivel a fiatal programozók most már elgondolkodva tudnak beszélni a kódról, és különbséget tudnak tenni a jó és a rossz között, ezzel is bizonyítva, hogy "képesek". Ez tovább táplálja a negativitást: a frusztráció megkönnyíti a kollégákkal való kötődést és a csoport részévé válást; a rossz kód kritizálása emeli a státuszodat és a professzionalizmusodat mások szemében. .
A negativitás felerősítése nem feltétlenül rossz dolog. A programozásról szóló viták, többek között, rendkívül a megírt kód minőségére összpontosítanak. A kód természete teljes mértékben meghatározza azt a funkciót, amelyet be kell töltenie (a hardvert, a hálózatépítést stb. figyelmen kívül hagyva), ezért fontos, hogy képesek legyünk kifejezni a véleményünket a kódról. Szinte minden vita arra redukálódik, hogy vajon elég jó-e a kód, és hogy elítéljük a rossz kód megnyilvánulásait olyan kifejezésekben, amelyek érzelmi színezete jellemzi a kód minőségét:
- "Ennek a modulnak sok logikai következetlensége van, és jó jelölt a jelentős teljesítményoptimalizálásra."
- "Ez a modul elég rossz, újra kell építenünk."
- "Ennek a modulnak nincs értelme, és át kell írni."
- "Ez a modul szörnyű, javítani kell."
- „Ez egy darab RAM, nem egy modul, még meg sem kellett írni, mi a fenét gondolt a szerzője?”
Egyébként pontosan ez az „érzelmi felszabadulás” az, ami miatt a fejlesztők „szexinek” nevezik a kódot, ami ritkán igazságos – kivéve, ha a PornHubnál dolgozol.
A probléma az, hogy az emberek furcsa, nyughatatlan, érzelmes lények, és bármilyen érzelem érzékelése és kifejezése megváltoztat minket: eleinte finoman, de idővel drámaian.
A negativitás csúszós lejtője
Néhány évvel ezelőtt informális csapatvezetőként interjúvoltam egy fejlesztőt. Nagyon kedveltük: okos volt, jó kérdéseket tett fel, technikailag jártas volt, és tökéletesen illett a kultúránkhoz. Különösen lenyűgözött a pozitivitása és a vállalkozó szelleme. Így hát felvettem.
Akkoriban már néhány éve dolgoztam a cégnél, és úgy éreztem, hogy a kultúránk nem túl hatékony. Kétszer, háromszor, és még néhányszor megpróbáltuk piacra dobni a terméket, mielőtt megérkeztem, ami hatalmas átdolgozási költségekhez vezetett, és ezalatt semmivel sem értünk célba, csak hosszú éjszakákkal, szoros határidőkkel és állítólagosan működő termékekkel. És bár még mindig keményen dolgoztam, szkeptikus voltam a vezetőség által kitűzött legújabb határidővel kapcsolatban. Még mellékesen káromkodtam is, amikor a kód bizonyos aspektusait megbeszéltük a kollégáimmal.
Így nem volt meglepő – bár én meglepődtem –, hogy néhány héttel később ugyanez az új fejlesztő ugyanazt a negatív érzést fejezte ki, mint én (beleértve a káromkodást is). Rájöttem, hogy egy másik cégnél, más kultúrával másképp viselkedett volna. Egyszerűen alkalmazkodott az általam teremtett kultúrához. Bűntudat lett úrrá rajtam. Szubjektív tapasztalataim miatt pesszimizmust csepegtettem egy újoncba, akit teljesen másnak tartottam. Még ha nem is volt igazán ilyen, és csak megpróbált annak látszani, hogy be tud illeszkedni, a saját szar hozzáállásomat erőltettem rá. És bármit is mondok, még ha tréfából vagy csak futólag is, csúnya módon azzá válik, amit az emberek hisznek.
A negativitás útjai
Térjünk vissza korábbi kezdő programozóinkhoz, akik némi bölcsességre és tapasztalatra tettek szert: jobban megismerték a programozási ipart, és megértették, hogy a rossz kód mindenhol jelen van, elkerülhetetlen. Még a legfejlettebb, minőségre összpontosító vállalatoknál is megtalálható (és hadd tegyem hozzá: úgy tűnik, a modernitás sem véd meg minket a rossz kódtól).
Jó forgatókönyv. Idővel a fejlesztők elkezdik elfogadni, hogy a rossz kód a szoftverek valósága, és hogy az ő feladatuk a fejlesztése. És ha a rossz kód elkerülhetetlen, akkor nincs értelme nagy ügyet csinálni belőle. Átveszik a Zent, a velük szemben álló problémák vagy kihívások megoldására összpontosítva. Megtanulják, hogyan mérjék pontosan és kommunikálják a szoftverek minőségét a vállalkozóknak, évek tapasztalatára támaszkodva jól megalapozott becsléseket írnak, és végül nagylelkű jutalmakat kapnak a vállalkozás számára nyújtott hihetetlen és tartós értékükért. Olyan jól végzik a munkájukat, hogy 10 millió dolláros bónuszt kapnak, és nyugdíjba vonulva azt csinálhatnak életük hátralévő részében, amit akarnak (kérlek, ne vedd ezt névértéken).
A másik forgatókönyv a sötétség útja. Ahelyett, hogy a rossz kódot elkerülhetetlennek fogadnák el, a fejlesztők magukra vállalják, hogy a programozási világban minden rosszat hirdetnek, hogy leküzdhessék. Számos jó okból megtagadják a meglévő rossz kód fejlesztését: „Az embereknek jobban kellene tudniuk, és nem kellene ennyire ostobáknak lenniük”; „Ez kellemetlen”; „Rossz az üzletnek”; „Bizonyítja, milyen okos vagyok”; „Ha nem mondom el az embereknek, milyen rossz ez a kód, az egész cég az óceánba omlik”; és így tovább.
Mivel valószínűleg képtelenek megvalósítani a kívánt változtatásokat, mivel a vállalkozásnak sajnos folyamatosan fejlődnie kell, és nem engedheti meg magának, hogy időt pazaroljon a kód minőségével való aggódásra, az ilyen emberek panaszkodóként szereznek hírnevet. Magas szintű kompetenciájukért ünneplik őket, mégis a vállalat peremére száműzik őket, ahol nem jelentenek kellemetlenséget, de továbbra is karbantartják a kritikus rendszereket. Az új fejlesztési lehetőségekhez való hozzáférés hiányában elveszítik képességeiket, és nem tudnak megfelelni az iparági követelményeknek. Negatív gondolkodásuk keserűségbe csap át, és végül az egójukat simogatják azzal, hogy húszéves diákokkal vitatkoznak arról, hogy milyen utat járt be szeretett régi technológiájuk, és miért működik még mindig ilyen jól. Végül nyugdíjba vonulnak, és öregkorukat madarakat káromkodva töltik.
A valóság valószínűleg valahol e két véglet között van.
Néhány vállalat rendkívül sikeresen alakított ki rendkívül negatív, bezárkózott és akaraterős kultúrát (mint például a Microsoft a felemelkedése előtt). ) – ezek gyakran olyan vállalatok, amelyek kiválóan illeszkednek a termék-piachoz, és a lehető leggyorsabb növekedésre van szükségük; vagy olyan vállalatok, amelyekben az irányítás és az ellenőrzés hierarchiája van (az Apple Jobs fénykorában), ahol mindenki azt teszi, amit mondanak neki. A modern üzleti kutatások (és a józan ész) azonban azt sugallják, hogy a maximális találékonysághoz, ami vállalati innovációhoz és magas egyéni termelékenységhez vezet, az alacsony stressz elengedhetetlen a folyamatos kreatív és módszeres gondolkodás támogatásához. És rendkívül nehéz kreatív munkát végezni, amely a vitára épül, ha folyamatosan aggódsz amiatt, hogy mit fognak mondani a kollégáid a kódod minden egyes soráról.
A negativitás mesterséges popkultúra
Manapság a mérnökök hozzáállása minden eddiginél nagyobb figyelmet kap. A "„Egyre több vicc és történet kering a Twitteren olyan emberekről, akik azért hagyták ott ezt a szakmát, mert nem tudták (vagy nem akarták) elviselni a kívülállókkal szembeni ellenségeskedést és rosszindulatot. Még Linus Torvalds is…” Az évek során más Linux fejlesztőkkel szembeni ellenségeskedése és kritikája vitát váltott ki e megközelítés hatékonyságáról.
Vannak, akik még mindig védik Linus jogát a túlzott kritikához – azok, akiknek sokat kellene tudniuk a „mérgező negativitás” előnyeiről és hátrányairól. Igen, az udvariasság kulcsfontosságú (sőt alapvető), de ha összefoglalnánk azokat az okokat, amiért sokan közülünk megengedjük, hogy a negatív megnyilvánulások „mérgezővé” fajuljanak, paternalisztikusnak vagy gyerekesnek hangzanak: „Megérdemlik, mert idióták”, „Biztosítania kell, hogy ne tegyék meg újra”, „Ha ezt nem tették volna, nem kellene rájuk kiabálnia”, és így tovább. Egy példa arra, hogy milyen hatással van egy vezető érzelmi reakciója a programozói közösségre, a Ruby betűszó, a MINASWAN – „Matz kedves, tehát mi is kedvesek vagyunk”.
Észrevettem, hogy a „megöljük a bolondot” megközelítés sok lelkes híve gyakran nagyon aggódik kódja minősége és helyessége miatt, azonosulva a munkájával. Sajnos gyakran összekeverik a határozottságot a merevséggel. Ennek a megközelítésnek a hibája abból az egyszerű, emberi, mégis improduktív vágyból fakad, hogy másokkal szemben felsőbbrendűnek érezzék magukat. Azok az emberek, akik hódolnak ennek a vágynak, a sötétség útján ragadnak.
A programozási világ gyorsan növekszik, és eléri konténerének – a nem programozási világnak – a határait (vagy a programozási világ a nem programozási világ konténerje? Jó kérdés).
Ahogy az iparágunk gyorsuló ütemben bővül, és a programozás egyre elérhetőbbé válik, a „tech-szakértők” és a „normálisok” közötti szakadék rohamosan csökken. A programozás világa egyre inkább ki van téve azoknak az embereknek az interperszonális interakcióinak, akik a korai tech-boom elszigetelt „nerd” kultúrájában nőttek fel, és ők fogják alakítani az új programozási világot. És függetlenül a társadalmi kérdésekről vagy generációkról szóló vitáktól, a kapitalizmus nevében elért hatékonyság a vállalati kultúrában és a felvételi gyakorlatban is megnyilvánul: a legjobb cégek egyszerűen nem alkalmaznak senkit, aki nem tud semlegesen, nemhogy pozitívan kommunikálni másokkal.
Amit a negativitásról tanultam
Ha hagyjuk, hogy a túlzott negativitás irányítsa a gondolkodásunkat és az interakcióinkat, és toxikussá váljon, az veszélyes a termékfejlesztő csapatok, és költséges a vállalkozások számára. Számtalan projektet láttam (és hallottam másokról is), amelyek szétestek, majd nagy költséggel teljesen újjáépítették őket, mert egy megbízható fejlesztő neheztelt egy technológiára, egy másik fejlesztőre, vagy akár egyetlen fájlra, amelyet a teljes kódbázis minőségének képviseletére választottak.
A negativitás demoralizáló és kapcsolatokat tönkretesz. Soha nem fogom elfelejteni, hogyan leszidott egy kollégám, amiért rossz fájlba tettem a CSS-t; ez felzaklatott, és napokig megakadályozott abban, hogy összeszedjem a gondolataimat. És a jövőben valószínűleg nem fogok ilyen embert a csapatom közelébe engedni (de ki tudja, az emberek változnak).
Végül a negatív .
Szerintem így kellene kinéznie egy mosolyokról szóló mesterkurzusnak.
Természetesen ez nem érv a boldogságtól való ragyogás, tízmilliárd emoji beillesztése minden pull requestbe, vagy egy mosolyworkshopon való részvétel mellett (nos, ha ezt akarod, az rendben van). A negativitás a programozás (és az emberi élet) kulcsfontosságú része, a minőséget jelzi, lehetővé teszi számunkra, hogy érzéseket fejezzünk ki és együttérezzünk embertársainkkal. A negativitás belátást és körültekintést, a probléma mélységét mutatja. Gyakran észreveszem, hogy egy fejlesztő új szintre lépett, amikor hitetlenkedését kezdi kifejezni olyan dolgokban, amelyekben korábban félénk és bizonytalan volt. Az emberek a véleményükön keresztül mutatnak körültekintést és magabiztosságot. A negativitás kifejezése lehetetlen; az orwelli lenne.
A negativitást azonban mérni és egyensúlyba hozni kell más fontos emberi tulajdonságokkal: empátiával, türelemmel, megértéssel és humorral. Mindig elmondhatod valakinek, hogy elrontott valamit anélkül, hogy kiabálnál vagy káromkodnál. Ne becsüld alá ezt a megközelítést: igazán ijesztő, ha minden érzelem nélkül közlik veled, hogy komolyan elrontottad.
Akkoriban, néhány évvel ezelőtt, a vezérigazgató beszélt velem. Megbeszéltük a projekt jelenlegi állapotát, majd megkérdezte, hogy érzem magam. Mondtam neki, hogy minden rendben van, a projekt halad előre, folyamatosan haladunk, és talán kihagytam valamit, és újra kellene gondolnom. Azt mondta, hallotta, hogy pesszimistább gondolatokat osztottam meg a kollégákkal az irodában, és hogy mások is észrevették ezt. Elmagyarázta, hogy ha bármilyen aggályom van, azt teljes mértékben kifejezhetem a vezetőségnek, de nem "csatornázhatom le" őket. Vezető mérnökként oda kell figyelnem arra, hogy a szavaim hogyan hatnak másokra, mert nagy befolyással bírok, még akkor is, ha nem is tudatosul bennem. Mindezt nagyon kedvesen mondta, és azzal zárta, hogy ha valóban így érzem, valószínűleg el kell gondolkodnom azon, hogy mit akarok magamtól és a karrieremtől. Ez egy hihetetlenül gyengéd, "szedd össze magad, vagy tűnj el" típusú beszélgetés volt. Megköszöntem neki a tájékoztatást arról, hogy a hozzáállásom, amely hat hónap alatt megváltozott, hogyan befolyásolja másokat anélkül, hogy észrevenném.
Ez a figyelemre méltó, hatékony vezetés és a gyengéd megközelítés erejének példája volt. Rájöttem, hogy bár csak látszólag hittem a vállalatban és céljai elérésének képességében, a valóságban egészen másképp kommunikáltam és beszéltem másokkal. Azt is felismertem, hogy még ha szkeptikus voltam is a projekttel kapcsolatban, amin dolgoztam, nem kellett volna hagynom, hogy a pesszimizmusom átragadjon a kollégáimra, és fertőzésként terjedjen, csökkentve a siker esélyeit. Ehelyett agresszívan kommunikálhattam volna a helyzet valóságát a vezetőségem felé. És ha úgy éreztem volna, hogy nem figyelnek rám, kifejezhettem volna az egyet nem értésemet azzal, hogy elhagyom a vállalatot.
Új lehetőséget kaptam, amikor átvettem a Teljesítmény-felülvizsgálat vezetőjeként. Korábbi vezető mérnökként nagyon körültekintően ítélem meg, hogyan fejezem ki a véleményemet a (folyamatosan fejlődő) régi kódunkról. Egy változtatás jóváhagyásához meg kell érteni a jelenlegi helyzetet, de sehova sem jutsz, ha beleragadsz a nyafogásba, a támadásba vagy bármi hasonlóba. Végső soron azért vagyok itt, hogy elvégezzem a munkát, és nem kellene panaszkodnom a kódra ahhoz, hogy megértsem, kiértékeljem vagy kijavítsam.
Valójában minél jobban visszafogom az érzelmi reakcióimat a kóddal kapcsolatban, annál jobban megértem, hogy mi lehet az, és annál kevésbé érzem magam zavartan. Amikor visszafogottan fejeztem ki magam („biztos van itt még mit javítani”), örömet szereztem magamnak és másoknak is, és nem vettem túl személyeskedésre a helyzetet. Rájöttem, hogy azzal, hogy tökéletesen (irritálóan?) ésszerű vagyok („igazad van, ez a kód elég rossz, de majd javítunk rajta”), képes vagyok mások negativitását serkenteni és csökkenteni. Örülök, hogy milyen messzire jutottam a zen úton.
Lényegében folyamatosan tanulok és újra meg újra megtanulok egy fontos leckét: az élet túl rövid ahhoz, hogy állandóan dühösnek és szenvedőnek legyünk.
Forrás: will.com
