Convinci lo sviluppatore a utilizzare IDE [chiuso]

Hai più o meno già risposto alla domanda:

1. È in libertà vigilata
2. Non è abbastanza produttivo

Quindi, deve essere reso chiaramente consapevole che:

1. Deve essere più produttivo o non sopravviverà alla sua libertà vigilata.
2. È suscettibile di essere più produttivo con un IDE corretto rispetto a un buon editor di testo.
3. Un buon IDE non significa rinunciare al controllo del codice che scrivi per fornirti strumenti che ti consentano di produrre codice funzionante più rapidamente indipendentemente dal fatto che tu scelga di utilizzare la generazione del codice e le strutture di template che possono essere disponibile all'interno dell'IDE .

Anche la mancanza di volontà di adattarsi al suo ambiente potrebbe essere una preoccupazione.

Bill dovrebbe dire a John che ha ragione a preferire un semplice editor di testo, ma sfortunatamente, con framework di linguaggio + come Java + Hibernate + Spring, ha bisogno di usare un IDE se vuole essere efficiente.

Sono un po 'come John. Non mi piace usare gli IDE.
Quando eseguo il codice in ruby / python / bash / lisp, non utilizzo alcun IDE.

Ma quando ho a che fare con un linguaggio di basso livello / verboso come Java e framework che rendono il tuo codice molto difficile da consultare senza aiuto, io uso l'IDE. Questo è anche vero se non conosco molto bene il linguaggio / framework.

• Più astrazione / schemi / framework usi, più hai bisogno di un IDE in grado di aiutarti a navigare nel tuo codice.
• Più un livello basso / prolisso / a te sconosciuto è una lingua, più hai bisogno di un IDE in grado di aiutarti a generare / trovare il codice che ti serve.

Digli che se vuole essere efficiente con gli strumenti che usi, deve usare un IDE. Bill dovrebbe anche eseguire una coppia di programmi con John per mostrargli quanto può essere efficiente con l'IDE.

Penso che spingere un IDE sia una cattiva idea. Penso che avere una lista di strumenti che le persone possano usare e che gli consenta di scegliere ciò che usa sia una soluzione più rispettosa.

Quindi concentrati sulle prestazioni e sulla produttività dei problemi reali, fornisci statistiche reali su come alcuni progetti hanno impiegato troppo tempo.

Non lasciare che il focus sia lo strumento che usa per codificare, ma fagli trovare la sua soluzione, a patto che l'obiettivo sia una migliore produttività.

Sono entrato in molte aziende, al 90% non importa, a patto che non debbano pagare strumenti, il 10% di attenzione e la domanda che usano i loro strumenti.

Se rendi l'IDE il vero punto focale della tua discussione, sei totalmente irrispettoso nei confronti di lui e dei suoi metodi.

Invece di concentrarsi sulla vera questione chiave della produttività, della qualità e delle prestazioni.

Io stesso, ho usato un editor di testo per oltre 6-7 anni, e non c'è niente di sbagliato nella mia performance.

Un IDE può essere d'aiuto, ma deve essere la scelta del programmatore di usarlo, purché non influenzi le prestazioni.

Personalmente odio che gli IDE non li useranno mai, più la gente li spinge su di me, più mi sento irrispettoso. Non ho alcun problema con quale strumento le persone usano, ma è come una religione e l'evangelizzazione, sentono il bisogno che tutti gli altri debbano pensare / fare tutto come fanno loro.

E questo è un approccio molto poco professionale a quale sia il vero problema, la sua produttività.

Se consegna il lavoro di qualità, nei suoi metodi, a chi importa quali strumenti usa? Purché sia privo di errori, di qualità e tempestivo.

Non so che abbiamo confermato che l'IDE è il problema di John. Penso che Bill dovrebbe lavorare con John per un po 'e osservarlo: cosa sta facendo diminuire la sua produttività. Se passa ore a formattare il suo codice e cerca di spostare le cose intorno o cercare le funzioni ... il tipo di cose che un IDE ti fornisce, allora dovresti mostrargli quanto più velocemente può trovare le funzioni che desidera e formattare il suo codice con l'IDE. Se questa è la frustrazione, sono sicuro che una volta che ti vedrà auto-formattare un blocco o trovare rapidamente qualche funzione oscura, salterà sul tetto in allegria.

Se tuttavia, l'efficienza è dovuta al fatto che sta navigando su Google o sta avendo problemi a formulare le sue idee in strutture di codifica, un IDE non lo aiuterà. In tal caso devi reprimere la sua disciplina, o aiutarlo a imparare a schematizzare le sue idee in un flusso di programma in modo che possa attaccare in modo più efficiente il problema

