Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
January 15, 2023 12:18 am GMT

Compilado dicas de carreira - parte 1

Ol pessoal, a pedidos eu decidi compilar as dicas em artigos. Nesse artigo eu vou compilar as primeiras 10 dicas.
As dicas sobre entrevistas em big tech eu vou postar em um artigo parte. Vamos l?

Dica #1 - Onboarding em um time novo

Sempre que entrar em um time novo, procure entender onde esto as mtricas e dashboards e onde esto os logs. Isso ajuda muito a entender a stack e se preparar pro oncall. Como colateral, voc verifica a ops do time e onde vocs podem melhorar.

Dica #2 - Gentileza em code reviews

Seja gentil em code reviews, existe um ser humano do outro lado. D sugestes quando possvel e tente fazer mais perguntas pra tentar entender a lgica da outra pessoa. Elogie as partes que voc acha legal.
Se algo for crtico/blocker, explique o problema. Proponha uma sugesto ou se for complexo demais, proponha um pair programming pra resolver o problema juntos. O principal intuito de code reviews a colaborao.

Dica 3 - O que monitorar em um sistema?

No sabe o que monitorar no seu sistema? Que tal comear com os 4 "golden signals"?

  1. Latncia,
  2. Trafgo (rps),
  3. Errors,
  4. Saturao (CPU/memria/disco/network).

E por favor, NO monitorem a mdia. Olhem os "percentiles" p50, p90, p99.
Curiosidade: Embora eu tenha aprendido a usar essas mtricas s recentemente eu aprendi que elas eram chamadas do 4 "golden signals". Acabei aprendendo quando eu fiz uma entrevista e o entrevistador mencionou isso pra mim .

Dica #4 - O que fazer quando o alarme de oncall toca?

Quando o pager tocar, tente estancar o sangramento primeiro. Procure a "root cause" depois. Um bom exemplo disso , rolou deployment recente? Faa o rollback. Rollback feito, anlise se o problem foi embora.

Um erro comum ficar tentando identificar o que aconteceu de errado, nisso se passa 1 - 2h de usurios sendo impactados. A melhor estratgia fazer rollback pra eliminar de cara a chance de ser um erro novo.

O mesmo vale para suas dependncias. Se o erro t vindo de uma dependncia, questione se houve um deployment e pea pra fazer rollback. Uma vez, a dependncia ficou negando por horas que o erro no era com eles, eu achei um deployment, fizemos rollback e o erro foi mitigado.

Erro mitigado, podemos gastar o tempo necessrio para analisar a root cause e corrigir o erro de uma vez por todas. Note que rollback apenas um exemplo, as vezes, rodar um comando manual na mquina ou qualquer outra interveno manual pode ser o passo de mitigao.

Dica #5 - Monitore suas dependncias

Monitore suas dependncias no dashboard. O que monitorar? Throttling, error rate e latncia um bom comeo. Por qu? Reduz o teu tempo de reao. Imagine voc ser pageado 3am e ao abrir o dashboard voc j v o servio X retornando 500. Bem mais rpido do que ir caar logs n? Outro uso bacana fazer load testing e rapidamente identificar no teu dashboard quais dependncias que so o gargalo da tua aplicao.

Dica #6 - Desconfie da frase " seguro, ns j fizemos isso antes"

Desconfie da frase "... seguro eu/ns j fiz isso 1000x (ou mais) antes...". No porque algo deu certo antes que vai dar certo de novo. Exemplo, em 2017 um SDE do AWS rodou um script e derrubou o S3 (https://go.aws/3Fcnda8).

Revise seus procedimentos, automatize e teste. Insista que as coisas podem dar errado e tente pensar "o que pode dar errado?". No confie no histrico do passado, um dia a sorte pode acabar.

Dica #7 - Utilize o protocolo de 2 pessoas para mudanas manuais em produo

Evite tocar em produo manualmente, mas se for realmente necessrio, faa a mudana seguindo o protocolo de "2-person rule". Em resumo, 2 pessoas executem a mudana juntos, tais quais filme para ativar cdigos nucleares.

Pessoa 1: "Executando script xpto na tabela y, ok?"
Pessoa 2: Verifica e confirma.

Esse protocolo se tornou bem difundido no AWS depois do evento no S3 (ver dicas anteriores). Para uma boa 2-person rule execute os passos devagar, perguntando por confirmao do seu peer.

Se a mudana for muito complicada, eu recomendo escrever uma "checklist de mudana" mas essa eu deixo para uma futura dica. Finalmente, se voc est pensando "nossa, tudo isso?". Pois , melhor automatizar para evitar ficar tocando em Prod n?

Dica #8 - Faa uma ata da reunio

Anote o que discutido na reunio, qual foi a deciso, se existem "action items" E QUEM responsvel por cada um deles. Depois da reunio envie as anotaes pros participantes pra todo mundo ficar alinhado com os prximos passos.

Se voc est ocupado discutindo e no pode anotar, pea para algum se voluntariar pra anotar. Essa "besteira" j evitou tanto mal entendido. Eu tambm j vi no ser feito e as pessoas perderem horas discutindo porque ningum lembrava o que foi acordado.

Um template bacana que eu uso:

  • Lista com principais pontos discutidos.
  • Lista de prximos passos e para CADA um eu coloco um "responsvel: ", por exemplo, "Enviar o dica #8. Owner: Hugo".

Isso serve para todos ficarem cientes de quem tem que fazer o que.

Dica #9 - Aprenda a usar suas ferramentas

Otimize suas ferramentas. Gosta de usar Vim? Aprendar a usar Vim de uma forma eficiente. Gosta de IDE? Aprenda os atalhos e os comandos que sua IDE te oferece. Pode parecer besteira mas no longo prazo isso vai te salvar muito tempo.

xemplo real: Mais uma de vez eu fui chamado pra ajudar algum com um bug. Chegando l a IDE da pessoa estava toda vermelha, nada compilava, basicamente um editor de texto mais lento. Eu ajeitei a IDE e na hora o erro foi acusado pela IDE.

A regra se aplica a qualquer ferramenta que voc esteja usando com frequncia: terminal, CLI, IDEs. Aprenda os atalhos, evite repeties, configure a ferramenta pra fazer o seu tempo ser mais eficiente.

Dica #10 - O que eu fiz nos meus primeiros 90 dias no Twitter

Disclaimer: Eu no estou mais no Twitter mas a dica ainda vlida mesmo assim.

Meus primeiros 90 dias no @Twitter como Sr SWE foram:

  1. Perguntas, perguntas e mais perguntas.
  2. Assuma que tudo tem um motivo em vez de chegar "no trampo antigo a gente faz Y e funciona".
  3. Pergunte pra todo mundo, Jr, Pleno, Snior, Staff.
  4. Tenha pacincia, com o tempo a produtividade e velocidade voltam.
  5. Eu gasto um bom tempo investigando como as coisas so feitas ao redor da empresa e no apenas no meu time. Eu leio docs, procuro em wikis, toma um bom tempo mas as vezes acho coisas interessantes.

Concluso

isso a, aguardem que vou compilando o resto das dicas em breve.


Original Link: https://dev.to/hugaomarques/compilado-dicas-de-carreira-parte-1-kif

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To