Esto es lo que aprendí nueve meses en mi trabajo de ingeniería de software

He trabajado durante unos nueve meses en Dexter como desarrollador de software. Escribí una publicación de blog sobre conseguir el trabajo inicialmente, así como una publicación técnica sobre un componente de autoposicionamiento que hice en mis primeros meses en la empresa. Conseguir un trabajo fue mi objetivo inicial, y mantenerlo y crecer como desarrollador fue el siguiente paso natural.

Mis pensamientos sobre mi rol han cambiado significativamente desde que comencé. Pensé que ser desarrollador se trataba de crear código lo más rápido posible. Es lo más alejado de la realidad. Lanzar mucho código basura rápidamente no es una forma escalable de construir un negocio o una carrera en el desarrollo. Afortunadamente, encontré un empleador que sentía lo mismo y cuyo producto es software.

El objetivo es escribir la cantidad justa de buen código y comunicarse bien. No se le paga por codificar, se le paga por pensar y resolver problemas. El subproducto es el pensamiento cristalizado y las instrucciones que debe seguir una máquina en forma de código. Prefiero resolver un problema en una línea de código legible claro que en 10 líneas de código que son difíciles de entender. Prefiero resolver un problema en 5 líneas de código comentado legible que en una línea de código altamente complejo y multi-anidado con múltiples operadores ternarios. Entiendes la idea.

Haga muchas preguntas y documente las respuestas

Mi jefe me envió este enlace que resume gran parte del estrés y la ansiedad que siento como ingeniero nuevo. Es un eufemismo decir que soy muy cohibido al hacer preguntas.

Utilizo esta lista de verificación antes de pedir ayuda a otros:

  • ¿Es esta una pregunta que ya he hecho antes? Y, de ser así, ¿dónde documenté la respuesta?
  • ¿Es esto algo que podría buscar en Google?
  • ¿Está esto documentado en algún lugar por alguien más internamente?
  • ¿Que está pasando aqui? ¿Cuál es la causa principal del error o comportamiento inesperado que estoy experimentando?
  • ¿Entiendo realmente la pregunta que estoy tratando de responder? Está bien tomarse un tiempo y volver a leer el problema en lugar de dar una respuesta a medias o apresurada.

Después de seguir estos pasos, resuelvo el problema por mi cuenta, encuentro una solución documentada o hago una pregunta con mucho mejor contexto y detalle, lo que facilita que alguien más me ayude. Aún mejor, si hago una buena pregunta y se puede responder por chat, mi compañero de equipo no necesita dejar todo para ayudarme.

Si he recorrido el 90% del camino para resolver el problema y solo necesito el último 10% de ayuda, un desarrollador senior estará feliz de ayudar sabiendo que llegué tan lejos como pude por mi cuenta. Buscar a otra persona para resolver sus problemas no es una buena forma de generar confianza dentro de su equipo.

A las personas inteligentes les gustan las buenas preguntas, así que hágalas.

Evite cometer los mismos errores y hacer las mismas preguntas una y otra vez

Esto es más fácil decirlo que hacerlo, y podría aplicarse a cualquier trabajo, no solo a la programación. Se le están lanzando muchos conceptos e información nuevos, y cometer errores es inevitable. Sea consciente de eso. Piense antes de preguntar. Cosas de Google. Mira los documentos. Son tus amigos. Si ve una tendencia, intente identificarla. Haga un esfuerzo activo para sorprenderse haciendo el mismo tipo de pregunta. Escríbalo y conviértase en una meta para solucionarlo.

Asegúrese de que la próxima vez que se encuentre con el mismo problema sepa qué hacer. Todos cometemos errores, pero ser conscientes de nosotros mismos y hacer un esfuerzo por cambiar es la forma en que todos mejoran.

Revise su trabajo, siempre

A nadie le gusta pasar por un PR y decirle que elimine su console.logs y depuradores o decirle que corrija los errores de colas. No publicaría esta publicación sin leerla un par de veces y que un amigo también la echara un vistazo.

Mire realmente su código y hágase estas preguntas:

  • Escribí una lógica compleja. ¿Existe una funcionalidad similar en la aplicación que tal vez lo haga de una manera más legible, flexible o genérica?
  • Si no es así, ¿recordaría por qué escribí este código en una semana? Si la respuesta es no, probablemente quiera cambiar el código o comentarlo. La persona que revisa el RP debe tener algún contexto sobre por qué tomé esa decisión.
  • Asegúrese de que su código esté pasando las pruebas antes de dárselo a otra persona.
  • ¿Me estoy repitiendo? ¿Puedo encapsular la lógica que estoy repitiendo en una función?
  • Si este fuera el código de otra persona que estuviera revisando, ¿qué comentarios haría? ¿Qué me gustaría cambiar para hacerlo más sencillo?

Mire su código con un par de ojos nuevos (tal vez al día siguiente). ¿Existe una hemorragia lógica específica en componentes que no debería ser así? ¿Su componente maneja la lógica empresarial que debería ir a un contenedor?

