Executando verificação de segurança...
6

Se você veio deste vídeo, queria aproveitar para expandir um pouco o motivo da comunicação ser uma grande parte do que eu conquistei na minha carreira.

A idéia principal é perceber que, dentro de uma empresa:

  1. Ou você aprende a se comunicar bem;
  2. Ou alguém vai precisar abstrair você (representar você).

E ter alguém abstraindo você é mais complexo do que parece, pois se você sempre precisar de um representante para comunicar as suas idéias e deixar claro o que deseja, você pode se colocar numa posição onde provavelmente será alongado demais a vinda de uma promoção ou o reconhecimento que você merece.

Isso não significa que comunicação deveria ser a sua única habilidade, pois isso faz a pessoa cair na cilada de ser o figurante de uma situação e não o protagonista, onde o figurante fala muito mais do que faz e geralmente não toma nenhuma decisão com risco real (apesar de ficar horas e horas falando das decisões das outras pessoas).

Ser um bom programador e ser uma pessoa que consegue se comunicar com clareza é uma das combinações mais poderosas que existem nos dias de hoje, tanto se você é funcionário de uma empresa, quanto se você está montando o seu próprio negócio, pois ambos tem o poder (e o dever) de se comunicar e entender os clientes.

Então fica como dica: experimente não deixar outras pessoas se comunicarem por você. De alguma forma (que só você vai descobrir como fazer), reduza o circuito de comunicação entre você e as outras pessoas e você vai começar a ver coisas interessantes acontecendo (para o bem e para o mal).

Carregando publicação patrocinada...
1

Sobre o vídeo, no exemplo dos comentários em PRs: Dentro de um time que tem x devs junior/pleno para 1 sênior, a prática de comentar "mastigadinho", por parte do sênior, não cria brechas para o resto do time ficar preguiçoso?

De repente um dev sentir um "estalo" e pensar: Eu posso subir PRs cada vez mais desleixados ou incorretos e sempre vou ter alguém para corrigir, daí vai ser copiar e colar.

Quando acontece comigo eu acho excelente porque paro momentâneamente de me preocupar com a implementação e passo a tentar entender porque a solução proposta é preferível a que foi implementada. Mas gostaria de ter percepção dessa prática vinda de dentro de outros times.

1

Na verdade, creio que seja dever do sênior como lider de corrigir seus juniores e exigir que eles melhorem nesse quesito. Se um dev sobe 10 PRs e desde o 3o o sênior ta pedindo pra ele ser mais claro, acaba ficando feio para ele como dev (e como profissional) que não tem atendido as necessidades de seus superiores.

Além de que deixar mastigado não é botar o código certo, por exemplo, mas indicar explicitamente como corrigir. Em vez de escrever "Esse código ta fora do padrão" pode ser "O código ta fora do padrão, verificar exemplo no arquivo teste_123.file a partir da linha 23"