EDIT: il mio rappresentante è troppo basso per commentare, quindi devo postare qui. Non sono d'accordo con le persone che dicono "lascialo licenziare, poi imparerà". Per alcune persone questo funziona; perdere il lavoro li sciocca e loro si svegliano e si svegliano. Altri si svilupperanno a spirale in una spirale autodistruttiva che di solito termina in terapia o benessere. Bill si preoccupa chiaramente di John o non gli chiederebbe come aiutarlo, quindi penso che i commenti e le risposte sul fatto di lasciargli licenziare non siano assolutamente ciò che Bill sta cercando.

Il fallimento è un grande maestro. Bill può smettere di proteggere John e lasciarlo alle proprie decisioni. Se John viene licenziato a causa di ciò, spero che questo lo renderà un dipendente migliore per la prossima compagnia che lo ingaggia.

Puoi provare a convincerlo che se capisce l'IDE e cosa fa, rimane in controllo totale.

Questa è la carota.

Il bastone è che è in libertà vigilata.

Devo dire che stavo usando e IDE (aptana per javascript), e lo odiavo, era lento e facevo cose strane con la formattazione. Sono passato a gvim con un sacco di strumenti da riga di comando e sono molto più felice.

naturalmente sono il tipo di persona che scriverà generatori di codice in elisp per divertimento.

Ho difficoltà a credere che la performance di John abbia a che fare con l'editor che sta usando. Sul mio posto di lavoro praticamente tutti usano un editor di codice diverso (Visual Studio, Source Insight, vim, SlickEdit ...) e non vi è alcuna correlazione visibile tra l'editor / IDE e le prestazioni lavorative.

Se esiste un IDE standard aziendale, basta dirgli chiaramente "Questo IDE è lo standard aziendale, USE IT".

Se non esiste un IDE standard aziendale e il desiderio di utilizzare un IDE è solo per aumentare le prestazioni, allora è:

1. L'assunzione errata di fare quella scelta di ambiente di sviluppo sarà un fattore determinante per le prestazioni
2. L'approccio sbagliato per dirgli di usare un IDE

Se vuoi davvero che usi un IDE, penso che l'approccio migliore sia dirgli che le sue prestazioni non sono all'altezza, quindi mostrargli come l'uso di un IDE può aiutare a migliorare le prestazioni. Mostrare con l'esempio è un motivatore molto migliore a mio parere.

Detto questo, penso che le ipotesi siano sbagliate qui. Gli sviluppatori più decenti possono essere produttivi in quasi tutti gli ambienti di sviluppo. Se non è all'altezza delle aspettative, forse la causa principale è lo sviluppatore, non l'IDE.

Se Bill, nonostante la sua posizione di capogruppo, non può convincere John a utilizzare un IDE quando Bill vuole che tutti lo usino, c'è qualcosa di sbagliato nella società in quanto il capo squadra non ha abbastanza autorità.

E no, a seconda del lavoro dato a una persona, quella persona può essere altrettanto produttiva senza un IDE come con uno, a seconda degli strumenti in uso, dell'esperienza della persona con quegli strumenti e della sua competenza generale (e ambiente generale, se John deve estrarre ogni sorgente da un server delle applicazioni, caricarla nel suo IDE, modificarla, caricarla di nuovo, ecc. ecc. è molto più veloce semplicemente modificando direttamente sul server delle applicazioni usando VI (supponendo che sappia che editor bene).

Non usare IDE è molto buono perché imparerà molto. Ma non dovrebbe essere sul costo del progetto. Dovrebbe usarlo quando pensa di poter finire il lavoro senza intaccare la timeline.

Suggerirei di fare entrambe le cose, in modo che possa imparare velocemente e allo stesso tempo non entrare nei problemi.

Dopo tutto hai bisogno di pane per sopravvivere, solo tu puoi pensare di diventare un body builder.

Penso che il valore principale di qualsiasi IDE non sia che si tratta di un editor, ma di un debugger. Ci sono alcuni che non hanno il concetto di un debugger. Eseguono il debug con le dichiarazioni di stampa.

Se altre funzionalità sono ciò che presumibilmente rende gli IDE più produttivi, come l'accesso al controllo della versione o di intellisense, potrei trovarmi d'accordo con John, per vari motivi che potremmo discutere.

Ma il debugging con le dichiarazioni di stampa trovo difficile da convincere (anche se ero abituato a farlo).

Ascolta, ci sono persone che usano roba, ci sono altre persone che usano altre cose. Mi piacciono sia l'IDE che gli editor di testo, sono solo 2 diversi tipi di applicazione, ma alla fine l'attività è assolutamente la stessa.

È solo Arance e Mele, fine linea, se vuoi licenziarlo litigando "usa un editor di testo" oppure "è troppo lento, PERCHÉ usa un editor di testo", continua, ma tu davvero devi cospirare per qualche strategia su come puoi convincerlo?

Sai, la libertà non riguarda "prevale solo il più adatto", si tratta di "Fare ciò che voglio".

Non è perché vivi in una democrazia che dovresti imporre la pratica della maggioranza. Sembra quasi una persecuzione di qualche tipo