Además, una buena revisión del código propio ahorra tiempo y dinero a la empresa. Es mucho más económico para usted encontrar sus propios errores y corregirlos usted mismo en lugar de que otra persona los encuentre dos días después.

Lo último sobre revisar su código. Toque y haga clic en TODO en lo que trabajó. Quiero que el código que le envío a cualquiera sea muy difícil de descifrar. Si hacen clic en una página nueva y obtienen un gran error o una pantalla blanca de muerte, muestra que realmente no he revisado mi trabajo. Grep para el código que editó y realmente asegúrese de no romper nada más con su adición a un componente compartido.

Puede parecer una tontería, pero las bases de código grandes son complejas y es posible que no se dé cuenta de que rompe algo hasta que lo hace.

En serio, no quieres ver el primer borrador de esta publicación de blog :)

Nada es mágico

Por lo general, hay una buena razón por la cual el código ha sido aprobado por LGTM (aprobado y en la base del código). Si no comprende cómo funciona, dedique algún tiempo a averiguarlo. Registre cosas, rompa cosas, mire alguna documentación de funciones y patrones que se usaron.

¿Podrías decirle a tu patito de goma cómo funcionó? Si aún no está seguro, haga algunas preguntas sobre lagunas específicas en su comprensión.

Póngase cómodo depurando, ya que lo hace mucho

Depurar es comprender el problema subyacente en la funcionalidad de su código y luego resolver el error. Debe comprender cómo funciona la cosa para descubrir por qué no funciona en primer lugar. Poder utilizar las herramientas de depuración del navegador le facilitará la vida y el trabajo. Los métodos de depuración y consola son tus amigos.

Algún recurso útil que encontré:

  • Trucos CSS para la depuración
  • Depuración de maestros de front-end (es pagado pero bastante bueno)

Pro-tip: la salida de console.log se puede estilizar usando CSS. Esto hace que el registro que desea ver sea más fácil de identificar.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

Siga los datos

Esto surgió una y otra vez, porque es cierto que era un error que seguía cometiendo. Es algo en lo que mejoré, pero aún necesito mejorar.

Una gran parte del desarrollo de software implica la manipulación de datos en un formato para que el usuario pueda obtener información procesable de ellos o actualizarlos por su cuenta.

Las aplicaciones con un flujo de datos unidireccional y un estado global tienen una línea directa de datos a seguir. Todos esos datos provienen de alguna parte. Una vez que sepa de dónde viene, es más fácil depurarlo.

Aísle sus problemas y luego intégrelos en lo que está trabajando

Codepen.io es un amigo cercano mío, y también debería ser tuyo. Cuando no puedo averiguar qué está causando el problema, hago una versión simple de lo que estoy construyendo. Me aseguro de que funcione y luego lo integro en mi entorno de desarrollo. Es más fácil descubrir qué podría estar dañando su interfaz de usuario en un entorno reducido.

Piense en cómo debería funcionar la funcionalidad

Escribir cómo debería funcionar algo desde un nivel de 30.000 pies y luego desde un nivel técnico me ha ayudado a comprender qué debería estar construyendo, cómo debería hacerlo y ayuda a mitigar las caídas en boxes. Si no puedo explicar cómo funciona lo que estoy construyendo (desde un nivel alto o bajo), me estoy haciendo un flaco favor. Sin un plan, voy a estar haciendo muchas vueltas en un futuro muy cercano.

Además, puedo consultar lo que escribí o mostrarle a alguien lo que estoy pensando, lo que ayuda a reducir la falta de comunicación.

Abraza la lucha

Después de 10,000 horas de lucha en el trabajo, será mucho mejor para superar y resolver problemas. Tendrás que hacerlo de todos modos, por lo que disfrutar de la experiencia hará que tu día a día sea mucho, mucho mejor. Ríase un poco de sí mismo y trate de resolver realmente el problema. Llegará allí, incluso si necesita un poco de ayuda adicional.

Acepta la crítica constructiva y repite constantemente

Tus compañeros de equipo quieren que lo hagas mejor. Los desarrolladores senior quieren convertirte en un desarrollador más fuerte. Actúe según sus consejos, incluso si inicialmente no comprende por qué le están diciendo que lo haga. Nunca hay una sola persona que lo sepa todo. Charla.

Tome su tiempo

El apresurarse en su trabajo causa una y otra vez, mucha confusión y frustración adicional. Mi jefe preferiría ver un código mejor más tarde que un código incorrecto antes. Quiero decir, ¿no lo haríamos todos?

Continuar aprendiendo fuera del trabajo

Por mucho que aprendo en el trabajo, todavía quiero seguir aprendiendo cosas nuevas además de trabajar en nuestra base de código. Eso podría ser aprender a Python, construir un bot, trabajar en una serie de videos o trabajar en un proyecto personal. Hice una tabla con Zenhub + Github para rastrear dónde estoy y a qué me he comprometido durante el mes. Mantener una meta general para el mes me ha obligado a seguir aprendiendo, construyendo y sí, blogueando en mi propio tiempo.