Você que é dev muito provavelmente vai em algum momento da sua carreira se deparar com a oportunidade de entrar em uma startup.
Se você já teve esta oportunidade e aceitou, possivelmente pode ter se encontrado na seguinte situação (se ainda não teve a oportunidade mas já pensou nela esse texto também vale pra você): “Acabei de entrar numa startup early stage, a cultura é sensacional, empresa crescendo muito, time técnico parece ser excelente. Mas, comecei a pegar no código e tem algumas coisas que parecem mal feitas, umas regras de negócio confusas… Fico com a sensação que eu preciso ensinar eles como faz, e que eu vou dar um jeito nisso!”.
Por acaso, isso passou isso na sua cabeça? Vou tentar explicar um pouco de onde vem o pensamento e porquê ele pode ser muito legítimo.
Antes de começar queria fazer um combinado com você, leitora.
A dev: você vai ler um texto no feminino
Como o mercado tech tem pouquíssima representatividade feminina, considero muito importante incentivar de que essa realidade mude. Portanto, adianto que sempre vou trazer no feminino profissionais de desenvolvimento ao longo deste texto.
Isso é bom porque nos ajuda a romper a barreira do gênero na profissão e incentivar de forma tímida que as mulheres se vejam programando. Além disso, escrever no feminino também nos aproxima do universo de programação. #GirlsRules
Aqui na Pier temos um time de engenharia, mas infelizmente ainda não temos tantas mulheres nele.
Um alô de quem escreve
Como (quase) todo mundo aqui na Pier é claro que eu também tenho um apelido e pouca gente me conhece pelo meu nome, Rafael, e sim pelo meu apelido: prazer, Fifo! Sou um dos fundadores e responsável por Tecnologia aqui na Pier.
Codificação do modelo da realidade
Um software é uma codificação da realidade. Nós, devs, modelamos a realidade seja em nossas cabeças, através de artefatos que podem ser diagramas, notas num papel ou cards num gerenciador de projetos (aqui na Pier nós usamos o Jira, veja um pouco mais da nossa stack no nosso Stackshare). Depois tentamos transformar esse modelo da realidade em software, através de linguagens (códigos) de programação.
Portanto codificar, ou programar, pode ser classificado também como o ato de tentar transformar um conjunto de regras da realidade em software, através de um modelo percebido por nós. Veja que aqui estamos falando de duas etapas:
A primeira etapa é a de transformar a realidade em um modelo, a segunda é de transformar o modelo em um software.
Codificando um mundo dinâmico
Tentar transformar a realidade em software, num conjunto de regras de negócio é uma tarefa complicada porque a realidade de negócios é uma realidade dinâmica. Portanto, regras que fazem sentido hoje, numa mesma indústria ou empresa, podem não fazer mais sentido amanhã.
Exemplos práticos disso são a chegada da COVID-19, que fez com que várias regras de pagamento que antes eram quase imutáveis (como prazos e taxas) em determinados produtos tivessem que ser flexibilizadas. Bem como o nome do novo filho de Elon Musk (que com certeza vai dar dor de cabeça para alguns sistemas de cadastro, rs 🤖).
Dentro do ambiente de startup, esse processo de codificação da realidade é ainda mais difícil. Para clarificar, podemos usar a definição de Startup de Eric Ries, autor do livro A Startup Enxuta, que diz no artigo What is a startup?:
“Uma startup é uma instituição humana, desenhada para entregar um novo produto ou serviço sob condições de extrema incerteza.”
Validando hipóteses em ambientes de incerteza extrema
O que torna tudo mais difícil é o “ambiente de extrema incerteza”. Para lidar com isso e chegar cada vez mais próximo da certeza, a startup costuma trabalhar num ciclo de criação e validação de hipóteses, para pouco a pouco se aproximar da realidade de seus clientes.
O que é importante aqui é que esse constante ciclo de criação de validação de hipóteses normalmente envolve criação de software e alguns dos pedaços de software que você vê hoje podem ter sido construídos meses atrás. A empresa pode até já ter um modelo mais próximo da realidade mas ainda não teve tempo para readequar a sua codificação do modelo (ou seja, seus softwares).
A realidade dinâmica e a startup early stage
Já falamos da dificuldade de modelar e codificar a realidade, como isso é mais difícil num ambiente de negócios e mais difícil ainda numa startup. Mas nosso papo não para por aí: ainda temos mais um agravante, que é a startup early stage.
Uma startup early stage é uma startup que está num nível de incerteza ainda maior e com menos pessoas para ajudar a codificar a realidade. Portanto, o ciclo de criação de validação de hipóteses pode ser ainda mais “frenético” com hipóteses em diversas direções sendo criadas e testadas ao mesmo tempo.
Por isso, é natural que se tenha menos tempo para codificações com alta sofisticação, dado que muitas das hipóteses serão invalidadas e jogadas fora. Algumas coisas são construídas para serem evoluídas depois e acaba que, por falta de tempo e pessoas, o item nunca mais é priorizado e fica sem atenção por um longo tempo. Que bom que você chegou! 🙌
Um pedaço de código que foi feito como uma POC (Prova de conceito), e que na cabeça da dev que fez ainda é uma POC, pode parecer um trabalho mal-feito (e finalizado) para alguém que acabou de entrar e não tem contexto. A falta de contexto (das decisões, história do projeto, da empresa) e muitas vezes a falta de documentação dos projetos/código aumenta essa percepção.
Ao longo do tempo, a startup começa a maturar. Isso não faz necessariamente com o que o ciclo de testes seja mais lento, mas possivelmente a diversidade de hipóteses diminui e um foco surge. Isso facilita na modelagem da realidade, dado que o aprendizado é mais correlacionado.
Uma sensação legítima
Bem, espero ter ajudado a deixar mais claro como as coisas acontecem nesse universo e porquê essa sua sensação normalmente é tão legítima.
Talvez de fato você encontre um software que poderia ter sido mais bem feito, com um nível de sofisticação maior. Porém, é importante ter em mente que ele pode não ter sido escrito melhor não por falta de capacidade ou entendimento técnico do time, mas sim por diversos outros fatores que vão além do conhecimento técnico e que estão também ligados à velocidade que o negócio exige e ao time que se tem disponível para executar tanta coisa ao mesmo tempo.
“Até os melhores times podem criar débitos técnicos” já diria Martin Fowler (tradução livre). Martin tem um excelente artigo sobre o tema, que vale a leitura completa, mas por enquanto recomendo um pedaço específico: Is High Quality Software Worth the Cost? – Even the best teams create cruft.
A melhor forma de entender? Perguntando!
Sabe aquela dev que está desde o início na empresa, entende todos os pedaços dos sistemas, faz pair programming com você, consegue revisar quase qualquer PR e que você admira? Então, provavelmente foi ela quem escreveu o código que você está olhando torto (esse que tá aberto no seu editor agora, 👀).
“Porque será que ela escreveu daquele jeito?”. Você já tem uma pista! Conversar com ela sobre o código para entender melhor pode te trazer uma visão interessante, além de te aproximar de uma pessoa tecnicamente importante na empresa.
Esse entendimento vai se solidificando ao longo do tempo que você está na empresa. Pouco a pouco, você começa a perceber nuances, motivos e histórias de decisões que você anteriormente poderia julgar estritamente equivocadas.
Desenvolvedoras mais experientes já viram esse padrão acontecer outras vezes na sua vida profissional e não precisam ter tanto contexto para entender por que alguns pedaços de software mais antigos têm implementações ou regras de negócio complicadas para a operação. Elas podem não entender no detalhe do universo daquela empresa, mas elas sabem como que é o processo que origina essas defasagens da percepção da realidade dentro do software.
Entender, sim. Normalizar, jamais!
“Ah, então beleza. Entrei na empresa e tudo que o pessoal fez até hoje é lindo, tudo tem justificativa e eles são sensacionais e maravilhosos. Viva!”
Não é bem assim. Precisamos ter cuidado para não usar toda essa construção argumentativa que fiz até agora como desculpa para decisões erradas, principalmente as técnicas, software mal escrito, ou arquiteturas ineficientes.
Cuidado com o perfeccionismo em uma startup!
Devemos construir sistemas em startups early stage sempre pensando em seguir boas práticas de desenvolvimento de software, o que explico aqui nesse texto é relacionado à codificação/modelagem da realidade e a sua constante mudança.
Portanto, cuidado com o pensamento de “Minha chance de fazer tudo melhor!”, você está numa startup, ela tenta modelar a realidade, os aprendizados são rápidos, a incerteza é alta. Trabalhe sempre com o objetivo de entregar o seu melhor, mas não se apegue tanto a sua nova solução que te enche de orgulho. Daqui um tempo virão novas pessoas para a equipe que terão as mesmas sensações que você em relação a código mais antigo. Elas vão pensar “Meu deus, como Rafael fez essa bagunça nas regras? Fazer um cancelamento de contrato é tão mais simples que essa confusão aqui.”
E quando você tiver essa sensação de que algo está ruim e podia ser melhor, procure combater o pensamento imediato de “arrumar a casa”.
“Isso aqui tá uma bagunça, eu já pensei um jeito bem melhor, dá pra refazer tudo e vai ficar lindo!”
Esse é o sonho de toda dev, a gente sabe. Mas vamos entender porque a “bagunça” de hoje existe e como podemos ir, aos poucos, melhorando e ajustando. Refatorações incrementais, commits pequenos e constantes são um caminho mais fluído que geram melhoras importantes tanto para a aplicação em performance, como em codebase e consistência/legibilidade de código.
Ps: Existem casos que a refatoração incremental pode não resolver o problema e a saída de fato é refazer, mudar a arquitetura, mudar a linguagem… Enfim. Para quem estudou Cálculo, é dicotomia de máximo local x máximo global.
Um ciclo sem fim, que nos guiará
É isso, entender esse ciclo de melhoria contínua e incremental é essencial. Ele vai acontecer algumas vezes na empresa: enquanto ela estiver crescendo, aprendendo mais sobre a realidade, alterando seus modelos, software e aumentando a equipe.
Se na empresa houver a preocupação de passar esse modo de pensar para quem entra e isso virar cultura, você estará no caminho para facilitar a comunicação entre as equipes. Isso vai evitar aquele racha de devs antigas x devs novas e terá uma organização que trabalha em conjunto de maneira saudável: respeitando as decisões mais antigas, confrontando elas e melhorando-as, sem vontade de refazer tudo o tempo todo e sem o sentimento de “que coisa mal feita, vou trazer a solução”.
Sua empresa estará num ambiente leve, fluído e pronto para escalar organizacionalmente!