Miguel Fernández, software engineer en Fastly

¡Hola Miguel! ¿Quien eres y a qué te dedicas actualmente?

Me llamo Miguel Fernández, tengo 36 años, y vivo en Gijón. Es este momento trabajo en Fastly como ingeniero de software, en un equipo que desarrolla y mantiene los sistemas de procesado y persistencia de datos.

¿Cómo fueron tus comienzos en el mundo de la programación?

A mí el contacto de la programación me llegó a través de un vecino que se llamaba Eloy, que era la persona que nos ayudaba cuando algo se estropeaba. Eloy había estudiado Ingeniería Informática Superior y recuerdo que de aquella programó un driver del ratón para MS-DOS y lo instaló en mi sistema. Yo ví cómo lo instalaba y lo rapidísimo que manejaba la consola, y con 14 años me pareció una cosa flipante. Ahí empezó a gestarse la idea en mi cabeza de dedicarme en el futuro a eso que me parecía programar.

Aunque flirteaba con Linux, y me manejaba bien con el ordenador, todavía no sabía programar cuando empecé la carrera de ingeniería técnica, y de hecho tardé en cogerlo. A mí lo que se me daban bien de aquella eran las mates. El primer año aprobé asignaturas que se suponen que eran muy difíciles como Cálculo o Métodos numéricos, pero suspendí introducción a la programación en Junio. Recuerdo que no me entraba en la cabeza la estructura básica de los programas, y tenía dificultades con la sintaxis. Durante el verano me apliqué un poco más pero tampoco aprobé. 

Recuerdo haberme frustrado tanto, que comentaba con algunos de mis amigos que estaba pensando en dejar la carrera y hacerme un curso de palista, que en 2002, con el auge de la construcción, era una profesión muy boyante. Por alguna suerte de destino, no llevé a cabo ese plan, y me matriculé en las de programación que había suspendido y en todas las de segundo. No recuerdo cuál fue la causa, pero al año siguiente al volver a las clases todo me hizo “click”, y a partir de ahí empecé a sacar sobresalientes y matrículas y el resto de mis estudios, aunque requirieron esfuerzo, me resultaron fáciles de entender.

El segundo año de carrera, me ofrecieron hacer unas prácticas en lne.es y ahí hice mi primer programa profesional. Una aplicación para gestionar las galerías de fotos del periódico. 

¿Qué es lo que más te motiva y te divierte de tu trabajo?

Yo no considero mi trabajo divertido, es un trabajo que paga facturas, y que es interesante en el sentido de presentarse problemas complejos, que te permiten aprender en el camino hasta encontrar su solución, pero no considero que sea una actividad lúdica la mayor parte del tiempo. 

Lo que hago es un trabajo complejo, requiere atención al detalle, exhaustividad, y habilidades de análisis, comunicación y negociación. En mi trabajo se invierte mucho tiempo en iterar sobre soluciones, en ponerse de acuerdo con otros equipos para que las piezas que componen la solución encajen correctamente, porque al final, detrás del producto que hacemos hay 300 ingenieros e ingenieras desarrollando cada una de sus partes, con objetivos e incentivos diferentes. Por así decirlo, programar es la parte menos difícil de mi trabajo.

Si tuvieras que trabajar con un único lenguaje de programación durante el resto de tu carrera, ¿cuál sería y porqué?

No podría elegir, porque las características del lenguaje hacen que sean más adecuado para un tipo de problemas que otros, y no quiero enfrentarme toda la vida al mismo tipo de problemas.

Si tuviera que quedarme con uno que me hiciese a mí la vida más fácil a mí, elegiría uno con pocas primitivas del lenguaje, chequeo estático de tipos,  gestión de memoria automática, una buena librería estándar, un buen ecosistema de tooling y una buena comunidad alrededor :-)  

¿Cómo es para tí un buen día de trabajo?

