Mover rápido e desistir

• No processo de recuperação de jogos inacabados de Mac de cerca de 1991, repetia-se uma forma de desenvolvimento que implementava ideias rapidamente e, se faltassem diversão ou chance real de conclusão, encerrava o projeto sem hesitar
• Na lista da época havia 27 títulos, mas só 5 foram realmente lançados; o restante era mais próximo de protótipos rápidos feitos ao longo de cerca de 18 meses
• Graças a um shell comum para jogos baseados em sprites, o custo de novos experimentos caiu, e recursos como som, high score e salvamento eram deixados para depois, quando o potencial do jogo já estivesse confirmado
• Experimentos como kite-fighting, K-10 e Thief of Baghdad eram avaliados para continuação com base na diversão dos controles, no objetivo do jogo e no volume de arte e implementação que um único desenvolvedor conseguiria assumir
• Mesmo os projetos descartados não foram desperdício: códigos como o algoritmo Fisher–Yates shuffle, troca de profundidade de cor da tela, detecção de colisão e tabelas de consulta trigonométrica foram reutilizados em projetos posteriores

---

Recuperando projetos antigos de jogos para Mac

• Ao recuperar arquivos de jogos escritos há cerca de 35 anos em um disco rígido antigo, os experimentos que quase não chegaram a ser concluídos acabaram sendo mais interessantes do que os lançamentos
• Os jogos shareware publicados no passado foram organizados em imagens de disco e enviados para Soft Dorothy Software — Early Shareware Projects
  • Essas imagens de disco podem ser usadas arrastando-as para emuladores Mac 68K ou PPC como Basilisk II, Sheepshaver e MiniVMac
• O código-fonte relacionado ao Glider 4.0, publicado pela Casady & Greene em 1991, e as ferramentas de build estão na imagem de disco Casady & Greene Projects
• AirBikes teria sido um jogo futurista de corrida se tivesse sido concluído, mas acabou permanecendo inacabado

Só 5 lançamentos entre 27 títulos

• Um documento criado por volta de 1991 organizava o creator code, o nome e o estado de cada jogo
  • O creator code era algo próximo de um bundle identifier bem rudimentar da era Macintosh anterior ao OS X, e precisava ser único para cada aplicativo
• A lista tinha 27 títulos, e apenas 5 deles foram lançados
  • A maioria dos demais era formada por protótipos rápidos
  • Esses projetos foram feitos ao longo de cerca de 18 meses
  • No momento em que a lista foi escrita, havia registro de trabalho simultâneo em 3 títulos
• Um utilitário chamado UnMask também foi publicado, mas, por ter levado cerca de 10 minutos para ser feito, foi tratado como algo fora do escopo da análise

O método de prototipagem rápida

• Codificando até tarde todas as noites, muitos experimentos foram produzidos, e um shell comum para jogos baseados em sprites reduzia o custo de criar novos protótipos
• Em novos esboços de jogos, a maior parte do tempo era gasta criando sprites e arte no MacPaint, e algum código era necessário para métodos de entrada específicos, mecânicas de jogo e implementação de física
• Recursos como som, high score e save game não eram feitos desde o começo; ficavam para depois, apenas nos jogos que valessem a pena salvar
• O ponto central era verificar rapidamente se a ideia realmente era divertida
  • Uma ideia parecer divertida no papel não significa que vá ser divertida de jogar na prática
  • Só de implementar controles e física em poucos dias já era possível ver se valia a pena continuar

Critérios para verificar rapidamente a diversão

• Um jogo de kite-fighting podia ter seus controles de voo e física implementados em poucos dias para teste
  • Se controlar a pipa em si já fosse difícil demais, provavelmente poucas pessoas se divertiriam com o jogo
  • Se só empinar a pipa já fosse divertido, mesmo sem combate, havia potencial
• No arcade Joust, o simples ato de voar com o botão de flap já era divertido mesmo antes de aparecer qualquer inimigo
  • Tanto o momento de bater as asas devagar quanto o de apertar freneticamente para subir rápido ajudavam a formar a sensação do jogo
• Um jogo em que um avião de papel ganhava sustentação pelos respiros no chão de uma casa bagunçada também já tinha certo apelo antes mesmo de o jogador entender que precisava avançar pelos cômodos e evitar torradas e outros obstáculos
• K-10 era outro jogo de corrida, batizado em referência à Kansas highway 10, mas não passou da fase de protótipo

