Lo que aprendí seis meses después de mi primer trabajo como ingeniero de software autodidacta

En esta publicación, compartiré mis experiencias y daré consejos ahora que llevo seis meses en mi primer trabajo como ingeniero de software autodidacta.

Foto de rawpixel en Unsplash

Tenga en cuenta que esta publicación no se centrará en cómo obtener un trabajo de ingeniería de software. Echa un vistazo a mi publicación anterior, Cómo pasé de novato a ingeniero de software en 9 meses para obtener más información al respecto.

¡Tenga en cuenta también que este es solo un punto de datos con respecto a mis experiencias con una compañía!

Recuerdo que cuando estaba buscando trabajo y absorbía una tonelada de materiales de lectura sobre la industria de la tecnología, la programación de aprendizaje y las historias de éxito, mi enfoque principal era descubrir cómo conseguir un trabajo. Pero siempre tuve un poco de curiosidad sobre cómo era una vez que realmente conseguías el trabajo. El propósito de esta publicación es tratar de responder algunas de esas preguntas.

¿Cómo fue el primer día, la primera semana y el primer mes? ¿Hay habilidades para aprender que podrían no ser útiles para la entrevista pero que lo serían una vez que comenzara a trabajar? Incluso si consigo un trabajo, ¿cómo sabré si podré hacerlo y hacerlo bien?

Fondo

Trabajo como ingeniero de software en una compañía llamada Human API en San Mateo, CA. Es una startup tecnológica de atención médica con ~ 35 empleados que se enfoca principalmente en el intercambio de datos de atención médica centrado en el usuario. Fui contratado como ingeniero de software centrado en el front-end, utilizando tecnologías como React, Redux y Sass.

Primer día

El primer día fue bastante surrealista. Había soñado con trabajar como ingeniero de software por un tiempo, y todavía se sentía como un sueño el primer día. Hubo una búsqueda del tesoro para romper el hielo para mí que implicaba hablar con todos en la oficina.

Me dieron un "Plan de éxito de nuevas contrataciones" que incluía cosas como:

  • Primer día: configure la computadora portátil, vaya al almuerzo de bienvenida
  • Semana 1: poder dibujar diagramas de cómo funcionan los productos, familiarizarse con la incorporación ágil y completa
  • Semana 2: cree algo utilizando nuestra API pública, corrija un error, agregue una mejora
  • Mes 1: comience a tomar posesión de mi parte del producto
  • Trimestre 1: tomar posesión de mi parte del producto

Pero principalmente, como era de esperar, el primer día implicó configurar mi computadora portátil con el entorno adecuado.

Primera semana

La primera semana fue más de lo mismo. Todavía tengo todas mis cuentas configuradas correctamente, terminando de leer los documentos incorporados, etc.

¡Se sintió tan extraño codificar durante el día en un día laborable! También todavía me estaba acostumbrando a las ventajas de inicio típicas del Área de la Bahía. Mi líder tecnológico seguía llamándome el "experto de React" porque me contrataron como la persona principal de ese equipo en particular. No estoy seguro de si eso es lo que él pensaba que era o si solo estaba tratando de poner el listón alto. En cualquier caso, traté de rodar con eso.

También estaba aprendiendo sobre el proceso ágil. Tuvimos reuniones diarias de 15 minutos para "ponerse de pie" donde todos se paraban y hablaban sobre en qué estaban trabajando, y si su trabajo era "bloqueado" por alguien.

Eso era algo de lo que estaba semi preocupado cuando me postulaba para un trabajo:

¿Es malo si no sé ágil, scrum, velocidad, incremento de producto, sprint, retro ...?

En mi opinión, no necesita saber qué significan esas cosas antes de comenzar su trabajo. Podría ser útil en una entrevista porque el entrevistador podría pensar inconscientemente que usted es más creíble si lo hace, pero en realidad, podría aprenderlo en menos de un día en el trabajo.

Primer mes

En este punto, estaba haciendo un desarrollo real y realmente contribuyendo al equipo. Estaba aprendiendo a trabajar con el diseñador, la gestión de productos y otros ingenieros de software. Empecé a trabajar desde casa en ocasiones, lo cual fue increíble. Descubrí que trabajar desde casa ocasionalmente me hacía mucho más productivo en general. A nadie parecía importarle cuando entrabas a la oficina o cuando te ibas, lo que era una gran diferencia con respecto a mi compañía anterior. También tuve MUCHO menos reuniones que en mi trabajo anterior.

