Harag a kódra: programozók és negativitás

Harag a kódra: programozók és negativitás

Egy kódrészletet nézek. Talán ez a legrosszabb kód, amit valaha láttam. Ha csak egy rekordot szeretne frissíteni az adatbázisban, akkor lekéri a gyűjtemény összes rekordját, majd frissítési kérelmet küld az adatbázis minden rekordjához, még azokhoz is, amelyeket nem kell frissíteni. Van egy térképfüggvény, amely egyszerűen visszaadja a neki átadott értéket. Léteznek feltételes tesztek a látszólag azonos értékű változókhoz, csak különböző stílusokban (firstName и first_name). Minden FRISSÍTÉS esetén a kód üzenetet küld egy másik sorba, amelyet egy másik szerver nélküli függvény kezel, de amely ugyanabban az adatbázisban egy másik gyűjteménynél végzi el az összes munkát. Említettem már, hogy ez a szerver nélküli funkció egy felhő alapú „szolgáltatás-orientált architektúrából” származik, amely több mint 100 funkciót tartalmaz a környezetben?

Hogy volt egyáltalán lehetséges ezt megtenni? Eltakarom az arcom, és láthatóan zokogok a nevetésemtől. A kollégáim megkérdezik, mi történt, én pedig színekkel mesélem el újra A BulkDataImporter.js 2018 legrosszabb slágerei. Mindenki együtt érzően bólint felém, és egyetért: hogy tehették ezt velünk?

Negativitás: érzelmi eszköz a programozói kultúrában

A negativitás fontos szerepet játszik a programozásban. Kultúránkba beágyazott, és arra használjuk, hogy megosszuk, amit tanultunk („te nem elhiszed, milyen volt ez a kód!”), együttérzés kifejezésére a frusztráción keresztül („Istenem, MIÉRT tegye ezt?”), hogy megmutassa magát („Soha nem tenném” így nem tette meg”), mást hibáztatni („az ő kódja miatt kudarcot vallottunk, amit nem lehet fenntartani”), vagy ahogy az a „legmérgezőbb” szervezetekben szokás, másokat irányítani egy szégyenérzet („Mire gondoltál?”? Helyes”).

Harag a kódra: programozók és negativitás

A negativitás annyira fontos a programozók számára, mert ez egy nagyon hatékony módja az érték közvetítésének. Egyszer részt vettem egy programozótáborban, és az ipari kultúra meghonosításának szokásos gyakorlata az volt, hogy nagylelkűen mémeket, történeteket és videókat szállítottam, amelyek közül a legnépszerűbbek a programozók frusztrációja, amikor szembesülnek az emberek félreértésével. Jó, ha érzelmi eszközökkel azonosítható a Jó, a Rossz, a Csúnya, Ne tedd, Soha. Az újoncokat fel kell készíteni arra, hogy valószínűleg félreértik őket az informatikától távol álló kollégák. Hogy a barátaik millió dolláros alkalmazásötleteket kezdenek el árulni nekik. Hogy az elavult kód végtelen labirintusain kell átmenniük egy csomó minotauruszsal a sarkon.

Amikor először megtanulunk programozni, a „programozási élmény” mélységének megértése mások érzelmi reakcióinak megfigyelésén alapul. Ez jól látható a bejegyzésekből sabe ProgramerHumor, ahol sok kezdő programozó lóg. Sok humoros valamilyen mértékben a negativitás különböző árnyalataival van színezve: csalódás, pesszimizmus, felháborodás, leereszkedés és mások. És ha ez nem tűnik elégnek, olvassa el a megjegyzéseket.

Harag a kódra: programozók és negativitás

Azt vettem észre, hogy ahogy a programozók tapasztalatot szereznek, úgy válnak egyre negatívabbá. A kezdők, akik nincsenek tudatában a rájuk váró nehézségeknek, lelkesedéssel kezdik, és hajlandóak elhinni, hogy e nehézségek oka egyszerűen a tapasztalat és a tudás hiánya; és végül szembesülnek a dolgok valóságával.

