Hábitos de programadores efectivos

Los ingenieros de software dedican mucho tiempo a desarrollar sus habilidades para las entrevistas de trabajo, incluyendo la práctica de preguntas de retroalimentación de código y la redacción de currículos. Este articulo te comentare las siete hábitos que necesitan los programadores efectivos.

Recomendado: Preguntas frecuentes en las entrevistas de React JS

Cuando llega el momento de conseguir un trabajo, pueden descubrir que las habilidades que utilizaron para conseguir el trabajo no coinciden con las que necesitan en su trabajo diario como programadores.

Todo el mundo escribe código malo

Por eso, la capacidad de seguir el código de otra persona es una habilidad excelente con múltiples beneficios.

No importa lo desordenado o pobre que fuera el código del ingeniero anterior. Después de todo, es tu trabajo. Incluso si ese ingeniero era usted hace un año.

Esta habilidad es útil de dos maneras. En primer lugar, poder leer el código de otras personas es una buena oportunidad para aprender lo que es un mal diseño. Cuando miras el código de otras personas, puedes ver lo que funciona y lo que no. Y lo que es más importante, puedes ver qué código es fácil de seguir para otros ingenieros y qué código es difícil de seguir.

Recomendado: Como conseguir trabajo como desarrollador web

Cuando leas el código de otras personas, debes intentar hacer observaciones lo máximo posible. Así, los demás ingenieros entenderán lo bueno que eres.

Trata de hacer hincapié en la importancia de un código de software mantenible y de una buena retroalimentación. Este es otro factor abrumador en el mundo de la programación.

Tu código debe estar tan bien diseñado que no necesita documentación. De hecho, si eres un buen programador, no deberías necesitar documentar tu código. Simplemente está perdiendo el tiempo que debería dedicar a la codificación y a las reuniones.

Además, el hecho de poder leer el código desordenado de otras personas hace que sea más fácil actualizarlo cuando sea necesario. A veces esto significa actualizar el código con el que no se tiene experiencia.

Leer el código de otras personas es valioso porque te permite estar al tanto de los sistemas demasiado inteligentes que podrían confundir a los demás.

Percepción de un mal proyecto de software.

Muchas habilidades se aprenden con el tiempo. Entender qué proyectos no merecen la pena y cuáles son claramente una marcha de la muerte es otra habilidad que merece la pena conocer.

Recomendado: ¿Qué tan cierto es que programar es fácil?

Las grandes empresas siempre tienen muchos proyectos que pueden no llegar a completarse o no tener ninguna repercusión. Algunos de estos proyectos pueden no tener sentido comercial (al menos para usted) o simplemente están mal gestionados. Esto no significa que debas aceptar inmediatamente una idea cuando tengas objeciones a un proyecto. Sin embargo, si las partes interesadas no pueden explicar adecuadamente lo que el proyecto hará en última instancia, entonces puede que no merezca la pena hacerlo.

Algunos proyectos también pueden centrarse en la tecnología más que en las soluciones y puede estar claro desde el principio que no habrá un impacto significativo. Para desarrollar esta habilidad, hay que hacer muchos proyectos malos y saber qué significan realmente los proyectos malos. Así que no hay que dedicar demasiado tiempo a identificar cada proyecto en las primeras fases.

En algún momento de tu carrera, tendrás una buena intuición.

Evita demasiadas reuniones

Cuando ingeniero de software como un científico de datos, las reuniones son casi obligatorias porque necesitas ponerte de acuerdo con los jefes de proyecto, los usuarios finales y los clientes. Sin embargo, las reuniones también tienden a acaparar de repente todo tu tiempo.

Debes aprender a evitar las reuniones innecesarias. Más que evitarlos, sería mejor decir gestionarlos. El objetivo es garantizar que se dedique tiempo a reuniones que faciliten la toma de decisiones y ayuden al equipo a salir adelante con las actividades.

La forma más habitual de hacerlo es reservar dos horas al día para reuniones permanentes. En general, la mayoría de las personas celebran reuniones periódicas en momentos que consideran beneficiosos. Aprovecha este tiempo para ponerte al día con el trabajo de desarrollo.

Otra forma de evitar las reuniones es llegar al trabajo antes que los demás. En lo personal, prefiero llegar temprano porque hay más calma en la oficina. La mayoría de las personas que llegan temprano están tratando de hacer su trabajo, al igual que tú, así que nadie te molestará.

Para los compañeros que trabajan individual esto es relevante para ellos, ya que nuestro trabajo requiere momentos de concentración cuando no estamos hablando con otras personas. Sí, puede haber ocasiones en las que quieras trabajar con otras personas para resolver un problema. Sin embargo, una vez superado el bloqueo, todo lo que hay que hacer es codificar. Se trata de entrar en esa zona en la que constantemente tienes pensamientos complejos en la cabeza sobre el trabajo que estás haciendo. Si te quedas quieto, será difícil avanzar.

Mejorar tus habilidades con Git

Algunos estudiantes de ciencias de la computación llevan usando Git desde que nacieron. Conocen todos los comandos y parámetros y pueden saltarse a los profesionales.

