Pronto llegará el décimo año, ya que estoy profesionalmente comprometido con la programación. ¡Diez años! Y además del trabajo formal, casi dos tercios de mi vida creé algo en Internet. Apenas recuerdo los años en que no conocía HTML: incluso es extraño si lo piensas. Algunos niños estudian música o ballet, y en su lugar creé mundos mágicos, codificando en mi cuarto de niños.

Pensando en esta primera década de recibir dinero regularmente por ingresar personajes extraños en la terminal, me gustaría compartir algunas observaciones sobre cómo ha cambiado mi pensamiento a lo largo de los años de trabajo .

Quizás los jóvenes actuales encontrarán aquí algunas de sus creencias y las verán desde el otro lado. O se dan cuenta de que ya se han librado de esto, por lo que fueron mucho más lejos que yo en su etapa.

Las personas mayores actuales también pueden querer compartir historias divertidas (y un poco humillantes) sobre las lecciones aprendidas de su experiencia juvenil.

Para mayor claridad, enfatizo que los juniors son increíbles : simplemente aparecer en el trabajo para aprender cosas nuevas, esto ya requiere mucho coraje. Este artículo trata sobre mi propia experiencia y capacitación. No generalizo en absoluto que todos los desarrolladores junior piensen o se comporten de esta manera.

Espero que disfrutes la publicación y te recuerdes algo del pasado o del presente.

¡Gracias a Artyom y Sarah por los comentarios!

Verdades absolutas del menor de las cuales era necesario desaprender

1. Soy un desarrollador senior

Cuando intenté conseguir un trabajo por primera vez, tenía 19 años. El trabajo se llamaba "webmaster estudiantil". Este es un nombre bastante sorprendente para el trabajo, porque se lo considera tanto "estudiante" como "maestro" al mismo tiempo. Hoy en día, todos quieren ser "ingenieros", porque suena más a la moda, pero para mí, "maestro" es una mejor palabra para este oficio. En cualquier caso, mi trabajo consistía en escribir PHP y MySQL y mantener nuestro sitio en Drupal, así como crear algunas herramientas internas.

Como antes había estado codificando durante varios años en mi habitación, estaba seguro de que estos años contaban como "años de experiencia". Por lo tanto, cuando me preguntaron cuánta experiencia he escrito en PHP, respondí con confianza: "¡3 o 4 años!"

Pensé que sabía mucho sobre SQL porque puedo hacer combinaciones externas (combinaciones externas).

Y cuando busqué en Google, descubrí que tres o cuatro años de experiencia significan mucho dinero.

Pasemos a mi último trabajo, que obtuve después de cinco años de experiencia estudiantil y profesional "combinada" (que consideré una experiencia normal). En ese momento, mi código casi nunca pasó por una revisión de código. Ejecuté ssh en el servidor e hice git pull. Estoy seguro de que nunca he visto una sola solicitud de extracción. No me malinterpreten, en los primeros dos trabajos aprendí muchas cosas increíbles, simplemente nunca trabajé con otros desarrolladores en la misma base de código. Sin embargo, solicité el puesto de "ingeniero principal senior", recibí una oferta y la acepté.

Así que me convertí en desarrollador senior a la edad madura de 24 años.

Después de todo, no me darían este puesto si realmente no fuera un desarrollador senior, ¿verdad? Por supuesto, mi experiencia impresionante me ha llevado a este pico, ¡así que la gente debería escucharme! Estoy en la cima de mi carrera técnica, mientras que el más joven en la oficina.

Como un jefe.

¿Qué entendí finalmente?

No toda experiencia es igual . Mi experiencia de codificación en el dormitorio, el trabajo de un programador de estudiantes es diferente de la investigación científica en informática y el trabajo en una startup en crecimiento. Esta es una experiencia diferente. Durante un año de trabajo en soporte técnico al comienzo de su carrera, puede aprender diez veces más de cinco años en proyectos individuales (o con comentarios mínimos). Si sus colegas nunca ven su código, la capacitación es mucho más lenta.

Es por eso que los mentores son tan importantes , y su equipo es mucho más importante que la diferencia en un par de dólares en salario. ¡No se conforme con un puesto junior donde trabajará solo! Y no elija su primer trabajo (o, francamente, cualquier trabajo) solo a cambio de un salario. El equipo es donde está el valor real.