A decisão de parar ou continuar

• Alguns jogos chegaram até uma implementação inicial, mas depois não estava claro o que fazer a seguir
  • Na lista, alguns jogos estavam marcados de forma seca com <no point>
• O jogo de plataforma Thief of Baghdad tinha uma parte divertida de correr sobre um tapete mágico, mas o objetivo do jogo depois disso era incerto
• Trabalhando sozinho, era difícil continuar um projeto que, mesmo promissor, levaria mais de um ano para ser concluído
  • Um jogo de adventure baseado em sprites no estilo Dungeons and Dragons era atraente, mas exigia muito trabalho com ações específicas para cada arma do jogador, monstros, efeitos de magia e sistema de combate
  • Depois de criar animações para espetar e defender com espada, seria preciso ainda adicionar variações como maça, arco e capa, aumentando a carga de arte

Retomar depois e reutilizar código

• Um jogo adiado não era um projeto totalmente morto; se os arquivos de código-fonte, recursos e projeto pudessem ser encontrados, ele podia ser retomado
• Thief of Baghdad foi reiniciado cerca de 18 meses depois em uma versão colorida, passou a se chamar Scheherazade e começou a ganhar algum senso de objetivo
  • Mesmo na segunda tentativa, ele acabou sendo interrompido de novo por não atingir um apelo difícil de explicar, mas claramente necessário
• O código de projetos suspensos podia ser reutilizado em trabalhos futuros
  • Fisher–Yates shuffle algorithm
  • código para mudar a profundidade de cor do monitor nos primeiros Macs
  • código de colisão entre polígono e ponto
  • tabela de consulta de seno para trigonometria rápida
  • rotinas de dot-product e cross-product
• Esse trabalho de protótipo não era tratado como desperdício

Um método iterativo que continuou na Apple

• À medida que os anos 1990 avançavam, a era do desenvolvedor indie de jogos para Mac parecia estar chegando ao fim; então, ao receber uma proposta para ir para a Califórnia e trabalhar na Apple, ela foi aceita
• Depois de entrar na Apple, entendeu-se que não seria possível fazer projetos não relacionados à Apple no tempo livre
  • Em termos estritos, para programar fora do trabalho era necessária autorização por escrito do gerente
  • Como a Apple não atuava no mercado de jogos, talvez fosse possível conseguir a permissão, mas o risco de pedir e receber uma negativa pesava
• Mesmo em projetos de trabalho que não eram jogos, a abordagem de prototipagem rápida continuou
  • Outros colegas repetiam o design no quadro branco e planejavam com cuidado antes de escrever código
  • A preferência aqui era mergulhar direto e iterar compilando
• O processo se repetia: juntar código rapidamente, encontrar gargalos cedo e, se necessário, recomeçar o projeto quase do zero
  • Mesmo depois de iniciar um projeto umas três vezes e reiniciá-lo, ainda assim muitas vezes se chegava a um estado suficientemente bom mais ou menos quando os colegas mais cautelosos estavam conseguindo executar o código pela primeira vez
• A última revisão do código normalmente era uma simplificação, e, ao tratar o código desde o começo como algo que podia ser mudado radicalmente, foi surgindo uma intuição melhor sobre como organizá-lo
• Houve até a experiência de poder responder a um colega que recomendava um Bloom Filter que ele já havia sido descartado, porque os dados reais eram pequenos demais para trazer ganho perceptível de desempenho e só aumentariam a complexidade da base de código

Always Be Iterating

• Ao se aproximar da aposentadoria, veio a sensação de ter sido um funcionário e colega que contribuiu na Apple
• Diferentemente da época de virar a noite programando sozinho, a melhor parte do trabalho na Apple foram os engenheiros com quem se trabalhou
  • Entre essas pessoas havia programadores mais de uma ordem de grandeza melhores
• Houve a percepção de ter sido um dos programadores mais rápidos, o tipo de pessoa que conseguia fazer duas versões de um protótipo para a demo da reunião daquela semana
• A frase repetida às filhas era A.B.I.
  • “Always”
  • “Be”
  • “Iterating”
  • isto é, “Always Be Iterating”
• Os projetos, códigos-fonte e ferramentas dos jogos que não chegaram a ser lançados foram organizados como imagens de disco e publicados no GitHub
  • Soft Dorothy Software: Unfinished Tales (Vol. 1)
  • Soft Dorothy Software: Unfinished Tales (Vol. 2)
