Sto guardando un pezzo di codice. Questo potrebbe essere il codice peggiore che abbia mai visto. Per aggiornare solo un record nel database, recupera tutti i record nella raccolta e quindi invia una richiesta di aggiornamento a ogni record nel database, anche quelli che non necessitano di essere aggiornati. Esiste una funzione map che restituisce semplicemente il valore che le è stato passato. Esistono test condizionali per variabili con apparentemente lo stesso valore, semplicemente denominate in stili diversi (firstName и first_name). Per ogni UPDATE, il codice invia un messaggio a una coda diversa, che è gestita da una diversa funzione serverless, ma che svolge tutto il lavoro per una raccolta diversa nello stesso database. Ho già detto che questa funzione serverless proviene da una "architettura orientata ai servizi" basata su cloud contenente oltre 100 funzioni nell'ambiente?
Come è stato possibile farlo? Mi copro il viso e singhiozzo visibilmente tra le risate. I miei colleghi mi chiedono cosa è successo e io lo racconto a colori I peggiori successi di BulkDataImporter.js 2018. Tutti mi fanno un cenno comprensivo e sono d'accordo: come hanno potuto farci questo?
Negatività: uno strumento emotivo nella cultura del programmatore
La negatività gioca un ruolo importante nella programmazione. È radicato nella nostra cultura e viene utilizzato per condividere ciò che abbiamo imparato (“non lo fai ci crederai, com'era quel codice!"), per esprimere simpatia attraverso la frustrazione ("Dio, PERCHÉ farlo?"), per mettersi in mostra ("Non avrei mai così non l'ha fatto"), per dare la colpa a qualcun altro ("abbiamo fallito a causa del suo codice, impossibile da mantenere"), o, come è consuetudine nelle organizzazioni più "tossiche", per controllare gli altri attraverso un sentimento di vergogna ("A cosa stavi pensando?" ? corretto").
La negatività è così importante per i programmatori perché è un modo molto efficace per trasmettere valore. Una volta ho partecipato a un campo di programmazione e la pratica standard per instillare una cultura industriale negli studenti era quella di fornire generosamente meme, storie e video, i più popolari dei quali sfruttavano . È bello essere in grado di utilizzare strumenti emotivi per identificare il buono, il brutto, il cattivo, non farlo, mai affatto. È necessario preparare i nuovi arrivati al fatto che probabilmente saranno fraintesi dai colleghi lontani dall'IT. Che i loro amici inizieranno a vendergli idee per app da milioni di dollari. Che dovranno vagare attraverso infiniti labirinti di codici obsoleti con un gruppo di minotauri dietro l'angolo.
Quando impariamo a programmare per la prima volta, la nostra comprensione della profondità dell'“esperienza di programmazione” si basa sull'osservazione delle reazioni emotive degli altri. Lo si vede chiaramente dai post in , dove si ritrovano molti programmatori principianti. Molti umoristici sono, in un modo o nell'altro, colorati con diverse sfumature di negatività: delusione, pessimismo, indignazione, condiscendenza e altri. E se questo non ti sembra abbastanza, leggi i commenti.
Ho notato che man mano che i programmatori acquisiscono esperienza, diventano sempre più negativi. I principianti, ignari delle difficoltà che li attendono, iniziano con entusiasmo e con la volontà di credere che la causa di queste difficoltà sia semplicemente la mancanza di esperienza e conoscenza; e alla fine si confronteranno con la realtà delle cose.
Il tempo passa, acquisiscono esperienza e diventano capaci di distinguere il codice Buono da quello Cattivo. E quando arriva quel momento, i giovani programmatori provano la frustrazione di lavorare con un codice ovviamente scadente. E se lavorano in gruppo (da remoto o di persona), spesso adottano le abitudini emotive dei colleghi più esperti. Ciò porta spesso ad un aumento della negatività, perché ora i giovani possono parlare in modo ponderato del codice e dividerlo in buono e cattivo, dimostrando così di essere “al corrente”. Ciò rafforza ulteriormente l’aspetto negativo: per delusione è facile andare d’accordo con i colleghi ed entrare a far parte di un gruppo; criticare Bad Code aumenta il tuo status e la tua professionalità agli occhi degli altri: .
Aumentare la negatività non è necessariamente una cosa negativa. Le discussioni sulla programmazione, tra le altre cose, sono estremamente focalizzate sulla qualità del codice scritto. Il codice definisce completamente la funzione che è destinato a svolgere (hardware, rete, ecc. A parte), quindi è importante essere in grado di esprimere la propria opinione su quel codice. Quasi tutte le discussioni si riducono alla questione se il codice sia sufficientemente buono e alla condanna delle manifestazioni stesse di un cattivo codice in termini la cui connotazione emotiva caratterizza la qualità del codice:
- "Ci sono molte incoerenze logiche in questo modulo, è un buon candidato per un'ottimizzazione significativa delle prestazioni."
- "Questo modulo è piuttosto scadente, dobbiamo rifattorizzarlo."
- "Questo modulo non ha senso, deve essere riscritto."
- "Questo modulo fa schifo, necessita di una patch."
- "Questo è un pezzo di ariete, non un modulo, non aveva bisogno di essere scritto affatto, cosa diavolo pensava il suo autore."
A proposito, è questo "rilascio emotivo" che fa sì che gli sviluppatori definiscano il codice "sexy", il che raramente è giusto, a meno che tu non lavori su PornHub.
Il problema è che le persone sono creature strane, irrequiete, emotive, e la percezione e l'espressione di qualsiasi emozione ci cambia: all'inizio in modo sottile, ma col tempo, in modo drammatico.
Una travagliata china scivolosa di negatività
Alcuni anni fa, ero un team leader informale e ho intervistato uno sviluppatore. Ci è davvero piaciuto: era intelligente, faceva buone domande, era esperto di tecnologia e si adattava bene alla nostra cultura. Sono rimasto particolarmente colpito dalla sua positività e da quanto sembrasse intraprendente. E l'ho assunto.
A quel tempo lavoravo in azienda da un paio d’anni e sentivo che la nostra cultura non era molto efficace. Abbiamo provato a lanciare il prodotto due, tre volte e un altro paio di volte prima del mio arrivo, il che ha portato a grandi spese di rilavorazione, durante le quali non avevamo nulla da mostrare tranne lunghe notti, scadenze ravvicinate e prodotti che funzionavano. E nonostante stessi ancora lavorando sodo, ero scettico riguardo all'ultima scadenza assegnataci dalla direzione. E ha imprecato con nonchalance quando ha discusso alcuni aspetti del codice con i miei colleghi.
Quindi non è stato sorprendente, anche se sono rimasto sorpreso, che poche settimane dopo, lo stesso nuovo sviluppatore abbia detto le stesse cose negative che ho fatto io (comprese le parolacce). Mi sono reso conto che si sarebbe comportato diversamente in un'azienda diversa con una cultura diversa. Si è semplicemente adattato alla cultura che ho creato. Ero sopraffatto da un senso di colpa. A causa della mia esperienza soggettiva, ho instillato pessimismo in un nuovo arrivato che percepivo come completamente diverso. Anche se in realtà non era così e stava solo facendo un'apparenza per dimostrare che poteva integrarsi, gli ho imposto il mio atteggiamento di merda. E tutto ciò che viene detto, anche per scherzo o di sfuggita, ha la brutta tendenza di trasformarsi in ciò che si crede.
Modi negativi
Torniamo ai nostri ex programmatori alle prime armi, che hanno acquisito un po' di saggezza ed esperienza: hanno acquisito maggiore familiarità con il settore della programmazione e hanno capito che il cattivo codice è ovunque, non può essere evitato. Succede anche nelle aziende più avanzate focalizzate sulla qualità (e lasciatemelo notare: a quanto pare, la modernità non protegge dai codici errati).
Buona sceneggiatura. Col passare del tempo, gli sviluppatori iniziano ad accettare che il codice difettoso è una realtà del software e che il loro compito è migliorarlo. E se non è possibile evitare un cattivo codice, allora non ha senso fare storie al riguardo. Prendono la via dello Zen, concentrandosi sulla risoluzione dei problemi o dei compiti che devono affrontare. Imparano come misurare e comunicare con precisione la qualità del software agli imprenditori, scrivere stime fondate basate sui loro anni di esperienza e, infine, ricevere generose ricompense per il loro incredibile e continuo valore per l'azienda. Fanno così bene il loro lavoro che vengono pagati 10 milioni di dollari in bonus e vanno in pensione per fare quello che vogliono per il resto della loro vita (per favore, non darlo per scontato).
Un altro scenario è il sentiero dell’oscurità. Invece di accettare il cattivo codice come inevitabile, gli sviluppatori si assumono la responsabilità di denunciare tutto ciò che è negativo nel mondo della programmazione in modo da poterlo superare. Si rifiutano di migliorare il cattivo codice esistente per molte buone ragioni: “le persone dovrebbero saperne di più e non essere così stupide”; "è spiacevole"; “questo è un male per gli affari”; “questo dimostra quanto sono intelligente”; “se non vi dico che codice schifoso è questo, tutta la compagnia cadrà in mare”, e così via.
Sicuramente incapaci di implementare i cambiamenti che desiderano perché l'azienda purtroppo deve continuare a svilupparsi e non possono perdere tempo a preoccuparsi della qualità del codice, queste persone si guadagnano la reputazione di lamentatori. Vengono trattenuti per la loro elevata competenza, ma vengono spinti ai margini dell'azienda, dove non daranno fastidio a molte persone, ma supporteranno comunque il funzionamento dei sistemi critici. Senza accesso a nuove opportunità di sviluppo, perdono competenze e cessano di soddisfare le richieste del settore. La loro negatività si trasforma in amarezza e, di conseguenza, alimentano il loro ego discutendo con studenti ventenni sul viaggio intrapreso dalla loro vecchia tecnologia preferita e sul perché è ancora così popolare. Finiscono per andare in pensione e vivere la loro vecchiaia imprecando contro gli uccelli.
La realtà probabilmente si trova da qualche parte tra questi due estremi.
Alcune aziende hanno avuto un enorme successo nel creare culture estremamente negative, insulari e volitive (come Microsoft prima della sua ) - spesso si tratta di aziende con prodotti che si adattano perfettamente al mercato e alla necessità di crescere il più rapidamente possibile; o aziende con una gerarchia di comando e controllo (Apple negli anni migliori di Jobs), dove ognuno fa quello che gli viene detto. Tuttavia, la moderna ricerca aziendale (e il buon senso) suggerisce che la massima ingegnosità, che porta all’innovazione nelle aziende e all’elevata produttività negli individui, richiede bassi livelli di stress per supportare il pensiero creativo e metodico continuo. Ed è estremamente difficile svolgere un lavoro creativo e basato sulla discussione se sei costantemente preoccupato di ciò che i tuoi colleghi avranno da dire su ogni riga del tuo codice.
La negatività sta ingegnerizzando la cultura pop
Oggi si presta più attenzione che mai all’atteggiamento degli ingegneri. Nelle organizzazioni di ingegneria, la regola “". Su Twitter compaiono sempre più aneddoti e storie di persone che hanno abbandonato questa professione perché non potevano (non volevano) continuare a sopportare l'ostilità e la cattiva volontà nei confronti degli estranei. Anche Linus Torvalds anni di ostilità e critiche nei confronti di altri sviluppatori Linux - ciò ha portato al dibattito sull'efficacia di questo approccio.
Alcuni difendono ancora il diritto di Linus ad essere molto critico - quelli che dovrebbero sapere molto sui vantaggi e sugli svantaggi della "negatività tossica". Sì, la civiltà è estremamente importante (anche fondamentale), ma se si riassumono i motivi per cui molti di noi permettono che l'espressione di opinioni negative si trasformi in "tossicità", questi motivi sembrano paternalistici o adolescenziali: "se lo meritano perché sono idioti ", "deve essere sicuro che non lo faranno più", "se non lo avessero fatto, non avrebbe dovuto sgridarli" e così via. Un esempio dell'impatto che le reazioni emotive di un leader hanno su una comunità di programmazione è l'acronimo MINASWAN della comunità Ruby: "Matz è carino, quindi siamo gentili".
Ho notato che molti ardenti sostenitori dell'approccio "uccidi un pazzo" spesso si preoccupano molto della qualità e della correttezza del codice, identificandosi con il loro lavoro. Sfortunatamente, spesso confondono la durezza con la rigidità. Lo svantaggio di questa posizione deriva dal semplice desiderio umano, ma improduttivo, di sentirsi superiore agli altri. Le persone che si immergono in questo desiderio rimangono bloccate sul sentiero dell’oscurità.
Il mondo della programmazione sta crescendo rapidamente e si sta spingendo contro i confini del suo contenitore: il mondo della non programmazione (o il mondo della programmazione è un contenitore per il mondo della non programmazione? Bella domanda).
Mentre il nostro settore si espande a un ritmo sempre crescente e la programmazione diventa più accessibile, la distanza tra i “tecnici” e i “normali” si sta rapidamente riducendo. Il mondo della programmazione è sempre più esposto alle interazioni interpersonali di persone cresciute nell’isolata cultura nerd del primo boom tecnologico, e sono loro che daranno forma al nuovo mondo della programmazione. E indipendentemente da qualsiasi argomento sociale o generazionale, l’efficienza in nome del capitalismo si manifesterà nella cultura aziendale e nelle pratiche di assunzione: le migliori aziende semplicemente non assumeranno nessuno che non possa interagire in modo neutrale con gli altri, per non parlare di avere buoni rapporti.
Quello che ho imparato sulla negatività
Se permetti a troppa negatività di controllare la tua mente e le interazioni con le persone, trasformandosi in tossicità, allora è pericoloso per i team di prodotto e costoso per il business. Ho visto (e sentito parlare) di innumerevoli progetti che sono andati in pezzi e sono stati completamente ricostruiti con grandi spese perché uno sviluppatore fidato aveva rancore nei confronti della tecnologia, un altro sviluppatore o anche un singolo file scelto per rappresentare la qualità dell'intero codebase.
La negatività demoralizza e distrugge anche le relazioni. Non dimenticherò mai come un collega mi ha rimproverato per aver inserito i CSS nel file sbagliato, mi ha sconvolto e non mi ha permesso di raccogliere i pensieri per diversi giorni. E in futuro difficilmente permetterò a una persona del genere di stare vicino a una delle mie squadre (ma chissà, le persone cambiano).
Infine, il negativo .
Penso che questo sia come dovrebbe essere una master class sui sorrisi.
Naturalmente, questo non è un argomento a favore di sorridere di felicità, inserire dieci miliardi di emoticon in ogni richiesta pull o frequentare un corso di perfezionamento sui sorrisi (no, beh, se è quello che vuoi, allora nessun problema). La negatività è una parte estremamente importante della programmazione (e della vita umana), segnala la qualità, consente di esprimere sentimenti e commiserare i propri simili. La negatività indica intuizione e prudenza, la profondità del problema. Noto spesso che uno sviluppatore ha raggiunto un nuovo livello quando inizia a esprimere incredulità in ciò di cui prima era timido e insicuro. Le persone dimostrano ragionevolezza e fiducia nelle loro opinioni. Non si può respingere l'espressione di negatività, sarebbe orwelliano.
Tuttavia, la negatività deve essere dosata e bilanciata con altre importanti qualità umane: empatia, pazienza, comprensione e umorismo. Puoi sempre dire a una persona che ha commesso un errore senza urlare o imprecare. Non sottovalutare questo approccio: se qualcuno ti dice senza alcuna emozione che hai commesso un grave errore, è davvero spaventoso.
Quella volta, diversi anni fa, il CEO mi parlò. Abbiamo discusso dello stato attuale del progetto, poi mi ha chiesto come mi sentivo. Ho risposto che andava tutto bene, il progetto andava avanti, stavamo lavorando a rilento, forse mi era sfuggito qualcosa e avevo bisogno di essere riconsiderato. Ha detto che mi aveva sentito condividere pensieri più pessimistici con i colleghi in ufficio e che anche altri lo avevano notato. Mi ha spiegato che se avessi avuto dei dubbi avrei potuto esprimerli pienamente al management, ma non “eliminarli”. In qualità di ingegnere capo, devo essere consapevole di come le mie parole influenzano gli altri perché ho molta influenza anche se non me ne rendo conto. E mi ha detto tutto questo molto gentilmente, e alla fine ha detto che se mi sentivo davvero così, probabilmente avrei bisogno di pensare a cosa voglio per me stesso e per la mia carriera. È stata una conversazione incredibilmente gentile, prendi o alzati dal posto. L'ho ringraziato per l'informazione su come il mio atteggiamento cambiato nel corso di sei mesi stava influenzando gli altri senza che me ne accorgessi.
È stato un esempio di gestione straordinaria ed efficace e della potenza di un approccio soft. Mi sono reso conto che solo apparentemente avevo totale fiducia nell'azienda e nella sua capacità di raggiungere gli obiettivi prefissati, ma in realtà parlavo e comunicavo con gli altri in modo completamente diverso. Mi sono anche reso conto che, anche se mi sentivo scettico riguardo al progetto a cui stavo lavorando, non avrei dovuto mostrare i miei sentimenti ai miei colleghi e diffondere il pessimismo come un contagio, riducendo le nostre possibilità di successo. Invece, potrei trasmettere in modo aggressivo la situazione reale al mio management. E se avessi la sensazione che non mi ascoltassero, potrei esprimere il mio disaccordo lasciando l’azienda.
Ho avuto una nuova opportunità quando ho assunto la posizione di responsabile della valutazione del personale. In qualità di ex ingegnere capo, sono molto attento nell'esprimere le mie opinioni sul nostro codice legacy (in continuo miglioramento). Per approvare un cambiamento, devi immaginare la situazione attuale, ma non arriverai da nessuna parte se ti lamenti, attacchi o simili. In definitiva, sono qui per completare un'attività e non dovrei lamentarmi del codice per capirlo, valutarlo o risolverlo.
Infatti, più controllo la mia reazione emotiva al codice, più capisco cosa potrebbe diventare e meno provo confusione. Quando mi esprimevo con moderazione (“ci deve essere spazio per ulteriori miglioramenti qui”), rendevo felice me stesso e gli altri e non prendevo la situazione troppo sul serio. Mi sono reso conto che potevo stimolare e ridurre la negatività negli altri essendo perfettamente (fastidiosamente?) ragionevole (“hai ragione, questo codice è piuttosto pessimo, ma lo miglioreremo”). Sono felice di vedere quanto lontano posso arrivare sul sentiero Zen.
Essenzialmente, imparo e ri-imparo costantemente una lezione importante: la vita è troppo breve per essere costantemente arrabbiata e sofferente.
Fonte: habr.com