No había usado Sass antes, así que vi algunos videos y leí algunos documentos. Es bastante similar a CSS, por lo que no fue un gran problema. El proyecto en el que estaba trabajando era bastante nuevo, por lo que no había un flujo de trabajo git estricto y estandarizado. Honestamente, en esa etapa del producto, era sorprendentemente similar a la forma en que desarrollaría mis proyectos de cartera. Había otra cosa por la que estaba semi preocupado ...

¿Sé lo suficiente git? ¿Qué pasa si hay un flujo de trabajo de git complicado y lo arruino todo?

Creo que es valioso adquirir algo de experiencia usando git en un equipo. Únase a una reunión local y haga un proyecto, vaya a un hackathon, contribuya al código abierto. Familiarícese con tirar, empujar, fusionar, rebase. Pasa por el dolor de lidiar con los conflictos de fusión. Lea un poco sobre las mejores prácticas para los flujos de trabajo de git.

Podrías aprender en el trabajo, pero serás mucho más efectivo si tienes experiencia con flujos de trabajo de git comunes.

Otra cosa con la que me topé mucho durante el primer mes fue tratar de averiguar qué debía hacer cuando me atascara. ¿Debería preguntarle a alguien o superarlo?

Una de las cosas que tenía muchas ganas de que me pagaran por el código era tener a otras personas que fueran más inteligentes y que supieran más que yo, para poder obtener ayuda cuando estuviera atascado.

Cuando estás aprendiendo por tu cuenta, no tienes ese lujo, y tienes que decidir si debes seguir golpeándote la cabeza contra la pared frente a ti o buscar una nueva pared para golpearte la cabeza.

Y luego me di cuenta ... enseñarme a mí mismo a codificar me dio una habilidad valiosa. Es una habilidad saber cuánto tiempo golpear tu cabeza contra la pared antes de seguir adelante, encontrar una solución o preguntarle a alguien más. Si siempre tuviera una sala de mentores para ayudarlo con cada problema, nunca se vería obligado a pasar por la dolorosa lucha de decidir qué hacer a continuación cuando esté atrapado.

Tu mentalidad NO debería ser ...

Wow, mira esto! ¡Tengo una sala de ingenieros de software que pueden ayudarme!

o esto…

Debería ser más como ...

Voy a hacer un esfuerzo activo para resolver esto por mi cuenta, y si necesito pedir ayuda, le diré a esa persona lo que intenté hacer que no funcionó.

6to mes

Por ahora, me he sentido cómodo con el código, mi equipo y la compañía en general. Hemos tenido un picnic de la compañía, un evento en una cervecería después del lanzamiento de un producto, una noche de juegos donde todos trajeron sus videojuegos favoritos para jugar, tuvimos el mundial jugando en la oficina y muchos más eventos sociales. También ha habido múltiples demostraciones de incrementos de productos estresantes.

Aprendí de muchas personas inteligentes, intenté ser vocal en la empresa, compartiendo mis opiniones sobre cómo creo que deberíamos hacer ciertas cosas. He estado al otro lado de las entrevistas técnicas, he estado involucrado con múltiples lanzamientos de productos. También comencé a involucrarme más con el backend, ya que eso es lo que más disfruto.

Estimar cuánto tiempo lleva agregar funciones / corregir errores es extremadamente difícil y parece que no estoy mejorando en eso.

Creo que la parte más difícil y desafiante (pero también divertida y gratificante) del trabajo es el diseño y la arquitectura. Cuando hay una característica para agregar, hay varias formas de hacerlo que aparecen instantáneamente en mi cabeza, pero descubrir la mejor manera de hacerlo dadas las limitaciones de tiempo es muy difícil.

A veces, ciertas funciones requieren muchas discusiones con muchas personas y otras veces solo tiene que tomar una decisión usted mismo, incluso si no puede pensar en una buena solución porque no vale la pena el tiempo. Luego miras tu código 3 meses después como:

Preguntas más frecuentes

En esta sección, he incluido preguntas frecuentes que pueden tener los principiantes.

He estado haciendo todo este esfuerzo para aprender a programar ... ¿Cómo sabré que me gustaría trabajar como ingeniero de software?

Si te gusta aprender a codificar, entonces creo que te gustará trabajar como ingeniero de software. Eso no significa que todos los trabajos de ingeniería de software sean geniales, o que los amará a todos. Incluso si obtienes un excelente trabajo de ingeniería de software, eso no significa que siempre te encantarán todos los aspectos.

Pero si te gusta construir cosas nuevas, refactorizar el código feo y finalmente corregir un error que te ha estado molestando por un tiempo, deberías ser bueno. Si disfrutas la lucha de aprender a codificar, entonces creo que la ingeniería de software es para ti.

Incluso si consigo un trabajo, ¿cómo puedo saber que podré hacerlo y hacerlo bien?