También aprendí que los títulos de trabajo no significan nada por sí solos. La posición de CTO puede estar en un equipo de 5 personas, 50 o 500 personas. Este es un trabajo completamente diferente, aunque el nombre es idéntico. Entonces mi título de "senior" no me convirtió en un programador líder. Además, los títulos jerárquicos son inherentemente defectuosos y difíciles de comparar. Me di cuenta de que es importante no quedarse atascado en los nombres y no debe usarlos como una especie de verificación externa.

2. Todos escriben pruebas

La primera mitad de mi carrera trabajé en el campo de la investigación. En particular, tres años y medio en un proyecto con fondos estatales, y luego un año y medio en la universidad en el departamento de procesamiento de lenguaje natural. Puedo decir una cosa: la programación en el entorno científico es completamente diferente de la programación en la industria comercial .

En su mayor parte, no está creando aplicaciones. Trabaja en algoritmos o analiza conjuntos de datos. Alternativamente, si está creando una aplicación, lo más probable es que el trabajo sea financiado por el estado. Esto significa que es gratis para otros y generalmente de código abierto. Y cuando algo es gratis, significa que generalmente usted no es responsable de garantizar que siempre esté disponible.

Porque ... bueno, es gratis.

Tampoco eres responsable de los ingresos financieros o resultados específicos. Sin embargo, el trabajo de un programador en una institución científica es un tema para un artículo completamente diferente.

En resumen, salí del instituto con grandes expectativas.

Expectativas sobre cómo funciona la industria. Despliegues automáticos. Solicitudes de extracción y revisiones de código. ¡Será genial! ¡Finalmente, la calidad del código con el que soñé! Pero aparte del código de alta calidad con los estándares adecuados y las mejores prácticas , creía firmemente que en la industria del software todos escriben pruebas .

Hm ...

Así que imagina mi sorpresa cuando el primer día hábil en el inicio no encontré ninguna prueba. No hay pruebas en la interfaz. No hay pruebas en el backend. No hay pruebas en absoluto.

Nda. Nada Cero NaN. Faltan pruebas como fenómeno.

¡No solo no hubo pruebas , sino que nadie parecía tener problemas debido a esto! Con cierta ingenuidad, sugerí que la razón es porque la gente simplemente no sabía cómo escribir pruebas para AngularJS. Si les enseño, todo saldrá bien y comenzaremos a realizar pruebas. Error En general, solo unos años más tarde implementamos pruebas automatizadas en el código, y no fue tan fácil como pensaba.

Pero no porque la gente no sepa cómo escribirlos.

O nunca experimentaron problemas por la falta de pruebas, o experimentaron problemas por la presencia de pruebas antiguas . Dos cosas que nunca he encontrado.

¿Qué entendí finalmente?

Muchas empresas y nuevas empresas prácticamente no tienen pruebas . Cuando luchan por el mercado o por la supervivencia, muchas empresas descuidan las pruebas en las primeras etapas. Incluso las empresas de moda que patrocinan conferencias o código abierto a menudo hacen un gran monolito torpe con pruebas mínimas. Simplemente pregunte a los desarrolladores sobre el estado de la base del código.

Ninguna empresa tiene una instalación técnica ideal . Cada empresa tiene problemas, cada uno tiene una deuda técnica. La pregunta es qué hacen con él. Al solicitar un trabajo, debe comprender claramente que no todo está en orden allí, de lo contrario no habrían abierto una vacante.

Tener demasiada confianza en sí mismo en asuntos en los que carece de experiencia real es bastante arrogante . Actué TANTO como un sabelotodo, insistiendo en la implementación generalizada de pruebas, casi sin experiencia en cómo implementar esto realmente a gran escala. No repitas mis errores. Es importante tener principios, pero aún es importante estar abierto y verdaderamente interesado para percibir la experiencia y las opiniones de otras personas.

3. Estamos tan detrás del resto (también conocido como la versión técnica del síndrome de pérdida de ganancias )

Esto está estrechamente relacionado con el tema de las pruebas unitarias. Mi compañía no realizó pruebas, pero, por supuesto, todas las demás compañías las hicieron, ¿verdad?

Leí un montón de publicaciones de blog. Vi muchos discursos de conferencias en YouTube. Maldita sea, leía "ese sitio naranja" todo el tiempo [probablemente refiriéndose a Hacker News - aprox. trans.]. Todo el mundo parece estar escribiendo aplicaciones súper sofisticadas y de alta calidad con un gran rendimiento y animaciones modernas, mientras que estoy haciendo parches tratando de alcanzar el plazo.

