Qué esperar en su primera semana como desarrollador de software

Sabes que disfrutas codificar, pero ¿cómo es hacerlo por un trabajo? ¿Qué puede esperar en su primera semana?

No podía imaginar mi primera semana en un nuevo trabajo. ¿Empiezas a codificar de inmediato? ¿Qué pasa si usan un lenguaje / marco que no has aprendido? ¿Cómo puede ponerse al día con el código base y saber cuáles son las prioridades? ¿Es fácil encajar en el equipo? ¿Simplemente ... abre su editor y comienza a codificar? ¿Qué pasa si te sale algo horriblemente mal y lo rompes todo?

Trabajé durante 2 años en un bootcamp de programación y escuché preguntas similares de muchos estudiantes. Sabían que les gustaba la codificación y les encantaba lo que hacían en el campo de entrenamiento a diario, pero querían saber qué se siente al entrar en un trabajo real.

En esta publicación, usaré ejemplos de lo que hice durante los primeros días en mi puesto más reciente para intentar darte una idea de lo que podrías esperar.

Antecedentes

Trabajo como desarrollador full stack en una empresa pequeña. Hay cuatro desarrolladores en el equipo de ingeniería (incluyéndome a mí) y un CTO. También trabajamos en estrecha colaboración con un Product Owner, que es uno de los fundadores. Entré con un par de años de experiencia en programación.

Todos los servicios están en AWS y usamos NodeJS y Ruby.

Día 1: Configuración mayoritaria

Llegué a la oficina a las 9 de la mañana. Una nueva y brillante MacBook Pro me esperaba en mi escritorio, con adaptadores y dos pantallas. El equipo de desarrollo me llevó a desayunar a un café cercano, y cuando regresamos, me senté y comencé a configurar mi máquina.

Como he configurado innumerables entornos de desarrollo antes mientras trabajaba en un campo de entrenamiento de codificación, esto fue bastante sencillo y no me llevó mucho tiempo. Sin embargo, solo había configurado un entorno Ruby / Rails en mi propia computadora portátil una vez, por lo que esa parte me llevó un poco más de tiempo.

Me proporcionaron una hoja A4 que enumeraba los requisitos, los números de versión, etc., que me aseguré de seguir cuidadosamente. También me dieron acceso a varios sitios como BitBucket, un administrador de contraseñas, AWS y Gitlab y configuré mis claves SSH en mi nueva máquina.

Antes del almuerzo, fui a charlar con el CTO y hablamos en detalle sobre el producto, la arquitectura y los objetivos y prioridades que tiene el equipo de desarrollo para el futuro previsible.

Después del almuerzo, cloné algunos de los servicios que componen la aplicación y comencé a familiarizarme con el código base. Afortunadamente para mí, me uní al equipo en un momento en que había algunas partes nuevas y frescas del servicio en desarrollo, lo que significa que no tenía demasiado código para ponerme al día.

Durante las últimas horas del día, me senté con uno de los desarrolladores senior mientras implementaba una función. Lo usamos como una oportunidad para que me guiara a través de esa parte de la aplicación, explicando por qué se habían hecho las cosas de manera específica, las partes que habían causado problemas y los aspectos que podrían terminar cambiando en el futuro.

Día 2: Prueba

Me asignaron la tarea de probar un par de funciones en uno de los repositorios de la aplicación. Darles pruebas a los nuevos empleados para que escriban es una excelente manera de presentarles una base de código y familiarizarlos con parte de la lógica de la aplicación.

Pasé bastante tiempo leyendo el código, averiguando cómo funcionaba todo junto y viendo si podía seguir el flujo de la lógica. Me interesaron las convenciones que había elegido el equipo, la forma en que se había dividido el código y las opciones estilísticas. Escribir las pruebas no fue difícil, pero siempre soy muy cauteloso al hacer mi primera marca en una base de código en la que no he trabajado antes.

No quería que mi trabajo sobresaliera, así que intenté observar y absorber el estilo de código que se estaba utilizando actualmente. Hasta cierto punto, tener buenas prácticas como el pelado ayuda mucho, pero también hay elecciones generales de arquitectura y estilo con las que el pelaje no puede ayudarlo.

Un pequeño desafío que tuve fue acostumbrarme al flujo de trabajo de Git que usaba el equipo. Cada equipo tiene su propia forma de hacer las cosas: algunos equipos se fusionan, algunos equipos se reorganizan, algunos equipos eliminan las confirmaciones y otros no, algunos siguen flujos de trabajo populares como este, y otros simplemente fuerzan el empuje hacia el maestro de cualquier manera. Además, existen las convenciones del mensaje de confirmación y la descripción para hacerlo bien, el proceso de revisión, etc.

En general, hay muchas cosas no explícitas de “así es como hacemos las cosas” para aprender. Después de pasar por el proceso un par de veces, corregir mis errores y hacer preguntas, ahora es una segunda naturaleza.

Todo el tiempo estaba escribiendo notas en un cuaderno y guardando fragmentos de código en una aplicación llamada Bear. Había mucho que asimilar: cómo hacer las cosas, los procedimientos preferidos por el equipo, cosas que no había hecho antes y nuevos lenguajes y marcos para aprender.

Necesitaba estar realmente activo anotando lo que estaba aprendiendo. Me propuse al final o al comienzo de cada día revisar mis notas, agregar explicaciones adicionales a las cosas que había escrito apresuradamente e investigar cosas que no entendía completamente. Todo esto también tomó algo de tiempo.

Día 3: Spiking AWS

