È fuori luogo dare critiche costruttive non richieste a un programmatore? [duplicare]

Se non sei nella posizione di modificare il codice da solo, dovresti decidere quale problema è il più importante e affrontarlo al riguardo. Piuttosto che esprimerlo come "critica" farlo sotto le spoglie del "feedback".

Quando dico feedback intendo un processo MOLTO distinto di affermazione del comportamento e dell'effetto di esso, sulla falsariga di "Quando fai X, ecco cosa succede ..." e parli STRETTAMENTE delle cose sono direttamente osservabili. Non attaccarlo, la sua professionalità, ecc. Atteniti ai fatti.

Per una grande panoramica sull'offerta di feedback tra pari ascolta questo postcast: link

Se hai successo con il primo elemento, passa a quello successivo più importante.

Buona fortuna!

In qualità di assistente sociale, apprezzeresti se questo programmatore venisse da te per consigliarti su come pensava di aver maneggiato in modo errato un caso importante sul quale hai lavorato, ma che non ti è stato assegnato?

Direi che si troverà su un terreno molto instabile per avvicinarsi a te; anche il contrario è vero.

Date le circostanze, direi che se nutrite preoccupazioni per lo stato di sicurezza dell'applicazione in questione (e considerato ciò che avete scritto qui, dovreste avere tali preoccupazioni), che sarebbe meglio servire portando le vostre preoccupazioni a coloro che hanno qualche potere di effettuare correzioni. Cercare di educare l'ex sviluppatore non è il tuo baluardo, ed è più probabile che venga visto come un'interferenza di qualsiasi altra cosa.

Poiché non è più pagato per lavorarci, probabilmente no. Ci sono due possibilità:

• Sa che è una cagata e non l'ha riparato.
• Pensa che sia buono, quindi non l'ha corretto.

In entrambi i casi, dirgli che ha gravi difetti non migliorerà, poiché non è più in fase di sviluppo.

Non penso che ci sia molto da discutere con il programmatore. Per cominciare, potrebbe non essere gentile a sentirsi dire come fare il suo lavoro da un "dilettante".

Tuttavia, potresti segnalare problemi di sicurezza gravi alla tua gestione. Lascia che decidano cosa fare al riguardo. In alcuni casi, sembra che le correzioni siano semplici modifiche alle autorizzazioni dell'account del database che possono essere implementate in pochi minuti.

Ma tu (e il tuo management) devi anche considerare se la sicurezza di questa applicazione è davvero importante. Contiene informazioni preziose o sensibili? È probabile che tu abbia problemi con dipendenti scontenti? La rete è correttamente protetta?

• Conoscete la storia del programma? Forse è stato scritto in un lasso di tempo molto breve in cui lo sviluppatore ha preso queste decisioni piuttosto rapidamente in quanto il software doveva essere fatto il più rapidamente possibile senza un sacco di indagini su di esso.

• Il supporto include patch sul codice? Questo potrebbe funzionare per alcune piccole cose che il codice ha che vedi come problemi principali. L'altro pensiero è quanto sarebbe difficile sostituire questo software.

Ci sono casi in cui un peer che aiuta un peer con critiche costruttive non richieste può funzionare, ma questo è un po 'diverso dalla mia mente. Direi che sii sensibile a come comunichi i problemi e cerca di mantenerlo professionale.

Innanzi tutto, in qualità di utente finale, sei uno degli stakeholder più importanti in questo progetto di sviluppo software. Le tue opinioni sono totalmente valide e meritano di essere ascoltate dalla direzione!

In secondo luogo, sembra che tu sappia di cosa stai parlando (sai quando un DB non è normalizzato correttamente), indipendentemente dal titolo del tuo lavoro o dalle credenziali accademiche.

In terzo luogo, ovviamente ti senti molto a cuore di questa questione.

Quindi dovresti esprimere le tue preoccupazioni alla direzione. Assicurati solo di esprimere il tuo caso in modo articolato e in un modo molto rispettoso.

Qual è il tuo intento nel dire al programmatore che il suo codice ha bisogno di miglioramenti?

Stai cercando di farlo diventare un programmatore migliore? Allora sì, sei fuori linea, non è il tuo posto per dirgli che le sue capacità di programmazione sono scadenti.

Se il tuo obiettivo è sollevare dubbi sulla sicurezza del codice, allora sì, può essere appropriato, ma non con il programmatore. Parla con chiunque sia responsabile dell'applicazione e chiedi se sono interessati ad alcune preoccupazioni che hai. Non limitarti a dire "Ehi, sai che l'app che conserva i record di foo? Fa schifo, ed ecco perché." Descrivi il problema separato dai problemi di come doveva essere in quel modo e chi lo ha fatto.

Pensa se hai notato che la porta basculante del magazzino era protetta di notte con un pezzo di spago. Non diresti "La tua sicurezza fa schifo, e chiunque lo abbia creato è un idiota, e se non lo aggiusti ora, sei fregato". Anche se conoscessi tutto il retroscena su come doveva essere in quel modo, lasceresti tutto questo.

Invece, diresti "Ho visto qualcosa che ho pensato di dover segnalare. Ho visto che la porta del magazzino è chiusa con spago, e temo che non sarebbe abbastanza strong da tenere fuori un ladro determinato ". È interamente focalizzato sul problema che vedi e non entra nel dramma di come deve essere in quel modo.

E se dici "Ehi, ho dei problemi di sicurezza" e loro dicono "Sì, va bene, è interno, non è un grosso problema", quindi lascia perdere. Hai fatto il tuo lavoro.

La mia esperienza è che gli sviluppatori raramente accettano critiche (chi lo fa?). Ecco perché ci sono così tante accese discussioni religiose su qualsiasi cosa abbia a che fare con la programmazione (miglior linguaggio, piattaforma, struttura). Quindi lo farei solo in una conversazione casuale, come hai detto che hai guardato il sistema.