Algunos aprendizajes importantes de mis 12 años de vida como ingeniero

Cuando comencé mi trayectoria como ingeniero de software hace dos décadas, no podía imaginar la increíble evolución que tendría nuestro campo. La industria de TI ha progresado continuamente en diferentes direcciones, desde el auge de las metodologías ágiles hasta el auge de la computación en la nube, desde las aplicaciones monolíticas hasta las arquitecturas de microservicios, y viceversa.

Sin embargo, con este cambio constante, descubrí que ciertos principios fundamentales se mantuvieron. Estas lecciones resistieron la prueba del tiempo y se volvieron aún más relevantes en nuestro mundo cada vez más complejo de ingeniería de software.

En esta publicación, compartiré diez lecciones fundamentales que aprendí a lo largo de mis 12 años de carrera. Estos principios me ayudaron a abordar muchos proyectos, liderar equipos y crecer profesionalmente de manera continua.

Las lecciones son:

1. No realice una optimización prematura
2. Piénsalo dos veces antes de escribir código
3. Aprenda buenas prácticas
4. Haz las cosas sencillas e incluso más sencillas que eso.
5. Nombra las cosas apropiadamente
6. Pruebe siempre su código
7. Administra tu tiempo sabiamente. Es lo más valioso que tienes.
8. Comunicar, comunicar, comunicar
9. No solo aprendas, hazlo
10. Tener una cultura de documentación

Entonces, vamos a sumergirnos en ello.

Catio: tu copiloto para la arquitectura tecnológica (patrocinado)

Navegue por las complejidades de la ingeniería de software moderna con Catio , su copiloto de confianza para la arquitectura tecnológica. Con recomendaciones impulsadas por IA las 24 horas, los 7 días de la semana, capacidad de observación en tiempo real y análisis personalizados basados ​​en datos, Catio permite a los directores de tecnología, arquitectos y equipos de ingeniería tomar decisiones más inteligentes en cada etapa del ciclo de vida de la arquitectura. Ya sea que esté optimizando una pila tecnológica existente, escalando su sistema de manera eficiente o elevando su arquitectura tecnológica para establecerse como líder en su categoría, Catio lo ayuda a diseñar con confianza.

¿Estás listo para sobresalir con tu stack tecnológico?

Obtenga más información en Catio.tech

1. No realices una optimización prematura

Recuerde la famosa frase de Donald Knuth : » La optimización prematura es la raíz de todos los males (o al menos de la mayor parte) en la programación «. En los primeros días de mi carrera, caí en la trampa de la optimización prematura más veces de las que me gustaría admitir. Una vez pasé semanas creando un sistema de gestión de documentos para millones de usuarios, solo para descubrir más tarde que apenas teníamos mil visitantes al mes. Además, algunas veces, implementé patrones de acceso a datos muy sofisticados que nos permitirán dar soporte a muchas bases de datos, junto con las principales utilizadas. Por supuesto, nunca usamos ninguna de las otras bases de datos.

Esto me enseñó una lección importante: como no vas a reemplazar ese componente por otro en el futuro, probablemente no necesites una abstracción ahora. En cambio, concéntrate en escribir código simple que resuelva de manera eficiente el problema actual.

La optimización prematura puede dar lugar a soluciones sobredimensionadas que son más difíciles de mantener y comprender. Estas soluciones suelen desperdiciar tiempo y energía, pero probablemente nunca sean necesarias.

Generalmente, siempre debemos seguir los principios YAGNI, KISS y DRY en este orden.

• YAGNI es lo más importante, ya que dice que debemos implementar las cosas cuando las necesitamos, no cuando pensamos que podríamos necesitarlas.
• Keep it Simple, Stupid (KISS) : mantener el código lo más simple y claro posible. El código simple es más fácil de entender y mantener y menos propenso a errores.
• No se repita (DRY) : evite la duplicación en el código, que puede generar inconsistencias y errores. Sin embargo, en algunos casos, deberíamos tener duplicaciones, por ejemplo, si usamos lógica compartida en diferentes lugares.

2. Piénsalo dos veces antes de escribir código

Como ingenieros, siempre solemos resolver todos los problemas con código. Sin embargo, durante muchos años en la industria, aprendí que, a veces, la mejor solución no implica código nuevo. Esta comprensión me quedó clara durante un proyecto en el que pudimos eliminar todo un microservicio planificado simplemente reconfigurando un sistema existente.

