ESCRITA / № 005
16 mai 20264 min de leitura

Longo prazo, juros compostos, software e maratonas

Aqui eu compartilho um pouco da minha experiência de vida e a relação entre anos de treino e anos como engenheiro de software.

Longo prazo, juros compostos, software e maratonas
Início4 min de leitura

É comum ouvir do mercado financeiro sobre longo prazo e juros compostos, e que investir R$500,00 todos os meses pode te dar uma aposentadoria no futuro. Na minha opinião, isso se aplica em áreas que vão muito além do que apenas o dinheiro.

Na minha vida, e como na vida de milhares de outras pessoas, nunca foi fácil conquistar as coisas. Sempre tive que trabalhar duro para comprar aquilo que me fazia feliz. Lembro que quando eu era criança, a minha primeira grande compra foi uma placa de vídeo pro computador — minha mãe tinha comprado o computador, mas sem placa de vídeo o pc não rodava jogo algum. Paguei R$200,00 na placa, o suficiente pra jogar alguns jogos. Foram meses de trabalho pra juntar essa grana.

Aprendi desde cedo que é preciso trabalhar duro pra conquistar as coisas, e acredito que por esse motivo eu tenho tanto interesse em fazer essas provas de endurance (provas de resistência). Essa "coisa" de dar tudo de si para atingir um objetivo me faz sentir vivo, e quando se atinge esse objetivo, vem uma sensação absurdamente boa e leve. E aqui eu não falo só sobre corrida, falo também sobre terminar uma faculdade, atingir o pico de uma montanha, fazer um pedal longo bem sucedido, ou então, ficar anos construindo um software até ele ficar excelente.

Falando sobre maratona, pra quem não sabe, uma maratona nada mais é do que correr 42,195km, e se você conseguir correr abaixo de duas horas, você provavelmente é um queniano. Não dá pra você acordar, do nada, num domingo de sol, 20ºC, e sair pra correr uma maratona, você não vai aguentar, simples assim. Para testar, tente percorrer essa distância de carro pra ver quanto tempo demora. Para correr os 42km é preciso muito preparo, são meses e até anos de preparação, é algo que você precisa construir de pouco em pouco, dia após dia, treino após treino. No meu caso, a primeira vez que eu decidi sair para correr, eu não aguentei correr 2km seguidos. Demorou um bom tempo até fazer os 42km. Nunca imaginei que um dia eu faria isso, foi uma realização pessoal enorme, jamais esquecerei. Dá pra escrever um artigo só sobre isso, é algo único.

Então, com software acontece a mesma coisa. Quando você decide que a sua profissão será na área da computação, uma coisa é fato: você terá que fazer um esforço mental muito grande pra não desistir, pois vão ter momentos em que você não entenderá nada e se achará a pessoa mais burra do planeta (às vezes você é hehe). E esse desafio mental não é só no começo da profissão, é algo que acontece todos os dias.

Pra dar um exemplo do que torna isso tão difícil: quando um engenheiro escreve um código, esse código pode rodar por anos. Só que mais cedo ou mais tarde outro engenheiro vai precisar mexer nele pra adicionar uma funcionalidade nova, e código mal escrito hoje vira dor de cabeça amanhã. É o famoso problema de manutenção. Por isso vale tanto a pena fazer bem feito desde o começo.

Existe uma semelhança clara entre correr uma maratona e construir um software: ambos precisam ser feitos pensando no longo prazo e nos juros compostos. Correr 5km pela primeira vez é um desafio gigante, na segunda vez será mais fácil, na terceira ainda mais fácil, e assim por diante. No longo prazo, a corrida vai ficando cada vez mais fácil, pois o seu corpo se adapta, até que chega um momento em que você consegue correr os 42km. É o efeito dos juros compostos dos treinos. Da mesma forma, pra construir um software você precisa sempre pensar no longo prazo. É preciso ter em mente que o código que você constrói hoje será alterado no futuro, então vale a pena fazer o trabalho de hoje bem feito já pensando lá na frente. Claro que aqui estamos desconsiderando muitas variáveis, pois o tempo é escasso e os recursos são finitos. Mas, pra dar um exemplo, você pode construir uma funcionalidade em 1 semana, de forma que cada melhoria depois leve 3 semanas, e depois mais 4 semanas. Ou então, construir a mesma funcionalidade em 1 mês, de forma que cada alteração nele leve apenas 2 dias.

Fui escrevendo enquanto pensava, valeu!!!

Fim · Obrigado pela leitura