Empiezo el día viendo dónde lo dejé el día anterior, y que puedo hacer. Idealmente tendría que terminar un parche de código que solucionar algún problema, sería complicado pero según fuera marchando el día, la solución iría cogiendo forma. Al final del día habría hecho progresos y habría discutido con mis compañeros el enfoque, incorporando cualquier idea de mejora. ¡Eso para mí es un día de trabajo ideal!

¿Cual es tu proceso a la hora de enfrentarte a una nueva feature o bug?

Depende mucho de lo que haya que hacer. El approach es diferente al abordar una feature o un bug. Algo que hago habitualmente es refactorizar sistemas para mejorar su performance, cambiando una parte del sistema por otro.

Primero hago un análisis durante unos días si no tengo familiaridad con el código, busco cuales son los hot points, qué código tiene mayor churn, cuál es el más complejo… para tener una idea de qué partes del código son más delicadas, bien porque cambian mucho o porque el código sea inherentemente complejo. También miro si está bien cubierto a través de tests.

Una vez entiendo bien el código decido que hacer para preparar mejor el cambio. Si la cobertura del código no es suficiente, invierto tiempo en escribir nuevos tests que me den confianza.

Una vez tengo confianza en los tests, intento romper el trabajo en tareas más pequeñas para desarrollar de forma incremental. Esto no es siempre es posible. Algunos cambios son atómicos, como cuando haces un upgrade de una una librería.

Yo siempre intento trabajar en incrementos pequeños, y pedir feedback cuanto antes, aunque sepa que el código tiene ciertas carencias. Así puedo anticiparme y entender cuales son las expectativas de la gente que va a hacer la review, especialmente de aquellos con más experiencia en el sistema, o miembros de otros equipos con los que puedan interferir los cambios y que pueden identificar aspectos que pueden ser delicados.

En resúmen: análisis y conocimiento del sistema, preparación para hacer el cambio, implementación y feedback.

¿Cual es el problema más complejo al que te has enfrentado y del que te sientas particularmente orgulloso?

Me suelo olvidar rápido de los logros técnicos. Si tuviera que nombrar alguno en particular, probablemente sería alguna optimización de rendimiento que fuese crítica porque estuviese apretando mucho la capacidad de algunos de los clusters de servidores en GitHub.

Pero, generalmente, los problemas que más me cuesta navegar normalmente tienen que ver con hacer una propuesta para un proyecto transversal a varios verticales y que requiere involucrar a varios equipos. Tu haces una propuesta y, de repente, tienes a 100 personas dándote feedback, muchas veces crítico pero acertado, y otras veces no tan acertado por miedo o por resistencias al cambio. A pesar de que me manejo bien argumentando, a veces surgen comentarios y conversaciones espontáneas que tienes que responder para persuadir de que tu opción es buena, sin que la otra persona lo vea como una amenaza, al mismo tiempo que eres receptivo al feedback.

¿Qué fue lo que te motivó a dar el salto a trabajar para empresas americanas como GitHub y Fastly?

Hubo varios factores que motivaron a dar ese salto.

La escena tecnológica en Estados Unidos, y en Silicon Valley en particular, es un entorno muy competitivo e innovador. Esto hace que emerjan problemas tecnológicos y de negocio muy atractivos para mí. 

Es el caso por ejemplo de Fastly, que está haciendo un producto que utilizo y que me gusta como usuario, y que al mismo tiempo tiene una complejidad notable a nivel de ingeniería. La curiosidad por entender cómo se construye algo así me mantiene motivado y satisfecho en el día a día.

Otro factor importante es la compensación: en términos económicos, pero también en términos de autonomía y confianza para la toma de decisiones, dos aspectos que influyen notablemente en mi calidad de vida.

Por último, este tipo de empresas cuentan con equipos de ingeniería de entre 500-2000 personas, con una variedad increíble de problemas a resolver y la posibilidad de moverte dentro de la propia empresa si quieres aprender cosas nuevas.

¿Cómo encontraste tu primer trabajo para una empresa americana?