Az idő múlik, tapasztalatot szereznek, és képesek lesznek megkülönböztetni a jó kódot a rossztól. És amikor eljön ez a pillanat, a fiatal programozók frusztrációt éreznek, amiért nyilvánvalóan rossz kóddal dolgoznak. Ha pedig csapatban dolgoznak (távolról vagy személyesen), gyakran átveszik a tapasztaltabb kollégák érzelmi szokásait. Ez gyakran a negativitás növekedéséhez vezet, mivel a fiatalok most már megfontoltan beszélhetnek a kódról, és feloszthatják azt rosszra és jóra, ezzel mutatva meg, hogy „tudatosak”. Ez tovább erősíti a negatívumot: a csalódottságból könnyű kijönni a kollégákkal és egy csoport tagjává válni; a Bad Code kritizálása növeli az Ön státuszát és professzionalizmusát mások szemében: a negatív véleményt nyilvánító embereket gyakran intelligensebbnek és kompetensebbnek tekintik.

A negativitás fokozása nem feltétlenül rossz dolog. A programozásról szóló megbeszélések többek között a megírt kód minőségére koncentrálnak. Az, hogy mi a kód, teljesen meghatározza azt a funkciót, amelyet el kell végeznie (a hardver, a hálózat stb. kivételével), ezért fontos, hogy véleményt nyilváníthasson erről a kódról. Szinte minden vita arra irányul, hogy a kód elég jó-e, és a rossz kód megnyilvánulásainak elítélésére, amelyek érzelmi konnotációja jellemzi a kód minőségét:

  • "Sok logikai inkonzisztencia van ebben a modulban, jó jelölt a jelentős teljesítményoptimalizálásra."
  • "Ez a modul elég rossz, át kell alakítanunk."
  • "Ennek a modulnak nincs értelme, át kell írni."
  • "Ez a modul szívás, javítani kell."
  • "Ez egy kos darab, nem modul, egyáltalán nem kellett megírni, mi a fenét gondolt a szerzője."

Egyébként ez az "érzelmi kiadás" az, ami miatt a fejlesztők "sexy"-nek nevezik a kódot, ami ritkán igazságos – hacsak nem a PornHubon dolgozol.

A probléma az, hogy az emberek furcsa, nyugtalan, érzelmes lények, és bármilyen érzelem észlelése és kifejezése megváltoztat bennünket: eleinte finoman, de idővel drámaian.

A negativitás zaklatott csúszós lejtője

Néhány évvel ezelőtt informális csapatvezető voltam, és interjút készítettem egy fejlesztővel. Nagyon kedveltük: okos volt, jó kérdéseket tett fel, ért a technikához, és jól illeszkedett a kultúránkhoz. Különösen lenyűgözött a pozitivitása és az, hogy mennyire vállalkozó szelleműnek tűnt. És felbéreltem.

Akkoriban pár éve dolgoztam a cégnél, és úgy éreztem, hogy a kultúránk nem túl hatékony. Megérkezésem előtt kétszer, háromszor és még néhányszor próbáltuk piacra dobni a terméket, ami nagy átdolgozási kiadásokhoz vezetett, ami alatt a hosszú éjszakákon, a szűk határidőkön és a működő termékeken kívül nem volt mit mutatnunk. És bár még mindig keményen dolgoztam, szkeptikus voltam a vezetőség által számunkra kijelölt utolsó határidővel kapcsolatban. És lazán káromkodott, amikor a kódex egyes vonatkozásait megvitatta kollégáimmal.

Így nem volt meglepő – bár meglepődtem –, hogy néhány héttel később ugyanaz az új fejlesztő ugyanazokat a negatív dolgokat mondta, mint én (beleértve a káromkodást). Rájöttem, hogy másként fog viselkedni egy másik társaságban, más kultúrával. Csak alkalmazkodott az általam teremtett kultúrához. Elfogott a bűntudat. Szubjektív tapasztalataim miatt pesszimizmust keltettem egy új jövevényben, akit teljesen másként érzékeltem. Még ha tényleg nem is olyan volt, és csak látszott, hogy megmutassa, hogy beilleszkedik, rákényszerítettem a szar hozzáállásomat. És minden, amit mondanak, még tréfából vagy futólag is, megvan az a rossz módja, hogy azzá változzon, amit elhisznek.

Harag a kódra: programozók és negativitás

Negatív módok