Por alguna razón, siempre pensé que había una gran diferencia entre alguien a quien le pagaban por el código y yo (alguien a quien no le pagaban por el código). Así que, naturalmente, esta pregunta se me ocurrió mucho.

Estoy de acuerdo con el consejo del cliché: "Si te contrataron, entonces estás listo para hacer el trabajo". Creo firmemente en dar un paso a la vez. Si no tiene trabajo, concéntrese en cómo conseguirlo. Una vez que obtenga un trabajo, puede concentrarse en hacer lo que necesita hacer para tener éxito en ese trabajo.

Si simultáneamente está preocupado por conseguir un trabajo Y su rendimiento hipotético en el trabajo hipotético, entonces agregará estrés y preocupación innecesarios a su vida.

¿Hay habilidades para aprender que podrían no ser útiles para la entrevista pero que lo serían una vez que comenzara a trabajar?

Reiteraré y diré que mi respuesta principal a esta pregunta es no preocuparse por su trabajo hipotético hasta que ya no sea hipotético.

Sin embargo, si no acepta un no por respuesta, le recomendaría lo que mencioné anteriormente. Intente trabajar en un proyecto con un equipo y elija un flujo de trabajo git de mejores prácticas.

Estoy seguro de que puedes encontrar muchos artículos al respecto si buscas en Google "flujos de trabajo comunes de git". No tengo muchos consejos adicionales aparte de las habilidades básicas. Intenta llevarte bien con tu equipo y con todos los miembros de la empresa desde el primer día.

¿Cuál es la principal diferencia entre construir un proyecto por su cuenta y trabajar en un equipo en una startup?

Realmente depende de qué tan maduro sea el producto en el que esté trabajando. La mayoría de las diferencias vienen con trabajar en un gran producto que será utilizado por mucha gente. Aquí hay algunas cosas que quizás no haya pensado al crear sus proyectos paralelos en lugar de trabajar en una aplicación de nivel de producción en una startup:

  • Seguridad: ciertamente no es algo de lo que deba preocuparse con sus propios proyectos paralelos si no lo desea. Cuando trabaja en un producto que utilizan muchas personas, la seguridad web es extremadamente importante. Escribí una introducción a la seguridad web que explica los conceptos básicos de seguridad web como CSP, HTTPS, CORS, etc.
  • Compatibilidad con el navegador: es posible que deba admitir versiones de IE, lo que significa que es posible que no pueda usar todos los sofisticados CSS más recientes y que pueda tener algunos problemas de JS. Con esto, viene la prueba entre navegadores, que es su propia bestia.
  • Análisis: puede utilizar algo como Google Analytics o Mixpanel para comprender la conversión y el uso del producto.
  • Pruebas: ciertamente no tiene que ocuparse de escribir pruebas en sus propios proyectos si no lo desea. Sin embargo, las pruebas son esenciales para escribir un buen código. Cuando aprende a codificar, cuanto más espere para comenzar a escribir exámenes, más difícil será convertirlo en un hábito.
  • Bloqueadores: puede confiar en que alguien cree algo antes de poder crear su característica. Por lo tanto, es posible que tenga que pensar en formas de evitar esto. Si eres un ingeniero frontend y la API aún no está lista, es posible que tengas que hacer una API simulada para que no te bloqueen el trabajo en la interfaz de usuario.
  • Mantenibilidad: sin duda, desea escribir un buen código para sus proyectos paralelos, pero lo que está en juego no es demasiado alto. Probablemente no lo mantendrás en un año a partir de ahora, entonces, ¿a quién le importa si no tiene comentarios y está en un archivo masivo, verdad? Cuando estás en un equipo, quieres una barrera baja para la contribución. Es decir, cuando una nueva persona se une, desea que pueda leer los documentos, ver el código y poder comenzar a contribuir rápidamente. Si el código es difícil de entender y leer, entonces no solo le tomará más tiempo a alguien hacer contribuciones, sino que también será más difícil agregar funciones sin agregar una cantidad considerable de deuda tecnológica.

Consejo de cierre

Como he dicho muchas veces, no creo que sea importante saber todo esto antes de obtener un trabajo de ingeniería de software. Creo que tiene valor saberlo, ya sea porque no sabes si te gustaría trabajar como ingeniero de software o si simplemente te gusta saber qué esperar.

Además, desafortunadamente, hay ciertos entrevistadores que le preguntarán algunas de estas cosas. Tal vez porque no saben nada mejor, tal vez porque están contratando para un puesto más alto. Es mi opinión que todas estas cosas se pueden aprender en el trabajo si tienes una base sólida.

¡Buena suerte!