A seconda di dove è andato a scuola, potrebbe non avere più di qualche mese di esperienza facendo cose molto banali in una sola lingua. Questo può essere risolto, ma assicurati che ne valga la pena.

Sembra che tu debba sapere se può essere salvato o no.

1. metti via il codice per un po '
2. spiega un problema di dimensioni medio-piccole che esiste nel progetto
3. fagli spiegare come lo risolverà: nessun codice, nessun modello, pratica, solo lingua nativa o diagrammi che spiegano cosa deve accadere a un livello base.

Se riesce a trovare una soluzione a metà ragionevole o addirittura una soluzione sbagliata, ma attraverso il giusto processo di risoluzione dei problemi, può apprendere il codice. Se non riesce a pensare correttamente al processo di trovare una soluzione, probabilmente non gli puoi insegnare a pensare meglio.

Assicurati anche che il tuo management comprenda la situazione o che tu stia facendo il lavoro di due persone prima che sia troppo lungo finché il tuo nuovo ragazzo non si avvicina.

Dagli l'opportunità di brillare

In realtà ho avuto una posizione molto simile da un po 'di tempo ma ora penso di fare progressi con lo sviluppatore. Penso che alla fine sarà solo un caso di timidezza, ma gli ho appena detto "Ho bisogno che tu commetta e spinga al server così posso aiutarti meglio se rimani bloccato, e puoi aiutarmi meglio a supervisionare progetto ", e quindi ha iniziato a impegnarsi.

Dagli delle responsabilità che può affrontare (cioè al di sotto del suo livello) per migliorare il morale.

Dagli la possibilità di fallire

È anche importante lasciare che prendano le decisioni e falliscano, è chiamato apprendimento. Dagli il potere di prendere piccole decisioni architettoniche o di design e vedere come si comporta. Quando fallisce, digli come può fare meglio e then sedersi con lui.

Non diventare impaziente perché sai che farai in 5 minuti il lavoro che farà in cinque ore. Lascialo fare.

Assegnazioni più piccole

Avere incarichi più piccoli e obiettivi più chiari lo farà sentire meno perso e attaccare meglio i problemi a portata di mano; piccoli passi se vuoi.

Non tutte le persone hanno abbastanza iniziativa, purtroppo, ma l'iniziativa può essere insegnata.

Sii lì non essendoci

In parte continuando l'argomento "lascia che fallisca", ma stai sempre a portata di mano (ad esempio IM) ma non fisicamente. Se rimani connesso con lui tramite messaggistica istantanea, a volte puoi rispondere con la risposta corretta, ma altre volte puoi semplicemente lasciarlo sospeso e fingere di essere occupato (crudele, lo so * ghigno malvagio *), e dirgli solo "brb" , google XHR e ActiveX "o" google l'errore del compilatore ", o" google "... in questo modo lo stai in parte facendo sentire stupido in modo positivo e perdi progressivamente la paura di fare ricerche da solo.

Forniscigli gli strumenti

Conosce Firebug o Chrome Dev Tools ?. Che ne dici delle trappole comuni di js? Sta usando un buon framework javascript? (ad es. MooTools ). Hai davvero bisogno di dargli le armi per rendere il suo lavoro il più divertente e produttivo possibile.

Pensa a lui come al tuo passato

Non eri sempre un professionista, giusto? Come hai imparato ?, ricordalo e prova a metterlo sullo stesso percorso.

Se non viene effettivamente tagliato per il lavoro ...

Chiedigli se ha problemi con qualcosa e fagli sapere che le sue prestazioni non sono abbastanza buone. Personalmente mi piace essere diretto con le persone, e glielo dico in anticipo, quindi c'è meno risentimento.

Potrebbe non sapere che c'è un problema se non glielo dici.

Ho avuto un'esperienza simile con un programmatore junior. Ti darò l'aneddoto, insieme all'evidente avvertimento che ciò che ha funzionato per lei non avrebbe funzionato necessariamente per nessun altro.

Il suo problema era che non aveva mai avuto a che fare con qualsiasi cosa al college che non fosse un sistema giocattolo che si potrebbe ragionevolmente chiedere di fare in un set di compiti a casa. E così quando ha affrontato un problema reale in una vera e propria base di codice che si è evoluta da decenni, non aveva davvero idea da dove cominciare.

Il nostro manager le ha dato un problema realisticamente difficile, che non aveva troppe dipendenze da altre cose, che avrei finito in pochi giorni. L'ho vista bloccarsi su di esso. Dopo un po 'ho iniziato a frequentarla regolarmente chiedendole: "Vuoi un suggerimento?" Dopo un mese o due, alla fine si ruppe e fu disposta a darmi il mio aiuto.

Il mio "aiuto" consisteva nel convincerla a rompere il problema in piccoli pezzi. Ogni giorno entravamo, le parlavo e le chiedevo quali fossero i suoi obiettivi per quel giorno. Invariabilmente ha scolpito un pezzo mal definito e troppo grande. Le direi che mi sembrava troppo grande, e l'avrei fatta sminuire e dedicarmi a qualcosa che realisticamente avrebbe potuto fare a pranzo se non avesse riscontrato problemi seri. Dopo pranzo controllerei come stava andando.