Térjünk vissza korábbi kezdő programozóinkhoz, akik egy kis bölcsességet és tapasztalatot szereztek: jobban megismerték a programozási ipart, és megértették, hogy a rossz kód mindenhol ott van, nem lehet elkerülni. Még a legfejlettebb, minőségre koncentráló cégeknél is előfordul (és hadd jegyezzem meg: úgy tűnik, a modernség nem véd a rossz kód ellen).

Jó forgatókönyv. Idővel a fejlesztők kezdik elfogadni, hogy a rossz kód a szoftver valósága, és az ő dolguk, hogy javítsák azt. És azt, hogy ha a rossz kódot nem lehet elkerülni, akkor nincs értelme felhajtást csinálni. A Zen útját választják, és az előttük álló problémák vagy feladatok megoldására összpontosítanak. Megtanulják, hogyan kell pontosan mérni és kommunikálni a szoftverek minőségét a cégtulajdonosokkal, megalapozott becsléseket írni több éves tapasztalatuk alapján, és végül nagylelkű jutalmakban részesülnek az üzlet számára nyújtott hihetetlen és folyamatos értékükért. Annyira jól végzik a munkájukat, hogy 10 millió dollár bónuszt kapnak, és nyugdíjba mennek, hogy életük végéig azt csináljanak, amit akarnak (kérlek, ne vegyék természetesnek).

Harag a kódra: programozók és negativitás

Egy másik forgatókönyv a sötétség útja. Ahelyett, hogy a rossz kódot elkerülhetetlenségként fogadnák el, a fejlesztők magukra vállalják, hogy minden rosszat kihívnak a programozási világban, hogy legyőzhessék azt. Számos jó okból elutasítják a meglévő rossz kód javítását: „az embereknek többet kellene tudniuk, és nem kell ennyire hülyének lenniük”; „kellemetlen”; „ez rossz az üzletnek”; „ez bizonyítja, milyen okos vagyok”; „ha nem mondom meg, milyen silány kód ez, az egész társaság az óceánba fog zuhanni” és így tovább.

Bizonyára nem tudják végrehajtani a kívánt változtatásokat, mert az üzletnek sajnos tovább kell fejlődnie, és nem tölthet időt azzal, hogy aggódjon a kód minősége miatt, ezért ezek az emberek panaszkodó hírnevet szereznek. Magas kompetenciájuk miatt megtartják őket, de a cég peremére szorulnak, ahol nem sokakat fognak bosszantani, de továbbra is támogatják a kritikus rendszerek működését. Az új fejlesztési lehetőségekhez való hozzáférés nélkül elveszítik készségeiket, és nem tudnak megfelelni az iparági igényeknek. Negativitásuk keserű keserűséggé változik, és ennek eredményeként egójukat azzal táplálják, hogy huszonéves diákokkal vitatkoznak arról, hogy kedvenc régi technológiájuk milyen utat járt be, és miért olyan forró még mindig. A végén nyugdíjba vonulnak, és madarakra káromkodva élik ki öregségüket.

A valóság valószínűleg valahol a két véglet között van.

Egyes vállalatok rendkívül sikeresek rendkívül negatív, elszigetelt, erős akaratú kultúrák létrehozásában (mint a Microsoft előtt elveszett évtized) - gyakran olyan cégekről van szó, amelyek termékei tökéletesen illeszkednek a piachoz és a lehető leggyorsabb növekedésre; vagy a parancsnoki és irányítási hierarchiával rendelkező cégek (az Apple Jobs legjobb éveiben), ahol mindenki azt csinál, 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, amely egy vállalatnál innovációhoz, az egyénekben pedig magas termelékenységhez vezet, alacsony szintű stressz szükséges a folyamatos kreatív és módszeres gondolkodás támogatásához. És rendkívül nehéz kreatív, vitavezérelt munkát végezni, ha állandóan azon aggódik, hogy kollégái mit szólnak majd a kód minden sorához.

A negativitás a popkultúra tervezése

Ma minden eddiginél nagyobb figyelmet fordítanak a mérnökök hozzáállására. A mérnöki szervezetekben a szabály „Nincsenek szarvak". Egyre több vicc és történet jelenik meg a Twitteren azokról az emberekről, akik azért hagyták el ezt a szakmát, mert nem tudták (nem tudták) tovább tűrni a kívülállókkal szembeni ellenségeskedést és rosszindulatot. Még Linus Torvalds is nemrég bocsánatot kért Több éves ellenségeskedés és kritika más Linux-fejlesztőkkel szemben – ez vitához vezetett ennek a megközelítésnek a hatékonyságáról.

