Anontações sobre a carreira de programação

00_carreira.md

👜 Chega um momento em que voce precisa dar um jeito de ser quem lidera projetos de software de ponta a ponta.

👜 Muitas pessoas evoluem muito tecnicamente, mas a falta de hábilidades de lidar com cliente e melhorar soft skills fazem a diferença entre o pleno e o senior.

👜 Senior não é só ter conhecimento técnico, é ter experiencia em diferentes tipos de problemas e soluções.

👜 É sempre importante estudar técnicas de refatoração. Pensar em mais soluções para um problema e escolher a menos complexa.

Alguns desenvolvedores são mais populares do que outros simplesmente porque compartilham o que sabem

As pessoas ao seu redor afetam a sua performance

Planejamento de carreira guiado pelo medo provavelmente o levará a um cubículo para o resto de sua vida. Apesar de ser seguro, não é divertido. Pessoas grandes assumem riscos

O que um programador NÃO deve fazer

1. Não se atualizar

2. Estudar várias coisas ao mesmo tempo

3. Permitir falta de equilibrio entre prática e teoria

4. Não buscar referencias de algo pronto antes de implementar a feature

5. Deixar código sujo para trás, pois isso criará uma bola de neve

6. Não colocar comentários em partes criticas do código

7. Não entender padrões e técnicas de código limpo

8. Não realizar backup do banco de dados

9. Não ter graduação na área ou um curso tecnico, pois seu poder de negociação será muito baixo (não concordo)

10. Não ter conhecimento básicos de design

11. Não ter conhecimento em linguagens para o mobile (concordo em partes, o seu nincho pode ser outro)

Especializações

Perder o medo do backend (ou de qualquer stack) é importante para continuar crescendo. É importante como dev conseguir "tocar" e participar das decisões em todas as partes do projeto e não gerar gargalos.

01_notes.md

📝 As coisas levam tempo pra acontecer, e intensidade nem sempre é a resposta. Os hábitos que voce escolher cultivar (ou não cultivar), vai determinar o seu futuro.

📝 Aceite o fato de que voce não vai aprender tudo.

📝 Aceite o fato de que o que é "novo" nem sempre é o "melhor".

📝 Foque nos fundamentos. Vai ser sempre mais dificil quando não se tem a base.

📝 Estude para não faltar profundidade tecnica.

📝 Trabalhe, porque voce não poderia simplesmente não trabalhar.

📝 Voce pode fingir por um tempo, mas a falta de paixão vai encontrar voce e o seu trabalho em algum momento.

📝 Pense sobre as partes que voce entende por completo no seu trabalho e se faça 2 perguntas: Como isso funciona e Por que deveria funcionar assim?

📝 Endenda como um negocio se torna lucrativo.

📝 Quanto mais programadores há no mercado, maior é a concorrencia.

📝 Um erro é se apegar a uma linguagem sabendo como usá-la e não o porque, fazendo com que exista uma dificuldade em mudar de linguagem/ferramenta.

📝 Aprendendo a aprender a se virar! Nada do que não te faça sentir dor vale a pena. As frustrações vão acontecer. Muitas vezes, a sua frustração vem da sua falta de dedicação.

📝 Temos que investir tempo em nossa profissão.

📝 Voce não pode praticar/estudar no emprego. Tire outro momento para isso.

📝 Cursos, livros e tutoriais nada mais são do que "passo a passo" para ganhar um certificado. Eles nada mais são do que um resumo da documentação.

📝 Vai ser sempre mais dificil quando não se tem a base.

📝 Desenvolver as coisas "na mão", ajuda a entender porque alguns soluções prontas surgiram e quais problemas elas resolvem

O que esperar de coadjuvantes (chefes, pessoas com mais experiencia)

• Fornecimento de orientação, apoio nos programas de desenvolvimento e feedback a respeito de suas habilidades

G definir objetivos R entender a diferença entre como estou e aonde quero chegar O o que voce pode fazer W montando um plano de ação

Geralmente a descrição da vaga é um ideal de candidato, o que precisamos nos atentar é nos requisitos obrigatórios.

