Canal do Moa

A Python Sudeste aconteceu entre os dias 30 de Março e 01 de Abril de 2018. 

No fim do evento eu estava tão feliz com todos os amigos que havia revisto e com os novos amigos de infância que conhecia pela primeira vez, que prometi a mim mesmo que faria um post sobre o assunto. 

Inspirado neste post eu resolvi gravar um vídeo te contando porque você DEVE frequentar eventos de programação!

Eu era uma criança completamente fascinada por saber como as coisas eram feitas. Como o som sai desse rádio? Como o motor do carro liga? Como a televisão funciona?

Quando eu tinha uns 7 anos, meu pai apareceu em casa com um computador. Eu fiquei maravilhado.

O tempo passou e veio a internet. Meia noite em ponto eu conectava o modem e começava a navegar por aquele mar de informação. Tudo novo, tudo mato.

Que nostalgia...

Olhando para essa trajetória, o resultado não poderia ser diferente. 17 anos de idade, qual vestibular prestar? Análise e Desenvolvimento de Sistemas, óbvio. Lá na faculdade tive a oportunidade do meu primeiro estágio. Finalmente eu comecei fazer coisas que outras pessoas usariam. Minha arte teve contato com o público!

Foi nessa época também que eu senti o gostinho de ganhar meu próprio dinheiro. Eu comecei a ganhar uma grana legal relativamente cedo. A carreira de tecnologia paga bem, fato.

Eu sempre tive interesse pelo dinheiro, pelo sucesso financeiro. Eu sempre quis mais. E eu percebi que havia uma espécie de teto. Para conseguir salários maiores eu fatalmente teria que me tornar um gestor. Dificilmente se via um programador ganhando um salário nesse nível. O cara precisava ser um gênio. Coisa que eu nunca fui.

Paralelo a isso, sempre tive um certo conflito interno. "O cara que ganha dinheiro com certeza está passando a perna em alguém". Quantas vezes você já não ouviu isso?

Eu queria ganhar dinheiro, mas não queria ser cuzão. Como fazer isso?

Foi quando, no auge do meu conflito interno, conheci grandes amigos que me ensinaram lições valiosas sobre como lidar com a carreira de tecnologia e como lidar com o dinheiro, em si.

Ouça o episódio que eu resolvi falar mais mais sobre essas lições.

O diretor da empresa precisa desenvolver o novo projeto. Ele chama o gerente de projetos, passa o escopo e o objetivo. O gerente de projetos chama a equipe e começa a planejar.

Com todas as ideias em mãos e documentadas em vários gráficos, fluxos e diagramas, a equipe começa a planejar a execução. Banco de dados, servidores, telas, funcionalidades, módulos, cadastros, automações. Tudo isso é definido e planejado o queremos surpresas.

Vamos para a execução? Quanto tempo vai demorar? Uns seis meses. Mas o prazo é três e já se passou um. Vamos apertar o passo.

Sem o projeto começar eu já consigo prever alguns resultados:

A equipe vai virar a noite para entregar. Como o tempo é curto e a equipe é pequena, a qualidade do código vai ser uma merda. Testes? O que é isso?

O mais temido acontece: o projeto atrasou. Os 3 meses viraram 6 meses.

Temos aqui um exemplo clássico de como NÃO planejar e executar o desenvolvimento de um software.

Mas, se você trabalha com desenvolvimento de software, sabe que é assim que quase todos os projetos são feitos.

Mas, por quê? E, o principal, como evitar? Assiste o vídeo que eu tenho uma solução!

Quando desenvolvemos software, vivemos em um ambiente de extrema incerteza, em um nível muito alto de abstração. Por causa disso, a chance de cometermos erros por causa de mal-entendidos é muito grande.

Perante a este cenário, nós temos duas alternativas plausíveis:

1) Planejar minuciosamente todos os nossos passos, considerando todas as variáveis possíveis para assim evitarmos estes erros;

2) Abraçar o erro como parte do processo e então trabalhar de forma empírica, elaborando e validando hipóteses.

No primeiro cenário, nós dedicamos grande parte dos nossos recursos ao planejamento. Diria que até a maior parte. A engenharia civil é um bom exemplo deste cenário.

Porém, não podemos utilizar outras engenharias como parâmetro. Você não consegue mover um prédio de 10 andares um pouquinho para a esquerda. Mas você, tranquilamente, consegue mudar o banco de dados de um sistema, por exemplo.

Software, por ser abstrato, é altamente mutável!

Além disso, nós vivemos em um mundo com recursos escassos. Nosso tempo é finito, nosso dinheiro é finito.

