Moverse rápido y abandonar

• Durante el proceso de recuperar juegos de Mac inconclusos de alrededor de 1991, se repitió un método de desarrollo de implementar rápido una idea y descartarla sin dudar si le faltaba diversión o posibilidades reales de completarse
• En la lista de entonces había 27 títulos, pero solo 5 llegaron a publicarse; el resto eran más bien prototipos rápidos hechos a lo largo de unos 18 meses
• Gracias a un shell común para juegos basados en sprites, el costo de probar nuevas ideas era bajo, y funciones como sonido, high scores y guardado se dejaban para después de comprobar que había potencial
• Experimentos como kite-fighting, K-10 y Thief of Baghdad se evaluaban para decidir si seguir o no según la diversión del control, el objetivo del juego y la cantidad de arte e implementación que una sola persona podía asumir
• Incluso los proyectos descartados no fueron un desperdicio, porque código como el Fisher–Yates shuffle algorithm, el cambio de profundidad de color de pantalla, la detección de colisiones y las tablas trigonométricas terminaron reutilizándose después

---

Recuperando proyectos viejos de juegos para Mac

• Al recuperar archivos de juegos escritos hace unos 35 años desde un disco duro antiguo, lo más interesante terminó siendo no los juegos publicados, sino los experimentos que casi no llegaron a completarse
• Los juegos shareware publicados en el pasado se subieron empaquetados como imágenes de disco en Soft Dorothy Software — Early Shareware Projects
  • Esas imágenes de disco pueden usarse arrastrándolas a emuladores Mac 68K o PPC como Basilisk II, Sheepshaver o MiniVMac
• El código y las herramientas de compilación relacionadas con Glider 4.0, publicado por Casady & Greene en 1991, están incluidos en la imagen de disco de Casady & Greene Projects
• AirBikes habría sido un juego de carreras futurista si se hubiera terminado, pero en la práctica quedó inconcluso

Solo 5 lanzamientos entre 27 títulos

• En un documento creado alrededor de 1991 estaban organizados el creator code, el nombre y el estado de cada juego
  • El creator code era algo parecido a un bundle identifier muy rudimentario de la era Macintosh anterior a OS X, y debía ser único para cada aplicación
• En la lista había 27 títulos, y solo 5 de ellos se publicaron
  • La mayoría de los demás eran prototipos rápidos
  • Estos proyectos se hicieron a lo largo de unos 18 meses
  • En el momento de redactar la lista, parece que había 3 títulos en desarrollo al mismo tiempo
• También se publicó una utilidad llamada UnMask, pero como fue una herramienta hecha en unos 10 minutos, se considera algo que puede quedar fuera del análisis

Método de prototipado rápido

• Se hacían muchos experimentos programando todas las noches hasta muy tarde, y un shell común para juegos basados en sprites reducía el costo de crear nuevos prototipos
• En los bocetos de nuevos juegos, el tiempo se iba sobre todo en crear sprites y arte en MacPaint, mientras que los métodos de entrada propios, las mecánicas de juego y la física requerían algo de código adicional
• Funciones como sonido, high scores y partidas guardadas no se hacían desde el inicio, sino que se dejaban para más adelante y solo para los juegos que valiera la pena salvar
• La clave era comprobar rápido si una idea realmente era divertida
  • Una idea escrita en papel puede parecer divertida, pero eso no significa que jugarla lo sea
  • Incluso implementando solo los controles y la física en unos pocos días, ya podía verse si valía la pena seguir

Criterios para comprobar rápido si era divertido

• Un juego de kite-fighting podía probarse en unos días implementando los controles de vuelo y la física
  • Si controlar el papalote resultaba demasiado difícil por sí solo, era probable que poca gente disfrutara el juego
  • Si solo volar el papalote ya era divertido incluso sin combate, entonces había potencial
• En el juego arcade Joust, el simple hecho de volar con el botón de flap ya era divertido incluso antes de que aparecieran enemigos
  • Tanto el momento de aletear despacio como el de presionar el botón frenéticamente para subir rápido contribuían a la sensación de juego
• Un juego de avioncitos de papel que obtenían sustentación de las rejillas del piso en una casa desordenada también tenía cierto nivel de diversión incluso antes de entender que había que avanzar por habitaciones y esquivar cosas como tostadoras
• K-10 era otro juego de carreras, nombrado por la Kansas highway 10, pero no logró pasar de la etapa de prototipo

