Los programadores novatos pasan mucho tiempo adquiriendo el conocimiento necesario para completar la entrevista.
Resuelven problemas y mejoran sus currículums. Pero la parte más interesante comienza después de que el programador recibe la posición deseada: en alguna startup, en Google, en Amazon o en otro lugar. A menudo resulta que el conocimiento y las habilidades que ayudaron a una persona a encontrar un trabajo no se corresponden con lo que necesita saber y poder realizar sus tareas diarias.
El autor del artículo, cuya traducción publicamos hoy, dice que el equipo en el que trabaja se inspiró
en la
historia de TechLead sobre 7 hábitos de programadores altamente efectivos. Los miembros del equipo decidieron expresar sus propios pensamientos sobre este tema. Aquí, en forma de consejos, proporciona un análisis de 7 habilidades de programadores efectivos.
1. Aprende a leer el código de otra persona
Todos excepto usted escriben un código horrible. Es por eso que la capacidad de un programador para trabajar con el código de otra persona es una habilidad valiosa. Esta habilidad le da al que la posee mucho bien.
El programador necesita poder entender el código de otra persona. Después de todo, este es su trabajo. No importa cuán confuso sea ese código o cuán mal escrito esté. Por cierto, "el código de otra persona" puede ser lo que escribió el programador, por ejemplo, hace un año.
Esta habilidad afecta positivamente al programador de dos maneras. En primer lugar, la capacidad de leer el código de otra persona permite comprender cómo funciona el código de baja calidad. Mirando a través del trabajo de otros, puede descubrir qué técnicas son trabajadores y cuáles no. En segundo lugar, y lo que es más importante, ayuda a revelar las características de la percepción del código de otra persona por parte de otras personas, para descubrir qué código se percibe fácilmente y cuál es difícil.
Si lees el código de otra persona y encuentras algo en él que no te gusta, trata de no guardar silencio al respecto. Esto aumentará su credibilidad a los ojos de sus colegas.
Presta atención a aquellos con quienes trabajas, sobre la importancia de escribir código que sea fácil de mantener, sobre la importancia de los buenos comentarios. Esto fortalecerá aún más su estado en el equipo.
Su propio código debe estar diseñado con una calidad tan alta que sea claro y sin documentación. De hecho, los buenos programadores no necesitan documentar el código. Es una pérdida de tiempo, el tiempo que sería mejor gastar en programación y reuniones.
La capacidad de comprender el código de baja calidad, entre otras cosas, ayuda a realizar cambios en dicho código. A veces esto significa editar código en el que alguien no es muy bueno en eso. Por ejemplo, un día nos encontramos con un script que involucraba tecnologías como PowerShell, Python y Perl. En Perl, no entendíamos muy bien. Sin embargo, logramos comprender el proyecto bastante profundamente, logramos comprender la esencia de lo que estaba sucediendo y hacer los cambios necesarios en el código. Esto fue posible debido al hecho de que entendimos el código que necesitábamos cambiar, incluido el código de los scripts de Perl.
La capacidad de comprender el código de otra persona aumenta el valor del programador porque puede comprender cómo se organizan incluso los sistemas sofisticados, de modo que cuando los miras, otra persona simplemente se dará por vencida.
2. Desarrollar un don para proyectos fallidos
Hay muchas habilidades que llevan tiempo dominar. Uno de ellos, que, estamos seguros, vale la pena dominar, es desarrollar una comprensión de los proyectos con los que no debe lidiar y qué proyectos con un alto grado de probabilidad pueden resultar en una "carrera por la supervivencia".
En las grandes empresas, siempre hay muchos proyectos en los que los programadores están trabajando. Pero no todos estos proyectos se completarán. No todos serán beneficiosos. Entre ellos pueden estar aquellos que no tienen un significado comercial (al menos para el programador). Algunos proyectos, generalmente prometedores, pueden sufrir deficiencias administrativas. Esto no significa que deba renunciar a algunas ideas inmediatamente después de darse cuenta de que no está de acuerdo con quienes las ofrecen. Sin embargo, si el autor de la idea no puede explicar claramente qué beneficio puede aportar la compañía al proyecto después de su finalización, entonces tal vez no valga la pena comenzar dicho proyecto.
Además, algunos proyectos pueden estar demasiado orientados a la tecnología en lugar de resolver un problema en particular. Esto a veces, incluso al comienzo del trabajo, nos permite comprender que la finalización de dicho proyecto no traerá muchos beneficios.
Para aprender de un vistazo a reconocer proyectos poco prometedores, debe participar en muchos de estos proyectos. Por lo tanto, si está en la etapa inicial de la carrera de un programador, no pase demasiado tiempo tratando de evaluar las perspectivas de todos los proyectos que le llegan. Con el tiempo, desarrollará un instinto interno, guiado por el cual podrá reconocer rápidamente proyectos que están condenados al fracaso.
3. Evita las reuniones
Lo que sea que trabajes, no puedes hacerlo sin reuniones. Esto se aplica a absolutamente todos. El hecho es que necesita encontrar un lenguaje común con los gerentes de proyecto, usuarios y clientes. Sin embargo, las reuniones tienen una característica desagradable: a veces ocupan de repente casi todo el día laboral. Por eso es muy importante aprender a evitar reuniones innecesarias. Quizás sería mejor no "evitar reuniones", sino esforzarse por "controlar el tiempo dedicado a las reuniones". El propósito de esto es pasar tiempo solo en aquellas reuniones que son realmente necesarias, en aquellas que contribuyen al desarrollo de proyectos.
El método de gestión del tiempo más común que se usa para las reuniones es asignar un bloque de dos horas todos los días, que se convierte en una reunión continua. Muchos organizan reuniones periódicas durante el tiempo que consideren más apropiado. Estas reuniones se utilizan para discutir temas de trabajo.
Otra forma de administrar el tiempo es venir a trabajar antes que otros para administrar su negocio. Por ejemplo, preferimos hacer precisamente eso. Y, por cierto, si vienes temprano a la oficina, será mucho más tranquilo trabajar allí de lo habitual. La mayoría de las personas que llegan temprano son iguales. Hacen esto para tener tiempo de hacer frente a su trabajo. Por lo tanto, no interfieren con el trabajo de los demás.
En nuestro caso, esto es importante para los miembros individuales del equipo. El hecho es que nuestro trabajo lleva tiempo para concentrarse completamente en una determinada tarea. En este momento, no nos comunicamos con nadie. Por supuesto, hay situaciones en las que, para resolver un problema, debe discutirlo con alguien y trabajar juntos. Pero después de que se resuelven todas las preguntas, el desarrollador solo necesita escribir código. En general, estamos hablando de entrar en una determinada zona de confort en la que el programador puede tener constantemente presente todo lo que está relacionado con la tarea que está resolviendo. Si lo interrumpen constantemente, puede tener dificultades para volver rápidamente a lo que le distrajo.
4. Master GitHub
Cuando miras a algunos programadores de clase alta, tienes la sensación de que comenzaron a usar GitHub el primer día de sus vidas. Entienden el significado de cada comando y parámetro, manejan fácilmente sus asuntos.
Pero otros se encuentran por primera vez con GitHub en su primer trabajo. Para ellos, GitHub es un verdadero infierno, construido a partir de equipos oscuros y procesos misteriosos. Nunca están completamente seguros de lo que están haciendo. Es por eso que todo tipo de "hojas de trucos" en GitHub son muy populares.
Lo anterior es cierto para cualquier sistema de control de versiones. Si se usa correctamente, es muy útil. Si lo usa incorrectamente, interfiere terriblemente con el trabajo. Un simple PR o commit puede convertirse fácilmente en una pesadilla que le toma al programador varias horas. Este tiempo se dedicará a desentrañar las complejidades de las ramas y los tenedores. Además, si regularmente se olvida de descargar la última versión del repositorio en su máquina, puede lidiar constantemente con los conflictos de fusión. No hay nada bueno al respecto.
Si necesita una "hoja de trucos" en GitHub, hágalo.
Aprenda a trabajar productivamente con GitHub. En este caso, no importa cómo exactamente lo consigas.
5. Escriba un código simple que sea fácil de mantener
Algunos programadores novatos tienen el siguiente rasgo: intentan, en un proyecto, darse cuenta de todo lo que saben. El punto aquí es que se esfuerzan por usar su conocimiento sobre programación orientada a objetos, estructuras de datos, patrones de diseño y nuevas tecnologías en cada pieza de código que crean. Esto complica innecesariamente el código debido al hecho de que con este enfoque, la tarea del programador puede verse afectada fácilmente, por ejemplo, por los patrones de diseño que ya ha implementado en la práctica.
Existe un equilibrio entre las estructuras de proyectos excesivamente complejas y el código simple. Los patrones de diseño y la programación orientada a objetos están diseñados para simplificar el código en proyectos a gran escala. Sin embargo, cuanto más recurrimos al resumen y la encapsulación, más cajas negras hay en nuestras soluciones, más difícil es depurar el código para tales soluciones.
6. Aprende a decir no y prioriza
Esta recomendación, de hecho, se puede dar a cualquiera, al menos un analista financiero, al menos un programador. Pero se puede notar que existe la sensación de que todos quieren algo especial de los técnicos. Por ejemplo, si usted es un ingeniero de análisis de datos, se le pueden ofrecer tareas que son mucho más amplias de lo que se supone que debe hacer. Algunos equipos necesitan algún tipo de muestra de datos, otros necesitan datos de resumen y otros necesitan nuevas canalizaciones.
Cabe señalar que la capacidad de priorizar y la capacidad de decir no, en realidad pueden ser dos habilidades separadas. Sin embargo, estas habilidades están muy relacionadas entre sí. Cuando se necesita uno de ellos, generalmente se necesita el segundo. La priorización es cuando se dedica tiempo solo a lo que tiene un impacto serio en la empresa. Y la capacidad de decir que no es una negativa a hacer el trabajo que alguien más debería hacer.
Aprender de qué estamos hablando puede ser difícil, ya que las personas a menudo se esfuerzan por resolver cada problema que se les plantea. Esto es especialmente cierto para aquellos que acaban de desaprender y obtuvieron su primer trabajo. Anteriormente, en sus estudios, se les asignaron tareas que afrontaron bien. Ahora, en el trabajo, esperan lo mismo y se esfuerzan por no decepcionar a nadie.
Aquí debe comprender que en las grandes empresas hay un número infinito de tareas. Lo más importante es asumir solo aquellas tareas que pueden resolverse.
Hay muchas habilidades que no se prueban en una entrevista. Raramente están disponibles en la escuela. A menudo, esta situación surge solo por las características del entorno de aprendizaje, y no porque alguien no quiera mostrar a los estudiantes las tareas reales que pueden enfrentar en la realidad.
7. Aprenda a pensar en cómo se utilizará su desarrollo.
Hay una habilidad para la cual es difícil organizar una prueba durante una entrevista. Las situaciones en las que se necesita son difíciles de reproducir mientras se estudia. Se trata de la capacidad de ver los errores que puede cometer el usuario final de un sistema de software. Generalmente llamamos a esto "pensar en los casos de uso del programa".
En realidad, este "pensamiento de escenario" es solo un nombre bastante suave para lo que se llama "protección contra el tonto".
Por ejemplo, dado que la mayor parte del trabajo del programador es admitir el código, a menudo tiene que cambiar el código, que está estrechamente relacionado con otra cosa. Incluso un simple cambio de algo requiere una búsqueda de todos aquellos lugares donde se usa. Por ejemplo, un objeto, método, API de un determinado sistema puede cambiar. Si realiza un cambio irrazonable en el sistema, puede "interrumpir" el trabajo de partes completamente inesperadas del programa. Además, estamos hablando de cambios de cualquier escala, incluso algo así como un cambio de tipo en la base de datos.
Esta habilidad también incluye la capacidad de encontrar y analizar situaciones límite que pueden surgir al trabajar con el sistema. Esto también incluye la capacidad de comprender un esquema de decisión de alto nivel en la etapa de diseño.
Esto también se aplica al desarrollo de partes más grandes de sistemas, como módulos o microservicios. Al comenzar a resolver estos problemas, debe pensar cómo se utilizarán exactamente las entidades que planea crear. Debe pensar en los escenarios de su mal uso, en las diversas opciones para su uso, y en que lo que cree se puede usar de manera completamente invisible a primera vista.
El proceso de escribir código es solo una parte del trabajo de resolver un problema determinado. Es fácil crear un programa que funcione bien en su computadora. Pero el código con el que alguien más está trabajando puede comportarse fácilmente de manera bastante diferente de lo esperado originalmente. ¿Cómo se usará el código que escribes en la producción? ¿Con qué sistemas tendrá que interactuar? ¿De qué procesos puede formar parte? ¿No parecería demasiado primitivo y limitado a un programador que tendría que apoyarlo después de unos años? Estas son preguntas muy difíciles.
Resumen
En este artículo, le presentamos una descripción general de 7 habilidades que son comunes a los programadores de alto rendimiento. Esperamos que haya encontrado entre ellos aquellos que querrá desarrollar usted mismo.
Estimados lectores! ¿Qué le aconsejaría dominar para alguien que se esfuerza por la profesionalidad en la programación?