Riuscire a fare le cose quando sai solo lamentarti

Questo sito dovrebbe parlare di software management. Alle volte però non hai il potere di cambiare le cose nella tua azienda con decisioni dirigenziali arbitrarie. Ovviamente, se sei solo un programmatore cazzuto ma l’ultima ruota del carro, non è che puoi ordinare ai colleghi di iniziare a tenere un diario dei lavori o ad usare un sistema di bug-tracking. Ed anche nel caso tu sia un manager avrai già scoperto che gestire sviluppatori è molto simile a riunire gatti in un recinto, anche se meno divertente.

Puoi sentirti frustrato a lavorare in un azienda che totalizza un basso punteggio nel Test di Joel.

Non importa quanto buono è il tuo codice, i tuoi colleghi scrivono codice così scadente che sei imbarazzato ad essere collegato al progetto. Oppure la dirigenza sta prendendo decisioni sbagliate su quale codice scrivere e ti ritrovi a sprecare il tuo talento a debuggare la versione per AS/400 di un gioco per bambini sui piani di pensionamento.

Suppongo potresti licenziarti. Ma magari ci sono delle ragioni che te lo impediscono. Non hai ancora riscosso le stock-options, non c’è un posto migliore per lavorare a Castelvecchio di Sotto, o magari il padrone tiene in ostaggio qualcuno che ami. Comunque sia, avere a che fare a vita con una cattiva squadra ti farà infuriare. Ma c’è qualche strategia per migliorare la tua squadra partendo dal basso e mi piacerebbe condivederne qualcuna.

Strategia 1 Fallo e basta

Anche una persona da sola può fare molte cose per migliorare il progetto. Non avete un server per fare i build giornalieri? Fallo tu. Imposta il tuo computer per fare il build di notte ed inviare i risultati via email. Ci vogliono troppi passi successivi per fare un build? Scrivi il makefile. Nessuno fa i test di usabilità delle GUI? Fai i tuoi test personali di usabilità con i colleghi dell’ufficio vicino usando un foglio di carta o un prototipo scritto in Visual Basic.

Strategia 2 Sfrutta la potenza del Viral Marketing

La maggior parte delle strategie del Test di Joel possono essere implementate da un singolo sviluppatore in una squadra non-cooperativa. Alcune di esse, se ben implementate, si diffonderanno per tutto il resto della squadra.

Ad esempio, supponi che nessuno della squadra possa essere persuaso ad usare un sistema di bug-tracking. Ciò non ti deve fermare. Semplicemente usa un tuo sistema di bug-tracking personale. Inserisci i bachi che trovi nel tuo codice. Se trovi un baco che dovrebbe veramente risolvere qualcun altro assegnaglielo usano il sistema di bug-tracking. Se hai un buon sistema di bug-tracking questo gli invierà una email. A quel punto potrai continuare a mandargli email finché non risolvono il baco. Potrebbe anche essere che riconosca il vantaggio di usare un sistema di bug-tracking e voglia pure lui iniziare ad usarlo. Se quelli della Qualità si rifiutano di inserire le segnalazioni di bachi nel sistema di bug tracking allora tu semplicemente rifiutati di prestare attenzione a qualunque segnalazione di bachi fatta in altro modo. Alla tre-quattro millesima volta che gli dirai “ascolta, ti risolverei volentieri il baco ma ho paura di dimenticarmene. Non potresti inserirlo nel sistema di bug-tracking?” inizieranno ad usare il sistema

Nessuno della tua squadra vuole usare un sistema di controllo delle versioni? Crea il tuo repository CVS personale, se necessario sul tuo disco fisso. Anche senza nessuna cooperazione puoi fare il check-in del tuo codice indipendentemente dagli altri. Quando avranno problemi che il sistema di controllo delle versioni può risolvere (ad esempio qualcuno per sbaglio ha scritto rm * ~ piuttosto che rm *~) allora verranno a chiedere il tuo aiuto. Potrebbe anche essere che capiscano che anche loro potrebbero fare il check-out.

Strategia 3 Crea l’eccellenza

La tua squadra non pianifica il lavoro? Non scrive le specifiche? Fai tu un piano e scrivi le specifiche. Nessuno si lamenterà se ti prendi un giorno o due per scrivere una specifica minima e fare un piano di lavoro per il codice che devi scrivere.

Ottieni per la squadra le persone migliori. Sii coinvolto nelle assunzioni e nei colloqui e trova ottimi candidati per unirsi alla squadra.

Trova le persone che vogliono migliorarsi e che ne sono capaci e portale dalla tua parte. Anche nelle squadre misere ci saranno una o due persone brillanti che però non hanno l’esperienza necessaria a scrivere buon codice. Aiutale a venir fuori. Mettile in grado di imparare. Leggi il loro codice. Se scrivono qualcosa di stupido non mandare loro una mail spocchiosa spiegando cosa c’è di stupido nel loro codice. Questo li farebbe semplicemente arrabbiare e mettere sulla difensiva. Segnala invece innocentemente un bug che tu sai discendere dal loro codice. Lascia che capiscano da soli cosa causa quel baco. Quando avranno trovato che è causato dal loro codice allora si ricorderanno molto meglio la lezione ricevuta.