• Um Volume 3 também está planejado, mas como ainda há trabalho para deixar cada projeto em estado "release", não há promessa de data para publicação

[GN⁺]

Opiniões do Hacker News

• Desde que comecei a programar, por volta de 1989, tenho no mínimo uma dezena e, no máximo, algo como cem projetos abandonados, a maioria jogos. A maior parte foi feita para Mac Plus ou Mac LC, e muitos tinham mecânicas ou estilos de arte parecidos com os mencionados no texto.
  Os poucos projetos que lancei ou dos quais participei parecem sombras de quem eu sou. O mesmo vale para meu currículo e minha carreira. São como impressões digitais de uma existência inteira vivendo a vida sonhada que nunca se concretizou, porque não tive a chance de acumular sucessos no começo. Por isso acho que a renda básica poderia ampliar o potencial humano em 10 ou 100 vezes, nos levando de uma economia de serviços para agência e autorrealização, e permitindo que cada um crie renda residual. E eu joguei muito Pararena.

  • Tenho uma visão diferente, e passei a pensar assim quando, durante a pandemia, surgiu uma situação parecida com renda básica ao meu redor e entre meus amigos. As pessoas que não precisavam mais trabalhar ficaram deprimidas bem mais rápido do que as que continuaram trabalhando, e isso mudou minha perspectiva sobre renda básica.
    Talvez ao seu redor tenha sido diferente, ou talvez no seu país essa abordagem não tenha sido adotada. Fico curioso sobre qual é a diferença entre trabalhar em vários jogos e focar em um só até terminá-lo. Com renda básica, será que surgiriam projetos concluídos, e será que as pessoas conseguiriam continuar fazendo esse tipo de coisa não só por um tempo, mas de forma contínua? Em certas fases da vida, como ao se tornar pai ou mãe, ou na infância, a renda básica faz sentido, mas acho que, no período de descoberta de si mesmo, a responsabilidade ajuda.
  • A renda básica não vai funcionar. No meu país ela está praticamente implementada. Mesmo sem trabalhar, dá para receber 600 euros por mês e vários benefícios sociais, e o resultado é o maior déficit público da UE, uma das maiores cargas tributárias do mundo, criminalidade disseminada, dificuldade de ganhar dinheiro trabalhando por causa desses impostos, uma saída em massa de pessoas qualificadas para o exterior, etc.
  • Se nem o salário mínimo deu muito certo, não sei quais seriam os indicadores que fariam alguém acreditar que um sistema parecido, que dá dinheiro a quem não trabalha, funcionaria.
    É muito difícil entender esse modo de pensar. Uma renda básica mágica viraria o salário mínimo para uma massa de pessoas que não trabalham; como isso poderia ser sustentável ou bom?
  • Vivemos vidas diferentes. Eu só participei de projetos em que teria sido melhor jogar o produto fora. Não eram jogos, mas esse era o estado em que foram lançados.
    Em teoria, havia a opção de terminar tudo direito, mas, se tentassem fazer isso, a organização teria falido, então era uma opção puramente teórica. Pelo estado dos softwares que uso no trabalho e que, inevitavelmente, também uso na vida pessoal, parece que todo mundo ao meu redor vive assim. Felizmente, os usuários não têm escolha, então precisam comprar algo péssimo ou não comprar nada. Estamos seguros vendendo coisas péssimas.
  • As coisas inacabadas eu simplesmente chamo de pesquisa. Tenho vários projetos em Unreal Engine 4/5 e nunca vou conseguir terminá-los, mas eles foram divertidos do ponto de vista de testar mecânicas de jogo, rigging e animação, desenvolvimento de shaders e criação de assets 3D.

