Domanda:
Cosa dovrei dire sul mio curriculum se sono stato promosso per aver abbassato la qualità del codice per rispettare le scadenze?
hackydude
2020-04-01 15:21:15 UTC
view on stackexchange narkive permalink

Avevo un contratto di 12 mesi (vivo in un paese in cui non è usuale per i nuovi sviluppatori) fino a un paio di settimane fa, quando la direzione della mia azienda mi ha offerto un'offerta e un aumento per diventare un dipendente a tempo indeterminato per loro. Mi piace mantenere il mio curriculum sempre aggiornato (soprattutto dato COVID), quindi ho cercato su Google per elencarlo nel mio curriculum.

Il consiglio che ho trovato è stato che in genere avrei dovuto elencare quale risultato è stato che ha spinto l'assunzione. Giusto.

Il problema è che il risultato è stato sempre quello di fornire scadenze ravvicinate del cliente e, francamente, l'ho fatto decidendo che l'ingegneria poteva essere meno che eccezionale in casi mirati (che la direzione ha accettato).

Sono uno sviluppatore relativamente giovane di un team di 6 sviluppatori. Tuttavia, sono diventato rapidamente uno degli sviluppatori di cui la direzione si fida di più per fornire materiale quando dico che lo consegnerò e li terrò informati dei relativi compromessi per arrivarci. Nel mio breve periodo qui, ammetto, sono sempre stato in grado di spedire qualcosa quando ho detto che posso spedirlo.

Ho avuto alcuni casi come questo, ma questo è quello che ho fatto appena prima che mi fosse offerto il lavoro a tempo indeterminato. Uno dei nostri prodotti è un'API batch che viene richiamata una volta al giorno da un singolo client. Non è necessario restituire nulla tranne un CSV di voci non riuscite tramite e-mail. Volevano aggiungere una nuova funzionalità e il venditore aveva contrattualmente accettato di averla per loro entro la fine del mese. Per vari motivi, quella richiesta di funzionalità non è arrivata a noi fino a 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. Non contraddico gli sviluppatori senior nelle riunioni di pianificazione dello sprint, ma forse era ovvio che non ero d'accordo con il ragazzo senior. Mi piace, non sono in disaccordo, ma esisteva un'opzione con alcuni 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 promettiamo di farlo. Il manager poi mi ha convocato nel suo ufficio dopo la riunione per chiedermi se vedessi un'alternativa. Gli ho detto che avrei potuto far funzionare qualcosa, ma probabilmente avrebbe raddoppiato il tempo di elaborazione dell'API (che avrebbe aggiunto 4 minuti) poiché non ho competenze SQL specifiche. Il manager era d'accordo e apparentemente il cliente non se ne è 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 inviato un'e-mail di ringraziamento per averlo consegnato.

Un altro caso non ha attirato tanta attenzione, ma c'era un processo che dovevamo eseguire su un database. Il modo corretto per farlo sarebbe stato scrivere un processo batch appropriato nel mega sistema Java che utilizziamo, inviarlo attraverso tutti i normali processi di QA e lasciarlo uscire alla fine due settimane dopo. Ho offerto al manager uno script Python che avrebbe dovuto essere eseguito manualmente e sarebbe stato terribilmente inefficiente (avrebbe dovuto eseguirlo durante la notte), ma se attivato una volta al mese, avrebbe tenuto a bada il problema fino all'arrivo di una soluzione permanente. Questo era un problema di produzione, quindi ha accettato come misura provvisoria. Questo era fondamentalmente solo un ciclo for economico che controllava le righe per un certo tipo di dati errati e lo riformattava.