Literalmente idolatraba a todas las otras compañías sobre las que leí, y me decepcionó cuánto se quedaron atrás mi empresa y el proyecto.

¿Qué entendí finalmente?

Muchas presentaciones de conferencias cubren pruebas de concepto, en lugar de escenarios de la vida real . Solo una historia en una conferencia sobre una tecnología no significa que la compañía use esta tecnología en su trabajo diario o que todo su código esté en perfecto estado. Los conferenciantes a menudo presentan aplicaciones de juguetes en lugar de aplicaciones reales: es importante distinguir entre ellas.

Trabajar con Legacy es completamente normal . No, en serio, es fácil imaginar que alguna otra compañía no tenga un legado. Pero después de pasar tiempo en conferencias, hablando con personas que trabajan en las principales empresas, queda claro que todos estamos en el mismo barco. ¿Intenta encontrar una empresa que NO tenga un gran monolito en PHP o Ruby que estén tratando de domesticar (o deberían haber domesticado en algún momento)? El código heredado es común, y trabajar con él a menudo te enseña más que crear aplicaciones desde cero, porque trabajas más con conceptos que aún no entiendes.

4. La calidad del código es muy importante.

En los viejos tiempos, podía hacer una revisión de código muy difícil .

Al menos yo era muy exigente con el estilo. Mi estilo resultó ser una versión modificada de la guía de estilo de JavaScript de Airbnb, pero se ajusta a mis gustos personales. Cosas como sangría, formateo, nombres: Dios no lo quiera, lo hará de manera diferente. Era completamente imposible pasar por una revisión de código sin un solo comentario mío: tendrías que aprender las habilidades de leer pensamientos y, además, ganar la lotería.

¡Envía más de 50 comentarios a tu solicitud de extracción que enumera todos los puntos y comas que te perdiste!

Porque tengo los ojos como un águila, ¡y este águila quiere obtener todos sus puntos y comas de alta calidad!