• Muitas empresas em que trabalhei funcionavam desse jeito. Os engenheiros criam um recurso novo e reluzente, ele é lançado, e todo mundo fica feliz. Alguns meses depois, há uma pilha de bugs.
  As pessoas que criaram aquilo originalmente já foram para outros times. A justificativa é “quebrar silos”, mas, na prática, é mais algo como “tornar todo mundo substituível”. Os engenheiros que herdam o projeto precisam mantê-lo e corrigir bugs até outro time assumir. É horrível.

  • Foi um inferno que nós mesmos criamos ao aceitar amplamente o produto mínimo viável como a forma correta de desenvolver produtos. Julgamos a viabilidade por uma lista de funcionalidades, não por saber se aquela coisa idiota é sólida ou manutenível.
    Além disso, “minimamente viável” está a apenas um passo de “inviável”. Todo projeto vira um Ícaro, testando quão perto do sol consegue voar antes que suas asas derretam.
  • Costumo brincar que toda vaga de startup pós-Series A parece pedir para fazer Viscera Cleanup Detail[1] para limpar a bagunça deixada pelos “heróis” da fase anterior ao product-market fit.
    [1]: https://store.steampowered.com/app/246900/Viscera_Cleanup_De...
  • Concordo totalmente, porque eu fui o autor original de uma funcionalidade que definia a empresa, ouvi que era preciso “quebrar silos”, saí dela e passei anos vendo meu trabalho se deteriorar.
    As pessoas que herdaram aquilo não tinham qualificação para tomar decisões, minha visão maior foi deixada de lado, foi insuportável ver a incompetência na gestão daquela funcionalidade, e até hoje fico irritado toda vez que aparece um bug idiota. Especialmente porque eu avisei quando ainda havia tempo suficiente para ajustar as coisas. Ainda assim, tirei uma lição importante, e posso dizer com certeza que, da próxima vez, mesmo que eu pareça uma pessoa teimosa, não vou recuar e vou brigar.
  • Isso está totalmente correto, mas não acho que seja o ponto que o texto original queria abordar, nem a intenção dele. O texto é mais uma recomendação para experimentar várias coisas, sentir se elas são tecnicamente possíveis e se parecem interessantes para os clientes, e então insistir nisso.
    Funciona bem para desenvolvedores independentes e, até certo ponto, também se aplica a grandes empresas. Essa filosofia é boa para identificar funcionalidades ou produtos nos quais vale a pena gastar tempo significativo. Na verdade, a situação que você descreveu também pode ser vista como uma consequência direta de não seguir a abordagem sugerida pelo texto original.
  • O que você descreveu não parece ter muita relação com este texto

• Ultimamente estou voltando ao desenvolvimento retrô. Estou criando software para o Macintosh 68K, com o qual aprendi programação pela primeira vez
  Vasculhei muitos livros antigos, posts do comp.sys.mac.programmer e códigos-fonte como Soft Dorothy e GliderPro. Ver código antigo com olhos novos é uma experiência curiosa. Também dá para enxergar por que Macs antigos travavam tanto, além da explicação simples de que “não havia proteção de memória”. Como o autor comentou, também gosto de arte de 1 bit, então mantenho uma lista de contas do Twitter que publicam esse tipo de arte. Se estiver faltando alguém, seria bom me avisarem: https://twitter.com/i/lists/1578111923324944397
  O bom de programar para sistemas limitados é que eles limitam suas opções. É uma pausa agradável em relação à experiência moderna de poder fazer qualquer coisa desde que você puxe a biblioteca adequada. Às vezes imagino um mundo em que a capacidade de computação fica congelada e o software para sistemas bem compreendidos só vai ficando cada vez melhor. Sistemas antigos como o Mac 68K eram vertiginosos porque o hardware avançava rápido demais. Quando saía um processador novo, como o 68020 ou o 80386, havia no máximo alguns anos para criar algo que realmente aproveitasse seu potencial. Se você demorasse demais, teria que competir com software novo para a nova geração de hardware

  • Olhando de novo para meu código com mais de 30 anos de retrospectiva, dá vontade de refatorar e simplificar tarefas comuns, como responder a eventos de janela
    Também dá vontade de criar funções wrapper para lidar com Handles e coisas do tipo. Mesmo assim, como foi dito, é surpreendente como a Toolbox era simples em comparação com sistemas operacionais modernos. Voltar a fazer desenvolvimento retrô parece realmente divertido
  • Faço arte de 1 bit para o Playdate, uma plataforma limitada. Não é tão limitada quanto um Macintosh Plus. No Twitter sou @gingerbeardman, e há exemplos aqui: https://blog.gingerbeardman.com/2024/07/14/shibuya-pixel-art...
  • Gosto de arte de 1 bit por causa das imagens com dithering dos Macs 68k. Também deixei com dithering algumas fotos que tenho para usar como papel de parede do computador