Como parte del lanzamiento que teníamos en progreso, necesitábamos decidir cómo implementar un servicio que estábamos construyendo. Estábamos usando AWS, pero había una opción entre usar una instancia EC2, que sería la opción más simple, ya que es solo un servidor en la nube que ejecuta su aplicación, o algo un poco más elegante como Elastic Container Service. El beneficio de ECS es que administraría el escalado de múltiples instancias EC2 y, por lo tanto, sería una buena opción para el futuro. Pero no era completamente esencial por el momento.

Dado esto, se me asignó (se ofreció como voluntario) la tarea de resaltar lo fácil que sería implementar nuestro servicio en ECS. Spiking solo significa probar algo para explorar la viabilidad. Si iba a ser difícil, no valía la pena, ya que era una optimización futura que no la necesitábamos desesperadamente en este momento.

Esto implicó mucho aprendizaje para mí, ya que no había usado ECS de Amazon antes, además de que la aplicación era una aplicación Rails y estaba mucho menos familiarizado con todo el ecosistema Ruby / Rails. Había pasado tal vez un total de 30 horas aprendiendo Ruby antes de unirme a la empresa, ya que sabía que era parte de su pila, pero apenas había tocado Rails. Además, la tarea implicó un poco de trabajo con Docker, que también era nuevo para mí.

Mi jefe de tecnología me ayudó a comenzar con lo que fue básicamente una introducción de 1 hora a Docker que fue muy útil. A partir de ahí, pasé la mayor parte del día creando una nueva aplicación Rails y siguiendo varios artículos, documentos y ejemplos para ver si podía ejecutarlo en ECS. Casi llegué allí, pero lograr que la integración de la base de datos funcionara resultó ser un obstáculo. Había tantas cosas nuevas.

Estoy seguro de que alguien más familiarizado con ECS o Rails no habría tenido tantos problemas. No pude decir que el proceso fue objetivamente difícil. Fue difícil para mí , pero eso no significa que fue difícil para todos.

No fue un día muy productivo en términos de código utilizable o salida, pero sentí que aprendí mucho y desde esa perspectiva fue genial.

Día 4: Maridaje y tutoría

Llegué a la oficina a las 8 de la mañana y, mientras esperaba a que llegaran otros, seguí parte de un curso de Docker que había estado viendo en Pluralsight. Todavía estaba ansioso por terminar el pico de ayer, pero reconocí que necesitaba más conocimientos en al menos una de las nuevas tecnologías con las que estaba trabajando.

Pasé aproximadamente una hora en el curso, antes de que llegaran más personas a la oficina y nos dispusiéramos a decidir quién haría qué. Otro nuevo desarrollador, que había comenzado un poco antes que yo, acababa de regresar de las vacaciones. Decidimos que haríamos una pareja juntos en una tarea. Estábamos creando una nueva función en la aplicación Rails. Esta fue una tarea bastante simple, pero Rails era nuevo para los dos, por lo que fue genial trabajar juntos. Cuando necesitábamos que se explicara algo, simplemente preguntáramos a uno de los otros desarrolladores, ya sea en persona o en Slack. Tuvimos grandes discusiones de esta manera y comencé a entender cómo funciona Rails.

Por la tarde, tuve una sesión de tutoría con el líder de tecnología que fue generosa ya que ya había recibido una clase privada de Docker el día anterior. La tutoría es una oportunidad para responder preguntas, resolver problemas juntos, aprender algo juntos o simplemente elegir el cerebro de alguien. La transferencia de conocimientos es muy beneficiosa.

Tenía muchas preguntas extrañas sobre las bases de datos y Rails, pero lamento no tener un solo objetivo para esa primera sesión. Supongo que no estaba seguro de qué esperar. En sesiones posteriores, le pedí a mi mentor que me mostrara cómo hacer algo específico, como configurar un servidor NGINX o configurar una instancia EC2 para tener acceso a una base de datos, cosas que él ya sabría, pero que me tomaría mucho más tiempo averiguarlo. por mi cuenta.

Día 5: Reuniones y fusiones

Muchos equipos de software utilizarán combinaciones de reuniones de pie (a menudo diarias), retrospectivas regulares (sobre prácticas de trabajo o problemas técnicos) y sesiones de planificación para organizar su flujo de trabajo a un alto nivel, en combinación con algún tipo de herramienta de seguimiento donde el trabajo Se puede visualizar el progreso y el trabajo que queda por hacer.

Nuestro equipo no es diferente, y tenemos la mayoría de nuestras reuniones programadas los viernes. Como muchos equipos, el énfasis durante nuestras reuniones es reflexionar sobre cómo hemos estado trabajando y lo que hemos logrado, para resolver colectivamente cualquier problema o bloqueo, e identificar y planificar el trabajo futuro para que siempre tengamos algo por delante. estamos listos para seguir adelante.

También salimos a desayunar para vincularnos, ¡lo cual es increíble!

Con todo, la mayor parte de la mañana se dedicó a estas actividades. Tenía poco que aportar, ya que todavía estaba entendiendo toda la terminología y la estructura del producto, y siempre estaba detrás de una oración, tratando de ponerme al día con lo que acababa de decir. Recuerdo que durante esa primera semana sentí que mi cerebro se estaba derritiendo mientras trataba de mantener todos los componentes de la arquitectura juntos en mi mente (mejora a medida que pasa el tiempo, ¡así que no se preocupe!)

Por la tarde, mi pareja y yo pudimos terminar en lo que habíamos estado trabajando, solicitar una revisión del código, hacer modificaciones y abrir una solicitud para fusionar nuestro trabajo en la aplicación. No nos desplegamos porque era viernes por la tarde, pero lo hicimos el lunes siguiente. ?

Gracias por leer, espero que este artículo te haya dado una idea de cómo será tu primera semana como desarrollador.

¡Me encantaría escuchar tus comentarios y experiencias!