(Afortunadamente, después de muchos años de trabajar en la computadora, la visión como la de un águila ha desaparecido, por lo que ahora no tiene nada de qué preocuparse: # chistes divertidos)

¿Qué entendí finalmente?

Lo suficientemente bueno, eso es suficiente . Al acercarse al código ideal, se aplica la ley de rendimientos decrecientes. El código no debe ser perfecto, pero lo suficientemente limpio como para funcionar y no ser un desastre completo para recibir asistencia. A menudo, el código que es demasiado repetitivo o demasiado detallado es más fácil de entender para otras personas. Además, "buen código" no es lo mismo que "código que parece que lo escribí yo mismo".

La arquitectura es más importante que la nitidez . Aunque se puede mejorar alguna línea, los principales problemas son el orden arquitectónico. Es mejor centrarse inmediatamente en la estructura de la aplicación, en lugar de en pequeños fragmentos de código individuales.

La calidad del código es importante , no me malinterpreten. Pero la calidad del código no es lo que pensaba. Este no es el revestimiento, el formato o cualquier estilo que se describe en el último artículo que leí.

5. ¡Todo debe ser documentado!

Cuando llegué a mi primera compañía real, por primera vez me topé con un código extraño por primera vez. Por supuesto, trabajé un poco con el código de otra persona en el primer trabajo, pero nunca tuve que entrar en la base de código existente y descubrir qué demonios estaba pasando aquí. La única vez que sucedió esto, reescribí todo el código, en lugar de tratar de entender cómo funciona.

En cualquier caso, el hecho de que fuera un código AngularJS escrito por los desarrolladores de Ruby no ayudó en absoluto a la situación, y yo era un junior que se imaginaba a sí mismo como un senior.

Entonces, ¿cómo lidié con el hecho de que 300 líneas de código desconocido me hicieron sentir como si me ahogara?

JSDOC. Por todas partes.

Comencé a comentar todo para tratar de tener sentido. Anotaciones para cada función que pueda acceder.

Aprendí toda esta elegante sintaxis JSDoc específica de Angular. Mi código siempre fue dos veces más largo porque tenía mucha documentación y comentarios.

¿Qué entendí finalmente?

La documentación a veces miente . Es fácil pensar que la documentación resuelve todos los problemas. "¡Necesitamos muelles!" Aunque la documentación es un trabajo duro, debe hacerse. Solo tiene que documentar las cosas correctas de la manera correcta. La documentación excesiva de cosas innecesarias, por regla general, impide a las personas que intentan resolver un problema real.

Donde sea apropiado, enfóquese en la automatización en lugar de la documentación . Las pruebas u otras formas de automatización tienen menos probabilidades de perder relevancia. Por lo tanto, trato de concentrarme en escribir buenas pruebas con un lenguaje claro para que otros desarrolladores puedan ver cómo funciona el proyecto con el código de trabajo. Otro ejemplo es automatizar la instalación de una aplicación con algunos comentarios, en lugar de una guía de instalación larga y detallada.

6. La deuda técnica es mala

Si después del último punto me considerabas neurótico, ¡solo lee este! Durante algún tiempo en mi carrera, consideré que cualquier código sucio era un deber técnico . La deuda técnica es un término divertido porque si pides un ejemplo, dicen cosas muy diferentes.

Como consideraba que cualquier código "desordenado" era un deber técnico, ¡inmediatamente intenté eliminarlo con la mayor severidad!

Una vez, literalmente, pasé un fin de semana corrigiendo manualmente 800 errores de linting.

Eso es lo neurótico que era.

(Descargo de responsabilidad: esto fue antes de que aparecieran las correcciones automáticas).

¿Qué entendí finalmente?

El código desorganizado o desordenado no es lo mismo que el deber técnico . La condición imperfecta no significa que sea un deber técnico. La deuda técnica en realidad lo ralentiza de alguna manera, o hace que ciertos tipos de cambios sean difíciles o propensos a errores. Si el código es un poco desordenado, es un poco desordenado. La limpieza puede no valer su tiempo.

Tener alguna deuda técnica es normal . A veces acortamos el camino, porque necesitamos hacer el trabajo con urgencia, y para ello "prestamos" parte del tiempo en el futuro. Tener fragmentos de código que son una verdadera "deuda técnica" es normal si reconoce que probablemente tenga que devolverlo. Si su base de código, en su opinión, está libre de deudas técnicas, lo más probable es que sobreestime la apariencia en detrimento de la entrega . ¡Y Dios mío, cómo lo sobreestimé!

7. Cuanto mayor es la posición de un programador, mejor programa

Después de haber comenzado a programar a una edad bastante temprana, me convertí en un verdadero profesional en loops, perfeccionándolos al automatismo en 15 años. Programar en sí mismo es como respirar para mí. Cuando la solución es obvia, puedo imprimir el código sin parar, como texto en un blog o correo electrónico. Puedo codificar la solución más rápido que otros, y generalmente asumí proyectos más complejos.

Durante mucho tiempo, pensé que esa era la esencia del desarrollador principal.

¿Todo parece encajar? Después de todo, el puesto se llama "desarrollador principal" y no "comunicador principal" o "gerente de proyecto principal". Realmente no entendía cuántas habilidades más se necesitaban desarrollar para convertirme en un verdadero "líder".

¿Qué entendí finalmente?

Los ingenieros superiores tendrán que dominar muchas habilidades además de la programación . En comparación con el comienzo de una carrera, tuve que desarrollar una cantidad astronómica de habilidades. Comunicación, gestión de dependencias, intercambio de contexto, gestión de proyectos, evaluación de plazos de ejecución de proyectos y colaboración con colegas que no son desarrolladores. Estas habilidades son difíciles de cuantificar y requieren mucha prueba y error antes de que se aprendan adecuadamente.

No todos los programadores se convertirán en un "senior" . Este es el resultado de muchos años de experiencia acumulada. Sin embargo, muchos años de experiencia son una condición necesaria pero no suficiente para el señor. También debe ser la experiencia correcta en la que haya aprendido las lecciones correctas y pueda aplicar con éxito este conocimiento en el futuro. A veces, las lecciones importantes saldrán en un año o más tarde, es por eso que años de experiencia aún importan, incluso si eres un buen programador.

En algunas áreas todavía somos juniors . No importa cuánta experiencia tenga, siempre hay lugares donde tiene poco conocimiento. Reconocer su incompetencia en un área en particular es el primer paso para llenar este vacío y obtener ayuda de camaradas más experimentados.

Bonificación : Me gustó mucho el artículo "Ser un programador líder" . Gran cosa, si en qué momento se pregunta qué significa este trabajo.