Archivo de la etiqueta: aprender a programar

Un lenguaje de programación no es una tecnología

Me encontré este Tweet:

Y creo que es una excelente oportunidad para recalcar un punto que a muchas personas se les escapa: un lenguaje de programación no es lo mismo que una tecnología.

Los lenguajes son herramientas que te permiten razonar sobre problemas puntuales de maneras muy particulares.

Por ejemplo, intentemos razonar sobre el concepto del “paso del tiempo”. Para los que hablamos Inglés y Español, vemos el pasado como algo que está a la izquierda, y el futuro como algo que está a la derecha del presente. Los que hablan Árabe, al revés, ponen el pasado a la derecha y el futuro a la izquierda. Y los que hablan Mandarín, ponen el futuro arriba y el pasado abajo.[1]L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22

Un lenguaje no solamente te permite resolver problemas particulares, sino que, además, cambia la manera en que entiendes el problema en primer lugar. Puedes hablar Mandarín perfecto, pero si te sigues refiriendo al pasado como algo que sucede a la izquierda del presente, no te van a entender cuando trates de explicarle el paso del tiempo a alguien en China.

Hay una distinción, sutil, pero importante, sobre lo que queremos expresar, y el contexto en el que lo expresamos.

Cuando el autor del Tweet original dice que “el lenguaje de SQL se ha mantenido vigente por más de 40 años” no se refiere a que no ha habido avances en la tecnología que le da el contexto necesario al lenguaje. SQL es un modelo mental tan poderoso para resolver problemas de organización, administración y escritura de datos, que trascendió su tecnología y se convirtió en un estándar de la industria. Hoy, si sabes SQL, puedes programar bases de datos utilizando diferentes tecnologías, como Oracle, MySQL, Access, PostgreSQL, Sybase, Microsoft SQL Server, y más.

Ahí es justamente donde yo dibujaría la línea. Si sabes SQL, un lenguaje que sigue siendo relevante después de 40 años, no significa que no tienes que preocuparte por el contexto en el que vas a usarlo. Ese contexto hoy en día es mucho más amplio y tiene muchos más matices que cuando la tecnología original fue inventada. Y la primera pregunta que cualquier persona experimentada te haría si le pides consejo porque quieres usar SQL para administrar una base de datos es, ¿tienes la certeza de que una base de datos relacional es la solución adecuada?

SQL permanecerá vigente indefinidamente mientras haya necesidad de resolver problemas de bases de datos relacionales. Pero la tecnología fundamental, el contexto en el que el lenguaje realmente brilla, puede cambiar, mejorar, empeorar, y sí, hasta desaparecer.

Saber cómo expresarte en un lenguaje de programación no es una bala de plata. Incluso me atrevería a decir que tener dominio de únicamente un lenguaje puede llegar a ser contraproducente. Porque para ser eficiente y efectivo programando, no solamente tienes que saber expresar la solución a un problema — también debes poder determinar si la solución que quieres expresar es la adecuada para el contexto de tu problema.

Es decir, tienes que saber si estás intentando usar Mandarín para explicarle a un Chino que ayer está a la izquierda.

References

References
↑1 L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22

El nombre que le pones a las cosas sí importa

“En las ciencias de la computación, hay únicamente dos problemas difíciles de responder: la invalidación de un caché, y cómo nombrar cosas.” — Phil Karlton

La cultura del Internet después modificó este refrán para incluir errores de enumeración de índices, pero esa es otra historia.

La realidad es que Phil tenía mucha razón: decidir cómo nombrar las entidades que manipulamos al programar es una de las tareas más difíciles de nuestra profesión. No por nada es tan común ver variables, métodos, clases, funciones, o cualquier otro elemento de programas, con nombres genéricos, como x, builder o manager.

Algunos argumentan que invertir tiempo en nombrar los componentes de un programa de manera coherente es una pérdida de tiempo. Las veces que he participado en discusiones donde se intenta impulsar la idea de que alguien debería poder diferenciar una variable X de otra simplemente por el nivel de sangría del código son demasiadas. Creo que desafortunadamente esto es otra muestra de lo inusual que es el sentido de compasión en la industria de la tecnología.

Al igual que agregar documentación completa a tus proyectos, usar nombres descriptivos y semánticamente correctos es un acto de compasión.

El lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día. Al compilador no le importa el nombre de tu variable, pero a la persona que va a leer y contribuir a tu código sí. Y como siempre, es importante recalcar que esa persona puedes ser tú mismo, años después.

Utilizar nombres descriptivos y semánticamente correctos para los componentes de tu programa no solamente hace más accesible la lectura de tu código. También te ayuda a razonar mejor sobre la solución que estás implementando. En algunos casos, hasta te podría salvar, potencialmente, de introducir vulnerabilidades de seguridad críticas.

Conforme he ganado experiencia colaborando en esta industria, he encontrado una relación, casi directa, entre el nivel de atención a la nomenclatura y semántica de los componentes de un programa y su fiabilidad.

Después de todo, me pregunto: si no te tomaste el tiempo de nombrar algo de una manera correcta y con sentido, ¿realmente habrás entendido el problema que estás intentando resolver?

¿La carrera de un desarrollador de software se termina a los 35?

Cuando hablo de Soft Skills con “programadores de hueso colorado”, la reacción más prevalente es la de “¿por qué dejaría de programar, si es lo que más me gusta en la vida?” Pero la medida en que te guste algo no es siempre indicativo de los ánimos que tienes de hacerlo.

Este artículo explora lo que sucede con algunos desarrolladores de software cuando cumplen 35 años. Esta es una edad interesante porque, digamos, si iniciaste a programar en tus veintes, a los 35 es probable que ya tengas una década, o más, de experiencia. 10 años haciendo lo mismo es suficiente tiempo como para comenzar a cuestionarte si te ves haciéndolo por otros 10. Para algunos, la respuesta es sí. Para otros, como yo, la respuesta es un resonante no.

Algunas de las conclusiones a las que llega el autor:

  • Dejas de llamarte “programador” y comienzas a especializarte en resolver cierto tipo de problemas para el mejor postor
  • Pones tu negocio o startup
  • Te sales de la industria completamente

Mi objetivo con Soft Skills para Devs y con mi newsletter, es ampliar el panorama de los desarrolladores de software de LATAM. Lo que quiero es ayudarte a que desarrolles habilidades que te permitan tener opciones para hacer un cambio en tu carrera cuando ya no quieras programar. ¿Estás lista?