In una settimana stava facendo buoni progressi e aveva capito il ritmo. Dopo un'altra settimana ha consegnato una soluzione perfettamente accettabile al problema che le è stato dato. Ha fatto bene il suo prossimo problema e ha continuato a fare perfettamente bene.

Si è scoperto che il nostro manager si aspettava effettivamente le sue prestazioni iniziali scarse. Sospetto che alla fine sarebbe intervenuto, ma ha visto quello che stavo facendo e ha calcolato che sarebbe stato più efficace venire da un collega che da un manager.

Scopri di più sul suo background e su ciò che gli è familiare. Se ha una laurea in informatica, presumibilmente ha fatto un po 'di codice (forse non Javascript però). Qualunque sia la lingua con cui ha familiarità, vedi se riesci a spiegare problemi / soluzioni in termini di quel linguaggio. Se riesce a vedere le somiglianze, forse le cose inizieranno a fare clic.

Le persone imparano in modi diversi, cercano di capire come impara meglio. Potresti chiedere a questo come una domanda diretta, o ancora come parte del sondaggio sul suo background, scoprire quale tipo di progetti ha goduto e ha fatto bene a scuola e vedere se può spiegare come sono stati strutturati. Alcune persone imparano meglio chiedendo di risolvere un problema con poca direzione e facendo sperimentazione / tentativi ed errori, mentre altri vorrebbero essere mostrati passo dopo passo ...

Un altro vantaggio nel chiedere informazioni sul suo background è che sarai in grado di determinare meglio se davvero non è adatto per un lavoro di programmazione. Ovviamente dovrebbe darsi un po 'di tempo e contribuire a migliorare, ma se alla fine non lo fa è male per entrambi se continua a provare a lavorare in un lavoro a cui semplicemente non è bravo.

Sembra che tu stia cercando di fare la cosa giusta aiutandolo.

(Inoltre: è possibile organizzare lavorare sul posto con lui per una settimana o giù di lì?)

è incompetente, non lo protegge - stai facendo al tuo cliente alcun favore stringendo una persona che non può eseguire

mi dispiace essere duro, ma è affari; non tutti con una laurea fanno un buon programmatore

che diceva, se vuoi aiutarlo a migliorare suggerisci di partecipare ai code kata, unirti a un gruppo di utenti locali, provare le competizioni di codifica e in generale mantenere la codifica, la codifica e la codifica finché non ha senso o si rende conto che ha scelto professione sbagliata

non, in nessuna circostanza, lasciare che questa persona diventi la tua responsabilità - a meno che non sia effettivamente il tuo lavoro

Duro.

Sfortunatamente, alcune persone affrontano i loro corsi di programmazione con la pelle dei loro denti, e spesso con l'aiuto (e il codice) degli altri, quindi è inevitabile che qualcuno venga immediatamente fuori dal college senza avere la prima idea di dove iniziare. (Potrei andare avanti e dare la colpa al sistema educativo un po ', qui, perché penso che ci sia la tendenza a fare troppo affidamento sul codice cookie-cutter, così come la tendenza ad astrarre qualsiasi programmazione di basso livello di distanza - qualcosa che io trova fondamentale il processo di programmazione, cioè la logica.)

Ecco qui:

• Comprendi che è totalmente nuovo in questo e non ha mai dovuto gestire qualcosa di più grande di un paio di migliaia di righe di codice ( se questo ). Di fronte a un'applicazione su larga scala con conseguenze nella vita reale, sarà più che un po 'esitante, ed è improbabile che capisca anche la foresta, per non parlare degli alberi e del modo in cui interagiscono tutti.
• Incoraggia, dove possibile. Se una parte del codice fosse utilizzabile, o se si potesse vedere la direzione in cui il codice stava andando era buona, allora incoraggia, anche se il risultato finale non è così caldo. A quel punto, guidalo verso la soluzione, senza pronunciarla parola per parola. (Dico alla gente che io google per tutto. Incredibile la gente che mi ignora, però.)
• Consenti errore. Lascialo vedere cosa succede quando le cose si rompono completamente e completamente se possibile. Se non è possibile, dimmi che non sta andando dritto alla produzione? Ambienti di test regola .) Si impara di più dal fallimento di quanto non faccia dal successo. (Dico questo perché posso scrivere codice che funziona, senza capire il motivo per cui funziona. Se il codice si rompe, devo lavorare su cosa dovrebbe fare, perché la sua parte funziona e perché la parte che fallisce non è funziona.)
• Entra in secondo piano un po '. Questo programmatore può avere un metodo di apprendimento completamente diverso e potrebbe non essere in grado di fare lo stesso salto logico nello stesso modo in cui lo si fa. (Sono un buon esempio: posso fare grandi, grandi, logici balzi logici che sembrano semplici per me. E poi mi chiedo perché tutti gli altri si chiedano come ottenere dal punto A- > B mentre sono già al punto D. E poi mi ricordo, sono naturalmente logico. Non lo sono tutti.)
• Dagli tempo. Non tempo mentre non fai nulla; no, ma nel tempo l'individuo dovrebbe iniziare a raccogliere le cose. Se non lo fanno, tuttavia, potrebbe essere il momento di ...
• ammettere la sconfitta. Con grazia. E non proprio. Con questo intendo che potrebbe essere necessario avere una discussione sincera con il manager, ma anche rendersi conto che sostanzialmente vieni pagato per aiutarlo. Se vuoi continuare un buon rapporto con il tuo cliente, stringere i denti o lasciar cadere il cliente potrebbero essere le tue uniche opzioni finali.