Tentar aproveitar as oportunidades, mesmo estando em pequenas empresas. O currículo conta uma história.

02_equipe.md

📝 Uma equipe é boa quando composta de 3 a 9 pessoas, pois em menor ou maior proporção, pode haver perda na capacidade de colaboração e comunicação.

📝 É normal ter que equilibrar as entregas e apoiar os mais novos.

📝 Qualquer processo repetitivo deve ser automalizado, se não, não será utilizado pela equipe.

03_estudos.md

04_mercado.md

05_projeto.md

Over Engineering é o processo de adicionar soluções muito robustas para um sitema que terá pouca sobrecarga. O inverso também é um projeto, onde são desenvolvidas soluções "fracas", ou seja, insuficientes para lidar com a sobrecarda de um sistema. Isso pode acontecer principalmente quando o produto cresce e não há um planejamento para lidar com isso.

Estimativas

🕐 Não dá para colocar no planejamento apenas o tempo que o time técnico acha que vai conseguir entregar.

Board

📖 Um board envolve: organização dos cards, priorização do backlog e definição do ritimo de entregas.

Setup de um projeto novo

Pontos para nos preocupar na fase inicial do projeto:

📝 Setup de testes (back + front)

📝 Configuração do banco

📝 Reset/Normalize do css, assim como a escolha de usar um design system pronto ou se ele será desenvolvido

📝 Configuração do papiline

📝 Configuração de eslint

Dependências

Escolhas de dependências: verificar se ela é atualizada e se ela de fato resolve nossa demanda (ou seja, se precisamos customizar muito, pode não ser uma boa ideia)

Perguntas para ajudar na escolha da stack

1. Qual seria a macro-arquitetura da solução? Monolitica, modular ou microservices?

2. Como seria feito o deploy no frontend? Está no mesmo build/disc do backend ou seria possível deployar um artefato separado (por exemplo, utilizando Cloud Front)?

3. Qual seria a arquitetura dos processos de integração com outros sistemas? Quando necessário

4. Seria possível centralizar os acessos as API's da aplicação utilizando API Geteway?

06_cliente.md

🙋 Do ponto de vista financeiro, o custo de manter um cliente é em média 7% do valor de ter um novo.

🙋 Evite cometer erros sequenciais em um curto periodo de tempo para evitar que o cliente perca a confiança em sua empresa/time/etc.

🙋 Tome cuidado com o silencio do cliente, pois pode indicar (no melhor dos casos) que ele está buscando um concorrente, ou até mesmo um processo judicial. Apesar de contraditório, é bom sinal quando o cliente continuamente trás feedback, tem anseios pelas entregas, pois indica que ele está engajado no projeto.

🙋 Quando não for possível entregar na data, de as devidas justificativas e uma alternativa do que pode ser entregue no momento.

🙋 Adiar é melhor do que entrega com defeitos. Se não haver saída, deixe o cliente ciente de tudo o que não foi entregue conforme o combinado. Não o faça ter surpresas.

🙋 Uma refatoração deve ser seguida de um objetivo, se não parece que o desenvolvedor vai ficar "um tempão fazendo código que ninguém sabe para que serve e no final não vai gerar nenhum resultado"

07_portfolio.md

📚 Desenvolva projetos autorais que tenham a ver com o que existe em demanda no mercado.

📚 Caso queira desenvolver um projeto de frontend e não tenha conhecimento em UX/UI, não tente criar telas da "sua cabeça", baseie-se em projetos de outros designers.

📚 Tenha um bom perfil de Likedin e Github a ponto das pessoas olharem e pensarem: Como assim voce ainda não está na minha empresa?

📚 Ao invés de reclamar das qualificações exigidas, que tal se qualificar?

08_processos.md

Daily

📝 As perguntas a serem respondidas na daily podem ser:

• O que falta para terminar o card?
• Existe algum impedimento?
• Falta informação que dificulte/impeça a finalização do card?
• Esse card tem alguma dependencia?
• Porque o card está envelhecendo?

Dica: separar 10 minutos antes da daily para pensar e listar esses pontos antes de entrar