Apréndete programación en diez años (1998)
Las afirmaciones de que puedes “aprender programación en 24 horas” son ampliamente rechazadas en favor de una trayectoria de una década de práctica deliberada, proyectos variados y acumulación de intuición. Los comentaristas contrastan la experiencia profunda con objetivos más modestos, como estar listo para un empleo mediante bootcamps, señalando que el éxito depende en gran medida de los antecedentes previos, la motivación y un esfuerzo sostenido más allá de cualquier curso. También reflexionan sobre cómo las herramientas del campo, las metodologías (como Scrum) y ahora los asistentes de IA moldean qué y cómo aprenden realmente los programadores, al tiempo que enfatizan que los fundamentos y la curiosidad autodirigida siguen siendo lo más importante a largo plazo.
Tiempo hasta la “maestría” y el horizonte de 10 años
- Muchos coinciden en que ~10 años de práctica sostenida y variada parece una cifra adecuada para convertirse en un desarrollador “sólido”, aunque no necesariamente un maestro.
- El heurístico de 10,000 horas se ve como una simplificación excesiva, pero útil en términos generales; la gente enfatiza la práctica deliberada, cada vez más difícil, en lugar del simple tiempo transcurrido.
- Varios señalan que algunos desarrolladores se estancan en “1 año de experiencia repetido 10 veces” si no se siguen desafiando.
Trabajo profesional vs. proyectos personales
- Algunos sostienen que un trabajo de software estándar de 40h/semana basta para acumular habilidad profunda a lo largo de los años.
- Otros dicen que solo hacer “trabajo comercial genérico” (especialmente en una sola empresa o stack) puede estancar el aprendizaje; los proyectos paralelos y los nuevos dominios aceleran el crecimiento.
- Hay tensión entre “programar todo el tiempo porque te encanta” y “no voy a pasar mis noches programando después de un día completo de trabajo”.
Caminos de entrada a la programación: CS, bootcamps y autoaprendizaje
- Múltiples historias de éxito: bootcamps, cursos intensivos breves, autoestudio en sótanos, personas con títulos no relacionados con CS que cambian a desarrollo.
- Patrón: el éxito suele requerir alta motivación, muchas horas además de la formación “central” y, a menudo, un primer trabajo duro donde ocurre el aprendizaje real.
- La falta de fundamentos de CS puede sentirse más tarde (p. ej., estructuras de datos, algoritmos), pero muchos cubren esas lagunas sobre la marcha.
Naturaleza de la ingeniería de software y decadencia del conocimiento
- Debate sobre si el software se parece más a la ciencia, la ingeniería o a sistemas sociales/legislativos.
- Algunos afirman que los fundamentos (algoritmos, teoría de SO, concurrencia, etc.) son estables; el caos está en los lenguajes, frameworks y herramientas bajo presiones económicas.
- Otros sienten que gran parte del esfuerzo diario se desperdicia luchando con herramientas, bibliotecas y “entropía” deficientes, análogo a malas herramientas físicas o componentes prefabricados.
Scrum, proceso y flujo de trabajo en equipo
- Crítica muy fuerte a Scrum: las reuniones diarias como “anuncios”, el enfoque en la apariencia a corto plazo, la fragmentación del trabajo profundo y el servicio a los informes de gestión más que a los resultados de ingeniería.
- Algunos defienden un núcleo simplificado (p. ej., Kanban, reuniones diarias simples) como útil; a menudo se culpa a la mala cultura y al exceso de ceremonial más que a las ideas centrales.
Herramientas de IA, aprendizaje y práctica deliberada
- Algunos estudiantes dicen que herramientas como ChatGPT evitaron que abandonaran al desbloquearlos en el límite de su capacidad.
- Otros temen que la IA y el autocompletado socaven la comprensión profunda, comparándolo con usar siempre GPS y nunca aprender la ruta.
- Norma emergente: luchar primero y luego usar la IA como un desarrollador senior para obtener pistas; usarla mucho para código repetitivo y pruebas, pero no como muleta para la resolución central de problemas.