Cosas que me hubiese gustado saber cuando empecé a programar, Parte 1

Aprender a programar es un viaje largo, y puede tomar años de esfuerzo constante volverse bueno en ello.

Cuando empecé a escribir mis primeras líneas de código, me sentí súper emocionado de poder hacer que una máquina hiciera cosas. Claro, eran cosas muy simples, pero sentí que podía lograr cualquier cosa con esta nueva habilidad. Después de un tiempo, comencé a notar que mientras más sabía, más confundido me sentía. Muchas preguntas empezaron a surgir cada vez que me sentaba a escribir código, y no solo preguntas técnicas sino también cosas como:

¿En qué lenguaje de programación debería enfocarme?

¿Qué áreas debería aprender, desarrollo web, sistemas embebidos, desarrollo móvil?

¿Cómo puedo estar seguro de que el código que estoy escribiendo es bueno? ¿Estoy escribiendo código basura?

Y muchas otras.

Quería compartir algunas de las cosas que he aprendido en los últimos años en una serie de artículos. Sí, estos artículos no responderán preguntas como qué camino profesional es correcto para ti, o qué lenguaje de programación deberías aprender, solo tú puedes responderlas. Son una colección de las muchas ideas que me hubiese gustado saber cuando comencé mi viaje como programador.

Espero que estas lecciones sean tan útiles para ti como lo han sido para mí.

Los principios son más importantes que las tecnologías

Sí, necesitas aprender un lenguaje de programación para conseguir un trabajo en desarrollo de software, es una herramienta importante. Y sí, usualmente también necesitas ser competente con un framework o librería específica para conseguir un trabajo específico, así son las cosas.

El punto es que, aunque este es conocimiento práctico importante, no es lo más importante en lo que enfocarse. En lugar de perseguir el último framework o coleccionar lenguajes de programación, deberías enfocarte en los principios principales de la ingeniería de software y ciencias de la computación. Cosas como:

  • Estructuras de datos y algoritmos.
  • Diseño orientado a objetos y patrones de diseño (o equivalentes en tu paradigma favorito).
  • Habilidad para manejar complejidad y abstracción.
  • Caché y jerarquías de memoria.
  • Redes de computadoras.
  • Calidad de software, y cómo escribir código claro y legible.
  • Habilidades de ingeniería de requerimientos y documentación de software.
  • Escritura de pruebas.

Priorizar este tipo de conocimiento tiene muchas ventajas. Primero, las computadoras no han cambiado tanto en las últimas décadas, y mientras tu framework favorito puede pasar de moda el próximo mes, el patrón observer continuará siendo útil por años. Segundo, estas habilidades serán útiles independientemente de tu área de enfoque. Entender cómo funcionan las computadoras y cómo crear gran software es importante, no importa si escribes código para una lavadora o un mainframe.

Así que, ve y toma un libro de patrones de diseño o lee sobre calidad de código, hará maravillas para tu carrera.

Cultiva habilidades sociales

Ser capaz de comunicarse de manera clara es la habilidad más importante que puede tener un desarrollador de software. El hecho de que trabajemos con computadoras y máquinas todo el tiempo da la impresión de que rara vez, si acaso, tratamos con otros seres humanos. Además de eso, está la forma en que los programadores son retratados en los medios: tipos antisociales que preferirían hacerse un tratamiento de conducto que tener que hablar con un colega.

En realidad, no somos diferentes de cualquier otro profesional. Aún vamos a muchas reuniones, charlamos con nuestros colegas y disfrutamos pasar tiempo con otras personas. De manera similar, la habilidad de comunicarse juega un papel muy importante en nuestras actividades diarias. Tarde o temprano necesitarás comunicarte con colegas, clientes y gerencia. Para sacar el máximo provecho de estas conversaciones, necesitas aprender cómo escuchar y cómo estructurar apropiadamente tus pensamientos usando palabras.

Los humanos son el núcleo del desarrollo de software. Después de un par de años, te das cuenta de que la principal fuente de complejidad en esta profesión es el factor humano, lo que me recuerda el siguiente punto.

No te pagan por escribir código, te pagan por resolver los problemas de otras personas

Esto es algo que he estado repitiendo por un tiempo: tu trabajo no es escribir código, tu trabajo es proporcionar valor.

A veces proporcionas valor en forma de escribir un nuevo producto de software que resuelve el problema de una persona. Otras veces, recibes una solicitud para una nueva característica (feature) y la agregas a una solución de software ya existente. Porque esto es lo que a menudo hacemos, es fácil perder de perspectiva el objetivo principal: resolver el problema de otra persona.

No importa lo que hagas en la cadena de valor, tu trabajo existe porque resuelve el problema de otra persona. Si trabajas en desarrollo de aplicaciones, creas productos para usuarios. Si pruebas software, proporcionas un servicio al desarrollo y a tus usuarios finales asegurando calidad. Si tu trabajo es en operaciones, aseguras que los usuarios puedan acceder a su software. Piénsalo, no hay trabajo de TI cuyo objetivo final no sea servir a las personas.

Es importante no perder esto de perspectiva por dos razones principales:

1. ¿Realmente necesitas escribir esa línea?

A veces no necesitas escribir ni una sola línea de código para proporcionar valor. ¿Puedes lograr el mismo impacto solo cambiando la configuración? ¿Hay una forma de ayudar a tus usuarios sin una nueva clase? Si esas son soluciones viables, ve por ellas.

2. Escucha a tus usuarios

La industria está llena de productos de software bien escritos que resuelven el problema equivocado o lo resuelven de la manera equivocada. ¿Cómo puede ponerse tanto pensamiento en escribir un producto divorciado de las necesidades reales de los usuarios? Bueno, para empezar, pregúntate cuándo fue la última vez que hablaste con las personas que usan tu software.

Sé que es difícil recopilar comentarios, pero trata de al menos hablar a menudo con tu product owner (o la persona equivalente en tu equipo). En nuestra profesión, pocas cosas son tan tristes como buen software que nadie usa. Comunícate con tus usuarios para prevenir que esto suceda.

Ah, ya sabía todas estas cosas

Está bien, todos aprendemos a diferente ritmo.

Sé que cualquier desarrollador experimentado leerá este artículo y pensará, “Todas estas cosas son obvias”. Es cierto, lo son, pero solo después de que pensaste en ellas, o después de que sentiste el dolor de ignorar estas ideas. En esta serie (Consejos para nuevos desarrolladores, o Cosas que me hubiese gustado saber cuando empecé a programar) me gustaría continuar compartiendo este tipo de ideas, creo que pueden ser útiles para muchas personas.

Espero que leer este artículo haya sido útil, y que hayas aprendido una o dos cosas nuevas.

Qué hacer a continuación:

  • Comparte este artículo con amigos y colegas. Gracias por ayudarme a llegar a personas que podrían encontrar útil esta información.
  • Lee el siguiente artículo de la serie.
  • Envíame un email con preguntas, comentarios o sugerencias (está en la página Autor)

Juan Luis Orozco Villalobos

¡Hola! Soy Juan, ingeniero de software y consultor en Budapest. Me especializo en computación en la nube e IA, y me encanta ayudar a otros a aprender sobre tecnología e ingeniería