Strategia 4 Neutralizza le Schiappe

Anche nella miglior squadra possono esserci una o due schiappe. La parte frustrante di avere cattivi programmatori nella squadra è quando il loro cattivo codice rompe il tuo buon codice, o quando i buoni programmatori devono perdere tempo a mettere ordine dove sono passati i cattivi programmatori.

Da programmatore cazzuto il tuo obiettivo è la minimizzazione dei danni, a.k.a. contenimento. Un bel giorno uno di questi geni avrà passato due settimane a scrivere un pezzetto di codice che è così incredibilmente cattivo che non potrà mai funzionare. Sei tentato di impiegare quei quindici minuti che ci vogliono per rifare correttamente il tutto da zero. Resisti alla tentazione. Hai un’ottima opportunità di neutralizzare quest’imbecille per diversi mesi. Inizia semplicemente a segnalare bachi relativi al loro codice. Non avranno altra scelta che starsene buoni per mesi finché non troverai più bachi originati dal loro codice.

Strategia 5 Stai lontano dalle interruzioni

Tutti gli ambienti di lavoro felici sono simili (uffici personali, silenzio, ottimi strumenti di sviluppo, poche interruzioni ed ancora meno riunioni interminabili). Tutti gli ambienti di lavoro infelici lo sono a modo loro.

La cattiva notizia è che cambiare ambiente di lavoro è quasi impossibile virtualmente in ogni ambiente di lavoro. Leasing a lungo termine significano che neanche il CEO può farci niente. Questo è il motivo per cui così pochi programmatori software hanno il proprio ufficio personale. E ciò danneggia queste aziende in almeno due modi. In primo luogo è difficile riuscire ad assumere i migliori programmatori che, a parità di tutto il resto, sceglieranno di lavorare là dove viene offerto loro un ufficio confortevole. In secondo luogo le interruzioni possono ridurre drammaticamente la produttività degli sviluppatori che faranno fatica ad entrare in flow e a rimanervi per almeno un po’ di tempo.

Cerca qualche modo per uscire da questo ambiente malsano. Vai con un portatile al bar aziendale dove ci sono molti tavoli liberi quasi sempre (e poi è fatica che ti trovino lì). Prenota una sala riunioni per un’intera giornata e mettiti lì a scrivere codice e dimostra poi, con il massiccio aumento di check-in, quanto codice in più riesci a scrivere quando sei da solo in una stanza tutta per te. La prossima volta che ci sarà del superlavoro ed il tuo capo ti chiederà di cosa hai bisogno per Fare Questo Per Domani saprai cosa rispondere. Ti troveranno un ufficio per un giorno. E poi inizieranno a domandarsi come poter mantenere così alta la tua produttività per tutto l’anno.

Arriva tardi a lavorare e vai via tardi. Quando la maggior parte dei colleghi è andata a casa rimangono ore che possono essere le più produttive. Oppure, se sei in una squadra dove tutti arrivano tardi, tu arriva presto, alle 9 del mattino. Farai più lavoro in quelle due ore prima che arrivino gli altri ed inizino a scocciarti che in tutto il resto della giornata.

Non tenere l’email o la chat costantemente aperte. Controlla l’email ogni ora, se vuoi, ma non tenerla sempre aperta .

Strategia 6 Diventa inestimabile

Nessuna delle precedenti strategia funziona veramente se non dai dei contributi eccellenti come sviluppatore. Se non scrivi buon codice, e molto, sarai tacciato come quello che fa solo casino con il sistema di bug-tracking quando invece “dovrebbe” scrivere codice. Non c’è niente di peggiore per la tua carriera che avere la reputazione di essere così preoccupato del processo da non concludere niente di buono.

Un tempo, quando cominciai un nuovo lavoro da programmatore cazzuto in una nuova azienda, scoprii che l’azienda totalizzava due punti nel Test di Joel ed allora presi a cuore la situazione. Ma sapevo anche che dare subito una ottima impressione era cruciale. Così le prime sette ore di ogni giornata lavorativa scrivevo codice, così come ci si aspettava da me. Non c’è niente di meglio di una sfilza di check-in per fare un’ottima impressione sul resto della squadra. Ma ogni pomeriggio, prima di andare a casa, mi riservavo un’ora per migliorare il processo. Sistemavo le cose per agevolare il debug della nostra applicazione. Implementai i build giornalieri ed il sistema di bug-tracking. Risolsi tutte le scocciature che da un pezzo rendevano lento lo sviluppo. Scrissi le specifiche per il lavoro che dovevo fare giorno per giorno. Scrissi un documento dove spiegavo passo passo come approntare da zero un pc per gli sviluppatori. Documentai diffusamente un linguaggio ad usao interno fino ad allora non documentato. Lentamente il processo migliorava giorno per giorno. Nessuno tranne me (e la mia squadra, quando me ne assegnarono una) aveva mai fatto piani di lavoro o scritto specifiche, però totalizzavamo 10 nel Test di Joel.

Tu puoi migliorare le cose, anche se non ne sei incaricato, ma devi essere come la moglie di Cesare: al di sopra di ogni sospetto. Altrimenti, andando avanti, ti farai solo nemici.

Articolo originale

Getting Things Done When You’re Only a Grunt

Lascia un commento

Back To Top