- La educación formal es útil para transmitir habilidades de manera eficiente, pero tiene límites a la hora de desarrollar la intuición para resolver problemas inesperados
- La prueba y error repetitiva con propósito (algoritmo) es el factor que más eleva la pericia, a través de fallas reales y su corrección en la práctica
- En ejemplos reales, figuras como Linus Torvalds y Margaret Hamilton desarrollaron capacidades sobresalientes al enfrentar y superar fracasos
- La mentoría es un acelerador importante, pero la experimentación autodirigida y la experiencia directa son la clave del crecimiento definitivo
- La experimentación orientada a objetivos de enfrentar problemas de primera mano y aprender al romper cosas es la base de la mejora real de habilidades
La fuerza que crea a los mejores ingenieros de software: prueba y error con propósito
El mito del aula
- La educación formal favorece la transmisión de conocimiento valioso, pero es un proceso optimizado para escalar
- Condensa la experiencia laboral compleja en procedimientos depurados y la entrega en una forma que puede completarse en un semestre
- En ese proceso, se pueden adquirir las habilidades básicas necesarias para el trabajo, pero existen límites para construir la capacidad de resolver problemas de forma intuitiva ante crisis inesperadas
- En particular, cuando a las 3 de la mañana surge un problema real en producción, las recetas aprendidas en el aula no bastan para resolverlo
El verdadero crecimiento al aprender chocando con la realidad
Casos ejemplares
- Linus Torvalds creó Linux al reescribir MINIX
- Margaret Hamilton forjó los conceptos modernos de confiabilidad al corregir directamente problemas de código en tiempo real durante el proyecto Apollo
- Innumerables maintainers de código abierto también crecieron rompiendo su propia laptop y volviéndola a arreglar por sí mismos
- Ellos no empezaron escuchando clases secuenciales; alcanzaron una pericia profunda gracias al fracaso y a sus consecuencias reales
Por qué la prueba y error supera a las recetas
- El bucle de retroalimentación es inmediato. Analizar un crash en los logs permite aprender mucho más rápido que un quiz
- Los casos límite aparecen de forma natural en entornos reales, donde surgen usos que ningún material didáctico imagina
- Los problemas resueltos con dificultad se quedan grabados. Se convierten en memoria muscular
- Cuando no existe una guía previa, la creatividad se dispara
Replantear la mentoría: complemento, no sustituto
- Un buen mentor acelera la retroalimentación y amplía la perspectiva, pero al final la persona que experimenta y aprende es uno mismo
- El code review tiene valor porque comparte los resultados de la experimentación, pero no sustituye la experiencia directa
Cómo cultivar hábitos de experimentación autodirigida
- Intentar proyectos paralelos que te hagan sentir un poco incómodo
- Medirlo todo para asegurar datos analizables cuando algo falle
- Imponer restricciones como limitar frameworks o terminar en 48 horas para desarrollar soluciones creativas
- Publicar el código para recibir validación externa
- Hacer una retrospectiva semanal para registrar las causas de los errores y lo aprendido
Cierre
- La mentoría, los cursos y los blogs actúan como aceleradores, pero la verdadera habilidad se construye en el choque intenso con la realidad del trabajo
- Los mejores ingenieros progresan y resuelven problemas reales repitiendo una prueba y error libre pero con propósito
- La experiencia obtenida en ese proceso se convierte en el mayor activo para tu yo futuro
1 comentarios
Comentarios de Hacker News
Yo mismo soy un desarrollador autodidacta y pasé la mayor parte de mi carrera en grandes empresas junto a colegas con formación en CS.
Según mi experiencia, si un desarrollador autodidacta tiene suficiente inteligencia, al final resuelve el problema que le pongan enfrente.
Los que estudiaron CS muchas veces ni siquiera intentan meterse en un terreno completamente desconocido para ellos (aunque, claro, hay variaciones según la personalidad; yo diría que aplica como al 85%).
Frente a una incertidumbre alta, se quedan bloqueados.
Al final, los de CS encajan mejor en entornos corporativos grandes, trabajando según patrones como engranes reemplazables.
Los autodidactas siempre están innovando, buscando reducir la repetición ineficiente, y esa actitud original pone nerviosa a la gente alrededor.
Pero esas personas autodidactas terminan produciendo resultados mucho mejores.
Me parece que la mayoría de los desarrolladores valoran más conservar el empleo y reducir la ansiedad que escribir código realmente sobresaliente.
Muchos ingenieros con educación formal también buscan resolver problemas nuevos de manera activa.
Esto no es tanto un tema de autodidacta vs. educación formal, sino de rasgos como curiosidad, disciplina, creatividad e inteligencia.
Un autodidacta necesariamente tiene que tener esas características para poder salir adelante, así que quizá por eso se notan más en ese grupo.
Cuando un ingeniero con educación formal también tiene esas cualidades, muchas veces termina destacando más que cualquiera de los dos grupos.
Probablemente la diferencia más grande sea de personalidad.
Yo, como desarrollador autodidacta, aposté por la constancia.
No era tan bueno viendo el “panorama general” desde lo técnico, pero en cambio trataba de ser quien más resultados entregara en el equipo.
Llegué a hacer tres prototipos en unos cuantos días y probarlos en condiciones reales.
Mis colegas de CS hacían el diseño una sola vez en el pizarrón y luego escribían el código una sola vez.
Nunca se aplicaron ambos métodos exactamente al mismo trabajo, así que es difícil decir cuál da mejores resultados.
En mi cabeza, mi método se siente como uno “probado en el mundo real”.
Sí es cierto que el enfoque de CS se percibía como el ideal.
Pero también creo que aprendí muchísimo gracias a la mentoría de ingenieros con formación en CS.
Después de unos 10 años de experiencia en la industria, sin importar cómo hayas empezado, uno termina pareciéndose bastante y desarrollando una intuición similar sobre la “respuesta correcta”.
Quizá yo también lo estoy embelleciendo o generalizando un poco; estaría bien que otros lo matizaran en las respuestas.
Lo admito.
La mayoría de los currículos de CS están bastante alejados del trabajo real, así que un título no es un indicador inmediato de capacidad.
Pero no puedo aceptar para nada que el 85% de los graduados de CS no pueda resolver problemas desconocidos.
Si hay una virtud del título de CS, es que la ruta de ingeniería incluye materias durísimas que exigen una gran capacidad intelectual.
Cuesta creer que alguien capaz de aprobar tantas materias simplemente no pueda con el desarrollo en el mundo real.
De hecho, cuando te metes en áreas de desarrollo realmente difíciles, más bien parece que una gran parte tiene títulos avanzados en CS.
Creo que esas características aparecen cuando existe un interés profundo por el software, y ahí también hay muchos de CS.
En mi experiencia, los autodidactas pasan por una selección natural.
Es decir, a los autodidactas que no pueden resolver problemas desconocidos ni siquiera los contratan.
Los de formación formal suelen ser promedio o mejores que eso, pero no necesariamente arrolladores.
Quien logra descifrarlo todo por sí mismo y además lo valida con educación universitaria demuestra una fuerza brutal en el trabajo real.
Creo que el punto clave no es el método de aprendizaje, sino la “pasión”.
Si la motivación es débil, da igual cuál sea el método: el límite aparece rápido.
Este tema también tiene lados difíciles de discutir numéricamente.
La educación formal puede darte una base sólida en conceptos fundamentales (matemáticas, hardware, OS, compiladores, etc.).
El autodidactismo es más orientado a objetivos, así que puede pasar por alto fundamentos.
Cuando ni siquiera sabes qué es lo que no sabes, tener un buen mentor (un profesor, un gran libro) te ahorra muchísimo tiempo.
Muchos ingenieros, incluyéndome, pasamos tanto por aprendizaje formal como informal.
Cuando hay pasión, uno sigue construyendo cosas por cuenta propia y también hace toda clase de experimentos fuera del aprendizaje formal.
Lo que realmente distingue a un gran ingeniero no es la vía educativa, sino una pasión evidente.
Casos como Linus o Margaret al final también eran personas con un impulso enorme por aprender.
Yo también, como programador autodidacta, estoy totalmente de acuerdo.
Aprendí por mi cuenta desde la época de las computadoras de 8 bits en los 80 y nunca fui a la universidad.
Cuando tuve mi primer trabajo formal de programación a los 19 años, ya llevaba 9 años programando.
Cuando la mayoría se graduaba de la universidad, yo ya llevaba casi 15 años escribiendo código.
Esa pasión y ese empuje son difíciles de ignorar.
Incluso ahora, casi 40 años después, sigo disfrutando el software con prácticamente el mismo entusiasmo.
Me divierte crear cosas, sigo leyendo papers, sigo el rumbo de la industria y todavía escribo muchísimo código.
Eso sí, me incomoda un poco la idea de que los autodidactas carecen de fundamentos.
En realidad, muchos autodidactas también profundizan bastante en la parte académica; depende mucho del área.
Puede faltar tiempo para estudiar a fondo, pero tras décadas de experiencia, a veces terminan con bases más sólidas que quienes solo pasaron por la escuela.
También he contratado y despedido bastante gente, y muchas veces los autodidactas daban mejores resultados.
Al final simplemente han “hecho” mucho más: la pasión termina empujando la cantidad de aprendizaje.
Me identifiqué mucho con la parte de “cuando no sabes lo que no sabes, ayuda mucho que alguien te guíe de forma eficiente”.
Yo soy un caso intermedio entre lo formal y lo informal.
Nunca cursé matemáticas discretas avanzadas ni álgebra lineal, así que me faltan muchos conocimientos de base.
Ni siquiera sé qué palabras clave tendría que buscar.
Hay áreas donde de verdad necesitas la guía de alguien.
Incluso ya rozando los 40, me costó muchísimo encontrar un tutor que pudiera validar mis programas de matemáticas vectoriales.
La pasión empuja el aprendizaje autodidacta, pero en un salón de clases puede hacer menos falta porque siempre hay alguien manteniéndote en el camino.
Y además, no todo autodidactismo es “orientado a objetivos”; también hay autodidactas cuyo objetivo es entender cómo funciona el sistema en sí.
Aunque alguien te lleve a la fuerza hasta el agua, eso no significa que nunca hayas ido por tu cuenta.
La diferencia consistente es que todos los autodidactas, al menos una vez, llegaron solos hasta el agua.
Yo soy una mezcla de formación formal y autodidacta.
Tomé muchas materias universitarias, pero no me fue lo bastante bien en los exámenes como para sacar el título.
Pude aprender por mi cuenta todo lo demás porque esas clases me habían dejado la base.
A mí me parece que las clases universitarias son realmente excelentes.
Si no hubiera sabido nada, jamás me habría puesto por mi cuenta a explorar el API de sockets de C, proyectos en bash, sistemas distribuidos, estructuras de datos o algoritmos.
De hecho, he entrevistado a muchos autodidactas o egresados de bootcamp, y suelen profundizar solo en las áreas que ya conocen o se vienen abajo ante preguntas más académicas.
En cambio, quien pasó por la universidad pero nunca codificó en serio sí suele tener un nivel bastante flojo, y hasta quienes siguen estudiando muchas veces olvidan por completo lo que aprendieron antes.
Creo que la mejor combinación es haber programado algo antes de entrar a la universidad.
Hace falta haberse golpeado un poco por cuenta propia para realmente apropiarte de las soluciones teóricas y elegantes que te presentan en la universidad.
Mientras más hayas sufrido errores de manejo de memoria como los que evita RAII, más profundamente puedes conectar con ese concepto.
A los egresados de bootcamp y a los autodidactas hay que verlos por separado.
Puede haber gente capaz en bootcamps, pero las personas que yo conozco muchas veces eligieron esa ruta porque no podían aprender solas y estaban pensando en irse a la universidad o a otro campo, y el bootcamp era una alternativa más barata.
Antes ni siquiera había bootcamps, y yo también me mantenía lejos de los cursos en línea y de los métodos tradicionales.
Yo quería construir algo increíble, y me parecía mucho más emocionante resolver problemas de forma independiente que volver a intentar lo mismo siguiendo un libro de texto.
Si aprendí C por mi cuenta de niño fue porque había cosas que no podía hacer con el material o el código ya existente, y quería tanto obtener un gran resultado que no me quedaba más que revisar foros, leer documentación y sacar las cosas a base de prueba y error.
Creo que importa más el deseo intenso de aprender que el método de estudio.
Antes de entrar a la universidad ya dominaba C, el API de sockets y hasta tenía experiencia entregando software.
Un amigo incluso ganaba dinero en la preparatoria vendiendo juegos para C64.
Los dos estábamos muy por delante de un recién egresado en capacidad real de programación.
Lo que me faltaba era la parte teórica: cálculo, álgebra lineal, matemáticas discretas, y de vez en cuando también algo de estructuras de datos o algoritmos.
El programa de CS sí me ayudó a llenar esos huecos, pero no elevó mi capacidad de programar en sí.
Las materias de programación no me costaron nada; lo difícil para mí eran más bien las matemáticas y la teoría.
El programa de CS me convirtió en un ingeniero más equilibrado, pero no en un mejor desarrollador.
En mis tiempos de universidad, el ambiente del departamento de CS era exactamente lo contrario de lo que hoy se vende como ventaja de la universidad.
Yo mismo no elegí estudiar CS en la universidad por esas razones (hoy soy desarrollador senior en una empresa tecnológica de EE. UU.), y en aquel entonces CS era terrible en todo: tasas de reprobación, desempleo y ambiente profesoral, incluso en una universidad de élite donde entraban solo los mejores promedios.
Claro, hay personas que obtuvieron mucho de la universidad, pero la realidad no siempre es así.
Muchos graduados de CS con los que trabajé en la práctica tenían serias dificultades para comunicarse, entender el negocio o priorizar el trabajo.
A menudo solo sabían escribir código (y ni eso muy bien), y es más raro de lo que parece que una carrera universitaria de CS te deje realmente listo para el trabajo real.
De hecho, me parece que la forma en que se enseña en la universidad es el ejemplo perfecto de quedarse dentro de la “zona de confort”.
También hay que reconocer que el acceso y el costo de la universidad son, en sí mismos, un problema de clase social y económica.
Y además, sí hay gente autodidacta que aprendió perfectamente cosas como el API de sockets o proyectos en bash.
Por cierto, un autodidacta y alguien salido de un bootcamp son perfiles completamente distintos.
Puede que yo me derrumbe en una situación impuesta, como una entrevista estilo audición, pero cuando estoy solo sí resuelvo problemas reales muy bien.
Puede sonar un poco a “viejo gruñón”, pero yo también vengo de una época en que la universidad de verdad era muy buena.
Hicimos compiladores, un OS de juguete, interfaces GPS y más.
Hace unos años me invitaron a dar clases en otra universidad y salí muy decepcionado.
El plan de estudios parecía un bootcamp estirado por varios años con materias encima que ni al caso venían.
Casi no había fundamentos y, salvo algoritmos, todo era React y frameworks populares en startups locales.
(Edición: revisando el plan, literalmente había clases de negocios, administración, humanidades, química, medio ambiente, emprendimiento y e-sports).
Parece que se invierte mucho esfuerzo en aceptar la falta de formación propia.
Hay autodidactas excelentes y titulados nada brillantes, pero por mi propia experiencia creo que tener un título en CS me habría ayudado más en mi camino.
CS no se trata solo de programar, del mismo modo que ME (ingeniería mecánica) tampoco se reduce a una sola labor.
Los ingenieros mecánicos también ven cómo un mecánico resuelve mucho mejor cosas pequeñas como una fuga de aceite o una llanta ponchada.
Pero nadie desprecia por eso un título de ingeniería.
Yo también empecé resolviendo en planta, con las manos llenas de grasa, problemas que los técnicos no podían arreglar, pero eso tenía más que ver con mi gusto personal y mi curiosidad.
Los autodidactas suelen tener un rendimiento sobresaliente porque justamente son personas con la motivación, la pasión y la iniciativa necesarias para llegar a ser autodidactas.
Al final, si tienes curiosidad, enfoque y disciplina, vas a estar por encima del promedio con educación formal o informal.
También hay sesgo de supervivencia: solo vemos a quienes aprendieron por su cuenta y además lograron sobrevivir en la profesión.
En cambio, quienes fracasaron como autodidactas quizá habrían estado mejor con una enseñanza adecuada.
A mí me gustaron tanto CS como las matemáticas, pero en cuanto a formato, sentí que el aprendizaje autónomo me iba mejor.
La palabra “a menudo” solo sirve para disfrazar la vaguedad.
Soy desarrollador de software y también profesor universitario de CS.
El rasgo común de los ingenieros que de verdad triunfan siempre es el “interés” y la “pasión”.
Los autodidactas, por definición, tienen mucho interés en el área, así que son un grupo cuya motivación ya viene validada.
Los titulados son más mixtos: hay quienes solo van por el papel, y entonces saben la terminología teórica pero cuesta distinguir si realmente tienen capacidad.
Un autodidacta es, por naturaleza, alguien con la motivación y el interés suficientes como para salirse del sistema existente y estudiar por su cuenta.
Piensa en el conocimiento como un círculo dibujado en un pizarrón.
https://matt.might.net/articles/phd-school-in-pictures/
El círculo que aprendes en la universidad es sorprendentemente estrecho y suele venir del mismo currículo para todos.
Por ejemplo, no hay tiempo de enseñar el algoritmo dmc (usado en el mejor algoritmo de compresión).
En cambio, todos repiten el mismo currículo generalista.
Pero hay personas que avanzan más allá de ese círculo.
Esas personas son las mejores programadoras de la industria: conocen incluso algoritmos rarísimos que normalmente solo ves en papers, y por eso muestran una capacidad fuera de lo común.
Lo mismo con los autodidactas: pueden tener huecos respecto a ese círculo común que todos aprenden, así que muchas veces parten desde su propia motivación y humildad.
Sin embargo, el círculo de conocimiento que sí tienen se construyó de forma orgánica gracias a la pasión.
Esa pasión me parece la mejor señal de rendimiento en ingeniería.
Dicho de otra forma: “alguien que ya demostró saber decidir por sí mismo qué necesita aprender de forma independiente, y luego aprenderlo de verdad, sobresale en trabajos donde se exige justamente esa capacidad”.
Torvalds casi no había recibido todavía formación formal en CS cuando publicó la primera versión de Linux en 1991.
También coincido con eso.
En la licenciatura tuvimos un proyecto donde había que escribir directamente un OS multiproceso en ensamblador 68K.
Gracias a esa experiencia me resultó mucho más fácil acercarme a la estructura y al funcionamiento del kernel de Linux.
Si ni siquiera hubiera sabido qué era un kernel, ni habría podido empezar.
Últimamente he estado intentando aprender por mi cuenta un problema de análisis numérico que no conocía: construir un solver LU disperso.
El material que más me sirvió no fue implementarlo directamente ni desarmar el código de un solver existente, sino unas notas de clase sobre el tema.
Al ver el curso completo, también entendí conceptos relacionados que no sabía que me faltaban.
En otras áreas me pasó lo mismo: muchas veces el material de universidad era de la mejor calidad.
Si la idea fuera que la universidad no hace falta, sería difícil explicar por qué justo el mejor material suele venir de la universidad.
También se dice que lo mejor para desarrollar habilidad es construir cosas directamente, pero en la universidad los proyectos siempre evalúan de forma activa esa parte de “hacer” de verdad.
Totalmente de acuerdo.
Los libros técnicos profundos también son excelentes, pero el valor que sacas de ellos cambia por completo según cómo te acerques.
Si solo aprendes teoría sin ninguna aplicación real, te aburres y se te olvida rapidísimo.
Pero cuando aprendes teoría vinculada a una necesidad real o a un trabajo relacionado, se convierte enseguida en conocimiento práctico indispensable.
Si alguien llega a la universidad con bastante experiencia autodidacta y logra mantener la pasión, puede hacer cosas impresionantes en muy poco tiempo.
En conclusión, la teoría claro que importa.
Solo que, si primero construyes algo y luego estudias la teoría, entiendes mucho mejor cuál es el verdadero insight.