O que um programador aprendeu sobre empreendedorismo

Anos após começar minha carreira como programador, nunca fui tão exposto ao empreendedorismo. Acredito que a maioria das profissões nunca foi. Temos startups em toda esquina, o que não necessariamente é bom, mas isso é polêmica para um próximo texto. Ver o empreendedorismo de perto me ensinou muito sobre coisas que eu aprendi como verdades absolutas e que eu sei que hoje podem ser conceitos bem vagos.

Podemos culpar quem nos ensina? Curso de Ciência da Computação não é curso para empreender, é para aprender Ciência da Computação. Ponto. Não se pode exigir de um professor que ele tenha background mercadológico, mas são poucos os que saem da universidade para se tornar pesquisadores e/ou cientistas, e no mercado, ah meu amigo! No mercado as coisas são muito diferentes de verdade. O pior é que saímos do curso tão enraizados que não fazemos uma coisa fundamental ao entrar no mercado: pensar.

Evoluir depois de fazer

Em algum local, li que “não se pode melhorar o que não está pronto”. Não me lembro aonde ou quem o falou, mas essa frase ficou marcada na minha cabeça. Aquele menino que aprendeu desde cedo na faculdade que “tudo deve ser transformado em classe” começou a perceber que a vida não é bem assim.

Percebi que manter as coisas simples sempre que possível, é a melhor opção. Isso não só na programação, mas na vida mesmo. Não me refiro à um paradigma aqui, mas a bom senso, apenas.

Todo e qualquer projeto tem um preço que é medido pelo tempo: o valor vai ser dado de acordo com o tempo que o programador precisar. Constantemente vemos esse tempo sendo estourado e isso é muito frustrante. Comecei a perceber o porque isso acontecia e vi que era algo relativamente simples: o cliente pedia e pagava por um Fusca, mas estávamos dando uma Ferrari para ele. E isso era injusto com a nossa empresa! O aumento que queríamos estava sendo gasto em horas que nós mesmos orçávamos. Comecei a simplificar esse processo o máximo que pude. Classe? Nem pensar, a não ser que necessário. Nada de pensar em fazer um projeto altamente modularizado se esse não fosse o intuito desde o começo. “Ah, mas daqui a dois anos…” — quem sabe o que vai haver daqui a dois anos? Dois anos atrás, você sabia do que o mercado ia precisar? Muito provavelmente não. Se sabia, você é um grande visionário. O cliente vai sentir a necessidade de mudança quando for necessário e vai pagar por isso quando for necessário.

Quando você vai em uma concessionária (como cliente) para comprar um carro, você leva o que pode pagar. Chorar para um vendedor dizendo que só tem metade do dinheiro ou que só pode pagar metade da parcela não vai adiantar. E isso não é feio, é justo. Temos que pensar nos nossos clientes, desde que isso não se torne insustentável para nossa empresa.

Sabe o que ocorre com o código altamente modularizado e complexo de um projeto que é simples em sua essência e cujo valor já está fixado? Ele vai pro limbo. Isso mesmo. Fazemos um trabalho tão grande e exaustivo para alimentar nosso ego, ou até para agradar o cliente, e no final, ninguém usa. E estouramos o tempo. E isso vira um problema.

Não é sobre fazer código mal-feito ou bem-feito, é sobre fazer código elegante e efetivo.

Fragmentação não é sinônimo de qualidade

Aí está mais uma falácia que aprendemos: transforme tudo em classe. Se fragmentação de código é sinônimo de qualidade, então programação funcional é um monte de código mal-feito. E se você sabe o que é esse paradigma, sabe que isso não é verdade. Muito pelo contrário. Ele é simples, efetivo e de fácil manutenção.

Vamos ser justos

Sempre que você pensa que estourar um tempo não é um problema, se coloque no lugar da empresa: imagine que, sempre que seu empregador quiser, vai exigir de você que fique mais tempo depois do seu expediente regular, sem te pagar hora extra ou oferecer algum outro tipo de vantagem. Isso é o mesmo que acontece com orçamentos que estouram: eles saem mais caro para a empresa.

Se o valor extrapolado do orçamento não é descontado do seu salário, então está na hora de você mudar.