Decidir si abandonar o continuar

• Algunos juegos llegaron a tener una implementación inicial, pero después no estaba claro qué hacer con ellos
  • En la lista, a varios juegos se les anotó con frialdad <no point>
• El juego de plataformas Thief of Baghdad tenía partes divertidas al correr y saltar sobre una alfombra mágica, pero no estaba claro cuál debía ser el objetivo del juego después de eso
• Desarrollando en solitario, era difícil seguir con proyectos que parecían prometedores si iban a requerir más de un año para completarse
  • Un juego de aventura basado en sprites al estilo Dungeons and Dragons resultaba atractivo, pero la cantidad de trabajo necesaria para acciones por arma del jugador, monstruos, efectos de hechizos y sistema de combate era enorme
  • Después de crear animaciones para apuñalar y bloquear con espada, había que sumar variantes para mazas, arcos, capas y más, aumentando la carga artística

Retomar después y reutilizar código

• Un juego puesto en pausa no era un proyecto completamente muerto; si se encontraban el código fuente, los recursos y los archivos del proyecto, podía retomarse
• Thief of Baghdad se reinició unos 18 meses después como una versión a color, recibió el nombre de Scheherazade y empezó a adquirir algo más de propósito
  • Incluso en ese segundo intento, al final no apareció suficiente atractivo difícil de describir, y volvió a detenerse
• El código de proyectos en pausa podía reutilizarse en trabajos posteriores
  • Fisher–Yates shuffle algorithm
  • código para cambiar la profundidad de color del monitor en las primeras Mac
  • código de colisión polygon-point
  • tabla de consulta de seno para trigonometría rápida
  • rutinas de dot-product y cross-product
• Este trabajo de prototipos no se consideraba un desperdicio

Un enfoque iterativo que siguió incluso en Apple

• A medida que avanzaban los años 90, parecía que la era del indie Mac game developer estaba llegando a su fin, y cuando llegó la oferta de ir a California a trabajar en Apple, se aceptó
• Después de entrar a Apple, se entendió que no se podían hacer proyectos ajenos a Apple en el tiempo libre
  • En sentido estricto, para programar fuera del trabajo se necesitaba permiso por escrito del gerente
  • Como Apple no estaba en el negocio de los videojuegos, quizá se habría podido obtener permiso, pero pesaba la posibilidad de pedirlo y recibir una negativa
• Incluso en proyectos laborales no relacionados con juegos, el método de prototipado rápido continuó
  • Otros colegas iteraban diseños en el pizarrón y planificaban cuidadosamente antes de escribir código
  • Aquí se prefería lanzarse primero y luego iterar compilando
• Se repetía el enfoque de juntar código rápido para encontrar pronto los cuellos de botella y, si hacía falta, reiniciar el proyecto casi desde cero
  • Incluso después de arrancar un proyecto unas tres veces y volver a comenzarlo, a menudo se llegaba a un estado suficientemente bueno más o menos al mismo tiempo que colegas que habían diseñado todo con cuidado antes de ejecutar código
• La última revisión del código por lo general consistía en simplificar, y se fue desarrollando un sentido de cómo organizarlo al tratar el código desde el principio como algo que podía cambiarse mucho
• También hubo casos en los que, ante un colega que recomendaba un Bloom Filter, se podía responder que ya se había descartado porque los datos reales eran demasiado pequeños para que hubiera ganancia de rendimiento, y solo añadía complejidad a la base de código

Always Be Iterating

• Hacia el momento de jubilarse, quedó la sensación de haber sido un empleado y colega que aportó en Apple
• A diferencia de la época de programar solo toda la noche, lo mejor de trabajar en Apple fueron los ingenieros con quienes se trabajó
  • Entre ellos había programadores que parecían un orden de magnitud mejores
• Se sentía haber sido uno de los programadores más rápidos, alguien capaz de hacer dos versiones de un prototipo si hacía falta una demo para la reunión de esa semana
• La frase que más se repetía a las hijas era A.B.I.
  • “Always”
  • “Be”
  • “Iterating”
  • es decir, “Always Be Iterating”
• Los proyectos, fuentes y herramientas de los juegos que no llegaron a lanzarse se organizaron como imágenes de disco y se publicaron en GitHub
  • Soft Dorothy Software: Unfinished Tales (Vol. 1)
  • Soft Dorothy Software: Unfinished Tales (Vol. 2)
