BUD/S

• Basic Underwater Demolition/SEAL
  • É um treinamento muito árduo
  • Poucos entram
  • Poucos ficam até o fim
  • Leva você a conhecer os próprios limites

Codar = BUD/S

• Basic Underwater Demolition/SEAL
  • É incrível!
  • E todo SEAL fez, então ninguém dá bola.
• Codar é incrível!
  • E todo mundo faz, então ninguém dá bola.
  • Codar é a estaca zero.
    • E às vezes até atrapalha!

"Soft" skills?

• Não!
• São parte integral do que se espera de você.

Minha situação atual

Eu gostaria que meus colegas passassem

menos tempo

escrevendo código.

Só codar é geralmente PÉSSIMO

• Média: 70 bugs a cada 1.000 linhas
  • Média: 15 chegam até o usuário
• Corrigir um bug custa 30 vezes mais
• Média: 75% do tempo corrigindo bugs
• Média: 115 bilhões de dólares gastos anualmente encontrando e corrigindo bugs

• 1.000 horas
  • 250 horas = código
  • 750 horas = bugs
• Bugs nem sempre são de design
  • Especificação ruim
  • Entendimento ruim
  • Arquitetura ruim
• 1 hora salva dos bugs = +3 horas para codar
  • 2 horas garantindo que não haverá bugs
    • = +1 hora para codar
• Ou seja: sejamos melhores que a média!

Para o líder da equipe

• Visibilidade > Habilidade
  • Comunicar que não sabe é mais importante do que saber
  • Ideal imaginário: "ele sabe de tudo!"
  • Ideal real: "se ele não souber ou tiver dúvidas, posso contar que ele vai me dizer!"

(e para o restante da equipe)

Um dia depois da reunião...

• Você entendeu?
• É, na verdade fiquei com algumas dúvidas
• Então por que não perguntou???

Comunicar O QUE você não sabe

• Para aprender, é necessário fazer as perguntas certas
  • Ou, no mínimo, saber fazer perguntas
• O aprendizado é uma via de mão dupla
  • Quem ensina precisa de feedback
  • Quem aprende precisa ser capaz de dar feedback

Comunicar o que você entendeu

• Importante para confirmar que todos estão na mesma página
• Saber escrever User Stories é uma habilidade magnífica (ajuda o time muitão)
• "Se não fosse a documentação, a gente tava na roça"

Exercícios

• Escrever!
  • Descrição inicial de funcionalidades
  • User Stories
• Desenhar
  • Diagramas Entidade/Relacionamento
  • Diagramas de sequencia
• Isso tudo te obriga a estruturar suas ideias.
  • Abstrato → Concreto

Diagrama E/R

Diagrama de Sequência

Estando tudo claro...

• agora é a hora de começar a codar.

Sem processo, não rola

• "Vai codando aí que mês que vem a gente vê no que deu"
• Se você está num lugar assim: fuja!

Processos iterativos

• Prioridade: você saber o que está fazendo.
  • Porque temos a tendência natural de nos perder.
  • Por isso "batemos o bumbo" todo dia.

O processo permeia tudo

• Abrir novo galho (branch) no repositório
  • Qual será o nome?
• Abrir MR (merge request)
  • Vou explicar como?
• "Passei o dia fazendo code review"
  • Absolutamente okay!
• "Tá pronto, só não testei"
  • Isso não existe.

Não existe "a minha entrega"

• Ajudar o colega a entregar é bom para todos
  • "Passei o dia revisando código" = ok!
• Você também vai precisar da ajuda dos outros

Não existe "meu código"

• Código não pode ter dono
• Todos devem ser substituíveis
• Código é escrito para ser lido por humanos
  • Escreva código banana, não código manga.

Olhar além do design

• Não perca a floresta olhando para a árvore
• Arquitetura
  • Como os componentes estão dispostos
  • Como a informação flui
  • Como meu código se insere nessa arquitetura
• Negócio
  • Quem é o cliente
  • Qual é a necessidade do cliente
  • Qual a melhor forma de atendermos essa necessidade

Entenda o todo

• Ou sua parte não se encaixará!

Choose your destiny

• "Vou só fazer o que me mandam"
• "Vou olhar além do código"

Motivação

• Maestria
• Autonomia
• Propósito

Mas não pule passos

• Se design é difícil, primeiro fique bom nisso!
• (Só não trate como se isso fosse tudo.)

Não precisa resolver TODOS os problemas do universo!

• A maioria já está resolvida.
  • Use serviços externos.
    • Infra
    • E-mails/SMS/WhatsApp
    • Chat
    • Filas
    • Push notifications
    • Et cetera...
  • Use bibliotecas de terceiros.
    • Algoritmos em geral

Desenvolvimento de Software é um vetor de N posições

• Arquitetura
• Design do código
• Ferramentas
• Design da interface
• User experience
• Negócio
• Marketing
• Tendências
• Processos
• Financeiro
• Pessoas
• Expectativas
• Comunicação

Sentir-se dono

• Te faz trabalhar bem
• Ajuda a enxergar propósito
• Todos saem ganhando
• Ajuda a tomar as melhores decisões

Dogmas?

• Algumas vezes é necessário tomar decisões difíceis
  • Entregar 3 funcionalidades sem testes
  • ou entregar 1 com testes?
• Corrigir o bug
  • ou terminar a tarefa atual?
• Criar uma biblioteca do zero
  • ou usar outra linguagem de programação?

Decisões

• Quais os efeitos de curto, médio e longo-prazo?
  • E os custos?
• Quais as vantagens?
  • E os riscos?
• Perco um cliente agora para ganhar mais depois?
  • Ou não tem como pagar os salários sem ele?

Não tem como dizer

"eu não tenho nada com isso"!

Contra-exemplo

• O cara que criou sua própria fila
  • Request → Response + mensagem
  • Já resistiu na questão da assincronia
  • NIH syndrome
    • (not invented here)
  • Fez direto no banco de dados
  • Opções:
    • AWS SQS
    • RabbitMQ
    • NATS
    • Kafka

O segredo dos seniores

• "Conceitos muito avançados" - NOPE!
  • Sempre busca-se a abstração mais simples
    1. estruturas de dados simples
    2. classes
    3. módulos
    4. metaprogramação | DSL | Actor model
    5. múltiplos serviços
  • Sempre busca-se o código mais simples
  • Menos linhas é sempre melhor

Bom código

• É estupidamente claro.
• É mais simples do que você pensava originalmente
• Se o problema é complexo, apresenta uma solução razoável

UX

• Todo código é uma API
• Procure fazer APIs elegantes
• Use técnicas de UI/UX
  • Seja coerente
  • Evite surpresas
  • Seja simples
    • Mesmo sem ser simplista