Cosa dovrei dire sul mio curriculum se sono stato promosso per aver abbassato la qualità del codice per rispettare le scadenze?
Avevo un contratto di 12 mesi (vivo in un paese dove questo non è usuale per i nuovi sviluppatori) fino a un paio di settimane fa, quando la direzione della mia azienda mi ha fatto un'offerta e un aumento per diventare un dipendente permanente per loro. Mi piace tenere il mio curriculum sempre aggiornato (specialmente dato COVID), così ho cercato su Google come elencarlo nel mio curriculum.
Il consiglio che ho trovato è che generalmente dovrei elencare quale risultato è stato quello che ha spinto all'assunzione. Mi sembra giusto.
Il problema è che il risultato era sempre la consegna di scadenze strette per i clienti e, francamente, l'ho fatto decidendo che l'ingegneria poteva essere meno che stellare in casi mirati (e la direzione era d'accordo).
Sono un dev relativamente junior in un team di 6 sviluppatori. Tuttavia, sono diventato rapidamente uno degli sviluppatori di cui la direzione si fida di più per consegnare le cose quando dico che le consegnerò e li tengo informati dei relativi compromessi per arrivarci. Nel mio breve tempo qui, sono sempre stato in grado di spedire qualcosa quando ho detto di poterlo fare.
Ho avuto alcuni casi come questo, ma questo è quello che ho fatto appena prima che mi venisse offerto il lavoro permanente. Uno dei nostri prodotti è un'API batch che viene chiamata una volta al giorno da un singolo cliente. Non ha bisogno di restituire nulla, tranne un CSV di voci fallite via e-mail. Volevano aggiungere una nuova funzionalità e il venditore aveva concordato per contratto di averla per loro entro la fine del mese. Per vari motivi, quella richiesta di funzionalità non è arrivata fino al lunedì dell'ultima settimana del mese.
Lo sviluppatore senior ha detto al manager che lo sviluppo non poteva essere fatto correttamente e di dire al cliente che non poteva essere fatto. Io non contraddico i senior devs nelle riunioni di sprint planning, ma forse era ovvio che non ero d'accordo con il senior guy. Tipo, non in disaccordo, ma che esisteva un'opzione con certi compromessi. Anche gli altri sviluppatori sono abbastanza passivi, quindi nessun altro lo ha contraddetto. Il manager non era contento di questo perché il cliente è già arrabbiato con noi per non aver consegnato quando abbiamo promesso di farlo. Il manager mi ha poi convocato nel suo ufficio dopo la riunione per chiedermi se vedevo un'alternativa. Gli ho detto che avrei potuto far funzionare qualcosa, ma che probabilmente avrebbe raddoppiato il tempo di elaborazione dell'API (che avrebbe aggiunto 4 minuti) dato che non ho competenze SQL. Il manager è stato d'accordo e apparentemente il cliente non se n'è nemmeno accorto.
Non sono sicuro di quali sarebbero state le conseguenze del mancato rispetto della scadenza, ma erano abbastanza ripide che il CEO della nostra azienda di 1000 persone mi ha mandato una mail di ringraziamento per averla consegnata.
Un altro caso non ha attirato così tanta attenzione, ma c'era un processo che dovevamo eseguire su un database. Il modo corretto di farlo sarebbe stato quello di scrivere un processo batch adeguato nel mega sistema Java che usiamo, mandarlo attraverso tutti i processi regolari di QA, e lasciarlo saltare fuori alla fine due settimane dopo. Ho offerto al manager uno script Python che avrebbe dovuto essere eseguito manualmente e sarebbe stato terribilmente inefficiente (doveva essere eseguito durante la notte), ma se attivato una volta al mese, avrebbe tenuto a bada il problema fino all'arrivo di una soluzione permanente. Si trattava di un problema di produzione, quindi ha accettato come misura temporanea. Questo era fondamentalmente solo un economico ciclo for che controllava le righe per un certo tipo di dati errati e li riformattava.
C'è un modo per elencare questi tipi di cose sul mio curriculum che non mi fa sembrare un programmatore hack che insidia i senior devs? Ammetto che le mie soluzioni non sono tecnicamente valide, ma erano valide per le esigenze di business del momento e il trade off di inefficienza era in gran parte irrilevante nella maggior parte dei casi.
Hai trovato diversi modi efficaci (non efficienti) per risolvere i problemi senza sovra-ingegnerizzarli e "Fatto è meglio che perfetto"
Trovare una soluzione che sia appena sufficiente è un'abilità importante per un ingegnere, perché altrimenti si spenderebbe un sacco di tempo per ottimizzare qualcosa che non vale la pena ottimizzare. Se qualcosa non è usato spesso, spesso non vale la pena di ottimizzarlo. C'è un bel XKCD-Comic con una tabella che ti dice quanto tempo dovresti investire in qualcosa.
Una soluzione vale qualcosa solo se è (o può essere) usata, quindi con un hack hai permesso al cliente di continuare a lavorare finché non hai una soluzione.
Non c'è motivo di dire a nessuno che non eri d'accordo con il tuo supervisore. Basta andare per qualcosa come "In grado di produrre soluzioni efficaci sotto pressione di tempo".
Avevi un solo compito: "trovare una soluzione che funzioni entro i limiti di tempo che risolva il lavoro". E questo è esattamente quello che hai fatto.
Ho la sensazione che solo il management abbia dato risposte in questo caso, perché non c'è stato altro che lode nel rispettare scadenze irragionevoli.
Qui c'è un altro punto di vista. Non si dovrebbero sottovalutare i disordini sociali che si accendono all'interno del team di sviluppo quando il management taglia gli angoli e ignora le opinioni degli sviluppatori senior. C'è un detto che è più o meno così:
Una cosa è una cosa se si va una/doppia volta per la strada del calcio perché si è costretti a farlo, ma una cosa completamente diversa se si sta ottenendo la norma. E dalla tua descrizione mi sembra che il management sia diventato abbastanza a suo agio con la pratica di usarti per prendere scorciatoie. Dovreste considerare seriamente di sollevare la questione al vostro management e ai senior devs per mantenere un ambiente di lavoro sano. Un'azienda è un equilibrio tra dev e management e non una semplice struttura dall'alto verso il basso. C'è una ragione per cui la parola "no" esiste e dovreste esercitarvi ad usarla.
Tuttavia, questo è ancora più un problema di gestione che non il vostro. Non c'è quindi motivo di menzionarlo in qualche modo nel vostro curriculum. Quindi sono d'accordo con lei:
Come dice il proverbio "Il perfetto è il nemico del bene" - fare compromessi tecnici per soddisfare le esigenze di business è più o meno de rigueur. I bravi sviluppatori/programmatori/ingegneri sono quelli che possono identificare i compromessi accettabili che possono essere fatti.
Nel tuo esempio di API il cliente era chiaramente più disposto ad accettare un ritardo di 4 minuti nell'elaborazione per qualcosa che funzionasse e fosse consegnato in tempo.
Idealmente si dovrebbe cercare di minimizzare il debito tecnico quando si fanno questi compromessi - ma questo fa parte dell'esperienza e del sapere dove si può risparmiare tempo e quando è necessario assicurarsi che qualcosa sia fatto bene per risparmiare più tempo nel lungo periodo.
La mia domanda fondamentale è, c'è un modo per elencare questi tipi di cose sul mio curriculum che non mi faccia sembrare un programmatore hack che insidia i senior devs?
Quando si tratta del tuo CV non c'è bisogno di entrare nello specifico della tua soluzione - puoi semplicemente dire che hai un buon track record di consegne entro le scadenze su progetti sensibili al tempo e menzionare gli esempi senza i dettagli dell'implementazione effettiva.
Quello che fate NON è "hacking", è "trovare soluzioni".
Lavoro come sviluppatore e consulente da 20 anni ormai, e questa abilità è ciò che i datori di lavoro cercano: Non lasciatela fuori dal vostro curriculum, ma sottolineate esattamente questo: Cercate di trovare soluzioni anche se questo significa percorrere strade "insolite".
Non scrivete che lo fate alle spalle degli sviluppatori più anziani, ma che lo fate ogni volta che vi vengono chieste delle soluzioni, anche se i ragazzi più esperti non sono d'accordo o dicono che non è possibile.
C'è una grande citazione che si dice provenga da Albert Einstein che descrive esattamente la tua situazione:
Tutti sapevano che era impossibile, fino a quando un pazzo che non lo sapeva è arrivato e l'ha fatto.
Ho lavorato insieme a molti sviluppatori e ne conosco ogni aspetto:
Ho lavorato con uno sviluppatore che è tra il top 1% degli esperti di JavaScript su stackoverflow. È un genio e ammiro davvero ogni riga di codice che scrive. Ma molto spesso non ha finito i suoi progetti: Preferiva non finire qualcosa piuttosto che finirlo quando non era soddisfatto della bellezza del codice.
E ho lavorato con sviluppatori che erano estremamente efficienti, ma quindi prendevano un sacco di scorciatoie che rendevano le soluzioni quasi immutabili (percorsi hardcoded, numeri magici, ecc.).
E ho sempre preferito "fatto" a "bello" e alla fine anche i miei clienti: Preferiscono avere "qualcosa" quando c'è la scadenza piuttosto che "niente ma sarà bello tra qualche tempo X"
Solo una cosa: i workaround / scorciatoie / "hack" devono essere comprensibili, documentati e mantenibili, poi non c'è niente contro le soluzioni come te
Così avete creato un software che ha richiesto quattro minuti per essere eseguito (perché il vostro codice non era molto buono). Se mi ci vogliono 12 ore per fare il lavoro a mano, il vostro software mi fa risparmiare 11 ore e 56 minuti. Se avete scritto un codice migliore che funziona in 1 secondo, mi fa risparmiare 11 ore, 59 minuti, 59 secondi. Se il codice migliore è stato consegnato una settimana dopo, quindi ho dovuto fare il lavoro manualmente cinque volte, i 3 minuti e 59 secondi aggiuntivi non compenseranno mai il tempo che ho perso.
O renderlo più estremo. Il software deve funzionare in 24 ore. Il vostro codice è scadente, quindi abbiamo bisogno di un computer da 5.000 dollari per farlo funzionare in 24 ore. Con un codice migliore, un computer da 2.000 dollari potrebbe eseguirlo in 24 ore. 3.000 dollari di risparmio. Se ci vogliono due settimane per rendere il codice più veloce, è una perdita complessiva.
Essere in grado di consegnare quando serve è una cosa molto, molto buona. Inoltre, uno sviluppatore molto bravo può scrivere del codice scadente in modo da poterlo migliorare facilmente in seguito. I cattivi sviluppatori scrivono del codice scadente che è una sofferenza rifattorizzare in una buona forma, i buoni sviluppatori sotto la pressione del tempo scrivono del codice scadente che è facile da migliorare.