Creo que la persona a la que te refieres puede haber mezclado dos niveles diferentes de conocimiento / capacidad .
El primero es capacidad general de resolución de problemas. Esto no va a desaparecer , como han explicado otros con buenos ejemplos. Yo mismo tuve dos oportunidades en mi carrera como desarrollador de software, una vez por un año, y la otra estuvo cerca de un año, durante el cual prácticamente no hice programación. Podría volver a la profesión sin mayores problemas después de cada uno de estos.
Sin embargo, como lo expresó Chris, mi conocimiento de las características específicas del lenguaje / API se volvió "oxidado". Ese es el otro nivel, que es un conocimiento más a corto plazo y, de hecho, puede desaparecer bastante rápido (aunque en mi humilde opinión no es en un mes, necesitaría varios meses para notar la diferencia).
Sin embargo, tenga en cuenta que estas cosas a menudo tienen una vida media más corta de todos modos: las API cambian, las expresiones idiomáticas preferidas se vuelven obsoletas y surgen nuevas formas , etc. Digamos que tiene varios años de experiencia en este tema. A, pero en la actualidad usted está programando exclusivamente en el lenguaje B. Sus habilidades en el lenguaje A inevitablemente se oxidarán con el tiempo. Sin embargo, podrás desempolvarlos bastante rápidamente.
En cuanto a la mejor manera de "destruir" a un programador, lamento decir que existen métodos bien conocidos, probados y (desafortunadamente para nuestra industria) ampliamente practicados:
- siempre presiona a él / ella para que entregue resultados a horarios poco realistas
- exigen horas extraordinarias no pagadas regulares
- cargarlo con burocracia, p. ej. exija que obtenga la aprobación del jefe de su jefe y / o complete documentos extensos antes / después de cada cambio de código
- rechace cualquier idea de proceso / mejora de la calidad de él / ella con cualquier excusa que pueda encontrar (por ejemplo, "si no está roto, no lo arregle" o "esto es solo la última moda, no es necesario aviso ")
- inicie un sistema de bonificación personal dentro del equipo, declarando abiertamente que el equipo tiene una cantidad fija de bonificación total asignada, por lo que los miembros del equipo deben competir entre sí por ello
- microgestione a él / ella, reteniendo el derecho de tomar cada decisión técnica usted mismo por autoridad
- déle herramientas inadecuadas para el trabajo (PC antigua, monitor pequeño)
- colóquelo en espacios de oficina abiertos, pequeños y ruidosos, de preferencia junto con personas totalmente no relacionadas pero ruidosas (por ejemplo, ventas / marketing)
Si se practica de manera consistente, en unos pocos años, es casi seguro que esto haga que sus desarrolladores se agoten, matando cualquier deseo y entusiasmo en la programación.
Estos son algunos que me vienen a la mente; desafortunadamente, hay más: - (((