C'è un modo per elencare questo tipo di cose nel mio curriculum che non mi faccia sembrare un programmatore di hacker che mina gli sviluppatori senior? Ammetto che le mie soluzioni tecnicamente non sono valide, ma all'epoca erano valide per le esigenze aziendali e il compromesso dell'inefficienza era in gran parte irrilevante nella maggior parte dei casi.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/106228/discussion-on-question-by-hackydude-what-should-i-say-on-my-resume-if-i-got-prom).
All'OP - Consiglio vivamente di rimuovere le informazioni che potrebbero essere utilizzate per determinare o indovinare la tua identità.Non vuoi che il tuo datore di lavoro legga questo e salti a conclusioni.Ex.Rimuovere cose come "CSV di voci non riuscite tramite e-mail", "ha offerto al gestore uno script Python" ecc. Sembra che il paragrafo CSV significhi davvero che il lavoro è stato facile e che ha ritardato la ricezione della richiesta di lavoro.È importante che tu debba lavorare con file CSV, TSV o separati da pipe?Se fossi il tuo capo, leggendo questo, capirei facilmente chi è.
Tredici risposte:
FooTheBar
2020-04-01 15:36:47 UTC
view on stackexchange narkive permalink

Hai trovato diversi modi efficaci (non efficienti) per risolvere i problemi senza ingegnerizzarli eccessivamente e "Fatto è meglio che perfetto"

Trovare una soluzione che sia sufficientemente buona è un'abilità importante per un ingegnere altrimenti spenderesti molto tempo per ottimizzare qualcosa che non vale la pena ottimizzare. Se qualcosa non viene utilizzato spesso, spesso non vale la pena 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) utilizzata, quindi con un hack hai consentito al cliente di continuare a lavorare finché non hai una soluzione.

Non c'è motivo di dire a nessuno che sei in disaccordo con il tuo supervisore. Scegli qualcosa come "In grado di produrre soluzioni efficaci sotto pressione".

Ammetto che le mie soluzioni non siano tecnicamente valide, ma all'epoca erano adatte alle esigenze aziendali e il compromesso dell'inefficienza era in gran parte irrilevante nella maggior parte dei casi.

Avevi un lavoro: "trovare una soluzione che venga eseguita entro i limiti di tempo che risolva il lavoro". Ed è esattamente quello che hai fatto.

