Combattere il debito tecnico come "lo sviluppatore più basso"?

Ogni volta che noti qualcosa di simile, inserisci un nuovo ticket nel tuo sistema di monitoraggio dei problemi.

Prendere l'abitudine di usare il tracker dei problemi come uno strumento primario per comunicare cose del genere, perché da lì sarà facile scegliere, valutare e dare la priorità ai colleghi senior / lead / manager / chi è responsabile per tenere traccia dei problemi nel tuo progetto.

Utilizza lo strumento giusto per il lavoro. Lo faccio sempre e strongmente ti consiglio di fare lo stesso.

Ad esempio, ecco un ticket che ho creato circa un mese fa. Al completamento di una funzione particolare, ho scoperto che il codice è diventato sostanzialmente più complicato di quanto fosse prima, ma non posso correggerlo entro il termine indicato per l'implementazione della funzione.

(I nomi delle funzioni, i ticket e il codice usati nel tracker reale sono oscurati, ma il testo viene copiato così com'è).

Summary: simplify design involving ParticularPieceOfCode

Description:
In the course of implementation per TICKET-12345, code involving usage of ParticularPieceOfCode accrued a bit of complication and became rather difficult to read, understand and maintain (see example code snippet below).

Find a way to simplify it.

An example of code which would be desirable to redesign can be found in ClassName#methodName:

<a piece of code like one behind the right door here:>

FWIW il mio consiglio si applica indipendentemente da quale "livello" sei.

L'ho usato al tuo livello attuale ("più basso") e lo sto usando ora che il mio livello è abbastanza lontano dal "più basso" e ho soddisfacente "dì" come lo chiami, e sto andando usarlo sempre, non importa cosa.

Pensaci, nessun livello, non importa quanta autorità hai, semplicemente non può esserci un modo migliore.

Se "dici" hey abbiamo un problema , è solo un tintinnio d'aria. E anche se il tuo capo / conduttore è d'accordo e dice hai ragione, abbiamo un problema , questo non cambia nulla - è solo un tintinnio d'aria ancora una volta, e non può essere nient'altro.

• ^{Potresti pensare che scrivere una tua opinione (ad esempio nell'e-mail) sarebbe meglio, ma se ci pensi, non lo è. Se il tuo progetto ha una notevole attività di posta, ciò che è stato scritto andrà perso e dimenticato da molto tempo un mese più tardi.}

Utilizza lo strumento giusto per il lavoro. Per il lavoro che descrivi, issue tracker è esattamente lo strumento giusto.

Noti il problema, lo inserisci in un sistema progettato per tracciarlo e si prende cura di tutto il resto, nel miglior modo possibile - semplicemente perché era progettato per questo :

computer software package that manages and maintains lists of issues, as needed by an organization... commonly used... to create, update, and resolve reported customer issues, or even issues reported by that organization's other employees... An issue tracking system is similar to a "bugtracker", and often, a software company will sell both, and some bugtrackers are capable of being used as an issue tracking system, and vice versa. Consistent use of an issue or bug tracking system is considered one of the "hallmarks of a good software team"¹...

Qualunque altro mezzo vorresti scegliere di comunicare, avere un ticket in tracker ti renderà più facile.

Anche se preferisci scuotere l'aria , dire "vorrei discutere di TICKET-54321 ..." è un punto di partenza più solido di "Ascolta, vorrei parlare di qualche pezzo di codice che ho trattato un po 'di tempo fa ... "E puoi tranquillamente passare i riferimenti al ticket per posta: anche se la posta si perde, il problema sarà ancora lì nel tracker, con tutti i dettagli che volevi raccontare circa.

Ciò che mi fa stare male nel tuo scenario è esattamente ciò che hai scritto nel titolo e più volte nel testo della domanda:

Sei lo sviluppatore più basso della catena

Perché quel punto è così importante? Bene, prima di tutto, e da un punto di vista puramente tecnico, hai certamente ragione. Sei assunto come ciò che chiami "implementatore" di cose, un'ape operaia che agisce sui comandi dati.

Ma anche se sei lo sviluppatore più basso per quanto riguarda il grado, questo non è ancora abbastanza giusto. La chiave qui è rendersi conto che sei percependo te stesso come lo sviluppatore più basso. Hai mai provato a superare questa percezione di sé ed effettivamente assumere la responsabilità di qualcosa ?

Prendere! Non aspettare, finché qualcuno non ti rende responsabile.

• You see the problem, but have no say with the matter.
• I'm not quantifying technical debt or looking for tools.
• You are locked to your tasks. You are not paid to do extra.
• Not your call. You're not management.

In genere è esattamente l'opposto: Sei pagato di più e la tua opinione è più rispettata, una volta che dimostri che valuti i tuoi soldi . È "fai prima di avere", non il contrario.

Ciò che mi aspetto dalle persone nel mio team è esattamente questo: un senso di responsabilità per il progetto o il prodotto che stiamo cercando di costruire e per tutti i processi correlati a tale sforzo. Ogni volta che qualcuno nel mio team mi impressiona assumendosi la responsabilità, ad es. proponendo miglioramenti o ancora meglio iniziare a migliorare le cose da soli, queste sono le persone che verranno promosse.

In altre parole: nessuno promuove le api operaie, le persone passivamente in attesa di compiti assegnati a loro, mancano anche il più piccolo battito d'arietta " perché non sono pagati per questo ", finalmente piagnucolando che non hanno mai avuto una possibilità.

Naturalmente, tutto ciò dipende ancora dalla cultura della tua azienda, da ciò a cui Joel si riferisce nelle "Due storie" collegate da Arthur. Se i dirigenti della compagnia sono davvero così stupidi da impedire al proprio personale di progredire, allora il rapporto di fluttuazione è probabilmente già molto alto e potrebbe essere il momento di trarne conclusioni. Ma se questo non è il caso, il vero problema potrebbe essere dentro di te.

Sei un professionista. Il tuo datore di lavoro ti ha assunto per essere professionale. Quindi, tratta le tue preoccupazioni nello stesso modo in cui vorresti che i tuoi professionisti assumano per trattare le loro opinioni professionali . In particolare, ci si aspetta che altri professionisti apportino le necessarie ottimizzazioni e correzioni lungo il percorso, a condizione che tali ottimizzazioni non aumentino inaspettatamente il costo.

Per esempio, supponiamo che porti la tua auto da un meccanico per far sostituire una lampada. Il meccanico nota quattro cose:

1. Il filo che conduce alla lampada è consumato e pericoloso. Ma, può essere tagliato senza aumentare notevolmente il costo. Ti aspetteresti che impieghi qualche minuto per tagliare il filo, possibilmente senza nemmeno notarlo.
2. Un bullone è allentato. È del tutto estraneo, gli è appena capitato di vederlo. È 20 secondi del suo tempo per afferrare il driver necessario e stringerlo; quindi, ti aspetteresti che lo faccia.
3. Il telaio della lampada è incrinato, il che farà vibrare la lampada. È costoso da sostituire. E non è essenziale. Quindi, ti chiama per chiederlo - se dici "no", inserisce una raccomandazione scritta sul riepilogo della visita.
4. C'è una buona quantità di liquido dei freni sotto la macchina. Dovrebbe, e potrebbe persino essere richiesto come professionista, di impedire di usare l'auto fino a quando non permetti a qualcuno di riparare la perdita.

Ciascuno di questi scenari, e sono sicuro che altri, hanno paralleli nello sviluppo del software, specialmente se ti consideri un di qualsiasi livello professionale. Come professionista, con pochissime eccezioni, il tuo compito è raggiungere l'obiettivo finale di migliorare il prodotto in un modo particolare secondo la tua comprensione professionale .

1. Se la correzione è banale, indipendentemente o non correlata, effettua la correzione.
2. Se la correzione è non banale e non necessaria, invia una raccomandazione formale utilizzando qualsiasi meccanismo formale di comunicazione / gestione dei problemi concordato.
3. Se è possibile fare in modo che la correzione sia necessaria per eseguire l'attività primaria, ma aumenterà inaspettatamente i costi, comunica la modifica dell'ambito.
4. Se il problema identificato rappresenta una seria minaccia per il successo del progetto, chiariscilo. Formalmente. Se ci sono preoccupazioni etiche che consentono al problema di non essere risolto (come nel caso di sistemi sanitari, di emergenza o di trasporto), insistere nell'affrontare il problema prima che il prodotto venga spedito (informare i media o le autorità se eticamente necessario).

Lo fai nello stesso modo in cui un impiegato in uno studio legale combatte comportamenti non etici, un lavoratore fast food combatte comportamenti antigienici, o un funzionario addetto al controllo dei parcheggi combatte la corruzione della polizia.

1. Sii un buon esempio. Nella misura in cui puoi, produci codice pulito e ragionevole. Quando viene data una scelta, scegli quella che soddisfa i tuoi requiremets con meno lati negativi. (Siate consapevoli che il debito tecnico non è diverso dal debito di mutuo - solo averlo non è necessariamente una brutta cosa.)
2. Comunicare le tue preoccupazioni . Dovresti avere qualcuno, un team lead o un cliente o un architetto, che ha l'effettiva responsabilità di gestire il debito tecnico e allocare le risorse della tua azienda. Quando vedi qualcosa che credi sia male, comunica loro la tua preoccupazione. Mettilo per iscritto (ad esempio, un'e-mail) se non sei sicuro che capirà, risponderà e darà credito per il tuo contributo.
3. Non stressare. Il debito tecnico raramente causa l'insuccesso definitivo di un'impresa. Finché hai comunicato le tue preoccupazioni e stai facendo il tuo lavoro, problemi di architettura come il debito tecnico non sono letteralmente il tuo problema. Sì, potrebbero interessarti, ma non sono più le tue preoccupazioni che la rielezione di uno sceriffo è la preoccupazione di un ufficiale di polizia junior.

Nell'esempio che hai fornito, con una funzione add che ha subito il creep completo della funzionalità, prendi alcuni minuti e disegna la struttura di ciò che potrebbe migliorarlo. Invia a chiunque tu abbia bisogno dell'approvazione per implementarlo e andare avanti.

Supponendo che la tua azienda fosse gestita da persone estremamente competenti e strutturata correttamente, la tua preoccupazione sarebbe indirizzata al progettista del sistema giusto per una decisione o ti sarebbe stata data la possibilità di implementare il tuo suggerimento. Come sviluppatore junior, mi preoccuperei di più di imparare come funziona la tua azienda rispetto al debito tecnico - e se conosci il primo, come gestire quest'ultimo dovrebbe essere ovvio.

Non ho mai sentito di un'organizzazione che non voleva che i suoi dipendenti partecipassero. Dici che sei pagato solo per fare i compiti. Sinceramente dubito che abbiate i compiti giusti in mente. Perché sei pagato per scrivere un buon software.

Assumiti questa responsabilità. Dì di no all'aggiunta di funzionalità se non sei in grado di supportare la base. Consigli il cliente con la tua esperienza. Aumenta i freni ora, prima che sia troppo tardi e devi buttare via l'intero progetto, perché non sarà più mantenibile.