Ci sono ovviamente molte variabili in gioco qui (e altre buone risposte), ma qui ci sono alcune domande da porsi e alcuni pensieri:

• Qual è l'aspettativa di gestione della sua posizione? È stato assunto con l'intento di essere mentore? In tal caso, quanto è previsto il tutoraggio? Questo è importante per aiutare a determinare quanti sforzi spendere per aiutarlo a diventare veloce ed esperto, anche se è per piccoli compiti.
• Trascorre qualsiasi autoapprendimento del "tempo libero" su ciò a cui sta lavorando? Ad esempio, se sta lottando con JavaScript, sta passando un po 'di tempo da solo per essere aggiornato?
• Si avvicina ai suoi coetanei quando si blocca o sta aspettando il suo tempo? Ho lavorato con alcuni sviluppatori che preferirebbero sedersi e fissare lo schermo piuttosto che chiedere aiuto.
• Come menzionato in un'altra risposta, qual è il suo background? Ha fatto qualche codifica prima del college? Contribuisce a progetti open source a qualsiasi titolo? Questo per aiutare a valutare l'interesse e la passione per il ruolo.
• Quando lavori con lui, permetti a lui di "guidare" e discutere il suo processo mentale? Lo aiuti a raggiungere una soluzione corretta attraverso la discussione?
• Mostra qualche segno di miglioramento mentre lavori con lui? Ricorda dove si trovava quando ha iniziato e fino a che punto è arrivato da allora. Il tasso di crescita delle competenze è accettabile?
• Ascoltate voi o altri quando date consigli? Alcune persone prenderanno consigli e ignoreranno o non capiranno, ma invece continueranno a fare le proprie cose. Questo include critiche costruttive.
• In realtà causa più lavoro per gli altri? È qui che diventa un po 'pericoloso continuare a incastrare qualcuno per la corsa. Se qualcuno sta avendo un impatto negativo su un progetto, può essere necessaria una nuova valutazione per determinare se è meglio mantenere il mentoring o meno. Vuoi un contributo positivo, non importa quanto sia piccolo all'inizio.
• Ha un atteggiamento positivo nei confronti della programmazione? Un atteggiamento povero può essere dannoso non solo per la sua performance, ma anche per quella degli altri.
• Renditi conto che non tutti sono uguali. Questo dovrebbe essere ovvio, ma è così. Tutti imparano ed eseguono i loro compiti in modo un po 'diverso, ma dovrebbero esserci anche dei limiti per ciò che è accettabile o meno. Questo può variare da azienda ad azienda e progetto da progettare.

Quindi, davvero, questo dovrebbe ridursi a aspettative, attitudine, attitudine e contributi. Se dimostra di essere capace di imparare e di raccogliere ciò che ha bisogno di sapere, allora può valere la pena tenerlo se anche lui ha un buon atteggiamento.

L'importante è che mostri progresso e crescita e non ristagni o si senta facilmente frustrato. Questo è un ruolo che richiede pazienza e un po 'di auto-motivazione.

Chiamata difficile. Cerca di identificare le basi che gli mancano.

Per aiutarti a localizzare l'area in cui si trova il problema, chiedigli quando è stata l'ultima volta che sta andando bene, l'ultima volta che ha veramente capito cosa stava facendo, poco prima che fosse confuso. Potrebbe essere qualcosa che ha studiato prima di entrare in azienda.

Troverete che da qualche parte in quell'area, nelle cose che crede di capire , è la vera causa della sua confusione. Potrebbe essere qualcosa di fondamentale come non aver mai capito cosa fosse una variabile o anche cosa significasse la programmazione. Ripeti l'operazione alcune volte e dovrebbe iniziare a diventare "più luminoso".

Un altro approccio sarebbe guardare le varie cose con cui è bloccato. Quindi "triangola" e scopri quali sono i denominatori comuni. Nota qualsiasi cosa faccia che non ha alcun senso. Quindi cerca di capire come si integrano. Se riesci a trovare un modello, dovrebbe darti una buona idea di ciò che davvero non capisce.

Un'altra possibile situazione è che non capisce cosa dovrebbe fare l'applicazione e perché. Una demo dell'applicazione e qualche contesto dal pov dell'utente potrebbero davvero aiutare lì.

Una volta che sai cosa non capisce, puoi aiutarlo in modo efficace. Fino ad allora, stai solo scherzando e sperando di essere fortunato.

Tuttavia, tieni presente che il debugging potrebbe non essere ciò che il tuo cliente paga, quindi, a meno che tu non abbia una comprensione con il tuo cliente, non lasciarti alle spalle i tuoi obiettivi.

Buona fortuna.