• O blog inteiro é ótimo. Há muita coisa interessante para explorar
  Tudo bem abandonar algo, e dá para aprender com projetos abandonados e até reutilizar partes deles. Para mim, o momento de virada foi quando decidi tornar as coisas pequenas o suficiente para conseguir terminá-las. Isso me ajudou a desenvolver a habilidade de terminar, que é uma habilidade separada e difícil de aprender. Como ela só aparece no fim de um processo longo e difícil demais, quase nunca se chega lá. Todos os meus amigos que fazem videogames começam escrevendo o próprio engine e ficam esgotados quando chegam à fase de criar um editor de fases. Eles aprendem muito sobre criação de ferramentas, o que, ironicamente, se parece com coisas que já sabiam fazer, mas não chegam a criar o jogo de fato. É como aprender alvenaria construindo uma catedral; você nunca vai ver o fim. É preciso começar com algo pequeno demais para fracassar e então avançar para projetos cada vez maiores

  • Já passei algumas vezes por isso de “todos os meus amigos que fazem videogames começam escrevendo o próprio engine”. Mesmo quando se decide usar ferramentas existentes, é fácil cair num poço de complexidade sem fundo
    Estou trabalhando em um projeto no Unity agora e estava empacado tentando descobrir a melhor forma de criar um sistema de posicionamento de construções no estilo RTS. Em vez de mergulhar de cabeça como de costume, decidi ajustar o conceito do jogo para que o jogador nem precisasse posicionar construções. Depois de testar, acabou sendo uma experiência de usuário melhor para aquilo que eu queria criar. No começo racionalizei dizendo “vamos adicionar o sistema de construção na próxima iteração”, mas agora provavelmente não vou fazer isso
    Cortar quase sempre é melhor. Concluir de verdade um ponto de partida pequeno é como nitrometano para a próxima iteração. É preciso chegar a 100% para que a próxima rodada seja muito melhor. Se você para em 80%, fica apenas a sensação de ter que empurrar a pedra de volta morro acima
  • Acho que nunca terminei sequer um projeto pessoal. Pelo menos para mim, essa é a habilidade mais difícil de desenvolver
  • Concentrar-me em reduzir projetos pessoais até um tamanho em que eu possa realmente terminá-los talvez seja exatamente o que preciso agora
  • Recentemente migrei do desenvolvimento front-end para acessibilidade. Alguns anos atrás, criei vários sites estáticos, templates e projetos de design, mas acabei abandonando tudo por vários motivos
    Depois que comecei a trabalhar com acessibilidade, retomei muitos deles e os refiz para que fossem acessíveis. Alguns usavam versões muito antigas do Bootstrap, então também aproveitei para atualizá-los para o Bootstrap mais recente. Aprendi muito só de corrigir designs antigos para torná-los acessíveis. Sinto que ganhei uma perspectiva muito melhor sobre o que observar ao avaliar sites e aplicativos. Também foi uma oportunidade para perceber como aquilo que eu havia criado era inacessível
  • A habilidade de terminar o que se começa parece ficar de fora das discussões sobre produtividade. Fico curioso se há algum post de blog ou artigo que explique isso em mais detalhes

• Os jogos do John foram uma inspiração para mim quando eu estava aprendendo a programar no Mac na infância. Joguei muito Glider e ainda mais Pararena. Ainda tenho aquele sample inicial ressonante grudado na cabeça
  Provavelmente passei ainda mais tempo fuçando os resource forks desses jogos no ResEdit. Não terminei muita coisa, mas concluí alguns pequenos jogos shareware e os enviei para a AOL. Fiquei realmente surpreso quando, alguns meses depois, chegou uma cheque pelo correio vindo da distante Califórnia
  O início da era Mac foi um período realmente especial, e havia a sensação de que uma pessoa desenvolvendo sozinha, com criatividade e tempo, podia criar algo e colocá-lo no mundo. Obrigado por escrever este texto e me levar de volta às lembranças; espero que esteja aproveitando a aposentadoria

  • Talvez você tenha lido meus outros textos ou o README do repositório de imagens de disco. Aquela época foi especial
    Será que foi especial porque, como primeiros usuários e primeiros desenvolvedores de computadores, tudo era novo para nós? Ou havia algo diferente no ar naquela época? Fico feliz que tenha gostado dos joguinhos que fiz. Também fico curioso se aquele cheque vindo da Califórnia acabou sendo o empurrão para a carreira que você tem hoje, seja ela qual for