• También está previsto un Volume 3, pero como hay trabajo pendiente para dejar cada proyecto en un estado apto para “release”, no se promete una fecha de publicación

[GN⁺]

Opiniones en Hacker News

• Desde que empecé a programar alrededor de 1989, tengo como mínimo una decena y como máximo quizá un centenar de proyectos abandonados, la mayoría juegos. Casi todos los hice para Mac Plus o Mac LC, y muchos tenían mecánicas o estilos artísticos parecidos a los del artículo.
  Los pocos proyectos que lancé o en los que participé se sienten como una sombra de mí mismo. Lo mismo pasa con mi currículum y mi carrera. Son como las huellas de una persona completa que vivía la vida soñada que no se pudo concretar porque no tuve la oportunidad de acumular éxitos al principio. Por eso creo que el ingreso básico podría multiplicar por 10 o por 100 el potencial humano, ayudarnos a pasar de la economía de servicios a la agencia y la autorrealización, y permitir que cada quien genere ingresos residuales. Y jugué muchísimo a Pararena.

  • Pienso distinto, y lo veo así porque durante la pandemia se dio una situación parecida al ingreso básico alrededor de mis amigos y de mí. Las personas que ya no necesitaban trabajar se deprimieron bastante rápido en comparación con las que siguieron trabajando, y eso cambió mi perspectiva sobre el ingreso básico.
    Tal vez en tu entorno fue distinto, o quizá en tu país no se adoptó ese enfoque. Me pregunto cuál es la diferencia entre trabajar en varios juegos y concentrarse en uno hasta terminarlo. Si hubiera ingreso básico, ¿saldrían proyectos terminados, y la gente podría seguir haciendo estas cosas no solo por un rato, sino de forma sostenida? En algunas etapas de la vida, como cuando uno se convierte en padre o durante la infancia, el ingreso básico tiene sentido, pero creo que en la etapa de encontrarse a uno mismo la responsabilidad ayuda.
  • El ingreso básico no va a funcionar. En mi país está casi implementado. Puedes recibir 600 euros al mes y varios beneficios sociales sin trabajar, y el resultado es el mayor déficit público de la UE, tasas impositivas entre las más altas del mundo, delincuencia generalizada, dificultad para ganar dinero trabajando por esos impuestos, una salida masiva de personas educadas al extranjero, etc.
  • Si ni siquiera el salario mínimo funcionó bien, no sé qué indicadores hacen creer que funcionaría un sistema similar que le da dinero a la gente que no trabaja.
    Esta forma de pensar me cuesta mucho entenderla. Un ingreso básico mágico sería el salario mínimo para las masas que no trabajan; ¿cómo podría eso ser sostenible o algo bueno?
  • Vivimos vidas distintas. Yo solo participé en proyectos en los que habría sido mejor tirar el producto a la basura. No eran juegos, pero así estaban al momento de lanzarse.
    En teoría existía la opción de terminarlo bien, pero si hubiéramos intentado hacerlo, la organización habría quebrado, así que era una opción puramente teórica. Al ver el estado del software que uso en el trabajo y que también me veo obligado a usar en privado, parece que todos a mi alrededor viven así. Por suerte, los usuarios no tienen opción, así que tienen que comprar algo pésimo o no comprar nada. Estamos a salvo vendiendo cosas pésimas.
  • A las cosas que no se terminan simplemente las llamo investigación. Tengo varios proyectos en Unreal Engine 4/5 y jamás podré terminarlos, pero desde el punto de vista de probar mecánicas de juego, rigging y animación, desarrollo de shaders y creación de assets 3D, fueron divertidos.