Antes de añadir una nueva característica o función, pregúntese: «¿Es esto realmente necesario? ¿Podemos resolver este problema sin añadir más código? «. No escriba si no está seguro de necesitar esa línea de código. El mejor código es el que no tiene código . Y esto es así porque cada línea de código que escribe es una carga . Debe mantenerse, probarse y, potencialmente, depurarse. También aumenta la carga cognitiva para otros desarrolladores (incluido usted en el futuro) que necesitan comprender el sistema.

Recuerde, su objetivo es resolver problemas y ofrecer valor, no solo escribir código . La solución más simple y fácil de mantener a menudo implica escribir menos código, no más. Piense como un ingeniero con mentalidad de producto, no como un mono codificador .

Así que ¡piensa siempre  dos veces y codifica una vez !

3. Aprende buenas prácticas

A lo largo de mi carrera, he visto cómo la adhesión a las buenas prácticas puede mejorar drásticamente la calidad del código, la productividad del equipo y las tasas de éxito de los proyectos. Sin embargo, también he aprendido que seguir las prácticas ciegamente sin comprender su contexto puede ser contraproducente.

Cuando digo buenas prácticas me refiero a:

• Código limpio . Lea y aplique los principios de » Código limpio » de Robert C. Martin para escribir código más legible y fácil de mantener. Nuevamente, no lo siga ciegamente; algunas cosas del libro todavía se mantienen y otras no envejecen bien.
• Patrones de diseño . Comprenda los patrones de diseño y cuándo aplicarlos adecuadamente. Además, no fuerce los patrones de diseño cuando no son necesarios. He visto proyectos que se han vuelto demasiado complejos debido al uso innecesario de patrones.
• Principios SOLID . Aprenda y aplique los cinco principios SOLID del diseño orientado a objetos. Estos principios pueden guiarlo en la creación de código más modular, flexible y fácil de mantener. Sin embargo, tampoco sea demasiado rígido en este aspecto.
  • Principio de responsabilidad única : una clase o módulo debe tener solo un motivo para cambiar, lo que significa que debe tener un solo trabajo o responsabilidad.
  • Principio abierto-cerrado : las entidades de software deben estar abiertas a la extensión pero cerradas a la modificación, lo que permite ampliar el comportamiento sin alterar el código existente.
  • Principio de sustitución de Liskov : los objetos de una superclase deben poder reemplazarse por objetos de una subclase sin afectar la corrección del programa.
  • Principio de segregación de interfaces : no se debe obligar a los clientes a depender de interfaces que no utilizan; en cambio, las interfaces deben ser específicas para las necesidades del cliente.
  • Principio de inversión de dependencia : los módulos de alto nivel no deberían depender de módulos de bajo nivel; ambos deberían depender de abstracciones en lugar de implementaciones concretas.
• Diferentes estilos de arquitectura de software . Conozca distintos patrones arquitectónicos , como microservicios, monolíticos, basados ​​en eventos, etc., y comprenda las ventajas y desventajas de cada estilo. Por ejemplo, los microservicios ofrecen flexibilidad, pero introducen complejidad en la implementación y la consistencia de los datos.

Recuerda que estas prácticas son solo herramientas que puedes usar. Debes saber cuándo y cómo aplicarlas y cuándo no. La clave es comprender los principios que sustentan estas prácticas, no solo seguirlas en todas las situaciones.

4. Haz las cosas sencillas e incluso más sencillas que eso.

» Hazlo todo lo más simple posible, pero no más simple «. Esta cita, a menudo atribuida a Albert Einstein, ha guiado mi diseño de software y mi enfoque en la resolución de problemas.

Al crear o diseñar nuestro software, no lo compliquemos demasiado. Optemos por soluciones simples y fáciles de entender. De todos modos, estamos en un espacio muy complejo. Esto significa que no debemos utilizar patrones complejos ni estilos arquitectónicos si no son necesarios. Al hacer algo, siempre debemos considerar si podemos lograr el mismo resultado con menos partes móviles.

La simplicidad tiene muchos beneficios:

• Un código más simple es más fácil de leer, comprender y mantener.
• Los sistemas más simples tienen menos puntos de fallo.
• La simplicidad conduce a un desarrollo más rápido y una depuración más sencilla.