• Se o objetivo deste texto é normalizar o abandono de projetos, não sei se é uma boa ideia. Mesmo deixando todo o resto de lado, pode ser um enorme desperdício de tempo, e isso não pode ser justificado só com “mas eu aprendi algo”. Não deveríamos aprender também ao concluir?

  • Em um excelente episódio do Smarter Every Day, Destin trabalha com um ateliê de vidro para colocar uma gota do Príncipe Rupert quebrada dentro de um bloco de resina.
    Como era algo que ninguém tinha feito antes, eles vão descobrindo o método ao longo do processo e cometem muitos erros no caminho. Um dos pontos enfatizados no vídeo é que, quando algo assim acontece, a equipe não simplesmente para e tenta a mesma coisa de novo. Eles continuam, estragam tudo de vez e usam aquilo como uma oportunidade para experimentar à vontade com o material.
    Ele fala longamente sobre como isso é excelente. Se estivessem no caminho de criar um produto finalizado e polido, poderiam experimentar livremente tentativas que não fariam; assim, aproveitam uma oportunidade incomparável de aprender mais sobre o comportamento do material com que estão lidando. Como é difícil estragar ainda mais algo que já virou lixo, fica até ambíguo dizer que ainda estão assumindo risco.
    Acho correta a observação de que uma mentalidade que valoriza aprendizado e experimentação, em vez de apenas sucesso, é uma das melhores formas de se tornar realmente excelente no que se faz.
  • Ele também de fato concluiu algumas coisas. O ponto central é evitar a paralisia por análise e, em vez de ficar só pensando, “simplesmente tentar”. É um viés para a ação e uma recusa ao custo afundado.
  • Isso é uma leitura equivocada do texto. O texto tem mais a ver com descoberta por meio de prototipagem iterativa rápida, incluindo descobrir cedo e rapidamente falhas fatais.
  • Acho o título ruim. A lição é mais próxima de “trabalhe em tudo que vier à mente, mas não lance nada antes de estar pronto. Alguns projetos talvez nunca fiquem prontos, e tudo bem. Daqui a 30 anos, você pode colocá-los no GitHub por nostalgia”.
    O ChatGPT resumiu como “construa rápido e nunca lance. Até lançar”.
  • Acho saudável que projetos morram. Isso libera tempo para começar outros projetos, em vez de ficar preso a uma forma.
    Às vezes você se agarra a um projeto que não vai a lugar nenhum e pensa que, se se esforçar o suficiente, ele vai chegar a algum lugar, mas ele já não é divertido e você não está aprendendo nada novo. Você se pressiona com o pensamento de “tenho que terminar, tenho que terminar”, e quando pergunta “por quê?”, geralmente é por medo de não conseguir terminar, ou talvez por medo de não conseguir distinguir um trecho difícil de um projeto fracassado. De um jeito ou de outro, já senti muitas vezes uma sensação de libertação quando algo fracassou. Vira uma chance de recomeçar.

• Algumas das pixel arts nas capturas de tela são realmente incríveis.

• Pessoalmente, aprendi e ganhei muito mais lançando coisas pequenas e depois iterando ou descartando.

• Eu gosto dessa abordagem e a acho interessante, mas, no nível organizacional, ela parece mais complicada. Muitas coisas que descobrimos sobre projetos e tecnologias têm a ver com viabilidade na escala em que um projeto real funciona, e isso não aparece necessariamente em experimentos pequenos.
  Às vezes o problema nem é técnico, mas algo como “conseguimos fazer a maioria dos desenvolvedores daqui entender esta forma de trabalhar?”. Isso não quer dizer que não devamos fazer mais tentativas desse tipo. Há coisas que podemos aprender tentando projetos pequenos. Só que isso não garante que funcionem em grande escala.

• Meu problema é simplesmente tempo. Quando chego em casa depois do trabalho, a última coisa que quero é sentar na frente do computador.
  Mesmo nos dois dias de folga por semana, preciso preenchê-los com tarefas domésticas, então continuo sem vontade de ficar sentado diante de uma tela de computador.

  • Sou júnior e estou tentando conseguir um estágio e depois um emprego.
    Invejo quem consegue fazer como você. Hoje, o setor parece uma seita que só procura pessoas que fazem de tecnologia e programação a vida inteira. Não é que eu odeie os requisitos em si; tenho ética profissional e quero fazer bem, mas as expectativas parecem mais altas do que nunca.
    Espero conseguir estabilidade profissional suficiente para ter hobbies que não exijam olhar para uma tela. Quero experimentar metalurgia em breve.