El salto vino cuando empecé a trabajar para GitHub. Entré a echar un vistazo en su página de ofertas de trabajo, vi que necesitaban un ingeniero de plataforma  y los requisitos de la posición encajaban parcialmente con mi experiencia y habilidades (otros no, pero sabía que podría llegar a adquirir las que me faltaban). Pensé que podría serles útil, y presenté mi candidatura enviando mi curriculum, una carta de presentación y las respuestas a un cuestionario técnico.

Durante las entrevistas, me sorprendió mucho la dimensión humana de los entrevistadores. Los entrevistadores puñeteros y que van a pillar, son ajenos a mi experiencia. Estoy acostumbrado a entrevistas empáticas, que buscan que el candidato se desarrolle lo mejor posible, entrevistas dedicadas a hacer benchmarking en términos de comunicación, diversidad e inclusión, etc. Me pareció que, en general, se buscaban el tipo de perfiles con los que a mí mismo me gustaría trabajar, y esto fué bastante satisfactorio para mí (lo cual no implica que fuese fácil y no hubiese cierta tensión). Tuve la suerte de que fué bien y me contrataron.

En realidad, y visto con perspectiva,  el “salto” fue gradual: empecé a trabajar en un sitio en el que me permiten trabajar en remoto, de ahí empecé a desarrollar el hábito de trabajar de manera más autónoma (aunque no fuese muy distribuido geográficamente), y desde ahí empecé a adquirir habilidades que me permitieron trabajar luego en una empresa americana. Ya tenía mucho camino hecho.

¿Qué diferencias encuentras entre las empresas españolas y las americanas para las que has trabajado?

Una diferencia muy fundamental, en mi experiencia, es el grado de autonomía, libertad, y ausencia total de micro-management. Esto ya lo había vivido antes en BeBanjo. Cosas como tener un jefe que esté micro gestionando, pendiente de cuando entras y cuando sales, pendiente de tu punch card de commits en GitHub, o cosas así, no ocurren en las empresas americanas para las que he trabajado. Tu tienes un objetivo y no tienes a nadie con un látigo encima.

Tu empresa considera que no te está haciendo un favor por darte trabajo. Es una relación contractual bidireccional, en la cual tu ofreces un servicio a cambio de una compensación. En ese sentido, el contrato en sí no te da derecho como empresa exigirle al trabajador nada que no sea razonable como estar todo el día pensando en el trabajo y no tener una vida fuera de este.

Esta diferencia es más notable a medida que vamos teniendo más edad. Por lo general, con veintipico años, las motivaciones suelen ser más egocéntricas. ¿Cómo puedo tener un impacto a través de mi esfuerzo?, en lugar de ¿Donde puedo ser útil?. En ese ímpetu de destaque personal, creo que el trabajo adquiere una relevancia mucho mayor que cuando eres más mayor y tienes una familia, o eres más consciente de que tu vida no es sólo tu trabajo. Eso creo que es algo que está, al menos en las empresas americanas en las que he trabajo, muy implícito en el trabajo.

¿Se cumple entonces eso de “work hard play hard”?

A mí me gusta más la frase “Work smarter, not harder”. Me parece más alineada con las filosofías con este tipo de empresas. “Work hard play hard” me parece un concepto nocivo.

A la hora de abordar los problemas, abordarlos desde la tranquilidad cuando sea posible y necesario, y no de manera impulsiva. Una reacción muy típica de la gente que está empezando y entra en un sitio nuevo es que muchas cosas les parecen que están mal y hay que rehacerlas. Todos sabemos cual es el ideal, y hemos leído libros de Robert. C. Martin, pero si un código es super estable, no hay cambios en los requerimientos, y los cambios son únicamente cosméticos, el esfuerzo no merece la pena. Dedicar tiempo a eso sería “work hard” pero no “work smart” porque no estás haciendo una evaluación de los costes de oportunidad y tomando una decisión que permita dedicar ese esfuerzo a hacer otras cosas que pueden impactar de forma más positiva en el producto, el equipo, la organización o los usuarios.