Vannak, akik még mindig védik Linus jogát, hogy nagyon kritikus legyen – azok, akiknek sokat kell tudniuk a „mérgező negativitás” előnyeiről és hátrányairól. Igen, az udvariasság rendkívül fontos (sőt alapvető), de ha összefoglaljuk azokat az okokat, amelyek miatt sokan hagyjuk, hogy a negatív vélemények "mérgezéssé" váljanak, ezek az okok paternalistának vagy kamasznak tűnnek: "megérdemlik, mert idióták ", "biztosnak kell lennie abban, hogy többé nem teszik meg", "ha nem tették volna meg, nem kellene kiabálnia velük" és így tovább. A vezető érzelmi reakcióinak programozói közösségre gyakorolt ​​hatására példa a Ruby közösség MINASWAN rövidítése – „Matz kedves, így mi kedvesek vagyunk”.

Észrevettem, hogy a "ölj meg egy bolondot" megközelítés sok lelkes híve gyakran nagyon törődik a kód minőségével és helyességével, és azonosítja magát a munkájával. Sajnos gyakran összekeverik a keménységet a merevséggel. Ennek a pozíciónak a hátránya abból az egyszerű emberi, de terméketlen vágyból fakad, hogy felsőbbrendűnek érezze magát másokkal szemben. Azok az emberek, akik elmerülnek ebben a vágyban, elakadnak a sötétség útján.

Harag a kódra: programozók és negativitás

A programozás világa rohamosan növekszik, és a konténerének – a nem-programozás világának – határaiba ütközik (vagy a programozás világa konténer a nem programozás világának? Jó kérdés).

Ahogy iparágunk egyre gyorsabb ütemben terjeszkedik, és a programozás elérhetőbbé válik, a távolság a „technikusok” és a „normálisak” között gyorsan csökken. A programozás világa egyre inkább ki van téve a korai technológiai boom elszigetelt nerd kultúrájában nőtt fel emberek interperszonális interakcióinak, és ők fogják alakítani a programozás új világát. És minden társadalmi vagy generációs érvtől függetlenül a kapitalizmus jegyében megnyilvánuló hatékonyság a vállalati kultúrában és a munkaerő-felvételi gyakorlatban is megmutatkozik: a legjobb cégek egyszerűen nem vesznek fel senkit, aki nem tud semlegesen kommunikálni másokkal, nemhogy jó kapcsolatokat ápolni.

Amit a negativitásról tanultam

Ha túl sok negativitást enged meg az elméjének és az emberekkel való interakciónak, ami mérgezővé válik, akkor az veszélyes a termékcsapatok számára, és költséges az üzlet számára. Számtalan olyan projektet láttam (és hallottam róla), amelyek szétestek és teljesen újjáépültek nagy költséggel, mert az egyik megbízható fejlesztő haragot érzett a technológiára, egy másik fejlesztőre, vagy akár egyetlen fájlra, amelyet úgy választottak ki, hogy a teljes kódbázis minőségét képviselje.

A negativitás demoralizálja és tönkreteszi a kapcsolatokat. Soha nem felejtem el, hogy egy kolléga szidott meg, amiért rossz fájlba tettem a CSS-t, ez felzaklatott, és több napig nem engedte összeszedni a gondolataimat. És a jövőben nem valószínű, hogy egy ilyen embert megengedek valamelyik csapatom közelében (de ki tudja, az emberek változnak).

Végül a negatívum szó szerint károsítja az egészségét.

Harag a kódra: programozók és negativitás
Szerintem így kell kinéznie a mosolyok mesterkurzusának.

Ez persze nem érv amellett, hogy sugározzon a boldogságtól, tízmilliárd hangulatjelet illesszen be minden húzási kérésbe, vagy elmenjen egy mosolyok mesterkurzusára (nem, hát, ha ezt akarja, akkor semmi gond). A negativitás rendkívül fontos része a programozásnak (és az emberi életnek), a minőséget jelzi, lehetővé teszi az érzések kifejezését és az embertársaival való együttérzést. A negativitás éleslátást és körültekintést, a probléma mélységét jelzi. Gyakran észreveszem, hogy egy fejlesztő új szintre lépett, amikor elkezdi kifejezni hitetlenségét abban, amiben korábban félénk és bizonytalan volt. Az emberek ésszerűséget és magabiztosságot tanúsítanak véleményükkel. Nem lehet figyelmen kívül hagyni a negativitás kifejezését, az orwelli lenne.

