Los que me conocen (o me encuentran de casualidad) saben que hago streams de programación.
De los que saltan sin red: me gusta codear en vivo, encontrarme con los problemas y limarme los cuernos buscando la solución mientras nos reímos con esos amiguitos virtuales que participan en el chat.
Y, al menos una vez por cada ciclo lunar, alguien hace la pregunta recurrente (ya sea en mi stream o de mis colegas y amigos): "Estoy empezando en programación, ¿qué consejo me darías?".
Si esa también es tu inquietud, y por eso caíste en este post, dejame compartirte mi opinión.
Disclaimer rápido: hablo desde mi formación personal. Ninguna experiencia es traspolable a otra persona esperando el mismo resultado, así que esto habla de cómo yo aprendí y me capacité. Algunos puntos podrían no aplicarse a tu caso.
1. La programación es práctica
Nada vas a lograr si nada vas a desarrollar. Elegiste una carrera donde la práctica efectivamente hace al maestro, porque conforme vayas escribiendo código te vas a encontrar con nuevos desafíos, nuevos problemas, distintas soluciones.
Y cada solución que encontrás a un problema te va a producir un pequeño escalofrío que te recorre la espalda. Eso es tu cerebro haciendo sinapsis, a tal nivel que hasta te hizo cimbrar la nuca.
Cada cosa que te enseñen, practicala mil veces si es posible.
Hacela funcionar, rompela explorando otros caminos, y arreglala para que funcione de nuevo.
2. Pero también es teoría
Un error común que veía en algunos alumnos cuando recién empezaban era querer saltearse el proceso de razonamiento y saltar directo al código. La teoría existe para que entiendas por qué lo que quisiste hacer no funciona, o hace algo distinto a lo esperado.
Nunca asumas que tu código falla por voluntad de Titivillus: el motivo por el que no hace lo que esperás seguro está documentado en algún lugar del ciberespacio.
Además, esa teoría es el contexto de cómo y para qué existe cada cosa. Delimitan las buenas y las malas prácticas de cada lenguaje o tecnología.
3. Mirá MUCHO código ajeno
Mirá streamers o videotutoriales de gente que desarrolle en vivo (no, ver gente promptear no entra en este punto). Si algún desarrollador que programe en el lenguaje que estás aprendiendo sube cosas a un repositorio, entrá, miralo, analizalo.
Este punto es sobre exponerte: cuanto más código ajeno consumas, más patrones, estilos y formas de resolver un mismo problema vas a tener guardados en algún cajón de tu cabeza para cuando los necesites.
Fui profesor de programación durante 11 años, y a la hora de corregir exámenes había dos extremos bien marcados.
El alumno al que le costaba adquirir los conocimientos, al punto de quizás hacer todo mal.
Para corregirlo y darle el conocimiento faltante, no me alcanzaba con decirle "te falla en tal línea". Mi responsabilidad era entender qué quiso hacer, para poder explicarle dónde se desvió del objetivo o por qué la manera en que lo razonó no funcionaba.
Y el polo opuesto: el alumno con un nivel de abstracción y conocimiento previo superior al mío.
Tampoco podía decirle "muy bien, tenés un 10" —no porque no se lo mereciera, sino- porque todo código es perfectible, y hasta las mentes más brillantes pueden estar cometiendo un error, accidental, incidental o intencional.
Entender esas líneas me empujaba a elevar mi propio conocimiento para estar a la altura de una devolución decente.
(Nota: obviamente también tuve alumnos en el medio, pero fueron los extremos los que más me ayudaron a entender código de todos los niveles.)
Gracias a eso, sin importar en qué proyecto me meta, tengo la capacidad de entender y adaptarme a las formas del equipo de trabajo. Porque eso importa (Y MUCHO) para no desentonar programando "como te sale y ya".
4. Entender ese código es otro nivel
Ahora, una cosa es mirar código ajeno, y otra muy distinta es poder entenderlo.
Este punto es consecuencia del anterior, pero merece su mención a parte.
Hay un mito que dice que "el programador que sirve es el que puede hacer código". Eso no es del todo cierto.
¡Claro que esperan que puedas programar! Pero el programador que realmente sirve es el que ve código y entiende lo que está pasando, incluso antes de ejecutarlo. Es el que se puede poner en el rol de intérprete o compilador del lenguaje.
No digo que puedas predecir el 100% de lo que va a pasar, pero sí tener claro qué podría suceder si se ejecuta una línea de código en particular. Eso, a mediano o largo plazo, te ayuda a encontrar errores más rápido, sin necesidad de ejecutar el código para saber por dónde arrancar el workaround.
Por ejemplo, en una consulta SQL escrita así:
SELECT columna1, columna2, FROM tabla;
Vas a tener un error de este tipo:
[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'FROM tabla' at line 1
El programador que solo hace código va a mirar primero el `FROM`, después se asegurará que el nombre de la tabla esté bien. El programador que interpreta código sabe que un error "near algo" en SQL siempre es por lo que está inmediatamente antes (en este caso, la coma después de la segunda columna).
5. El pizarrón es solo la punta del iceberg
El profesor te va a evaluar en base a lo que explicó durante la cursada, y va a esperar que hagas algo similar a lo que te enseñó.
Pero por más que sientas que te tiró mil exabytes de información de golpe, no te enseñó todo. Queda mucho más por aprender.
Y no es por mala voluntad, ni por ninguna conspiración para no formarte una competencia en un mercado saturado de gente que "cree que sabe". Es que toda asignatura tiene una ventana de tiempo para darte el máximo conocimiento posible.
Pensalo así: si es una materia semestral, sin correlatividad, que pasa una vez por semana, el profesor tiene menos de 20 clases.
En ese tiempo tiene que elegir qué enseñarte, sin agobiarte ni hacerte creer que no vas a poder con esta profesión.
Y sí, vas a poder. Pero va a ser tu responsabilidad aprender más de lo que quedó plasmado en el pizarrón, un apunte o una diapositiva.
6. Usá las herramientas disponibles
Ni usar Google, ni consultar Stack Overflow, ni pedirle a una IA que te ayude a desarrollar o debuggear es mala palabra. Al final del día a tu cliente le va a interesar que el proyecto funcione y se lo entregues en tiempo y forma.
Lo único que importa es esto: después de usar las herramientas que necesitás para cumplir con el deadline, ¿aprendiste algo más? ¿Volviste a sentir el escalofrío sináptico atravesándote la espalda?
Espero que algo de todo esto te sirva en tu camino a explotar todo el potencial que yace debajo de esas dudas e inseguridades.