1. Aprenda a leer el código de otras personas
Todos menos usted escriben un código terrible.
Es por eso que una gran habilidad que tiene múltiples beneficios es poder seguir el código de otras personas.
No importa cuán desordenado o mal pensado sea el código de un ingeniero anterior, aún debe ser capaz de leerlo. Después de todo, es tu trabajo. Incluso cuando ese ingeniero era usted un año antes.
Esta habilidad te beneficia de dos maneras. Una, poder leer el código de otras personas es una gran oportunidad para aprender qué es un mal diseño. Mientras observa el código de otras personas, aprende qué funciona y qué no. Más importante aún, aprende qué tipo de código es fácil de seguir para otro ingeniero y qué código es difícil de seguir.
Debe asegurarse de quejarse tanto como sea posible mientras lee sobre el código de otras personas. De esa manera, otros ingenieros entienden qué tan superior eres como ingeniero.
Asegúrese de mencionar los puntos sobre la importancia del código mantenible y los buenos comentarios. Esto muestra aún más su dominio en el área de la programación.
Su código debe estar tan bien diseñado que no requiera documentación. De hecho, no debe documentar ninguno de sus códigos si es un buen programador. Esto es solo una pérdida de tiempo y necesita pasar su tiempo codificando y en reuniones.
}
}
Poder leer el código desordenado de otras personas también facilita la actualización cuando es necesario. Esto ocasionalmente significa actualizar el código en el que carece de experiencia. Por ejemplo, una vez seguimos una secuencia de comandos de Powershell a Python a Perl. Teníamos una experiencia limitada en Perl, pero aún teníamos suficiente contexto para descubrir qué estaba pasando y hacer los cambios necesarios.
Esto viene de tener una comprensión decente de todo el código y de poder leer los scripts de Perl.
Leer el código de otras personas te hace valioso porque puedes seguir incluso los sistemas sobredimensionados que pueden confundir a otros.
2. Un sentido para los malos proyectos
Hay muchas habilidades que toman tiempo para aprender. Una de las habilidades que creemos que vale la pena conocer es comprender qué proyectos no vale la pena hacer y qué proyectos son claramente marchas de la muerte.
Las grandes empresas siempre tienen muchos más proyectos en marcha de los que probablemente se completarán o impactarán. Hay algunos proyectos que pueden no tener sentido comercial (al menos no para usted), y hay otros que están mal administrados. Esto no quiere decir que deba cortar una idea justo cuando no esté de acuerdo con el proyecto. Sin embargo, si las partes interesadas no pueden explicar adecuadamente qué harán con el resultado final, entonces quizás no valga la pena hacer el proyecto.
Además, algunos proyectos podrían estar tan enfocados en la tecnología en lugar de la solución que podría estar claro desde el principio que no habrá mucho impacto. Esta habilidad requiere hacer muchos proyectos malos antes de tener una idea de lo que realmente es un proyecto malo. Por lo tanto, no pase demasiado tiempo tratando de discernir cada proyecto.
En algún momento de tu carrera, solo tendrás un buen sentido común.
3. Evitar reuniones
Ya sea que sea un ingeniero de software o un científico de datos, las reuniones son una necesidad porque necesita poder estar en la misma página con sus gerentes de proyecto, usuarios finales y clientes. Sin embargo, también hay una tendencia a que las reuniones de repente se hagan cargo de todo su horario. Por eso es importante aprender cómo evitar reuniones innecesarias. Quizás una mejor palabra para usar es administrar en lugar de evitar. El objetivo aquí es asegurarse de pasar su tiempo en reuniones que impulsen decisiones y ayuden a su equipo a avanzar.
El método más común es simplemente bloquear un bloqueo de dos horas todos los días que es una reunión constante. Por lo general, la mayoría de las personas organizarán una reunión periódica en el momento que les resulte beneficioso. Lo usarán como un momento para ponerse al día con su trabajo de desarrollo.
Otra forma de evitar las reuniones para que pueda hacer el trabajo es presentarse antes que cualquier otra persona. Personalmente, nos gusta llegar temprano porque, en general, la oficina es más tranquila. La mayoría de las personas que aparecen temprano son como tú, solo queriendo terminar el trabajo para que nadie te moleste.
Esto es importante para los contribuyentes individuales porque nuestro trabajo requiere momentos en los que nos concentramos y no hablamos con otras personas. Sí, hay ocasiones en las que podrías estar resolviendo problemas en los que quieras trabajar con otras personas. Pero una vez que superas los problemas de bloqueo, solo necesitas codificar. Se trata de entrar en esa zona donde constantemente tienes muchas ideas complejas en tu cabeza sobre el trabajo que estás haciendo. Si te detienen constantemente, puede ser difícil retomar donde lo dejaste.
4. Github … ¿Espera, no Git?
Algunas especialidades de CS comenzaron a usar Git el día en que nacieron. Entienden cada comando y parámetro y pueden correr círculos alrededor de profesionales.
Otros obtienen su primer sabor de Git en su primer trabajo. Para ellos, Git es un paisaje infernal de comandos y procesos confusos. Nunca están 100% seguros de lo que están haciendo (hay una razón por la que las hojas de trucos son populares).
No importa qué sistema de repositorio utilice su empresa, el sistema es útil si lo usa correctamente y un obstáculo si se usa incorrectamente. No se necesita mucho para que un simple empujón o compromiso se convierta en pasar horas tratando de desenredar una mezcolanza de múltiples ramas y tenedores. Además, si olvida constantemente extraer la versión más reciente del repositorio, también se enfrentará a conflictos de fusión que nunca son divertidos.
Si necesita mantener una hoja de trucos del comando Git, hágalo. Lo que sea que haga tu vida más simple.
5. Escribir código simple y mantenible
Una tendencia que podrían tener los ingenieros más jóvenes es intentar implementar todo lo que saben en una solución. Existe este deseo de comprender su programación orientada a objetos, estructuras de datos, patrones de diseño y nuevas tecnologías y utilizar todo eso en cada parte del código que escriba. Crea una complejidad innecesaria porque es muy fácil estar demasiado apegado a una solución o patrón de diseño que haya utilizado en el pasado.
Existe un equilibrio con conceptos de diseño complejos y código simple. Se supone que los patrones de diseño y el diseño orientado a objetos simplifican el código en el gran esquema de las cosas. Sin embargo, cuanto más se abstrae, encapsula y encajona un proceso, más difícil puede ser depurarlo.
6. Aprenda a decir no y priorizar
Esto se aplica a cualquier rol, ya sea que usted sea analista financiero o ingeniero de software. Pero en particular, los roles tecnológicos parecen hacer que todos necesiten algo de ellos. Si es un ingeniero de datos, probablemente se le pedirá que haga algo más que desarrollar tuberías. Algunos equipos necesitarán extractos de datos, otros necesitarán paneles de control y otros necesitarán nuevas canalizaciones para sus científicos de datos.
Ahora, priorizar y decir no podría ser dos habilidades diferentes, pero están estrechamente entrelazadas. Priorizar significa que solo pasa tiempo que tiene un alto impacto para la empresa. Mientras que decir no a veces solo significa evitar el trabajo que debería ser manejado por un equipo diferente. A menudo suceden en tándem para todos los roles.
Esta puede ser una habilidad difícil de adquirir, ya que es tentador aceptar cada solicitud que se le presente. Especialmente si estás recién salido de la universidad. Desea evitar decepcionar a alguien y siempre se le ha proporcionado una cantidad de trabajo factible.
En las grandes empresas, siempre hay una cantidad interminable de trabajo. La clave solo es asumir lo que se puede hacer.
Hay muchas habilidades que no se prueban en las entrevistas ni se enseñan en las universidades. A menudo, esto es más una limitación del entorno que una falta de deseo de exponer a los estudiantes a problemas que existen en entornos de desarrollo real.
7. Pensamiento de diseño operacional
Una habilidad que es difícil de evaluar en una entrevista y difícil de replicar cuando estás tomando cursos en la universidad es pensar cómo un usuario final podría usar tu software de manera incorrecta. Por lo general, hacemos referencia a esto como pensar en escenarios operativos.
Sin embargo, esta es solo una forma educada de decir que está intentando utilizar un código de prueba falso.
Por ejemplo, dado que gran parte de la programación es mantenimiento, a menudo significa cambiar el código que está muy enredado con otro código. Incluso una alteración simple requiere el seguimiento de todas las referencias posibles de un objeto, método y / o API. De lo contrario, puede ser fácil romper accidentalmente módulos que no sabe que están conectados. Incluso si solo está cambiando un tipo de datos en una base de datos.
También incluye pensar en casos extremos y pensar en un diseño completo de alto nivel antes de entrar en desarrollo.
En cuanto a los casos más complejos en los que está desarrollando nuevos módulos o microservicios, es importante tomarse su tiempo y pensar en los escenarios operativos de lo que está construyendo. Piense en cómo los futuros usuarios podrían necesitar usar su nuevo módulo, cómo podrían usarlo incorrectamente, qué parámetros podrían ser necesarios y si hay diferentes maneras en que un futuro programador podría necesitar su código.
Simplemente codificar y programar es solo una parte del problema. Es fácil crear software que funcione bien en su computadora. Pero hay muchas formas en que la implementación del código puede salir mal. Una vez en producción, es difícil decir cómo se usará el código y qué otro código se adjuntará a su código original. Dentro de cinco años, un futuro programador podría sentirse frustrado por las limitaciones de su código