Proprio questo.Bilanciare i compromessi per creare una soluzione che sia "abbastanza buona" per risolvere il problema dato è l'abilità più importante che un ingegnere può avere.Non è un effetto collaterale del lavoro, è il lavoro.
Ebbene sì, ho pensato anche a quella parte per la prima parte.D'altra parte, l'OP probabilmente rende la vita difficile a se stesso, al suo team e alla sua azienda per il futuro.La direzione è in genere l'ultima a riconoscere il costo futuro del debito tecnico, motivo per cui abbastanza spesso ricade sugli sviluppatori principali per respingere queste cose "fatte domani".Inoltre, eseguire regolarmente tali acrobazie può aumentare l'aspettativa del management che fare tali acrobazie va bene e bene, quando dovrebbero essere l'eccezione.Perché ti costeranno in futuro quando cadrai su funzionalità fatte a metà.
Ma nel vendersi sicuro, questa sarebbe una linea di discussione.E in effetti è un'abilità importante da consegnare in base ai requisiti, ma con essa arriva la conoscenza di quando andare avanti con una correzione rapida e quando spingere indietro e mantenere la linea per farlo "correttamente".
@FrankHopkins Ero convinto che questo sarebbe stato temporaneo fino a quando non sarebbero state messe in atto questioni più efficienti, quindi lui ha menzionato lo stop-gap
@Amon Sono d'accordo che la valutazione se questa sia una buona o cattiva applicazione di detta abilità dipende un po 'dal contesto reale, ecc. Sembrava che fosse successo un paio di volte ora, in modo tale che vedo uno schema che potrebbe portare su una cattiva strada.Anche se ciò non si applica all'OP, una risposta equilibrata potrebbe indicare tale rischio.Dato che sto già vedendo qualcuno che sceglie regolarmente la soluzione rapida e sporca citandola come giustificazione ... ^^ È una parte importante dei ruoli degli sviluppatori garantire determinati standard di qualità, così come i costruttori di ponti devono assicurarsi che i loro ponti sianonon costruire per durare solo 6 mesi
@FrankHopkins Questo modello è chiamato il suo "lavoro".È quello che facciamo.Non abbiamo mai il tempo di fare tutto perfettamente la prima volta.Scendiamo sempre a compromessi.Non è possibile ottenere tutto perfetto la prima volta ei progetti che provano vengono generalmente abbandonati.Il massimo che puoi dire qui è: "se i suoi compromessi sono in media saggi, va bene; in caso contrario, è un male; tuttavia, * non sappiamo quale sia *, a parte il fatto che la direzione è contenta del suoprestazione."Ammetto che non è un segnale incoraggiante, ma la gestione non è attendibilmente sbagliata.
E ovviamente se trovi una soluzione adeguata che sia buona, solida e veloce, è fantastico, ma non sembra adattarsi alla domanda.
[XKCD] (https://xkcd.com/2030/)?
Per ridurre il debito tecnico ci deve essere debito tecnico.
Tieni presente che il fumetto in questa risposta tiene conto solo del tempo * che * spendi.L'azienda per cui lavori ha acquistato il tuo tempo / lavoro, quindi se vuole una soluzione, ha il diritto di utilizzare il tuo tempo, anche se il tempo risparmiato non è "recuperato" dalla soluzione.
Caro dio questa è una risposta terribile.Non solo l'OP ha implementato queste soluzioni nel * peggior modo possibile *, lo ha fatto andando contro i processi stabiliti del proprio team di sviluppo, risultando quindi sia insubordinato che distruggendo ogni fiducia con quel team.Inoltre, fornendo tali soluzioni, hanno minato la fiducia che l'azienda ha in quel team.Quindi, hanno premiato la mancata pianificazione dell'azienda con una soluzione funzionante, il che significa che l'azienda si aspetterà questo dal team di sviluppo in futuro.OP non è uno sviluppatore con cui ** mai ** vorrei lavorare.
Sono solo io o il grafico xkcd è difficile da capire?L'asse x indica la frequenza con cui eseguiamo l'attività;fatto.y è quanto tempo risparmiamo;Presumo tra 5 anni?Ma cosa rappresentano i dati all'interno delle celle?È forse il tempo utilizzato per l'ottimizzazione o potrebbe essere il tempo necessario per completare l'attività non ottimizzata?Nessuna di queste opzioni ha senso.Il chiarimento sarebbe molto apprezzato :)
@NoelWidmer: in alto a destra: se fai qualcosa all'anno e ti ci vuole 1 secondo (asse y), puoi impiegare 5 secondi per ottimizzarlo (ingresso nella cella) in modo da guadagnare qualcosa in un periodo di 5 anni.
image
2020-04-02 11:51:55 UTC
view on stackexchange narkive permalink

Ho la sensazione che solo la direzione abbia dato risposte qui, perché non c'erano altro che elogi nel rispettare scadenze irragionevoli.

C'è un altro punto di vista qui. Non dovresti sottovalutare i disturbi sociali che accendi all'interno del team di sviluppo quando la direzione taglia gli angoli e ignora le opinioni degli sviluppatori senior. C'è un detto che va più o meno così:

Finché c'è qualcuno che spegne costantemente il fuoco, la direzione non smetterà di giocare con i fiammiferi.

Una cosa è se una / due volte percorri la strada degli hacker perché sei costretto a farlo, ma è completamente diversa se sta diventando la norma. E dalla tua descrizione mi sembra che la gestione sia diventata abbastanza a suo agio con la pratica di usarti per tagliare gli angoli. Dovresti considerare seriamente di sollevare questo problema alla tua direzione e agli sviluppatori senior al fine di mantenere un ambiente di lavoro sano. Un'azienda è un equilibrio tra sviluppo e gestione e non semplicemente una struttura dall'alto verso il basso. C'è un motivo per cui esiste la parola "no" e dovresti esercitarti a usarla.

Tuttavia, questo è ancora più un problema di gestione che il tuo. Quindi, non c'è motivo di menzionarlo in qualche modo nel tuo curriculum. Quindi vorrei accettare:

in grado di rispettare le scadenze

motosubatsu
2020-04-01 15:39:36 UTC
view on stackexchange narkive permalink

Come dice il proverbio "Perfetto è il nemico del bene", fare compromessi tecnici per soddisfare le esigenze aziendali è praticamente d'obbligo. I bravi sviluppatori / programmatori / ingegneri sono quelli che possono identificare i compromessi accettabili che possono essere fatti.

Nel tuo esempio API il cliente era chiaramente più disposto ad accettare un 4 minuti di ritardo nell'elaborazione per qualcosa che ha funzionato ed è stato consegnato in tempo.

Idealmente dovresti cercare di ridurre al minimo il debito tecnico quando fai questi compromessi, ma è tutto parte integrante dell'esperienza e del sapere dove puoi radere il tempo e quando devi assicurarti che qualcosa sia fatto "bene" in per risparmiare più tempo a lungo termine.

La mia domanda fondamentale è: c'è un modo per elencare questo tipo di cose nel mio curriculum che non mi faccia sembrare un programmatore di hacker che mina gli sviluppatori senior?

Quando arriva in cima al tuo CV non c'è bisogno di entrare nelle specifiche della tua soluzione: puoi semplicemente dire che hai una buona esperienza di consegna alle scadenze in tempo -progetti sensibili e menzionare gli esempi senza dettagli sull'effettiva implementazione.

Ho dovuto cercare su Google la tua formulazione di fantasia ed è scritta [de rigueur] (https://en.wiktionary.org/wiki/de_rigueur)
In alternativa, va benissimo avere un grande debito tecnico per rispettare una scadenza, o ottenere qualcosa dalla porta, e poi tornare indietro dopo lo scricchiolio del tempo e la pulizia.Ecco perché si chiama * debito *, va bene prendere in prestito, fai solo attenzione agli interessi che ripaghi fino a quando non viene ripulito ed evita il fallimento.
Non sono un fan di questa risposta (anche se la conclusione è quella giusta).Il cliente potrebbe essere disposto ad accettare un ritardo di 4 minuti, ma alla società potrebbe non piacere dover ripulire questa merda più tardi.E i colleghi dell'OP di certo non lo faranno.
Il problema con quel detto è che è vero se stai sostenendo la perfezione o se stai sostenendo "abbastanza buono".È come dire: "Queste parole significano cose diverse e queste cose producono risultati diversi".
Torsten Link
2020-04-01 15:57:54 UTC
view on stackexchange narkive permalink

Quello che fai NON è "hackerare", è "trovare soluzioni".

Lavoro come sviluppatore e consulente da 20 anni e questa abilità è ciò che i datori di lavoro cercano: non lasciarla fuori dal tuo curriculum, ma sottolinea esattamente questo: Cerchi di trovare soluzioni anche se questo significa percorrere strade "insolite".

Non scrivere che lo fai dietro le spalle di sviluppatori senior ma che lo fai ogni volta che vengono richieste soluzioni anche se ragazzi più esperti non essere d'accordo / dire che non è possibile.

C'è una bella 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 sapeva è arrivato e l'ha fatto.

Ho lavorato insieme a molti sviluppatori e conosco ogni aspetto di questo:

ho lavorato con uno sviluppatore che è tra l'1% dei migliori esperti di JavaScript su stackoverflow. È un genio e ammiro davvero ogni riga di codice che scrive. Ma molto spesso non portava a termine 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 hanno preso molte scorciatoie che hanno reso le soluzioni quasi impossibili da mantenere (percorsi hardcoded, numeri magici, ecc.).

E ho sempre preferito "fatto" a "bello" e alla fine anche i miei clienti lo hanno fatto: preferirebbero avere "qualcosa" quando la scadenza è lì che "niente ma saranno belli in un po 'di più time X "

Solo una cosa: soluzioni alternative / scorciatoie /" hack "devono essere comprensibili, documentate e gestibili, quindi non c'è nulla contro soluzioni come te

Questo è interessante, perché nelle domande dell'intervista mi è stato chiesto innumerevoli volte se preferirei consegnare un progetto perfetto in ritardo o un progetto meno che perfetto in tempo.Ho sempre risposto al primo, ma ora non ne sono così sicuro.Quando si considerano le esigenze aziendali del cliente.
"Hacking" _è_ "trovare soluzioni".
Dave3of5
2020-04-01 20:40:06 UTC
view on stackexchange narkive permalink

Mi sembra un normale debito tecnologico. Il Senior era probabilmente più vecchio e stanco e non voleva aggiungere altri debiti al progetto già sovraccarico (un po 'come me in realtà sarei io quello che respinge questo). O forse stavano solo cercando di proteggere la squadra. Diamo un'occhiata direttamente alla tua domanda:

c'è un modo per elencare questo tipo di cose nel mio curriculum che non mi faccia sembrare un programmatore di hacker che mina gli sviluppatori senior?

Forse sono ingenuo qui, ma non dovresti elencare questo tipo di cose nel tuo curriculum. Solo i risultati complessivi, quindi se questa è la norma per questa azienda sarebbe che "hai lavorato in tempi ristretti per fornire soluzioni ai clienti" piuttosto che i dettagli su come hai sollevato una procedura memorizzata o due in pochi giorni per creare qualcosa che lavora per il cliente. Se leggo un curriculum che dice che consegni in tempi stretti, capisco il punto, ha detto nuff.

Questo è tutto ciò che dovresti aggiungere davvero al tuo curriculum anche se lo manterrei libero se hai lavorato per Blah Inc uno sviluppatore che lavora con SQL e qualsiasi altra tecnologia. Perché anche questo deve essere sul tuo curriculum.

E ovviamente dovresti considerare di lasciarlo fuori se non vuoi lavorare in tali situazioni in futuro,)
StackOverthrow
2020-04-02 00:29:54 UTC
view on stackexchange narkive permalink

Stai descrivendo il debito tecnico e il debito tecnico non è sempre negativo. L'analogia del debito si estende all'esistenza di molte ragioni legittime per cui una società dovrebbe contrarre debiti finanziari. La chiave è che è intenzionale e c'è un piano realistico per ripagarlo. Martin Fowler ha scritto molto su questo, in particolare su quello che chiama il quadrante del debito tecnico:

enter image description here

come se avessi preso una decisione prudente riguardo al debito tecnico. Riconoscere dove il debito tecnico è prudente e sapere come gestirlo sono competenze estremamente preziose.

Ma il debito tecnico tende ad accumularsi fino a una riscrittura forzata (molto lunga e costosa).
@PeterMortensen È qui che devi prendere una decisione prudente.Se spedisci ora, ricevi contanti da un cliente, quindi devi pagare il debito tecnico.Se non spedisci ora, non ricevi contanti da un cliente, potresti andare in bancarotta e non riuscire mai a finire il prodotto.
@PeterMortensen Gli sviluppatori devono comunicare lo stato del debito alla direzione.Se gli sviluppatori riconoscono il debito e i manager no, elabora le stime su altre attività per includere il tempo per ripagare il debito e / o inizia a cercare un datore di lavoro più degno del tuo talento.
@PeterMortensen No, il debito tecnico si accumula _quando decidi di lasciarlo accumulare_ (invece di ridurlo man mano che procedi con la modifica del codice).È una scelta dello sviluppatore se fornire stime che aumentano o riducono il debito tecnico (anche se la direzione potrebbe costringerli a lavorare in modo tale da aumentarlo comunque).
Karl Bielefeldt
2020-04-03 19:13:16 UTC
view on stackexchange narkive permalink

Devo dire che non vorrei assumerti e non è perché hai fatto dei compromessi. Questa è una parte importante del lavoro e un'abilità difficile da acquisire. È perché hai fatto cieco compromessi senza il vantaggio dell'esperienza del resto del tuo team.

Esplorare potenziali progetti non è "contraddire" uno sviluppatore senior. La conversazione sarebbe dovuta andare in questo modo:

Tu: e se facessimo X?

Senior dev: probabilmente raddoppierebbe il tempo di elaborazione. Non credo che il cliente ne sarebbe contento.

PM: In realtà, penso che preferirebbero che fosse lento piuttosto che per niente. Li ricontatterò per esserne sicuro.

Altro junior: Bob sa molto di SQL. Se riusciamo a convincerlo ad aiutare, scommetto che potrebbe risparmiare molto tempo.

Senior dev: Ma sono ancora preoccupato per il caso d'angolo Y. Ci vorrebbe un po 'di tempo per testarlo correttamente . Sarebbe davvero imbarazzante se ci sbagliassimo.

PM: Sono d'accordo. Se lavori sul test e OP ha lavorato con Bob per modificare l'API come ha detto, potrebbe essere fatto?

Senior dev: Penso di sì per la scadenza, ma vorrei tornare indietro e ripuliscilo per la prossima versione. Altrimenti rischiamo il mal di testa da manutenzione Y ogni volta che il cliente lo fa.

PM: Va bene.

Inoltre, queste cose fanno vengono fuori interviste. L'intervistatore vede qualcosa come "riconosciuto per aver fatto dei compromessi per fornire valore in scadenze ravvicinate" e chiede un esempio, quindi prosegue ponendo più o meno le stesse domande che farebbe il tuo sviluppatore senior.

Sono d'accordo sul fatto che il coinvolgimento di sviluppatori senior sarebbe molto desiderabile, ma mi aspetto anche che * loro * trovino e considerino le scorciatoie che hanno permesso a hackydude di fornire in tempo.Nella mia esperienza, gli sviluppatori senior sono mentalmente così bloccati con il loro modo di fare le cose, l'unico modo * corretto *, che confondono "brutto" con "impossibile".
Si Questo!Mi piace particolarmente il fatto che lo sviluppatore senior abbia condizionato la soluzione hacky sulla pulizia post-operatoria per migliorare la manutenibilità.
Non c'è niente di sbagliato nel debito tecnico.Il debito tecnico sconsiderato senza piano di rimborso è il modo in cui i prodotti cadono a pezzi.È come i soldi.Accendere un mutuo non è male.Il rifiuto di rimborsare la banca, tuttavia, alla fine tornerà a morderti.
Josiah
2020-04-02 12:31:06 UTC
view on stackexchange narkive permalink

Lascio la domanda "Il tuo curriculum è il posto giusto per questa storia?" da un lato. Forse il curriculum non ha spazio per tali dettagli, ma diciamo che è il genere di cose che potrebbero emergere in un'intervista e stai cercando di pensare a come presentarlo nella luce migliore. In ogni caso, anche se nessuno ne parla più, vale la pena riflettere sulle implicazioni per il proprio sviluppo professionale. Ora, ecco l'unica osservazione che suggerirei pertinente e che nessun altro ha menzionato:

Hai ancora il lavoro.

Tu " stai cercando il modo migliore per presentare la storia, ma hai anche il privilegio di poter cambiare la storia.

Quindi, hai espresso un giudizio e hai preso un rischio. Per questo motivo, sei riuscito a rispettare una scadenza con funzionalità completamente osservabili, a soddisfare un cliente e a fare colpo sui tuoi manager. Per questo motivo hai anche fornito una soluzione con costi di esecuzione più elevati del necessario, potenzialmente compromesso il design della base di codice e messo in imbarazzo i tuoi team leader. Questa è una decisione ragionevole da fare. Altri hanno già spiegato come presentarlo: lasci del tutto fuori dalla storia il conflitto intra-team, dichiari esplicitamente i problemi tecnici con la tua soluzione che hai riconosciuto, insieme alla consapevolezza della realtà aziendale, e spieghi che hai fatto un chiamata.

Ma se potessi raccontare una storia migliore, includerebbe sia l'accettazione che la cancellazione di questo debito. Sarebbe necessario dedicare un po 'di tempo alla revisione ora che la scadenza non si avvicina, forse per incapsulare meglio il codice e aggiungere alcuni test unitari chiave. Potrebbe significare ridurre due dei quattro minuti extra, magari consultandosi con il tuo esperto SQL locale. Comprenderebbe la ricerca di modi per condividere gentilmente il merito con il resto della tua squadra.

Se non vuoi una reputazione come il ragazzo che si muove velocemente e rompe le cose, valuta i pasticci tecnici, commerciali e interpersonali che le tue decisioni (comprese decisioni difficili ma molto ragionevoli) fanno e assumiti la responsabilità di chiarirli.

Hai ancora il lavoro.

Joe Strazzere
2020-04-02 01:21:45 UTC
view on stackexchange narkive permalink

Il problema è che il risultato è stato sempre quello di fornire scadenze ravvicinate dei clienti e, francamente, l'ho fatto decidendo che l'ingegneria poteva essere meno che eccezionale in casi mirati (che la direzione ha accettato).

Non sono sicuro di quali sarebbero state le conseguenze del mancato rispetto della scadenza, ma sono state abbastanza forti che il CEO della nostra azienda di 1000 persone mi ha inviato un'e-mail di ringraziamento per averlo consegnato.

È lì un modo per elencare questo tipo di cose nel mio curriculum che non mi faccia sembrare un programmatore di hacker che mina gli sviluppatori senior?

Il curriculum dovrebbe evidenziare il risultato "... consegnato il scadenze ravvicinate del cliente e ricevuto un'e-mail di ringraziamento dal CEO ".

Il modo in cui ci sei arrivato può o non può emergere in un colloquio, ma non appartiene al curriculum.

A volte, le decisioni aziendali richiedono rapidità. Posso dirti per esperienza personale che i manager apprezzano le persone che possono trovare un modo per fare cose importanti.

Potresti dire in quale paese si menziona un'e-mail di ringraziamento dal CEO sul curriculum?Non ne ho mai sentito parlare.
Non ho nemmeno sentito parlare di mettere un motivo per la tua promozione nel tuo curriculum.Penso che le regole siano cambiate da quando ho imparato a scrivere curriculum.
gnasher729
2020-04-02 15:04:37 UTC
view on stackexchange narkive permalink

Quindi hai creato un software che richiedeva quattro minuti per essere eseguito (perché il tuo codice non era molto buono). Se mi ci vogliono 12 ore per fare il lavoro a mano, il tuo software mi fa risparmiare 11 ore e 56 minuti. Se hai scritto un codice migliore che viene eseguito in 1 secondo, mi fa risparmiare 11 ore, 59 minuti e 59 secondi. Se il codice migliore è stato consegnato una settimana dopo, quindi ho dovuto eseguire il lavoro manualmente cinque volte, i 3 minuti e 59 secondi aggiuntivi non compenseranno mai il tempo perso.

O renderlo più estremo. Il software deve essere eseguito entro 24 ore. Il tuo codice è errato, quindi abbiamo bisogno di un computer da $ 5.000 per eseguirlo in 24 ore. Con un codice migliore, un computer da $ 2.000 potrebbe eseguirlo in 24 ore. Risparmio di $ 3.000. Se ci vogliono due settimane per rendere il codice più veloce, è una perdita complessiva.

Essere in grado di offrire quando è necessario è una cosa molto, molto buona. Inoltre, un ottimo sviluppatore può scrivere codice errato in modo da poterlo migliorare facilmente in seguito. I cattivi sviluppatori scrivono codice cattivo che è un problema da refactoring in una buona forma, i buoni sviluppatori sotto pressione di tempo scrivono codice cattivo che è facile da migliorare.

Mike Robinson
2020-04-02 03:06:01 UTC
view on stackexchange narkive permalink

"Che cos'è, dici?"

Il problema è, il risultato (!) è stato sempre rispettando scadenze strette dei clienti e francamente, l'ho fatto decidendo che l'ingegneria poteva essere meno che eccezionale in casi mirati (a cui la direzione ha acconsentito).

E ... (!)

Non sono sicuro di quali siano le conseguenze della mancanza del la scadenza sarebbe stata, ma erano abbastanza ripide che il CEO della nostra azienda di 1000 persone mi ha inviato un'e-mail di ringraziamento (!) per consegnarlo.

"Amico .... !!!" Voglio assumere you!!!

... a meno che tu non diventi prima un consulente di gestione!


Molto semplicemente, devi ... prima di tutto ... riconoscere che sei diventato eccezionale " dal duro lavoro delle tue stesse mani e dal fatto che sei stato riconosciuto molto correttamente per questo. Nei tuoi curriculum, dovresti enfatizzare le qualità che hai appena delineato nel tuo post originale.

Ma anche: "Non trascurare la tua situazione attuale". Non presumere automaticamente che l'unico modo in cui puoi ora avanzare è lasciarli ... Da qui derivano titoli come "Direttore", "Chief Technology Officer" e "Vicepresidente esecutivo".

Dmitry Grigoryev
2020-04-02 15:02:26 UTC
view on stackexchange narkive permalink

Parafrasando Einstein,

La qualità del software dovrebbe essere mantenuta la più bassa possibile, ma non inferiore.

So che ci sono molti sviluppatori che sono orgogliosi nel codice scrivono e sono fortemente in disaccordo con questo. Ma dal punto di vista aziendale, non appena viene raggiunto l'obiettivo di qualità del software, migliorare ulteriormente la qualità equivale a un lavoro extra speso per qualcosa che non ti è stato chiesto di fare o per cui non sei pagato. La qualità assoluta non è semplicemente raggiungibile: non importa quanto sia buono il tuo software, c'è sempre spazio per miglioramenti.

Chiaramente, non sei stato elogiato per aver abbandonato la qualità del codice. Sei stato elogiato per aver mantenuto una qualità del codice accettabile pur rispettando una scadenza. È così che dovresti esprimerlo nel tuo CV.

cjs
2020-04-03 16:31:54 UTC
view on stackexchange narkive permalink

Non ho un'opinione particolare su cosa inserire nel tuo curriculum per questo, anche se tendo a essere d'accordo con le risposte che dicono che quel genere di cose non si adatta veramente a un curriculum.

Tuttavia, Vorrei sottolineare cosa accadrebbe se ti intervistassi e descrivessi la situazione come hai fatto nella domanda.

Il mio primo pensiero sarebbe: "Bene, mi piace qualcuno che può fare ciò che necessario a breve termine pur riconoscendo i compromessi che sta facendo ". Ma c'è anche un problema abbastanza chiaramente identificabile nella gestione dei suoi progetti software da parte della tua azienda che ti chiederei di identificare.

La risposta che vorrei sentire è che qualcuno che non fa parte del team tecnico ha promesso qualcosa a un cliente entro una determinata scadenza senza un preventivo in mano dal team tecnico per quando potrebbe essere consegnato. Farlo è la ricetta per un disastro a lungo termine. Se non riuscissi a identificare questo tipo di problema, sarei molto diffidente nell'averti nel mio team.

Inoltre, una volta identificato il problema, qualcuno deve implementare soluzioni a lungo termine per farlo assicurarsi che il problema venga gradualmente ridotto e, idealmente, eventualmente eliminato. Ti chiederei cosa hai fatto tu, nel tuo nuovo ruolo dirigenziale, per realizzarlo. Se non riuscissi a trovare una buona risposta, di nuovo sarei piuttosto diffidente nell'assumerti. Assumersi la responsabilità di costose correzioni a breve termine è fantastico, ma se non ti assumi la responsabilità di correzioni a lungo termine che eliminano la necessità di quelle costose correzioni a breve termine e fanno risparmiare tempo e denaro all'azienda in generale, ti prenderei in considerazione adatto solo per un ruolo da junior fino a quando non hai imparato a farlo.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...