O conceito básico de economia que todo programador deve saber
Opa… um novo projeto! O líder técnico reúne todos numa sala e explica qual é a ideia geral. Esse é o momento mais legal: o momento da criação! É no ponto de partida que a gente nos permite sonhar. Então começam as trocas de ideias.
O Carlos viu numa talk que Rust está bombando. O time inteiro tem experiência apenas em PHP e já está de saco cheio. "Poxa, seria legal pra caramba aprender Rust" você pensa. Além do mais, com certeza saber a linguagem sexy da moda daria um up no seu currículo.
Eis o dilema: usar o PHP, que todo mundo já conhece, mas é chato e velho, ou usar a nova linguagem da moda, mas que ninguém conhece e que terá uma boa curva de aprendizado?
Antes da resposta, vamos deixar esse cenário um pouco de lado e imaginar outra situação…
Há anos o time de programação da empresa cuida do próprio servidor. Sempre que tem um novo projeto, o dev mais experiente monta uma máquina na DigitalOcean (que é mais barata que a AWS) e faz o setup do banco, do Apache, da linguagem, etc. Depois de tudo pronto ele investe mais um tempo tunando as aplicações para extrair o máximo da máquina.
No final, depois de muito esforço, ele conseguiu deixar a máquina redondinha e custando apenas $200 por mês. Pelo menos uma vez por semana ele vai lá e limpa os backups, ajusta os logs para manter a máquina rodando. Dá um trabalhinho. Algo em torno de uma manhã de trabalho. Mas, pelo menos, deu pra economizar bem.
Certo dia, um outro programador vem com a ideia de migrar toda a infra para o Heroku. Lá, por ser um plataform as a service, não vai ser mais preciso ficar instalando lib, fazendo update de segurança, tunando banco, etc. O próprio Heroku resolve tudo isso sozinho. Ainda dá pra conectar com o Github e subir, de forma automática, uma versão nova do software toda vez que fizermos um push no repositório. Muito moderno. Só que o custo seria o dobro: $400 por mês.
E aí? Setup próprio na DigitalOcean ou PaaS no Heroku? Qual é a melhor opção?
O programador que não tem visão estratégica tende a querer programar o seu próprio servidor ao invés de usar um PaaS.
Os motivos são a (aparente) economia e também o desafio técnico. Esse mesmo programador, na história anterior, tende a querer desenvolver o novo sistema em Rust, pela novidade e o desafio de aprender uma nova linguagem.
Se você decidir dessa mesma forma, sinto-lhe dizer, mas essas não são as decisões mais estratégicas a serem tomadas.
Escassez: a base da economia
Por mais que você seja um programador e trabalhe no mercado de tecnologia, para saber como decidir em cenários como os de cima, é preciso usar os conhecimentos básicos de outra disciplina: a economia.
Uma das verdades básicas da economia diz que nossos recursos são escassos. Isso significa que não há quantidade suficiente de um recurso para atender todas as pessoas que o demandam.
Deixa eu dar um exemplo para ficar mais claro: Em um dia normal, você precisa dormir, comer, se locomover, trabalhar, fazer exercício físico (eu sei que você virou o olho agora, mas, vem na minha que precisa), estudar, scrollar o Tiktok, assistir vídeos no Youtube, ver uma série no Netflix e trabalhar no seu projeto paralelo. Entretanto, seu dia só tem 24h. Nesse caso, o seu recurso, o tempo, é escasso em relação a todas as suas necessidades e desejos.
Já que eu quero demais e tenho de menos, como resolver essa diferença? Usando um sistema de preços. Ao se cobrar algo de valor (dinheiro, ouro, entre outros) em troca de recursos escassos, nós conseguimos adequar a demanda à oferta existente.
Em um leilão, por exemplo, essa dinâmica fica evidente. O sistema é simples: leva quem pagar mais. Já que há pouca oferta do artigo que está sendo leiloado (apenas uma unidade), quem fizer a melhor oferta em dinheiro será o beneficiado.
No exemplo do tempo, você possui excesso de demandas e falta de tempo para executá-las. O seu "sistema de preço" nesse caso é a prioridade de cada tarefa. Dormir é mais prioritário que scrollar o TikTok, por exemplo.
Partindo dessas premissas, podemos concluir que o uso de um recurso possui um custo inerente. Para um carro se locomover é preciso que haja gasolina. Isso tem um custo. Para fazer ligações de um celular, é preciso que haja créditos. Isso tem um custo. Para que a sua roupa esteja limpa, é preciso de sabão. Isso tem um custo.
Essa é uma lei natural: tudo na vida tem um custo.
O problema do cobertor curto
Quando eu falo que tudo tem um custo, eu não estou falando só de elementos materiais. Toda decisão também possui um custo. Essa categoria de custo é tão relevante que até deram um nome específico à ela. Estamos falando de custo de oportunidade, um dos conceitos mais importantes da economia.
"O valor subjetivo que o agente dá aos fins a que renuncia ao agir de determinada forma", Essa é a definição de custo de oportunidade do economista espanhol Jesus Huerta de Solo. Entretanto, eu prefiro ficar com uma definição mais simples, do economista N. Gregory Mankiw:
"Custo de oportunidade é qualquer coisa de que se tenha que abrir mão para se obter algum item".
Imagine a seguinte situação: chegou o sábado a noite e, depois de uma semana super cansativa, você tem duas opções: ir na festa daquele seu colega de trabalho ou se enfiar embaixo das cobertas e assistir o último episódio da última temporada de Succession (a melhor série da atualidade, diga-se de passagem). Ao escolher ir na festa você abre mão de assistir a série. Ao escolher assistir a série você abre mão de se divertir na festa.
Ao escolher uma opção em detrimento da outra, você estará diante de um trade-off. O famoso economista americano Thomas Sowell costumava dizer que, na vida, "não há soluções, apenas trade-offs". Um trade-off é um conceito da economia que significa a escolha de uma opção em detrimento de outra.
Qual o custo de ir na festa ao invés de ficar assistindo série? Você já está cansado da semana. Talvez o custo seja o mal para a sua saúde em não descansar. E se você decidir ficar em casa. Qual o custo? Talvez seja o mal a sua carreira, por não estar confraternizando e fazendo networking com seus colegas de trabalho.
Percebe que, para cada escolha, você precisa fazer uma renúncia?
Em outro post que fiz aqui no TabNews, eu falei que o ofício do programador é resolver problemas. Acredito que o problema que você mais vai enfrentar ao longo da sua jornada como empreendedor é o problema do cobertor curto. Se os recursos são escassos, é preciso ter em mente qual o custo-benefício das nossas escolhas.
A mentalidade correta na tomada de decisão
Voltando nos exemplos do começo deste texto. Na primeira situação, quais são os custos de cada opção? Se você optar por utilizar PHP, você terá uma linguagem bem menos sexy, e isso pode prejudicar na atração de novos talentos. É sabido também que, geralmente, o PHP é menos performático. PHP é uma linguagem que está cada vez ficando mais verbosa. De bate pronto, consigo imaginar esses problemas.
Agora, quais seriam os contras de se utilizar Rust? O time não tem experiência e conhecimento, portanto o projeto demoraria mais para ser entregue e a qualidade de código não seria tão boa. Existem menos profissionais no mercado que dominam a linguagem e, por isso, seria mais difícil encontrar talentos. Esses talentos também serão mais caros. A comunidade de PHP é mais antiga e, imagino eu, mais populosa e consolidada do que a de Rust.
Agora, e os benefícios de cada opção? Ao escolher PHP, você tem um time mais experiente, que vai entregar um projeto com uma boa qualidade de código e mais rápido, do que comparado com Rust. A comunidade de PHP é enorme e consolidada. É fácil e barato achar gente que programa em PHP. Já ao escolher Rust, você tem uma linguagem muito mais sexy que pode atrair profissionais mais talentosos. Você vai iniciar um projeto numa linguagem mais moderna e, com isso, o projeto tende a "envelhecer" mais devagar.
Partindo da premissa de que estamos falando de um projeto importante, que não demanda complexidade técnica e que possui um prazo para ser entregue, o custo de aprender uma nova linguagem é muito alto, mesmo diante de todos os benefícios.
A escolha aqui seria ir de PHP (claro, estamos falando de um simples cenário hipotético com fins didáticos. Se fossemos levar ao pé da letra, a resposta seria um belo "depende", dado que temos poucas informações sobre o contexto).
Agora, na segunda situação, a resposta é mais simples, já que conseguimos quantificar os custos.
De um lado temos o custo visível de $200 mais o custo invisível das horas de trabalho de configuração e manutenção do servidor. Vamos assumir 20h de trabalho para o setup do servidor + 4h semanais de manutenção. Se o salário do profissional que fez essas configurações for $4.000/m ($25/h), em doze meses temos um custo de mão de obra de $5.300 (4h semanais * 4 semanas no mês * 12 doze meses + 20h de setup * $25 por hora de trabalho). Somando aos $2.400 de custo de servidor, temos um total de $7.700.
Do outro lado temos um custo de $4.800 por 12 meses de Heroku. $2.900 de economia, sem nem colocar na conta a redução da mão de obra e os benefícios intangíveis, como a segurança da plataforma x segurança de um profissional não especializado part-time.
A decisão (quase que óbvia) aqui seria optar pelo Heroku. Quando levamos em consideração o custo da mão de obra necessária para configurar um servidor, o custo da escolha por montar o próprio servidor triplica. Ainda temos o custo de oportunidade, que é termos que investir tempo configurando servidor ao invés de investir tempo desenvolvendo o produto.
Para finalizarmos, tenha em mente que o ponto de partida de uma decisão estratégica sempre é o problema a ser resolvido.
Iniciar um novo projeto foi a solução encontrada para resolver algum problema de mercado. Essa é a verdadeira motivação, não aprender uma nova linguagem. Configurar um servidor é um custo para que você consiga entregar seu software para seus usuários. Seu software foi a solução encontrada para resolver algum problema de mercado.
E aí, nos cenários acima você teria tomado uma decisão estratégica?
Esta foi mais uma edição da minha newsletter.
O objetivo da newsletter é ajudar programadores que desejam empreender mas ainda possuem uma visão muito técnica e pouco estratégica.
Além disso, pretendo também compartilhar outras coisas, como um pouco dos bastidores da construção de um negócio SaaS, as minhas opiniões e meus aprendizados. A ideia geral é ser uma documentação pública e estruturada dos meus aprendizados ao longo dos anos.
Portanto, se você se interessa por empreendedorismo, desenvolvimento pessoal e opiniões relativamente polêmicas, se inscreva para receber as próximas edições.