Penso che la persona a cui fai riferimento possa avere un misto di due diversi livelli di conoscenza / abilità .
Il primo è abilità di risoluzione dei problemi generali. Questo non sta per svanire , come altri hanno spiegato con buoni esempi. Io stesso ho avuto due interruzioni nella mia carriera come sviluppatore di software, una volta all'anno, e l'altro era vicino a un anno, durante il quale praticamente non avevo programmato. Potrei tornare alla professione senza grossi problemi dopo ognuno di questi.
Tuttavia, come ha affermato Chris, la mia conoscenza delle specifiche funzionalità linguistiche / API è diventata "arrugginita". Questo è l'altro livello, che è una conoscenza più a breve termine, e può effettivamente svanire abbastanza rapidamente (anche se IMHO non tra un mese - avresti bisogno di diversi mesi per notare la differenza).
Nota che queste cose spesso hanno un'emivita più breve comunque - le API cambiano, gli idiomi linguistici preferiti diventano obsoleti e nuovi modi di procedere , ecc. Supponiamo che tu abbia molti anni di esperienza nella lingua A, ma al giorno d'oggi si sta programmando esclusivamente in linguaggio B. Le tue abilità nel linguaggio A si arrugginiranno inevitabilmente nel tempo. Tuttavia, sarai in grado di rispolverare abbastanza rapidamente.
Per quanto riguarda il modo migliore per "distruggere" un programmatore, sono triste a dire che esistono metodi ampiamente noti, provati e (purtroppo nel nostro settore) ampiamente utilizzati:
- spingilo sempre a fornire risultati a programmi non realistici
- richiede un normale straordinario non retribuito
- affaticarlo / a con la burocrazia, ad es. richiedi che (s) ottenga l'approvazione dal capo del tuo capo 'boss' e / o compili lunghi documenti prima / dopo ogni cambio di codice
- rifiuta qualsiasi idea di miglioramento di processo / qualità di lui / lei con qualsiasi scusa riesci a trovare (ad esempio "se non è rotto, non aggiustarlo" o "questa è solo l'ultima moda, non c'è bisogno di prendere avviso ")
- avviare un sistema di bonus personale all'interno della squadra, dichiarando apertamente che la squadra ha una quantità fissa di bonus totale assegnata, quindi i membri del team devono competere l'uno contro l'altro per questo
- gestiscilo / controllandolo, mantenendo il diritto di prendere autonomamente ogni decisione tecnica
- dargli gli strumenti inadeguati per il lavoro (vecchio PC, piccolo monitor)
- stipularlo in spazi aperti e rumorosi, preferibilmente insieme a persone totalmente estranee ma rumorose (ad es. vendite / marketing)
Se praticati in modo coerente, nel giro di pochi anni è quasi garantito che i tuoi sviluppatori si esauriscano, uccidendo qualsiasi desiderio ed entusiasmo verso la programmazione.
Questi sono alcuni che mi vengono in mente - sfortunatamente ce ne sono di più: - (((