Por supuesto, debemos equilibrar la simplicidad con la funcionalidad. No queremos sacrificar la funcionalidad necesaria solo por la simplicidad.

5. Nombra las cosas apropiadamente

Phil Karlton dijo:  “En informática solo hay dos cosas difíciles: invalidar la caché y nombrar cosas”. Aprendí esto a las malas. Al escribir código, siempre debemos tener en cuenta al lector, porque pasamos la mayor parte del tiempo leyendo ese código, y ese lector puede ser usted en el futuro.

Una buena denominación tiene un gran impacto en una base de código. Reduce la carga cognitiva para cualquiera que lea el código (incluido usted en el futuro) y reduce la deuda técnica. También sirve como una forma de autodocumentación, lo que hace que el código sea más fácil de entender y mantener. También ayuda a prevenir errores al aclarar el propósito y el comportamiento del código.

Por ejemplo, en lugar de nombrar una función processData(), puedes usar nombres más específicos como calculateMonthlyRevenue()o validateUserInput(). Esto permitirá que el lector comprenda la intención de esa función.

Algunos principios que podemos utilizar para un buen naming:

• Sea específico y descriptivo : los nombres deben transmitir el propósito o el comportamiento de la entidad.
• Utilice convenciones consistentes : mantenga un estilo de nombres en todo su código base.
• Evite las abreviaturas a menos que sean ampliamente entendidas en su dominio.
• Utilice verbos para funciones/métodos y sustantivos para clases/variables.
• Tenga en cuenta el alcance : utilice nombres más descriptivos para las cosas en más lugares.

Recuerde que el código se lee con mucha más frecuencia de la que se escribe. No se conforme con el primer nombre que le venga a la mente . Piense siempre desde la perspectiva del lector: ¿entenderá lo que representa ese nombre? Elegir buenos nombres es una inversión en la productividad de su equipo y en el futuro.

6. Pruebe siempre su código

En mis inicios, consideraba que las pruebas eran algo bueno que hacer si quedaba tiempo libre. Y eso fue un gran error . Esta forma de trabajar generó muchos errores y dejó a muchos clientes insatisfechos, lo que nos hizo perder credibilidad ante ellos. Nadie quiere ver errores en las cosas que usa, lo que también se aplica al software.

No podemos permitirnos tener código sin probar en nuestras bases de código. Esto significa que algunas pruebas deben cubrir cada línea de código, y lo hacemos siguiendo la Pirámide de pruebas . Esto significa:

• Escriba pruebas unitarias para funciones y métodos individuales. Mantenga las pruebas rápidas, independientes y deterministas.
• Implemente pruebas de integración para garantizar que las diferentes partes de su sistema funcionen juntas correctamente.
• Utilice pruebas de extremo a extremo (e2e) para validar flujos de trabajo de usuarios completos.

Trate el código de prueba con el mismo cuidado que el código de producción, manténgalo simple y refactorícelo en consecuencia.

Probar su código tiene muchos beneficios:

1. Detecta errores al principio del ciclo de desarrollo, cuando es más barato solucionarlos.
2. Sirve como documentación viva de cómo debe comportarse el sistema.
3. Permite la refactorización y la incorporación de funciones de forma segura.

También puedes crear un gran diseño de software escribiendo primero las pruebas y luego refactorizándolas siguiendo  el desarrollo basado en pruebas (TDD) . Comienza escribiendo una prueba que falló, escribe el código mínimo para que pase y, finalmente, refactoriza. Esto puede dar como resultado un código mejor diseñado y más modular.

Al trabajar con código heredado no probado , agregue pruebas primero y aumente gradualmente la cobertura de pruebas a medida que modifica o refactoriza el código.

Además, siempre intente automatizar sus pruebas e integrarlas en su flujo de trabajo de CI/CD . Intente lograr una alta cobertura de pruebas ( 60-80 % ), pero concéntrese en las rutas críticas y los casos extremos.

7. Administra tu tiempo sabiamente. Es lo más valioso que tienes.

A medida que he avanzado en mi carrera, me he dado cuenta de que la gestión eficaz del tiempo es una de las habilidades más importantes para un ingeniero de software. No se trata solo de ser productivo, sino de mantener la concentración, evitar el agotamiento y ofrecer valor de forma constante.

Hay algunas cosas que puedes hacer para mejorar tu gestión del tiempo:

• Empieza el día planificando : dedica entre 10 y 15 minutos a delinear tus prioridades para el día.
• Priorizar tareas (aprender la matriz de Eisenhower ) . Clasificar las tareas en función de su urgencia e importancia para centrarse en lo que realmente importa.
• Utilice bloques de tiempo : asigne franjas horarias específicas para distintos tipos de trabajo. Incluya todo en el calendario.
• Trabaja profundamente durante 4 horas diarias y concéntrate en UNA cosa . Utiliza técnicas como el método Pomodoro para mantener la concentración. Configura el modo «No molestar» durante los períodos de trabajo concentrado en tus dispositivos.
• Dedica un día a la semana a trabajar en profundidad y a resolver problemas complejos. Usa este tiempo para tareas que requieran concentración ininterrumpida, como el diseño de sistemas o la resolución de errores complejos.
• Aprende a decir no . No te comprometas con tareas o reuniones que no se alineen con tus prioridades ni asistas a reuniones en las que no te necesitan.
• Tome descansos regulares : los descansos cortos pueden mejorar la productividad general.
• Reflexione y adapte : revise sus estrategias de gestión del tiempo periódicamente y ajústelas según sea necesario. Utilice herramientas como RescueTime o Toggl para realizar un seguimiento de sus actividades.

Lea más sobre la gestión del tiempo:

Boletín informativo de Tech World With MilanCómo ser 10 veces más productivoSiempre me asombraban los mejores empleados. Me preguntaba qué hacían y en qué eran mejores que los demás. Entonces, comencé a investigar y a hablar directamente con algunos de ellos. Finalmente, logré que algunos de ellos fueran mis mentores y, al final, me convertí en uno de ellos. Aprendí que no son mejores que los demás, pero usan algunas técnicas que los ayudan a…

Leer máshace un año · 55 me gusta · 6 comentarios · Dr Milan Milanović

Y cómo priorizar las cosas adecuadamente.

Recuerda, el objetivo no es trabajar más horas sino aprovechar al máximo tus horas.

8. Comunicar, comunicar, comunicar

Durante mi carrera, he visto grandes soluciones técnicas fracasar debido a una mala comunicación y soluciones mediocres triunfar gracias a una comunicación excelente. La capacidad de comunicarse de manera eficaz suele diferenciar a los buenos ingenieros de los excelentes porque reduce los malentendidos y alinea a todos hacia objetivos comunes.

¿Cómo puedes mejorar tu comunicación?

• Practique la escucha activa: concéntrese en comprender, no solo en responder. Escuche el contenido, la estructura y, detrás de todo eso (la imagen completa).
• Sea claro y conciso : evite la jerga siempre que sea posible y vaya al grano. Si tiene dificultades, prepare lo que necesita decir antes de la reunión.
• Intente siempre adaptar su mensaje a su audiencia : tenga en cuenta sus antecedentes técnicos y sus intereses. Si habla con personas del área de productos o de negocios, no analice demasiado los detalles técnicos.
• Utilice elementos visuales con frecuencia : los diagramas, los diagramas de flujo y los wireframes pueden transmitir ideas de manera más eficaz que las palabras por sí solas. Soy un gran admirador de este enfoque.
• ¡Haz un seguimiento, haz un seguimiento siempre! No dejes que las cosas queden en el aire. Sé proactivo ; sé el responsable de principio a fin de todo lo que haces.

Una forma de mejorar la comunicación es probar  la programación en parejas y en grupo . De esta forma, no es necesario revisar el código; se escribe código de forma colaborativa con el mismo objetivo: mejorar la comunicación.

Además, no olvides que una mayor comunicación siempre es algo bueno en el mundo remoto. Por lo tanto, si tienes dudas, siempre comunícate en exceso.

9. No te limites a aprender, hazlo

En ingeniería de software, donde hay tantas cosas por saber, tanto en amplitud como en profundidad, es esencial aprender y aplicar constantemente nuevos conocimientos.

Debemos ser intencionales con nuestro aprendizaje . Esto significa que queremos aprender algo justo antes de que lo necesitemos porque si aprendemos algo ahora y no lo necesitamos este año, probablemente olvidaremos la mayor parte. Por supuesto, es bueno realizar un seguimiento de las cosas nuevas en un nivel superior para estar lo suficientemente informado.

Entonces, mi recomendación para aprender cosas nuevas es la siguiente:

• Establece un horario fijo para el aprendizaje , pero céntrate siempre en la aplicación práctica. ¡Inclúyelo en tu calendario como un bloqueo!
• Al aprender una nueva tecnología o concepto , desafíese a usarlo en un proyecto real dentro de una semana .
• Comparte lo que aprendes a través de publicaciones en blogs, presentaciones o tutorías con otros . Enseñar es el mejor método de aprendizaje.

Recuerde, el objetivo no es sólo adquirir conocimientos, sino desarrollar habilidades que puedan aplicarse para resolver problemas del mundo real.

Lee más sobre cómo puedes aprender cualquier cosa :

Boletín informativo de Tech World With MilanCómo aprender cualquier cosa de manera eficienteEl número de esta semana le trae lo siguiente…

Leer máshace un año · 74 me gusta · 5 comentarios · Dr Milan Milanović

Y cómo puedes convertirte en un experto en cualquier cosa :

Boletín informativo de Tech World With Milan¿Cómo convertirse en un experto en algo?Convertirse en un experto en ingeniería de software o en cualquier otro campo no se trata solo de combinar años de experiencia o aprender los últimos marcos de trabajo. Se trata de recorrer un camino estructurado de adquisición de habilidades y profundizar su comprensión en todos los niveles…

Leer másHace 2 meses · 147 me gusta · 8 comentarios · Dr Milan Milanović

10. Tener una cultura de documentación

En mis primeros años, solía considerar la documentación como algo que debía hacerse después del «trabajo real» de codificación y, por lo general, muy aburrido. Después de ver muchos proyectos, considero que la buena documentación es una parte clave del proceso de desarrollo .

Nuestros proyectos tienen muchos tipos de documentación, como documentos de API, diagramas de arquitectura, documentos de usuario, archivos README y más. Cada tipo juega un papel importante en el panorama general del proyecto.

Mis recomendaciones sobre la documentación en tus proyectos son:

• Mantenga la documentación cerca del código (documentación como código). Utilice herramientas como Sphinx o Jekyll para generar documentación a partir de su código base.
• Intente encontrar un equilibrio entre la cantidad de documentación que necesita. El exceso de documentación puede ser tan problemático como la falta de documentación.
• En este caso, solo hay una única fuente de verdad. Evite la documentación en muchos lugares: el mejor lugar en el código fuente es cerca del código que explica la documentación.
• Actualice periódicamente la documentación para evitar que quede obsoleta.

Además, una buena práctica es incluir documentación en la definición de «terminado» para cualquier característica o proyecto.

Recuerde que una buena documentación es una inversión en el futuro de su proyecto . Ayuda a que los nuevos miembros del equipo se pongan al día rápidamente, reduce el factor de bus e incluso puede ayudarlo a comprender su código meses o años después (disminuye la deuda técnica ).

Lea más sobre cómo crear documentación de arquitectura adecuada en sus proyectos:

Boletín informativo de Tech World With MilanDominando el arte de la documentación de la arquitectura de softwareEn este boletín intentaremos comprender…

Leer másHace 4 meses · 112 me gusta · 2 comentarios · Dr Milan Milanović

¿Que sigue?

Al reflexionar sobre estas lecciones de mis dos décadas en ingeniería de software, me sorprende lo mucho que ha cambiado nuestro campo y cómo estos principios fundamentales siguen siendo relevantes. Tal vez la lección más importante sea esta: nuestro camino como ingenieros de software implica un aprendizaje y una adaptación continuos todo el tiempo . Las tecnologías que utilizamos hoy pueden quedar obsoletas mañana, pero nuestra capacidad de pensar de manera crítica, resolver problemas de manera creativa y trabajar eficazmente con otros siempre será necesaria.

Estos veinte años me han enseñado que la ingeniería de software es más que un trabajo: es un oficio y una mentalidad. Se trata de resolver problemas, crear valor y superar continuamente los límites de lo que creemos que podemos hacer. A medida que continúes tu carrera, espero que estas lecciones te resulten tan útiles como me han resultado a mí.

Recuerda que el código que escribas hoy podría hacer funcionar sistemas, impulsar empresas o cambiar vidas en los años venideros. Aborda cada línea con cuidado, cada problema con curiosidad y cada colaboración con respeto. ¡Por los próximos 20 años de aprendizaje, crecimiento y creación de cosas increíbles juntos!

¡Buena suerte!