E quando os recursos não são suficientes? E se errarmos no planejamento?

O primeiro cenário trata-se de uma grande aposta de recursos. Você está apostando a maior parte dos dois mais importantes: tempo e dinheiro. O risco é altíssimo!

Por isso eu defendo o segundo cenário.

Já que software tem alta capacidade de mudança e nós não sabemos o que o nosso cliente quer, vamos usar essas características a nosso favor!

Mas, como trabalhar em um ambiente de extrema incerteza, "sem planejamento" e com eficácia?

Eu explico no episódio de hoje!

Se você é aquele tipo de programador que pensa que o seu código está pronto quando você faz o commit para o repositório, sinto lhe dizer mas você está errado.

Eu sei disso porque eu também já pensei dessa maneira. Por muitos anos eu pensei que o papel do programador era entregar código. Hoje eu vejo que eu estava errado. O papel do programador não é escrever código. É resolver problema.

A única constante no mundo é a mudança. O software, de uma maneira genérica, tem como objetivo facilitar processos do mundo real. Se o mundo está mudando a todo instante, o software deve, necessariamente, mudar também para continuar gerando valor.

Mas meu objetivo não é falar do software como uma forma abstrata. Eu quero descer um pouco mais o nível e falar sobre as funcionalidades que compõem um software. Mais especificamente sobre o código que compõe essa funcionalidade.

Quando a gente pode considerar que um código foi entregue? Eu resolvi fazer esse vídeo para refletirmos sobre esse questionamento.

Quantas vezes você já ouviu a expressão "Às vezes, o barato sai caro"?

Por que a grande maioria das pessoas preferem pagar 3x, 4x mais em um tênis da Nike ao invés de um tênis sem marca?

Por que muitas pessoas preferem pagar MUITO mais caro para fazer a manutenção dos seus carros em uma concessionária ao invés de levar no mecânico do bairro?

Porque a Disney, ou o Starbucks fazem muito mais sucesso do que o parquinho ou a padaria da esquina?

A resposta é simples: Credibilidade.

Você sabe o que é credibilidade? Você sabe como conquistar credibilidade? E, o principal, você é uma pessoa com credibilidade?

Então dá uma olhada nesse vídeo que eu respondi todas essas perguntas.

Ao longo destes 10 anos de desenvolvimento de software, eu já me deparei com quase todo tipo de situação.

Dessas situações, teve uma que me marcou pro resto da vida.

Eu tinha passado toda minha vida profissional trabalhando com PHP e Python. Já tinha tido contato com Java, Dotnet e outras linguagens mais corporativas. Com nenhuma delas eu tinha me dado tão bem como com Python.

Pra mim, a melhor linguagem de programação definitivamente era Python.

Foi quando eu vi que tinha uma galera ganhando MUITO mais dinheiro com outra "linguagem de programação". Coloco entre parênteses porque nem linguagem era, era uma espécie de framework.

Quando eu vi isso fiquei muito intrigado e fui bater um papo com meu chefe sobre como eu poderia aprender aquela linguagem.

A reação dele foi completamente diferente do que eu esperava. A resposta dele mudou completamente minha forma de pensar.

Depois de mais de 5 anos desse fato eu resolvi gravar esse vídeo e falar sobre como eu descobri qual é a melhor linguagem de programação.

Vivemos na era das startups. A receita é simples: você tem uma ideia inovadora e disruptiva; consegue o investimento necessário para transformar sua idéia em uma empresa; seu produto viraliza e explode; você vende seu negócio para o Mark Zukemberg.

Foi isso que aconteceu com o Instagram, com o Whatsapp e mais umas seis outras startups, pelo menos.

Parece o cenário ideal, ter o Facebook como o seu investidor. Ou melhor: como o comprador do seu negócio!

Mas será que na vida real funciona dessa forma?

E se o dinheiro acabar antes do Tio Mark querer comprar minha ideia? E se ele não quiser comprar minha startup? Aliás, como eu consigo dinheiro pra implementar a minha ideia?

Mas relaxa, eu encontrei a solução!

Quando a gente começa a planejar um novo projeto, um novo produto ou até mesmo um novo negócio, as possibilidades são infinitas, né?

Temos várias ideias, desenhamos várias telas, imaginamos milhares de usuários utilizando nosso software.

Só tem um problema com tudo isso: O papel aceita tudo!

Você não deve criar o que você acha que deve ser feito, você deve criar o que o seu cliente quer.

E já te digo de cara: Não, você NÃO SABE o que o seu cliente quer.

E só tem uma forma de saber o que o seu cliente quer: Perguntando pra ele!