Este documento fornece dicas e estratégias para desenvolvedores se tornarem profissionais melhores. Ele enfatiza a importância de focar na simplicidade, testes, comunidades e soft skills. O documento também discute como evitar armadilhas como reinventar a roda e manter o código limpo e organizado.

1. EUquipe,
evoluindo como
dev
Alan Zanatta | @alanzanatta

2. Olá mundo!
● Tecnólogo em Análise e Dev de Sistemas -
UNIPAR
● MBA em Gerência de Projetos em T.I - FCV
● Analista de Sistemas - Matera
● Ex professor
● Investidor iniciante
● Amante de futebol
● Se aventurando no mundo custom

3. Pergunta
Quem aqui veio acreditando que essa seria mais uma talk
de Clean Code?

4. “Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo.” - Manifesto Ágil
Mas, na verdade, a maior parte do tempo estaremos
sozinhos: nós e a máquina. Essa é a hora de nos
fortalecermos como indivíduos.
Objetivo da talk

5. Por que EUquipe?
Equipe é um conjunto ou grupo de indivíduos aplicados
na realização de uma mesma tarefa ou trabalho.
EUquipe é você e um conjunto de skills (hard e soft)
necessárias, que de fato irá aplicar na realização de uma
tarefa ou trabalho.

6. Tenha sua razão e lembre-se dela
Qual foi a razão pelo qual
você escolheu ser dev?
Programação é difícil e às
vezes você fica frustrado.
Será essencial manter
esse motivo em mente
para cumpri-lo.

7. A Ilusão das Novidades Rápidas

8. A Ilusão das Novidades Rápidas
Bits, computação, latência
Modelo de Turing, Associativo FPGAs, GPUs
Paradigmas - Estruturado, OO,
Reactive Funcional, Blockchain
Linguagens
Frameworks
Bibliotecas
Componentes, Features

9. Seja especialista em no mínimo uma linguagem

10. Mas cuidado!
Se tudo o que você tem é um martelo, tudo parece um
prego.

11. Pergunta
Qual a primeira coisa mais ?

12. As pessoas!

14. Não seja a vergonha da profisson
De um lado, vemos muitas pessoas de
mente aberta que contribuem para a
comunidade (projetos open source, palestras,
escrevendo artigos). Por outro lado,
encontramos pessoas que trollam novas
idéias, desrespeitam os recém-chegados e
demonstram comportamento rude com
todos ao seu redor.

15. Seja uma pessoa legal

16. Participe de comunidades
● Pessoas com o mesmo
interesse
● Compartilhar
conhecimentos
● Temas diversos
● Networking
● Ser lembrado
● Falar em público
● Conteúdos de altíssimo nível
e de graça

17. Participe de comunidades
● Lista de grupos no telegram
● Meetup.com
● TDC (The developers Conference)

18. Ensine-se a si mesmo
Atualmente, não faltam
materiais de aprendizagem,
online, offline e de graça :)

19. Algumas ideias de estudo

20. A desordem gera desordem
A teoria das janelas quebradas (por James Q. Wilson e George
Kelling)
1 dia 1 mês depois 1 ano depois

21. Dívida técnica

28. Descubra um jeito de pagar a dívida
Uma delas é a qualitividade (Por Klaus Wuestefeld):
● Alocar 20% ~ 50%
● Mandato: “Trabalhar na simplificação do código, do
processo e das ferramentas para maximizar a própria
produtividade.”
● Autonomia / Apoio

29. Precisamos ser profissionais, de fato!
“A diferença entre um trabalhador e um profissional é
que um trabalhador recebe ordens de seu chefe e um
profissional fornece informações aos seus
superiores.” - Uncle bob

30. Precisamos ser profissionais, de fato!
Paciente: “Meu braço dói.” Médico: “O que você
gostaria que eu fizesse?” Paciente: “Faça meu braço
parar de doer.” Médico: “Você quer que eu o
corte?”, Eu posso fazer isso.” paciente: ‘Não, eu só
quero que ele parar de doer.’ Médico: “Eu poderia
cortar todos os nervos de seu braço. Isso vai
impedi-lo.” Paciente: “Não há algo menos drástico
que você possa fazer? ” Médico: “ Opa, desculpe,
hora do meu descanso.”
fonte: https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/saying-no

