10 hábitos de un Desarrollador de Software Senior
Con el crecimiento de la tecnología, tenemos que esforzarnos más para mantenernos al día con los frameworks y herramientas más nuevas. Sin embargo, muchos desarrolladores ignoran algunos pasos simples que podrían ayudarlos a llevar su carrera al siguiente nivel. Por lo tanto, si bien este artículo está escrito para ayudarlo a mejorar sus habilidades de programación, no cubrirá las mejores prácticas de codificación ni otros enfoques para mejorar su código. En cambio, esta es una lista de diez formas sencillas de sobresalir entre otros desarrolladores.
Automatice tanto como sea posible
Están sucediendo muchas cosas con respecto a CI / CD y DevOps. Puede que todo parezca un mundo loco que aún no estás listo para explorar. Sin embargo, aún puede ahorrar algo de tiempo de desarrollo al automatizar pequeñas actividades ejecutadas con frecuencia, como:
Secuencias de comandos que ejecuta todos los días y que podrían programarse.
Comandos de rutina. En lugar de 4 comandos para iniciar la aplicación, envuélvalos en solo 1 script / comando, por ejemplo: “npm run prepareSeedBuildStart” o simplemente “npm start” o “prepareSeedBuildStart.sh”.
Consultas de datos mensuales que se pueden ejecutar mediante un script.
Además de eso, hay varias herramientas que permiten la integración con otros, compartiendo estados y actualizaciones en todo el equipo automáticamente. En lugar de escribir a su grupo en espera el estado de una implementación, puede simplemente agregarlo en su secuencia de comandos de implementación. El tiempo es dinero.
Prueba tu propio código
Esto puede parecer obvio, pero también es un error muy común. Si se le ha solicitado que cree un nuevo CRUD, asegúrese de probar no solo el camino feliz sino también los inválidos. Esto incluye intentar guardar sin datos, leer datos que el solicitante no posee, actualizar sin un campo obligatorio, etc. Sin embargo, si está pensando que este debería ser el trabajo de un ingeniero de calidad o de otra persona, quiero que se pregunte usted mismo:
Si se detecta un error, ¿quién será responsable de ello?
Cuando hay un error en la función que creó, ¿quién es muy probable que lo solucione?
¿Es mejor que encuentre un error y lo arregle o permitir que otra persona lo haga?
¿Cómo se reflejará eso en sus habilidades de programación?
Supongo que no tengo que dar las respuestas a estas preguntas, pero espero que le hagan comprender el valor de las pruebas de desarrollo. Con respecto al tiempo de desarrollo adicional, si esto le preocupa, consideremos que dedicará un 15% adicional de su tiempo a probar la función. Hay dos cosas que podemos obtener de eso: 1. El tiempo en que alguien más encuentra el error, lo informa y lo devuelve para que se resuelva y 2. El tiempo que dedicará a volver a la función y corregir el error. Ambos son mayores que el tiempo de mi enfoque sugerido.
Haz siempre lo que prometiste.
¿Sabes ese archivo que alguien te pidió y que dijiste que enviarías en un par de minutos? ¿Qué pasa con la tarea rápida / favor que le pidieron verbalmente? ¿También el mensaje que dijo que respondería con el mejor momento para reunirse? No estoy aquí para discutir si estas solicitudes deben llegar a través de un ticket, porque sabemos que siempre habrá algunas que no lo harán, sino para reforzar que debes hacer lo que prometiste.
Como siempre estamos demasiado ocupados (o simplemente desorganizados) haciendo otras cosas, estas tareas se ignoran muy fácilmente. Sin embargo, todavía existe la expectativa de que se cumplan. Cuando reciba este tipo de solicitudes, considere escribirlas (tal vez publicarlas) en un lugar muy visible o agregarlas a su lista de recordatorios / tareas pendientes. Una vez que haya terminado la tarea, asegúrese de informar a la persona que el trabajo se ha realizado. Esta actitud no solo muestra responsabilidad, sino también respeto por sus colegas.
Nunca digas «funcionó en mi computadora»
Aunque lo entendería completamente si alguien me dijera eso, todavía no es suficiente. Vuelve a la propiedad de su código y esta declaración implica que está tratando de encontrar algo (o alguien) más a quien culpar. La mejor solución para este problema sería un CI, que utilizará un contenedor dedicado para construir y probar la aplicación. Sin embargo, si su equipo no tiene eso, hay dos cosas que debe hacer:
Solicite un proceso de CI. Implacablemente.
Asegúrese de probar su aplicación no solo localmente, sino también después de la implementación en el entorno de prueba / ensayo. También puede probarlo apuntando a la base de datos de prueba.
Los problemas suelen ser uno de los siguientes: 1. Dependencias o complementos que instaló localmente pero olvidó agregar al proyecto, 2. Nuevos datos de configuración que agregó en su base de datos local pero olvidó agregar al script de implementación , 3. Su versión local de herramientas y complementos no es la misma que en el otro entorno, 4. El caché no se ha invalidado (tanto para el Front End en los navegadores como para el Back End). Sin embargo, tener un enfoque proactivo, y decir «Mi función no funciona en el entorno de ensayo, pero no sé por qué» es mejor que decir «Funcionó en mi computadora».
Sigue aprendiendo constantemente
Inicialmente fui ambivalente acerca de agregar este tema, ya que es un paso obvio. Pero luego me di cuenta de cuántas personas no lo hacen. Si su excusa para no aprender más es la falta de tiempo o motivación, solo tengo una cosa que decir: «No aprenda para el negocio en el que trabaja, aprenda por sí mismo». El aprendizaje no tiene por qué estar relacionado necesariamente con las tareas del día a día, sino con cualquier cosa que pueda ayudarlo a ser un mejor profesional.
No hace falta decir que sería fantástico si buscara conocimientos en su campo profesional. Pero también es seguro decir que: Es mejor saber que alguien ha estado estudiando música (aunque no esté relacionado con el trabajo) que saber que no está aprendiendo nada en absoluto. La gente puede quitarte todo, excepto tu conocimiento.
Comprender el problema antes de resolverlo
Lo sé, esto suena muy obvio, pero créame, no sucede tan a menudo como creemos. Aunque hay muchas cosas que contribuyen a este problema, las principales son: “una cultura de hacer las cosas lo antes posible” y “tareas centradas en la ejecución, más que en el problema”.
En una cultura ASAP, la gente se siente atraída a centrarse en las presiones del tiempo mientras se olvida lo más importante, la solución. Le da al inconsciente la idea de que es mejor entregar algo rápido que algo que resolverá el problema.
Con respecto al enfoque incorrecto, imaginemos dos descripciones de tareas: «Actualizar la base de datos a la versión más reciente» o «Permitir a los usuarios utilizar las sintaxis de consulta más recientes a través de la base de datos». Este último realmente informa cuál es el problema y, como resultado, capacita a la persona responsable para pensar en la mejor solución. En lugar de comprar una nueva versión de base de datos e instalarla en la computadora de cada empresa, es posible instalar un parche que aún resuelva el problema, en menos tiempo y a un costo menor.
Es posible que esté pensando que no es culpa del desarrollador si una tarea está mal descrita. Por el contrario, independientemente de la situación, la persona responsable de implementar una solución debe asegurarse de comprender el problema que está tratando de resolver. Si no está claro, deberían preguntar.
Al adoptar este enfoque, el ejecutor de tareas podrá:
Proponer una mejor solución.
Piense en diferentes casos de usuarios.
Proponer una solución más rápida o eficaz.
Informe a la persona que planteó el problema si ya hay algo implementado (solo de una manera diferente) que pueda resolver el problema.
Nunca digas «Siempre ha sido así»
Considere este escenario: Paul comienza un nuevo trabajo y el gerente hace todo lo posible para asegurarse de que el empleado actual que será reemplazado comparta todo lo que sabe con Paul. De esta forma, Paul debería poder seguir desarrollando y manteniendo el proyecto por su cuenta. Una semana después, el empleado ha compartido todo lo que sabe, ha proporcionado una guía adecuada de sus actividades diarias (incluido un script que ejecuta manualmente cada mes) y deja la empresa. Ahora Paul está a cargo.
Seis meses después, el gerente busca ayuda y le pregunta a Paul en qué está trabajando actualmente. Paul responde informando que está ejecutando el guión mensual del proyecto y el gerente pregunta «¿Por qué?».
Pablo responde diciendo “siempre ha sido así”, lo cual sería correcto si consideramos que solo ha estado haciendo lo que se le pidió. Sin embargo, debido a que ignoró el impacto de la tarea en el negocio o por qué lo estaba haciendo, la respuesta no es válida. Para evitar esto, es importante ser inquisitivo y comprender por qué las cosas se hacen como están. Quizás hace 2 años se tomó la decisión de ejecutar el script manualmente debido a la falta de tiempo, pero se esperaba que fuera automatizado en algún momento. Quizás fue solo una solución temporal para otro equipo y ya no es necesaria. El punto es que nunca lo sabrá a menos que deje de usar esa respuesta y comience a hacer las preguntas correctas.
Haga seguimiento
Probablemente hayas escuchado que “no tener noticias es una buena noticia”, pero créeme, la gente podría estar quejándose a tus espaldas culpándote por no entregar algo a tiempo o diciendo que la última tarea en la que trabajaste no está completamente arreglada. Debido a que damos las cosas por sentado, después de entregar algo, generalmente pensamos que todo está funcionando bien, sin embargo, la persona que necesita la solución podría estar imaginando que usted sabe que todavía no está funcionando. ¿Cómo se arregla esto? Simplemente haciendo un seguimiento. La única forma de asegurarse de que su colega silencioso esté contento o satisfecho con su última solución es preguntándole directamente.
Por lo general, un Project Manager o Scrum Master debería encargarse de esto, sin embargo, las personas cometen errores y no necesito explicar cómo se lo verá como un mejor desarrollador si toma la iniciativa en el «seguimiento». Además de eso, la parte interesada apreciará su preocupación para asegurarse de que se aborden sus problemas.
Revisar su propio código
Hay dos reglas principales que tengo con respecto a enviar un correo electrónico: 1. Nunca lo envíe en el calor de la emoción. 2. Vuelva a leerlo siempre. El caso es que suelo hacer algunos cambios, ya que leer mi propio correo me pone en la piel de la persona que lo recibirá.
Cuando se trata de codificación, no hay diferencia. ¿Recuerdas aquella vez que miraste tu propio código y no pudiste entenderlo? Tal vez esto no hubiera sucedido si simplemente hubiera leído su código nuevamente antes del commit. Aquí hay una lista de algunos de los otros beneficios de volver a verificar su propio código:
Valide si su código será claro si alguien más intenta arreglarlo.
Literalmente refactorice.
Corregir un error o error tipográfico.
Recuerda otro caso de usuario y mejora tu solución.
Mejore el rendimiento o la arquitectura.
Si suena como algo demasiado complicado de hacer, sugiero planificar una revisión antes de un commit o una revisión en la diferencia antes de crear un pull request. Hágalo como si estuviera revisando el código de otra persona.
Tomar posesión
Imagínese un escenario en el que acaba de conseguir un perro nuevo y todos los demás en su casa lo cuidan menos usted. ¿Eso suena justo? Si no es así, ¿por qué su código es diferente? Actuar de esta manera con respecto a su código da la impresión de que no le importa. Debe comprender que asumir la propiedad no solo ayudará a la empresa, sino que también creará una buena imagen profesional para usted. Aquí hay algunas acciones de alguien que realmente se hace cargo:
Escribe tu código pensando que si sale mal, es tu responsabilidad arreglarlo. Aunque no lo sea.
Si alguien se hace cargo de la tarea, asegúrese de que aún esté bajo su control. No permita que se pierda solo porque se ha reasignado a diferentes personas.
Asegúrese de que esté bien documentado y el código bien escrito, de manera que se sienta orgulloso de hacerse cargo del proyecto.
Asegúrese de haber comunicado y registrado todos los eventos que ocurrieron durante la vida de la tarea / proyecto. Si alguien completamente fuera del proyecto verifica las tareas, ¿podría comprender todas las decisiones y cambios realizados?
Esto parece bastante sencillo, ¿verdad? Veamos algunos problemas que ocurren cuando nadie se hace cargo:
Es difícil rastrear el estado de una tarea que genera un montón de preguntas en el equipo.
Hay muchos errores, problemas de arquitectura y fallas de infraestructura porque a nadie le importaba desarrollar una tarea de manera adecuada.
Las tareas se pierden hasta que alguien de otro departamento las solicita. Luego volvemos a la etapa uno, tratando de averiguar todo lo relacionado con una tarea.
Se asigna a todos en un equipo, pero nunca se resuelve. Puede que no lo resuelva usted mismo, pero cuando se hace cargo, cuida de alguien que pueda ayudarlo a solucionarlo.