• Muchas empresas en las que trabajé funcionan así. Los ingenieros crean una nueva función brillante, se lanza y todos están felices. Unos meses después se acumulan montones de bugs.
  Las personas que la crearon originalmente ya están en otro equipo. La justificación es “romper silos”, pero en la práctica se parece más a “hacer que todos sean reemplazables”. Los ingenieros que heredan el proyecto tienen que mantenerlo y corregir bugs hasta que otro equipo lo herede. Es horrible.

  • Es un infierno que nosotros mismos creamos al aceptar ampliamente el producto mínimo viable como la forma correcta de desarrollar productos. Juzgamos la viabilidad por la lista de funciones, no por si esa cosa tonta es sólida o mantenible.
    Además, “mínimamente viable” está a solo un paso de “inviable”. Todos los proyectos se vuelven como Ícaro, probando qué tan cerca del sol pueden volar antes de que se les derritan las alas.
  • A menudo bromeo diciendo que todas las ofertas laborales de startups después de la Serie A parecen pedirte hacer Viscera Cleanup Detail[1] para limpiar el desastre que dejaron los “héroes” de la etapa previa al encaje producto-mercado.
    [1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
  • Fui el autor original de una función que definía a la empresa, y estoy totalmente de acuerdo porque me dijeron que “había que romper silos”, me sacaron, y durante años vi cómo mi trabajo se deterioraba.
    Las personas que lo heredaron no estaban lo bastante calificadas para tomar decisiones, mi visión más amplia quedó desplazada, ver la incompetencia con la que gestionaban esa función fue insoportable, y todavía me irrita cada vez que aparece un bug estúpido. Especialmente porque lo había advertido cuando aún había tiempo suficiente para ajustar el rumbo. Aun así, aprendí una lección importante, y puedo decir con certeza que la próxima vez no voy a ceder y voy a pelear, aunque parezca una persona testaruda.
  • Es totalmente cierto, pero no creo que ese sea el punto que intenta plantear el artículo original ni su intención. El texto más bien recomienda probar varias cosas, hacerse una idea de si son técnicamente posibles y de si parecen interesantes para los clientes, y luego apostar por eso.
    Funciona bien para desarrolladores indie y, hasta cierto punto, también puede aplicarse a grandes empresas. Esta filosofía es buena para identificar funciones o productos en los que vale la pena invertir tiempo significativo. De hecho, la situación que describes también podría verse como una consecuencia directa de no seguir el enfoque que propone el artículo original.
  • Lo que describes no parece tener mucha relación con este artículo

• Últimamente volví al desarrollo retro y estoy trabajando en eso. Estoy creando software para el Macintosh 68K, con el que aprendí a programar por primera vez.
  Revisé un montón de libros viejos, publicaciones de comp.sys.mac.programmer y código fuente como Soft Dorothy y GliderPro. Ver código antiguo con ojos nuevos es una experiencia extraña. También se ven razones, más allá de la explicación simple de que “no había protección de memoria”, de por qué las Mac de antes se colgaban tanto. Como mencionó el autor, también me gusta el arte de 1 bit, así que mantengo una lista de cuentas de Twitter que publican arte de 1 bit. Si falta alguien, me gustaría que me avisaran: https://twitter.com/i/lists/1578111923324944397
  Lo bueno de programar para sistemas limitados es que te restringen las opciones. Es un buen descanso frente a la experiencia moderna de poder hacer cualquier cosa con solo traer la biblioteca adecuada. A veces imagino un mundo en el que la capacidad de cómputo se congela y el software para sistemas bien entendidos simplemente mejora cada vez más. Los sistemas antiguos como el Mac 68K fueron de una época en la que el hardware avanzaba tan rápido que mareaba. Cuando aparecía un procesador nuevo como el 68020 o el 80386, tenías, como mucho, unos pocos años para crear algo que aprovechara bien su potencial. Si llegabas demasiado tarde, tenías que competir con software nuevo para una nueva generación de hardware.

  • Al volver a ver mi código con más de 30 años de perspectiva tardía, me dan ganas de refactorizarlo y simplificar tareas comunes como responder a eventos de ventanas.
    También me gustaría crear funciones envoltorio para manejar cosas como Handle. Aun así, tal como se dijo, sorprende lo simple que era Toolbox comparado con los sistemas operativos modernos. Volver a hacer desarrollo retro se siente realmente divertido.
  • Hago arte de 1 bit para Playdate, una plataforma limitada. No es tan limitada como una Macintosh Plus. En Twitter soy @gingerbeardman y aquí hay un ejemplo: https://blog.gingerbeardman.com/2024/07/14/shibuya-pixel-art...
  • Me gusta el arte de 1 bit por las imágenes con dithering de las Mac 68k. También tengo algunas fotos para fondos de pantalla de computadora a las que les hice dithering.

• Todo el blog es genial. Tiene mucho contenido interesante para explorar.
  Está bien tirar algo a la basura, y también se puede aprender de proyectos abandonados e incluso reutilizar partes. Para mí, el momento decisivo fue cuando decidí hacerlo lo suficientemente pequeño como para poder terminarlo. Me ayudó a desarrollar la habilidad de terminar, que es una habilidad aparte y difícil de aprender. Es difícil porque solo ocurre al final de un proceso demasiado largo y exigente, así que casi nunca llegas hasta ahí. Todos mis amigos que hacen videojuegos empiezan escribiendo su propio motor, y para cuando llegan a crear el editor de niveles ya están quemados. Aprenden mucho sobre creación de herramientas, que casualmente se parece bastante a lo que ya sabían hacer, pero en realidad no llegan a crear el juego. Es como aprender cantería construyendo una catedral: no vas a llegar al final. Hay que empezar con algo tan pequeño que no pueda fallar, y después ir subiendo hacia proyectos cada vez más grandes.

  • Eso de que “todos mis amigos que hacen videojuegos empiezan escribiendo su propio motor” también me pasó varias veces. Incluso si decides usar herramientas existentes, es fácil caer en un pozo de complejidad infinitamente profundo.
    Ahora estoy trabajando en un proyecto de Unity y estaba trabado tratando de decidir cuál era la mejor manera de hacer un sistema de colocación de edificios estilo RTS. En lugar de lanzarme de inmediato como siempre, decidí ajustar el concepto del juego para que el jugador no tuviera que colocar edificios en absoluto. Al probarlo, resultó ser una experiencia de usuario incluso mejor para lo que quería construir. Al principio lo racionalicé pensando “agreguemos el sistema de edificios en la próxima iteración”, pero ahora probablemente no lo haga.
    Quitar cosas casi siempre es mejor. Terminar de verdad un punto de partida pequeño es como nitrometano para la siguiente iteración. Llegar al 100% hace que la siguiente vuelta sea mucho mejor. Si te detienes en el 80%, solo queda la sensación de tener que empujar la roca cuesta arriba otra vez.
  • Creo que nunca terminé ni un solo proyecto personal. Al menos para mí, esa es la habilidad más difícil de desarrollar.
  • Enfocarme en reducir mis proyectos personales lo suficiente como para poder terminarlos de verdad puede ser justo lo que necesito ahora.
  • Hace poco pasé del desarrollo frontend al área de accesibilidad. Hace unos años hice varios sitios estáticos, plantillas y proyectos de diseño, pero al final los dejé abandonados por varias razones.
    Después de empezar a trabajar en accesibilidad, volví a muchos de ellos y los rehíce para que fueran accesibles. Algunos usaban versiones muy antiguas de Bootstrap, así que también aproveché para actualizarlos a la versión más reciente de Bootstrap. Aprendí muchísimo solo corrigiendo diseños antiguos para hacerlos accesibles. Siento que obtuve una perspectiva mucho mejor sobre qué observar al evaluar sitios y aplicaciones. También me hizo darme cuenta de lo poco accesibles que eran las cosas que yo había creado.
  • La habilidad de terminar lo que uno empieza parece faltar en las discusiones sobre productividad. Me pregunto si hay alguna publicación de blog o artículo que lo explique con más detalle.

• Los juegos de John fueron una inspiración para mí cuando aprendía a programar por primera vez en una Mac de niño. Jugué mucho Glider y todavía más Pararena. Aún tengo grabada en la cabeza esa muestra inicial resonante.
  Probablemente pasé todavía más tiempo hurgando en los resource forks de esos juegos con ResEdit. No terminé muchas cosas, pero sí completé algunos pequeños juegos shareware y los subí a AOL. Meses después me sorprendió muchísimo cuando llegó un cheque al buzón, enviado desde la lejana California.
  Los primeros tiempos de la Mac fueron una época realmente especial, y existía la sensación de que una persona desarrollando sola, con creatividad y tiempo, podía crear algo y lanzarlo al mundo. Gracias por escribir esto y llevarme de vuelta a esos recuerdos; espero que estés disfrutando la jubilación.

  • Quizás hayas leído mis otros textos o el README del repositorio de imágenes de disco. Aquella época fue especial.
    ¿Fue especial porque, como primeros usuarios y primeros desarrolladores de computadoras, todo era nuevo para nosotros? ¿O había algo distinto en el ambiente en ese momento? Me alegra que te hayan gustado mis pequeños juegos. También me pregunto si ese cheque de California fue lo que te empujó hacia la carrera que tengas hoy.

• Si el objetivo de este texto es normalizar abandonar proyectos, no estoy muy seguro de que sea una buena idea. Dejando todo lo demás de lado, puede ser una pérdida enorme de tiempo, y no se puede justificar solo con decir “igual aprendí algo”. ¿No se supone que también hay que aprender mientras se termina?

  • En un excelente episodio de Smarter Every Day, Destin trabaja con un taller de vidrio para meter unas gotas del príncipe Ruperto rotas dentro de un bloque de resina.
    Como nadie lo había hecho antes, van descubriendo el método sobre la marcha y cometen bastantes errores en el camino. Uno de los puntos que enfatiza el video es que, cuando pasa algo así, el equipo no simplemente se detiene y vuelve a intentar lo mismo. Siguen adelante hasta arruinarlo por completo y lo convierten en una oportunidad para experimentar libremente con los materiales.
    Él habla largo y tendido de lo genial que es eso. Si hubieran estado en el camino de fabricar un producto terminado y pulido, no habrían podido intentar libremente ciertas cosas; así aprovechan una oportunidad incomparable para aprender más sobre el comportamiento del material con el que trabajan. Como es difícil arruinar aún más algo que ya se volvió basura, tampoco está tan claro que seguir asumiendo riesgos lo sea realmente.
    Creo que tiene razón al señalar que una mentalidad que valora el aprendizaje y la experimentación por encima de enfocarse solo en el éxito es una de las mejores formas de volverse realmente excelente en lo que uno hace.
  • En realidad, él sí terminó algunas cosas. El punto es evitar la parálisis por análisis y, en vez de quedarse pensando sin parar, “simplemente probar”. Es un sesgo hacia la acción y una negativa a caer en los costos hundidos.
  • Eso es una mala lectura del texto. El texto va más bien de descubrir mediante prototipado iterativo rápido, lo que también incluye detectar rápido y temprano fallas críticas.
  • Creo que el título no es bueno. La lección se acerca más a: “Trabaja en todo lo que se te ocurra, pero no lances nada antes de que esté listo. Algunos proyectos quizá nunca estén listos, y está bien. En 30 años puedes subirlos a GitHub como recuerdo”.
    ChatGPT lo resumió como: “Construye rápido y nunca lances. Hasta que lances”.
  • Me parece sano que los proyectos mueran. Liberan tiempo para empezar otros proyectos, en vez de quedarse encasillado.
    A veces uno se aferra a un proyecto que no va a ningún lado y piensa que, si se esfuerza lo suficiente, llegará a alguna parte, pero ya no se divierte ni aprende nada nuevo. Se presiona con la idea de “tengo que terminarlo, tengo que terminarlo”, y cuando se pregunta “¿por qué?”, normalmente es por miedo a no terminar, o tal vez por miedo a no saber distinguir entre una etapa difícil y la etapa de un proyecto fracasado. En cualquiera de los casos, demasiadas veces sentí una sensación de liberación cuando fracasé. Se convierte en una oportunidad para volver a empezar.

• Algunas piezas de pixel art de las capturas de pantalla están realmente geniales.

• Personalmente, aprendí y gané mucho más lanzando cosas pequeñas y luego iterando o descartándolas.

• Este enfoque me gusta y me parece interesante, pero a nivel organizacional se ve más complicado. Mucho de lo que descubrimos sobre proyectos y tecnología tiene que ver con la viabilidad a la escala en la que funciona un proyecto real, y eso no necesariamente aparece en experimentos pequeños.
  A veces ni siquiera es un problema técnico, sino algo como “¿podemos lograr que la mayoría de los desarrolladores aquí entiendan cómo hacerlo de esta manera?”. Eso no significa que no debamos hacer más intentos de este tipo. Hay cosas que se pueden aprender probando proyectos pequeños. Solo que no garantiza que también funcionen a gran escala.

• Mi problema es simplemente el tiempo. Cuando salgo del trabajo y llego a casa, lo que menos quiero es sentarme frente a la computadora.
  Incluso los dos días libres a la semana tengo que llenarlos con tareas de la casa, así que sigo sin querer sentarme frente a una pantalla.

  • Soy junior y ahora estoy buscando una pasantía y luego mi siguiente trabajo.
    Envidio a la gente que puede hacerlo como tú. Ahora mismo la industria se siente como un culto que solo busca personas que hagan de la tecnología y la programación toda su vida. No es que odie los requisitos en sí; tengo ética de trabajo y quiero hacerlo bien, pero las expectativas parecen más altas que nunca.
    Espero tener suficiente estabilidad laboral como para poder tener pasatiempos que no impliquen mirar una pantalla. Pronto quiero probar la metalurgia.