31. Precisamos ser profissionais, de fato!
Paciente: “Quero que você corte meu braço.” Médico:
“O que há de errado com seu braço?” Paciente: “Dói.
Estou cansado disso. Apenas pare com isso. ” Médico: “
Deixe-me ver seu braço. Hummm. Parece que você
tem uma entorse ou talvez uma fratura na linha do
cabelo. Deveríamos tomar alguns raios-X. ” Paciente: “
Não, apenas interrompa. ” Médico: “Senhor, eu não
cortei braços saudáveis. ” Paciente: “Mas estou
pagando. Você tem que fazer o que eu digo! ” Doutor: “
Não, senhor, eu não faço. Cortar seu braço violaria
meu juramento.

32. Não reinvente a roda

33. Não reinvente a roda

34. Não reinvente a roda

35. Foque na simplicidade
"Simplicidade é um pré-requisito para
confiabilidade". - Edsger W. Dijkstra
“Coisas simples são focadas, elas não
tratam de vários problemas”
“Muitas vezes, os desenvolvedores dizem
que algo é simples, mas eles querem dizer
fácil, porque querem dizer que é algo com
o qual estão familiarizados.”
Rich Hickey - Criador do Clojure

36. Foque na simplicidade
“Se alguém escolhe facilidade, as coisas se
movem rapidamente, mas a complexidade
acumulada matará o projeto ao longo do
tempo. Se a simplicidade é escolhida, o
projeto começa mais devagar porque é
preciso pensar sobre as coisas.”
"Os benefícios da simplicidade são:
facilidade de entendimento, facilidade de
alteração, facilidade de depuração,
flexibilidade.” Rich Hickey - Simple Made Easy

37. Grady Booch:
Código limpo é simples e direto.
Código limpo parece uma prosa bem
escrita. O código limpo nunca
obscurece a intenção dos designers,
mas é cheio de abstrações nítidas e
linhas de controle diretas.

38. David Thomas:
O código limpo pode ser lido e
aprimorado por um desenvolvedor
que não seja o autor original. Possui
testes de unidade e aceitação. Tem
nomes significativos. Ele fornece
uma maneira e não muitas
maneiras de fazer uma coisa.

39. Michael Feathers:
O código limpo sempre parece que foi escrito
por alguém que se importa. Não há nada óbvio
que você possa fazer para melhorar. Todas essas
coisas foram pensadas pelo autor do código e, se
você tentar imaginar melhorias, será levado de
volta para onde está, apreciando o código que
alguém deixou para você - código escrito por
alguém que se preocupava profundamente
com o ofício.

40. The good code
Não estresse o seu eu do futuro, FAÇA um código bem feito :)

41. Mostre o seu código para alguém

42. Mostre o seu código para alguém

43. Dicas
SOLID | Design Patterns
YAGNI | BDUF X Enough
KISS (Keep It Simple)
Object Calisthenics | Tell don’t ask
OWASP | Separation of Concerns
https://martinfowler.com/
https://blog.cleancoder.com/
https://refactoring.guru

44. Faça testes!
TestPyramid - Martin Fowler

45. Ferramentas de análise de código estático
“Eu gosto de pensar nas ferramentas de revisão de código
como sentinelas; eles cuidam de você enquanto você
escreve seu código e, de tempos em tempos (pré e / ou
pós confirmação, dependendo da ferramenta específica),
eles informam como você pode melhorar seu código” -
Autor desconhecido

46. XP > XGH

47. Checklist do Dev

48. Conheça bem suas ferramentas de trabalho

49. Soft skills

50. Soft skills
Tenha a sua razão
Foque mais nas
montanhas
Seja especialista
Não use apenas
uma ferramenta
Ajude e seja ajudado
Não quebre janelas
Dívida técnica
Seja profissional
Não reinvente a roda
Foque no que é simples
Mostre o seu código para
alguém
Informações direto
da fonte
Ferramenta de análise de
código
Usar bem as ferramentas
Práticas ágeis Checklist
Testes

51. Por fim...
Software é difícil, não deixe que as pessoas lhe digam o
contrário. Quando você faz isso o tempo todo, você se
prejudica, mesmo que não perceba.
Cuide da sua saúde mental, seu cérebro precisa de uma
pausa, isso também faz parte da sua evolução.

52. Algumas referências
● THE WAY TO SOFTWARE MASTERY - Klaus Wuestefeld
● Simple Made Easy - Rich Hickey
● https://sites.google.com/site/unclebobconsultingllc/ -
Uncle Bob
● https://www.manifestoagil.com.br
● Broken windows theory - James Q. Wilson e George
Kelling
● https://martinfowler.com/

53. Thanks!
@AlanZanatta
alanpaulozanatta@gmail.com

54. Hora do jabá
Vagas: https://jobs.kenoby.com/matera
Venha conhecer nossa nova sede!