¿Qué es lo que más valoras tú a la hora de elegir una nueva empresa?

Da igual lo que te paguen, la libertad que tengas, si tienes que trabajar con gente que es gilipollas. Todo lo que expliqué antes, se basa en una premisa que se cumple en el tipo de empresas que me motivan, y que se ven claramente en la forma en que redactan la oferta de trabajo. El nivel de “vaporware” en estas empresas es bajo. Son ofertas honestas, que no tratan de venderte que es el mejor trabajo del mundo y te lo vas a pasar chupi trabajando, por que el trabajo es trabajo, no una actividad lúdica como dije antes. Ahí en mi cabeza ya se va gestando lo que hay detrás a nivel de personalidades, y esto se suele corroborar durante las entrevistas.

Por ejemplo, en Fastly hice varias entrevistas técnicas, pero en ninguna escribí código. Fueron más conversaciones de cómo enfocaría un problema, o cuáles eran mis opiniones acerca de determinados temas. Fue más un intercambio de opiniones en el que se me estaba evaluando, pero sin ponerme en situaciones de desequilibrio para ver cómo reaccionaba. Te puedes llevar sorpresas, pero en ese proceso ya ves cómo es la gente, cómo se relacionan, cómo es su estilo comunicativo. En general, mi sensación fue que era gente tranquila y sensata.

Muchas empresas, a la hora de “venderse” para atraer candidatos, utilizan como argumento el impacto del trabajo, como si esa misión tecnológica fuese más importante que la gente que cohabita en la organización, o que la compensación que obtienes por tu trabajo (no sólo a nivel salarial, sino en términos de autonomía, libertad, etc.).

Trabajar con gente tranquila, humilde y honesta es para mí un factor importantísimo. Y que eso sea real, no una proyección para atraer talento. 

¿Qué consejos le darías a alguien que se esté planteando trabajar en remoto para empresas de fuera?

Que no se amedrenten ante el reto porque no hay nada intrínseco a este tipo de trabajos que haga que sean para unos pocos elegidos

Que hagan un análisis realista sobre si cumplen los requisitos para trabajar en remoto en una empresa de fuera y que en mi opinión no son mucho más que: proactividad, capacidad para trabajar con mínima supervisión, para proveer a sus compañeros de contexto, de predecibilidad (la base para la confianza), saber comunicarse en el idioma de trabajo de forma respetuosa, clara y concisa, y tener las herramientas conceptuales básicas para resolver problemas técnicos de su puesto concreto. 

Que si no cumplen alguno de ellos, tracen y ejecuten un plan para conseguirlos, pidiendo ayuda a gente con experiencia. Al final, todas estas habilidades se pueden cultivar con tiempo y esfuerzo! 

Y como no, que lo intenten. Que elijan un grupo pequeño de empresas, que las investiguen, y dediquen tiempo a escribir una carta de presentación honesta y bien redactada, y que la envíen. Una vez intentado, que perseveren, aunque les digan que no varias veces. 

Por último, en el momento en el que lo consigan y lleguen a una negociación de las condiciones, que no sean excesivamente ambiciosos, pero que tampoco acepten una reducción notable de salario respecto a sus compañeros por el hecho de vivir en España, porque al hacerlo estarían devaluando su trabajo, y el de muchas otras personas que vivan en otros territorios fuera de Silicon Valley.

¿Qué es lo que te ha ayudado a convertirte en el profesional que eres hoy?

Pues una cadena de fortunas, que comienza con pensar que se puede aprender algo de todo el mundo. A partir de ahí, hacer preguntas, y ser honesto y curioso, observando la forma en la que distintas personas perciben lo que es ser profesional, y entendiendo sus motivaciones y sus prácticas, y de forma natural, aprendiendo de ellas.

