La tecnologeda me ha apasionado toda mi vida. Empecé con Turbo Pascal cuando era niño y, desde entonces, he trabajado con sistemas embebidos, desarrollo front-end/back-end y proyectos de machine learning.
iOS/macOS entró en escena durante un breve curso universitario. En un mes, había aprendido un nuevo lenguaje y conseguido unas prácticas en Readdle. Cinco años después, me convertí en Principal Engineer. Aun así, sigo guiando a nuevos compañeros de equipo, participando en entrevistas y desarrollando habilidades de liderazgo para seguir creciendo.
Mi camino, desde no tener ninguna experiencia con las plataformas de Apple hasta llegar a mi puesto actual, me inspiró a reflexionar sobre mi enfoque de aprendizaje y a describir las direcciones clave que me ayudaron a crecer. Creo que mi experiencia puede ser valiosa para otros ingenieros que se sienten estancados o inseguros sobre sus próximos pasos.
Estos son los enfoques y recursos clave que me ayudaron, y que también podrían ayudarte a ti.
Cómo los proyectos paralelos aceleraron mi crecimiento
Después de alcanzar el nivel intermedio, llegué a una meseta profesional. Sentía que completaba tareas de forma rápida y eficiente, corregía errores sin problemas y tenía una comprensión sólida de cómo diseñar la arquitectura de nuevas funcionalidades. Pero no terminaba de entender que9 me separaba de ser un verdadero Senior Engineer.
El cambio se produjo gradualmente. Mirando atre1s, me di cuenta de que la diferencia no estaba en un gran proyecto en el trabajo ni en un ascenso. Fue todo el tiempo que había pasado programando fuera del trabajo.
Por las noches y los fines de semana, construía pequeños proyectos, a veces solo por diversión y otras para poner a prueba una idea. Estos proyectos paralelos me expusieron a problemas reales fuera de mi ámbito habitual. Esa experiencia práctica se trasladó directamente a mi trabajo y me dio una ventaja a la hora de abordar problemas desconocidos.
La mayor leccif3n fue que la mayoreda de las habilidades en el desarrollo de software no este1n ligadas a un fanico lenguaje o plataforma. Algunos ejemplos:
- Incluso si este1s leyendo sobre arquitectura de aplicaciones para iOS/macOS, probablemente reconocere1s patrones similares en el desarrollo web o en los sistemas embebidos.
- Conocimientos de Python en el contexto del machine learning pueden ayudarte a escribir rápidamente el script necesario para automatizar procesos de CI en un dominio completamente distinto.
- Los fundamentos de los sistemas operativos te ayudarán a comprender clases enteras de problemas en cualquier lenguaje de programación. Al fin y al cabo, cualquier programa, independientemente del lenguaje, interactúa en última instancia con el sistema operativo de manera similar.
- Uno de los primeros libros que leed fue Effective Java—un lenguaje que no he usado en af1os. Pero ese libro me enseñó principios orientados a objetos que se aplican en todos los ámbitos. Ese es el tipo de conocimiento que perdura.
- Si disfrutas programando, estos proyectos paralelos no se sentire1n como trabajo. Según mi experiencia, los mejores ingenieros son quienes programan porque les encanta crear y aprender.
Formas de aprender cualquier cosa
Algunas personas parecen aprender más rápido que otras. Puede ser un nuevo lenguaje de programación, un patrón, una arquitectura o incluso algo completamente ajeno al desarrollo, como aprender a jugar al ajedrez. Creo que eso se debe a que aprender en sed mismo es una habilidad—una metahabilidad que puedes practicar.
Al reflexionar sobre mi propio camino de aprendizaje, noté patrones recurrentes en la forma de abordar temas nuevos. Creo que esto viene de mi etapa en la escuela y la universidad, donde compaginar múltiples disciplinas llevó a mi cerebro a optimizar patrones similares. Eso me permitió aprender más rápido.
Ahora tengo un proceso específico para aprender algo nuevo. No creo que este proceso sea revolucionario, pero me ha permitido mantenerme enfocado y ser intencional tanto en el aprendizaje como en mi crecimiento personal. En esta seccif3n, te explicare9 las tres etapas de mi enfoque de aprendizaje: Filtrado, Estructuracif3n y Pre1ctica.
Filtrado
Una buena fuente de información es un primer paso crucial al aprender una nueva habilidad. Aquí tienes algunas recomendaciones basadas en mi experiencia:
- La mayor parte de la información sobre cualquier tema está disponible gratis. Rara vez hace falta pagar por cursos o conferencias, a menos que este9s completamente seguro de que el contenido es fanico. Pero si este1s empezando, todaveda no tendre1s la experiencia necesaria para distinguir entre ideas realmente valiosas y material de baja calidad.
- Los recursos en texto suelen ser me1s concisos y me1s fe1ciles de asimilar que los veddeos, especialmente si lees re1pido. Con el tiempo, aprended a hojear re1pidamente y filtrar la informacif3n irrelevante, algo que resulta me1s difedcil con el contenido en veddeo.
- Con el tiempo, desarrolle9 la capacidad de hojear y filtrar la informacif3n irrelevante, algo que no es posible con los materiales en veddeo porque su consumo es lineal y lleva tiempo. Tambie9n es me1s fe1cil guardar un marcador o copiar un fragmento en el texto que buscar el momento adecuado en el veddeo.
- Los recursos en inglés son mucho más fáciles de encontrar que los recursos en otros idiomas, especialmente cuando se trata de programación y tecnología. a1Por lo tanto, poder leer y entender ingle9s con rapidez es imprescindible!
- No te saltes los cle1sicos. Los libros recomendados repetidamente (como Clean Code o Design Patterns) a menudo siguen siendo el mejor material disponible.
- También recomiendo crear tu propia biblioteca personal de libros sobre distintos temas. Ased, siempre tendre1s a mano material fiable. Personalmente, mantengo una carpeta sencilla en mi ordenador.
Estructuración
Una vez que he reunido algunas fuentes sf3lidas, estructuro la informacif3n. Este proceso incluye:
- Procesar las fuentes. Mientras leo un libro o un artículo, destaco los puntos clave con marcadores o los copio en mis notas para consultarlos en el futuro.
- Contrastar la información. Especialmente cuando el tema es subjetivo, es muy importante comparar varias soluciones y perspectivas. La información que coincide en varias fuentes diferentes probablemente sea cierta. Cuando las fuentes se contradicen, normalmente pospongo la decisif3n hasta haber adquirido me1s experiencia personal con el tema. Más adelante, con una comprensión más profunda, puedo elegir el mejor enfoque.
- Centralizar el conocimiento. Para analizar toda la información recibida y encontrada, es necesario almacenarla en un solo lugar. Uso Obsidian para centralizar mi conocimiento. Es gratis, y el formato markdown me resulta muy pre1ctico.
- Almacenamiento. Normalmente guardo artículos y enlaces útiles en listas sencillas de markdown. Esto me ayuda a encontrar rápidamente un recurso específico sin rebuscar en el historial del navegador. Además, si vuelvo al tema en el futuro, ya tengo una buena base guardada.
Práctica
Leer no basta. Solo aprendes de verdad cuando construyes algo. Intento reforzar cada tema que estudio creando pequeños proyectos. Cuando se trata de programación, esto suele significar crear una aplicación sencilla que demuestre mi capacidad para aplicar las habilidades necesarias. La práctica rápida también revela de inmediato cualquier laguna de comprensión. A menudo pensaba que entendía todo lo que necesitaba, solo para encontrarme con problemas inesperados apenas 10 minutos después de empezar la implementación.
Un ejemplo que me viene a la mente es aprender arquitecturas de UI. Cuando estudié MVVM por primera vez en el contexto del desarrollo para iOS, pensé que la arquitectura era simple y directa. Pero cuando intenté crear una aplicación básica de lista de tareas, de inmediato me encontré con una laguna de conocimiento. Los recursos explicaban cf3mo la View se comunica con la ViewModel y cf3mo la ViewModel interactfaa con el Model, pero ninguno abordaba quie9n debeda crear que9 y cf3mo. a1
Mi aplicación tenía una tabla que mostraba las tareas pendientes actuales. ¿Debía crear una ViewModel independiente para cada tarea? ¿O una sola ViewModel para toda la tabla? ¿Y qué pasaba si necesitaba ambas ViewModel? ¿Quién crea cuál? Estas preguntas me abrieron la puerta a comprender cómo coordinar componentes en arquitecturas similares.
Más tarde, mientras trabajaba en PDF Expert, nuestro equipo decidió probar a implementar MVVM. Pude construir la arquitectura y ayudar a liderar al equipo durante el desarrollo de esa funcionalidad. Ese es el tipo de experiencia que no habreda adquirido si antes no hubiera creado por mi cuenta aquella pequef1a y caf3tica app de tareas pendientes.
Mis recomendaciones para proyectos paralelos
- Encuentra inspiración y una idea. La idea suele surgir primero, y después la vinculo a un objetivo concreto de aprendizaje. La idea no tiene que ser fanica ni especialmente fatil, porque el propf3sito principal es ganar experiencia. Por ejemplo, podría decidir crear una app para hacer seguimiento de hábitos. A partir de ahí, puedo elegir centrarme en la arquitectura o usar esta idea para diseñar una UI llamativa con animaciones. ¿O quizá necesito crear un servidor para esta app? Eso podría ser una gran oportunidad para probar nuevas tecnologías backend.
- Define qué significa “terminado”. Si intentas llevar todos los proyectos a producción, tendrás que dedicar mucho tiempo a cada uno. Por lo tanto, creo que necesitas definir los hitos que quieres alcanzar con cada proyecto.
- Lo perfecto es enemigo de lo bueno. Si te obsesionas demasiado con encontrar la solución “perfecta”, puede que pierdas la motivación por completo.
- Minimiza las tareas innecesarias. ¿Importa realmente la paleta de colores exacta en una app destinada a enseñarte arquitectura? ¿O el sistema de registro? Los proyectos más valiosos fueron aquellos centrados en un único objetivo de aprendizaje. Cuanto menos tiempo dedico a detalles de baja prioridad, más puedo invertir en lo que de verdad importa.
10 temas que cambiaron mi forma de desarrollar software
Estas son 10 áreas que exploré por mi cuenta y que impactaron en mi carrera.
Arquitecturas de aplicaciones UI
Cualquier ingeniero que haya trabajado en proyectos basados en UI conoce los patrones cle1sicos de organizacif3n del cf3digo. bfQuie9n no ha oeddo hablar de MVC, MVP o MVVM? Según mi experiencia, un conocimiento teórico simple puede darte la confianza para empezar un proyecto nuevo, pero sin experiencia práctica, a menudo se viene abajo ante el primer signo de complejidad.
En otro tiempo pense9 que entendeda por completo cf3mo funciona MVVM, pero no teneda la experiencia necesaria para probarlo. Me di cuenta de esto cuando intenté desarrollar una pequeña aplicación con MVVM. Quedó claro que necesitaba coordinators y routers para navegar y ensamblar aquella mezcolanza de clases en una estructura coherente. Esa experiencia me ensef1f3 una leccif3n clave: no existe una arquitectura universal que sirva para todo. Una arquitectura que funciona bien en un proyecto (o incluso en una sola pantalla) puede encajar mal en otro contexto.
Patrones de diseño
Cualquiera que haya pasado por entrevistas para desarrolladores probablemente se haya encontrado con preguntas sobre patrones de disef1o. Muchos ingenieros parecen reconocer ciertos patrones en teoría, pero tienen dificultades para aplicarlos en la práctica. The forma me1s sencilla de cerrar esa brecha es crear un pequef1o proyecto centrado en implementar un patrf3n especedfico.
El libro original suele usar un editor de texto como ejemplo. Según mi experiencia, los editores de distintos tipos de documentos requieren el uso de muchos patrones de diseño. Puede ser un editor de texto, un editor de imágenes o incluso un programa de diagramación.
Pruebas
Las pruebas de código son una piedra angular de las bases de código estables. Y aunque la idea parece simple – “¡simplemente escribe pruebas!” –, escribir pruebas útiles a menudo dista mucho de ser trivial.
El principal desafío es que mantener las pruebas consume recursos del equipo. Si tienes que reescribir las pruebas después de cada refactorización del código, el valor general de esas pruebas se vuelve cuestionable. Este concepto se conoce como Test Fragility y, según mi experiencia, no es tan conocido como debería. Puedes aprender sobre la teoría del testing, por ejemplo, en este libro.
Un fuerte enfoque en el testing también afecta a la calidad del código. En general, el código escrito pensando en las pruebas será más modular y expondrá una API más limpia y sencilla. Es fe1cil probar las pruebas en la pre1ctica – basta con integrar tests en un proyecto existente o empezar uno nuevo con el foco puesto en escribir pruebas.
Algoritmos y estructuras de datos
Conocer algoritmos no es un requisito estricto en el desarrollo de software moderno. Muchas empresas siguen incluyendo retos algorítmicos en sus entrevistas, aunque esas habilidades quizá no sean necesarias en el trabajo del día a día. Aun ased, creo que merece la pena invertir tiempo en aprender algoritmos porque es divertido e interesante. Además, hoy puedes explorar estos temas de forma interactiva a través de plataformas como LeetCode.
Si alguna vez tienes la oportunidad de participar en concursos de programación algorítmica como ACM ICPC, te recomiendo mucho intentarlo. Aunque al principio este conocimiento no parezca directamente fatil, las te9cnicas de optimizacif3n de cf3digo pueden aplicarse a cualquier proyecto, y participar en una competicif3n por equipos es una experiencia que probablemente recordare1s con carif1o.
Multihilo
El multithreading es un tema fascinante. Puedes pasarte años escribiendo código sin entender siquiera los conceptos básicos. Todo desarrollador sabe que bloquear el hilo principal congelará la app. Pero, si algo sale mal, solo los desarrolladores que realmente entienden el código multihilo y pueden visualizar la línea temporal completa de los eventos pueden diagnosticar esos errores escurridizos, casi fantasma.
En mi opinión, entender las primitivas de sincronización, los hilos y las consecuencias de ignorar estos conceptos es uno de los factores clave que separan a un desarrollador de nivel medio de uno senior. Para entender los conceptos básicos, recomiendo el libro gratuito The Little Book of Semaphores.
Para adquirir experiencia práctica, puedes intentar escribir un programa que realice un procesamiento intensivo en segundo plano y sincronice los resultados con la UI, especialmente si el propio trabajo en segundo plano implica múltiples hilos. Simular procesos físicos puede ser un gran punto de partida para este tipo de proyecto.
Programación gráfica
Los procesadores gráficos son una de las pocas partes de un ordenador con las que la mayoría de los desarrolladores rara vez tiene que interactuar directamente. En la mayoreda de las aplicaciones, el renderizado de la UI ocurre en la CPU o queda abstraeddo del dispositivo GPU real, ased que ni siquiera necesitas pensar en ello. Pero una vez que el nfamero de elementos en pantalla crece lo suficiente y las abstracciones de alto nivel no pueden seguir el ritmo de fotogramas requerido, necesitas profundizar me1s. Entender los problemas que las GPU están diseñadas para resolver, así como la capacidad de “explicarles” qué debe renderizarse, puede ayudarte a identificar rápidamente soluciones en situaciones similares.
Un proyecto clásico para aprender programación gráfica es crear un motor de juego. Si te encantan los videojuegos como a med, probablemente te hayas preguntado cf3mo se programan. Hay muchísimos recursos en internet para aprender Metal, DirectX, OpenGL o Vulkan. Eso sed, no esperes que tu proyecto se convierta en el prf3ximo Unreal Engine. Pero si logras llegar al punto de haber creado un pequef1o juego que funcione sobre tu propio motor, te garantizo que te encontrare1s con desafedos fascinantes y adquirire1s conocimientos valiosos.
Programación embebida
Cuando supe por primera vez que incluso los dispositivos electrónicos más pequeños que nos rodean ejecutan sus propios programas y procesadores, me fascinó de inmediato y quise intentar construir algo parecido. Sin embargo, desarrollar para microprocesadores conlleva muchas limitaciones. Estos sistemas suelen tener menos de 128 kilobytes de memoria, y la asignación dinámica de memoria normalmente ni siquiera es una opción.
Escribir y depurar código embebido presenta muchos desafíos. Pero, como resultado, puedes ver cómo tu código cobra vida en el mundo real. Incluso conseguir que un simple LED parpadeara se sintió como un gran avance para mí. Entender cómo funcionan los microcontroladores es un primer paso importante para comprender cómo funcionan las CPU y los sistemas operativos modernos. Al trabajar con dispositivos embebidos, puede que incluso necesites adentrarte en lenguaje ensamblador especedfico de la plataforma (normalmente ARM).
Hoy en deda, empezar con el desarrollo embebido es me1s fe1cil que nunca. Los microcontroladores asequibles, como la línea STM32, son un gran punto de partida, y muchas placas listas para usar vienen con programadores integrados que se conectan por USB. Las posibilidades son infinitas, desde iluminación dinámica para habitaciones hasta crear tu propio hub IoT para el hogar inteligente.
Desensamblador
A veces, poder mirar un nivel más abajo en tu código puede ser invaluable. Por ejemplo, en el desarrollo para plataformas de Apple, a menudo trabajamos con bibliotecas de Apple mayormente de código cerrado. Cuando algo no se comporta como se esperaba, normalmente es necesario enviar un informe a trave9s de Feedback Assistant y esperar (a veces durante af1os!) una respuesta. Pero con la ayuda de un desensamblador, a menudo puedes mirar bajo el capó y entender cómo funciona realmente el código cerrado.
Entender el código ensamblador de tu propio programa también puede ser útil, especialmente en el contexto de la optimización. Solo inspeccionando el código compilado puedes saber realmente qué está haciendo tu código. Personalmente, para este propósito uso Hopper Disassembler en macOS.
Compiladores
El mundo de la programación tiene sus propios “clubes secretos”. Si pensamos en las personas cuyos productos impactan a más ingenieros, inevitablemente llegamos a quienes construyen los compiladores detrás de nuestros lenguajes de programación favoritos. Hasta que dediqué tiempo a estudiar compiladores por mí mismo, estos programas me parecían pura magia. Pero incluso al aprender lo be1sico, esa niebla me1gica afan no te permite comprender por completo la brillantez de quienes han creado lenguajes de programacif3n enteros.
La buena noticia es que hay muchísimos recursos y libros disponibles sobre el tema. Dos de mis favoritos son Engineering a Compiler y, por supuesto, el clásico Dragon Book. Puedes adentrarte en el desarrollo de tu propio lenguaje de programación empezando con el tutorial Kaleidoscope de LLVM. En el desarrollo de software del “mundo real”, a menos que seas ingeniero de compiladores, este conocimiento puede darte una comprensif3n mucho me1s profunda del comportamiento del lenguaje y de errores difedciles de explicar. Además, la mayoría de los compiladores son de código abierto, lo que te permite contribuir a proyectos enormes y de gran impacto. Por ejemplo, contribuir al repositorio de Swift aporta mucho valor al portfolio de cualquier desarrollador.
Fundamentos de sistemas operativos
Si hay proyectos aún más complejos que los compiladores, los sistemas operativos son los primeros que me vienen a la mente. Como desarrolladores que pasamos la mayor parte del tiempo trabajando en ordenadores, resulta sorprendentemente fe1cil olvidar que un sistema operativo es solo otro programa, como los que escribimos nosotros mismos. Una enorme capa de abstracciones desde el hardware crea la ilusión de que cada programa en espacio de usuario se ejecuta en su propio procesador con su propia memoria. Estas abstracciones son tan precisas que el código escrito y compilado una sola vez puede ejecutarse de forma fiable en una enorme variedad de configuraciones de hardware.
El libro Operating Systems: Three Easy Pieces es un excelente punto de partida para entender cómo funcionan los sistemas operativos. Y si te interesa especedficamente el funcionamiento interno de iOS o macOS, te recomiendo el recurso gratuito MacOS X and iOS Internals. Comprender cómo funciona un sistema operativo salva la última distancia entre el hardware y el código que escribimos. Para un desarrollador, esto significa un control y una comprensión casi completos de lo que ocurre cuando se ejecuta tu programa.
Para terminar
Mirando atre1s, no segued un plan estricto. Simplemente seguí aprendiendo, construyendo y persiguiendo lo que me interesaba. Esa curiosidad se convirtió en una carrera profesional.
Si te sientes cf3modo pero te preguntas que9 es lo siguiente, intenta ampliar horizontes. Explora algo nuevo. El tiempo que inviertas en proyectos paralelos y aprendizaje se acumulare1, y las distancias entre niveles—Junior, Middle, Senior y Principal—empezare1n a reducirse me1s re1pido de lo que imaginas.
Siempre hay me1s por aprender. Pero con cada proyecto, cada error y cada concepto nuevo, sigues avanzando. Sigue creando.
— Andrii Zinoviev, Principal Product Engineer
¿Quieres formar parte de nuestro equipo de Engineering y generar impacto para millones de personas? a1Descubre nuestras vacantes!
The Readdle Team 
