Esto es lo que he aprendido nueve meses en mi trabajo de ingeniería de software.

He estado trabajando durante unos nueve meses en Dexter como desarrollador de software. Escribí una publicación de blog sobre el inicio del trabajo inicialmente, así como una publicación técnica sobre un componente de posicionamiento que hice en mis primeros meses en la empresa. Obtener un trabajo fue mi objetivo inicial, y mantenerlo y crecer como desarrollador fue el siguiente paso adelante.

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

El objetivo es escribir solo la cantidad correcta de buen código y comunicarse bien. No se le paga a Código, se le paga por pensar y descubrir problemas. El subproducto es el pensamiento y la instrucción cristalizados para que una máquina siga en forma de código. Prefiero resolver un problema en una línea de código legible claro que 10 líneas de código que es difícil de entender. Prefiero resolver un problema en 5 líneas de código comentó legible que una línea de código multiusuario altamente complejo con múltiples operadores de Ternarios. Tienes la idea.

Haz muchas preguntas y documenta las respuestas.

Mi jefe me envió este enlace que encapsuló mucho el estrés y la ansiedad que siento como un nuevo ingeniero. Es una subestimación para decir que soy muy consciente de que haga preguntas.

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

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

Si he ido el 90% del camino hacia la resolución del problema y solo necesita el último 10% de la ayuda, un desarrollador principal se complacerá para ayudarlo a saber que llegué tan lejos como pude por mi cuenta. Buscando a alguien más para resolver sus problemas, no es una excelente manera de generar confianza dentro de su equipo.

A las personas inteligentes les gustan las buenas preguntas, para preguntarles.

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

Esto es más fácil decirlo que hacerlo, y podría ser cierto para cualquier trabajo, no solo programando. Se están lanzando muchos conceptos y información nuevos, y cometer errores es inevitable. Sé consciente de eso. Piensa antes de preguntar. Cosas de Google. Mira los documentos. Son tu amigo. Si ves una tendencia, intenta identificarlo. Haz un esfuerzo activo para atraparte haciendo el mismo tipo de pregunta. Escríbelo y conviértalo en un objetivo de arreglarlo.

Asegúrese de que la próxima vez que entre en el mismo problema, sabe qué hacer. Todos cometemos errores, pero ser conscientes de sí mismos y hacer un esfuerzo por cambiar es cómo cada uno mejora.

Revisa tu trabajo, siempre.

A nadie le gusta pasar a través de una PR y le indicará que elimine su consola. Loslogs y los depuradores o que le dicen que arregle errores de la inflexión. No publicaría este post sin leerlo durante un par de veces y tener un amigo, también echarle un vistazo a un amigo.

Realmente mira tu código y hazte estas preguntas:

Mire su código con un fresco conjunto de ojos (tal vez al día siguiente). ¿Hay sangrado lógico específico en componentes que no deberían ser? ¿Es la lógica de negocios de su manejo de componentes que debe entrar en un contenedor?

Además, la revisión de la buena autoodía ahorra tiempo y dinero para la empresa. Es mucho más barato para que encuentre sus propios errores y los arregle en lugar de tener a alguien más encontrarlos dos días después.

Lo último de ser revisando su código. Toca y haz clic en todo lo que trabajaste. Quiero el código que envío a cualquiera que sea súper difícil de romper. Si hacen clic en una nueva página y obtienen un gran error o una pantalla blanca de la muerte, muestra que realmente no he revisado mi trabajo. GREP para el código que usted editó y realmente asegúrese de no haber rompido algo más con su adición a un componente compartido.

Puede parecer tonta, pero las bases de código grandes son complejas y es posible que no se dé cuenta de que rompa algo hasta que lo hagas.

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

Nada es magia

Por lo general, hay una buena razón para por qué el código ha sido LGTM'ed (aprobado y en la base de código). Si no entiendes cómo funciona, pasa un tiempo a quiéralo. Cosas de registro, rompiendo cosas, mira alguna documentación de funciones y patrones que se utilizaron.

Imagen de mi trabajo de goma de trabajo que sabe más sobre la programación que yo.

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

Consigue una depuración cómoda, ya que lo haces mucho.

Para depurar es comprender el problema subyacente en la funcionalidad de su código y luego resolver el error. Debe entender cómo funciona la cosa para averiguar por qué no funciona en primer lugar. Ser capaz de utilizar las herramientas de depuración del navegador va a hacer que su vida y su trabajo sea más fácil. Los métodos del depurador y la consola son tus amigos.

Algún recurso útil que encontré:

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

Salida de la consola

Seguir los datos

Esto surgió una y otra vez, porque es cierto que fue un error que seguí haciendo. Es algo en lo que mejoré, pero aún necesita trabajo.

Una gran parte del desarrollo de software implica la manipulación de los datos en un formato para que un usuario pueda obtener una visión procesable de ella o actualizarla 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 los datos vienen de alguna parte. Una vez que descubras a dónde viene de que es más fácil de depurar.

Aísle sus problemas y luego integral en lo que está trabajando.

Codepen.io es un amigo mío cercano, y debería ser tuyo también. 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 integre en mi entorno de desarrollo. Es más fácil averiguar qué podría estar rompiendo su UI en un entorno eliminado.

Piensa en cómo debería funcionar la funcionalidad.

Escribiendo cómo algo debería trabajar a partir de un nivel de 30,000 pies y luego de un nivel técnico me ha ayudado a entender lo que debería estar construyendo, cómo debería estar construyendo y ayuda a mitigar las caídas del pozo. Si no puedo explicar cómo la cosa que estoy construyendo obras (desde un nivel alto y bajo), me estoy haciendo un diservicio. Sin un plan, voy a hacer una gran cantidad de ruedas girando en un futuro muy próximo.

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

Abrazar la lucha

Después de 10.000 horas de lucha en el trabajo, estará mucho mejor para luchar y resolver problemas. Vas a tener que hacerlo sin importar, por lo que disfrutar de la experiencia va a hacer que su día a día sea mucho, mucho mejor. Ríete un poco y trata de romper realmente el problema. Llegarás allí, incluso si necesitas un poco de ayuda adicional.

Tomar críticas constructivas y constantemente iterar en ella

Tus compañeros de equipo quieren que lo hagas mejor. Los desarrolladores principales quieren hacerte un desarrollador más fuerte. Actúa sobre su consejo, incluso si no entiendes inicialmente por qué le dicen que lo hagas. Nunca hay una sola persona que lo conozca todo. Chateando.

Tome su tiempo

Correr a través de su trabajo causa de un lado a otro, mucha confusión y frustración adicional. Mi jefe preferiría ver un código mejor más tarde que el código malo antes. Quiero decir, ¿no todos nosotros?

Continuar aprendiendo fuera del trabajo.

Por mucho que aprenda en el trabajo, todavía quiero continuar aprendiendo cosas nuevas afuera de solo trabajar en nuestra base de código. Eso podría estar recogiendo Python, construyendo un bot, trabajando a través de una serie de videos o trabajando en un proyecto personal. Hice una tabla con Zenhub Github para hacer un seguimiento de donde estoy y en qué me he comprometido durante el mes. Mantener un objetivo general para el mes me ha obligado a continuar aprendiendo, construyendo y sí, blogueando por mi propio tiempo.