memorias de ingenieria de software
Jan 26 2023
Cuatro años como ingeniero de software en una startup de alto crecimiento, aprendí algunas lecciones muy valiosas sobre las que reflexiono aquí. Esta es una lista creciente y la seguiré agregando.
Cuatro años como ingeniero de software en una startup de alto crecimiento, aprendí algunas lecciones muy valiosas sobre las que reflexiono aquí. Esta es una lista creciente y la seguiré agregando.
- El trabajo siempre está cambiando . Sobre todo cuando la empresa es pequeña. Cuando comencé en OpenGov como el empleado número 180, no podía decir si estaría haciendo el mismo trabajo que estaba haciendo en ese momento, un mes después. Las cosas están cambiando rápidamente, la empresa está tratando de encontrar su lugar en el mercado y eso viene con requisitos en constante evolución.
- Tú eres la cultura . Cuando una empresa es pequeña, cada elemento nuevo, proceso o mejora técnica que introduzca puede ser adoptado por toda la organización de ingeniería. (o en algunos casos, toda la empresa) y podría convertirse en parte de la cultura a medida que la empresa crece. Eso, en mi opinión, es muy gratificante y no todos tienen esa oportunidad. Busque siempre las cosas que puede mejorar e intente iniciar una discusión. No tienes que hacer todo el trabajo pesado tú mismo; identificar lo que podría mejorarse y dar el primer paso es muy útil.
- Toque cada parte de la pila . En una startup que trabaja como ingeniero, los roles rara vez tienen un límite claro de las "cosas" en las que se le puede pedir que trabaje, especialmente como ingeniero junior. Puede esperar trabajar en el frontend, backend, infraestructura, bases de datos y mucho más. Desde preparar una acumulación de JIRA para una función hasta implementar el código relacionado, todo es parte del trabajo.
- Las cosas se rompen. Implementa una pieza de código que rompe el sistema o no se comporta como lo hacía en un entorno previo a la producción. A veces, la infraestructura se descompone y no se puede implementar nada en absoluto. Todas estas son oportunidades para aprender y mejorar. En opengov, aunque teníamos un equipo de desarrollo dedicado para manejar problemas como estos, nosotros, como ingenieros, también estábamos expuestos al lado operativo de la ingeniería de software.
- La documentación es importante. Como estamos ocupados escribiendo y enviando código, la documentación tiende a quedar en un segundo plano. Vale la pena tomarse un tiempo, en una cadencia regular, para crear nueva documentación y mantener actualizada la existente. Buena documentación, es en mi opinión la señal de un equipo de alto rendimiento. A medida que las personas van y vienen, especialmente en el caso de las empresas emergentes, la documentación es lo que ayuda a incorporar a nuevas personas y a difundir el conocimiento de varios sistemas y dominios dentro de los miembros del equipo existentes.
- La comunicación es difícil . Para obtener la aceptación de diferentes partes interesadas para un proyecto técnico, debe explicar cómo aporta valor a su cliente. ¿Quiere pasar los próximos sprints refactorizando la administración de estado de su aplicación? Bueno, prepárate para explicarle al producto o a tu EM (quien a su vez deberá explicárselo a los superiores) por qué es importante. A veces, hay un beneficio directo para el usuario final, como tiempos de carga más rápidos de la aplicación, mejor UX, etc. Otras veces, el beneficio sería una mejor experiencia para el desarrollador que aceleraría el desarrollo de funciones en el futuro. Sea lo que sea, formar esa narrativa correctamente puede ser complicado e incluso si usted no es el involucrado en estas negociaciones, sugiero siempre alejarse y mirar su trabajo desde una perspectiva de usuario.
- Encontrar el mentor adecuado. Al igual que en otras disciplinas, la tutoría puede cambiar el juego como un joven ingeniero. Un mentor no tiene que tomarte de la mano para enseñarte algo, sino empujarte en la dirección correcta. Tienen una vasta experiencia en el campo, son profesionales experimentados y están dispuestos a compartir sus aprendizajes con usted. Comuníquese con las personas de su equipo/empresa a las que admira y hable sobre un problema que está resolviendo, un documento de diseño técnico que está escribiendo o cualquier cosa sobre la que necesite orientación.

![¿Qué es una lista vinculada, de todos modos? [Parte 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)



