Otros tuvieron su primer contacto con Git en su primer trabajo. Para ellos, Git es un infierno de comandos y procesos. No saben al 100% lo que están haciendo (por eso son tan populares las hojas de trucos).

Cualquiera que sea el sistema de repositorio de codigo que utilice su empresa, puede ser útil si se utiliza correctamente, y un obstáculo si se utiliza de forma incorrecta. Un simple push o commit que no lleva mucho tiempo puede convertirse en un gran problema de múltiples ramas y bifurcaciones, que puede llevar horas desenredar. Además, si a menudo te olvidas de sacar la última versión de tu repositorio, tendrás que lidiar con conflictos de fusión, lo que no es divertido.

Si necesitas llevar una hoja de referencia de los comandos de Git, hazlo. Lo que te haga la vida más fácil.

Escribir un código sencillo y fácil de mantener

Los jóvenes ingenieros pueden tener la tendencia a tratar de incorporar todo lo que saben en sus soluciones. Hay un deseo de desarrollar una comprensión de la programación orientada a objetos, las estructuras de datos, los patrones de diseño y las nuevas tecnologías y aplicarlos a todo el código que escriben. Tienden a confiar demasiado en soluciones y patrones de diseño que han utilizado en el pasado, creando una complejidad innecesaria.

Existe un equilibrio entre los conceptos de diseño complejos y el código sencillo. Los patrones de diseño y el diseño orientado a objetos están generalmente diseñados para simplificar el código. Sin embargo, cuanto más abstracto, encapsulado y en caja negra sea un proceso, más difícil será su depuración.

Aprenda a decir "no" y a priorizar

Esto se aplica a cualquier función, ya sea un analista financiero o un ingeniero de software. Sin embargo, parece que todo el mundo lo necesita, sobre todo en una función técnica. Si eres un ingeniero de datos, es posible que se te pida que hagas algo más que desarrollar pipelines. Un equipo necesita extracción de datos, un equipo necesita cuadros de mando, un equipo necesita una nueva canalización para sus científicos de datos.

Ahora bien, priorizar y decir no son dos habilidades diferentes, sino que están estrechamente relacionadas. Priorizar significa dedicar tiempo sólo a las cosas que tienen un impacto significativo en su empresa. Decir "no" también puede significar evitar el trabajo que debería ser manejado por otros equipos. Sea cual sea el papel, ambos suelen ir de la mano.

Desarrollar esta habilidad puede ser difícil. Esto se debe a que está tentado a aceptar todas las peticiones que le lanzan. Esto es especialmente cierto si eres un recién graduado universitario. Se le presenta constantemente una carga de trabajo fácil porque no quiere defraudar a nadie.

En una empresa grande, siempre hay más trabajo del que se puede manejar. Es importante asumir sólo lo que se puede hacer.

Hay muchas habilidades que no se evalúan en las entrevistas ni se enseñan en las universidades. Muy a menudo esto se debe a las limitaciones del entorno más que a la falta de voluntad de exponer a los estudiantes a los problemas que existen en un entorno de desarrollo real.

Pensar en el Diseño operativo

Una habilidad que es difícil de comprobar en las entrevistas y difícil de reproducir en los cursos universitarios es pensar en cómo los usuarios finales podrían utilizar su software de forma incorrecta. Solemos llamar a esto "pensar en escenarios operativos".

Sin embargo, esto es sólo una forma educada de decir que tratamos de validar falsamente nuestro código.

Por ejemplo, gran parte de la programación es mantenimiento, y a menudo cambiamos código que está muy entrelazado con otro código. Incluso los cambios más sencillos requieren el seguimiento de todas las referencias a objetos, métodos y API. De lo contrario, te arriesgas a romper accidentalmente una conexión de módulo de la que no eras consciente. Aunque sólo sea cambiando el tipo de datos de la base de datos.

También hay que pensar en los casos límite y en el diseño general de alto nivel antes de empezar el desarrollo.

Para casos más complejos, como el desarrollo de un nuevo módulo o microservicio, es importante tomarse el tiempo necesario para pensar en el escenario operativo de lo que se está construyendo. Piense en cómo los futuros usuarios tendrán que usar su nuevo módulo, cómo podrían usarlo de forma incorrecta, qué parámetros necesitarán, si hay otra forma en que los futuros programadores necesitarán su código, etc.

La simple codificación o programación es sólo una parte del problema. Es fácil crear programas que funcionen bien en un ordenador. Sin embargo, el despliegue del código puede fallar de muchas maneras. Cuando se pone en producción, no se sabe cómo se utilizará el código ni qué otro código se añadirá al original. Dentro de cinco años, los futuros programadores pueden sentirse frustrados por las limitaciones de su código.

Aprende más de programación:

¿ Te fue útil este artículo ?
⬇️ Ayudame compartiendo para poder llegar a más personas.⬇️

Si quieres conocer otros artículos parecidos a Hábitos de programadores efectivos puedes visitar la categoría Consejos.