Me gusta usar como motivación “querer hacer las cosas bien”, y eso, que no depende de muchos factores externos, me ha funcionando como filosofía de trabajo. Ha habido temporadas en el pasado, que el aprendizaje me obsesionaba y estudiaba un montón, pero no tengo la sensación de que esa obsesión me haya ayudado a ser un mejor profesional, sino todo lo contrario. 

Ahora, mi fuente principal de aprendizaje es el trabajo en sí. Como parte del mismo también estudio. Leo papers, y libros, pero con estos últimos soy bastante selectivo: suelo leer capítulos específicos, de libros publicados por autoras y autores con experiencia profesional o académica en aquello que versa el libro. Rara vez leo libros from cover to cover, a no ser que sea una lectura que además de enseñarme algo, sea muy entretenida.

También creo que me ha ayudado hablar sólo de lo que creo que sé, y no intentar dar la impresión de que soy muy bueno en nada. En general, no tengo muchas opiniones fuertes, y eso es algo que creo que es positivo, porque no genera resistencia a cambiar de ideas cuando existe evidencia de que las anteriores ya no son útiles o relevantes.

Por último, los privilegios y la suerte (entendiendo ésta como la ocurrencia de un fenómeno poco probable) también juegan un papel importante. Por ejemplo, hace 8 años ya conocía a gente que trabajaba en remoto, y hacerlo me facilitó poder volver a Asturias y trabajar para una empresa que me gustara como fue BeBanjo, y de ahí saltar a una experiencia de trabajo remoto más compleja, como la que fue GitHub, y en todas estas experiencias aprendí un montón, ¡y también a caerme! ya que cuando dejé GitHub, tuve que parar un tiempo para recuperarme de unos niveles de exigencia poco saludables, y a los que no voy a volver a exponerme.

¿Qué te gusta hacer cuando no estás delante de la pantalla?

Me gustan mucho las actividades al aire libre. Tengo una furgoneta camper, y me gusta mucho viajar con ella, o dormir un día en ella durante la semana y levantarme en un sitio que no es habitual.

Me gusta sentir que tengo tiempo libre, a pesar de ser un día entre semana, y a pesar de no ser un periodo muy prolongado. Disfruto mucho esa sensación de poder meter interrupciones de este tipo durante la semana, en vez de tener que esperar al fin de semana. Ir con la furgo, surfear, patinar, pasear a mi perra, ir a tomar cañas con los amigos, ir al cine, cocinar…

¿Cómo te ves dentro de 5 años?

Mi intuición es que seguiré haciendo algo bastante parecido a lo que hago ahora: resolver problemas con una fuerte componente técnica, en el área de backend, y en una empresa de tamaño mediano.

¿Cómo y dónde podemos contactar contigo?

Ya no tengo twitter, ni web. Podéis enviarme un email a hola@mff.io.

Muchas gracias Miguel 🙇‍♂️

Otras entrevistas interesantes

¿Quieres más? ¡Aquí tienes más entrevistas que te podrían interesar!

Vanessa Medina, FrontEnd Software Engineer en eDreams y co-fundadora de FrontFest

Escribió sus primeros GOTOs en un Amstrad CPC464. Comenzó siendo sysadmin, hasta que descubrió el desarrollo frontend. Trabaja en eDreams, organiza FrontFest, da charlas...

Oriol Barcelona, software engineer en Dynatrace

Escribió su primer programa antes de los 15 años y le apasiona su profesión. En Dynatrace, lidera un equipo de 4 personas, encargado de construir una UI para sus sistemas de persistencia.

Manuel Montenegro, software engineer en Personio

Manolo es Malagueño. Descubrió la programación en quinto de primaria. Hoy, su trabajo ayuda a que los empleados de los clientes de Personio cobren las nóminas a final de mes.
Suscribirme

¡Suscríbete!

Más de 900 desarrolladores/as reciben ya nuestras ofertas y contenidos para estar al día de cómo está el mercado y aprender de los mejores profesionales. Y tú, ¿te lo vas a perder?

¿Qué quieres que te enviemos?