A negativitást azonban más fontos emberi tulajdonságokkal kell adagolni és kiegyensúlyozni: empátiával, türelemmel, megértéssel és humorral. Kiabálás vagy káromkodás nélkül mindig elmondhatja valakinek, hogy elrontotta. Ne becsüld alá ezt a megközelítést: ha valaki minden érzelem nélkül azt mondja neked, hogy komolyan elrontottad, az nagyon ijesztő.

Annak idején, néhány évvel ezelőtt, a vezérigazgató beszélt velem. Megbeszéltük a projekt jelenlegi állását, majd megkérdezte, hogy érzem magam. Azt válaszoltam, hogy minden rendben, a projekt halad, lassan dolgozunk, lehet, hogy valamit kihagytam, és át kell gondolni. Elmondta, hogy hallott róla, hogy pesszimistább gondolatokat osztok meg az irodában dolgozó kollégákkal, és ezt mások is észrevették. Elmagyarázta, hogy ha kétségeim támadnának, teljes mértékben ki tudom fejezni azokat a vezetőség felé, de nem „leszedhetem”. Vezető mérnökként szem előtt kell tartanom, hogy szavaim hogyan hatnak másokra, mert akkor is nagy befolyásom van, ha nem veszem észre. És mindezt nagyon kedvesen elmondta, és végül azt mondta, hogy ha tényleg így érzem magam, akkor valószínűleg át kell gondolnom, mit akarok magamnak és a karrieremnek. Hihetetlenül gyengéd beszélgetés volt. Megköszöntem neki az információt arról, hogy hat hónap alatt megváltozott hozzáállásom milyen hatással volt másokra észrevétlenül.

Példa volt a figyelemre méltó, hatékony irányításra és a puha megközelítés erejére. Rájöttem, hogy csak úgy tűnt, hogy teljesen hiszek a cégben és abban, hogy képes elérni céljait, de a valóságban teljesen más módon beszéltem és kommunikáltam másokkal. Arra is rájöttem, hogy még ha szkeptikusnak is érzem magam a projekttel kapcsolatban, amin dolgozom, nem szabad kimutatnom az érzéseimet a kollégáimnak, és fertőként terjesztenem a pesszimizmust, csökkentve ezzel a siker esélyeit. Ehelyett agresszíven közvetíthetném a valós helyzetet a vezetőségemnek. Ha pedig úgy éreztem, hogy nem hallgatnak rám, egyet nem értésemet azzal fejezhettem ki, hogy elhagyom a társaságot.

Új lehetőséget kaptam, amikor elvállaltam a személyügyi felmérés vezetői posztját. Korábbi főmérnökként nagyon óvatosan fejezem ki véleményemet (folyamatosan fejlődő) örökölt kódunkkal kapcsolatban. A változtatás jóváhagyásához el kell képzelni a jelenlegi helyzetet, de nem jutsz semmire, ha nyögdécselsz, támadsz vagy hasonlók. Végső soron azért vagyok itt, hogy elvégezzek egy feladatot, és nem szabad panaszkodnom a kód miatt annak megértése, kiértékelése vagy javítása érdekében.

Valójában minél jobban irányítom a kóddal kapcsolatos érzelmi reakciómat, annál jobban megértem, mivé válhat, és annál kevésbé érzek zavart. Amikor visszafogottan fejeztem ki magam ("itt kell még fejlődni"), akkor magamnak és másoknak is örömet okoztam, nem vettem túl komolyan a helyzetet. Rájöttem, hogy stimulálhatom és csökkenthetem mások negativitását, ha tökéletesen (bosszantóan?) ésszerű vagyok ("igazad van, ez a kód elég rossz, de javítani fogunk rajta"). Örömmel látom, meddig jutok el a Zen ösvényen.

Lényegében folyamatosan tanulok és újratanulok egy fontos leckét: az élet túl rövid ahhoz, hogy folyton dühös és fájdalmas legyek.

Harag a kódra: programozók és negativitás

Forrás: will.com

Hozzászólás