--- title: "Soft Skills para Rustaceans: Habilidades Além do Código" url: "https://rustlang.com.br/carreira/soft-skills/" markdown_url: "https://rustlang.com.br/carreira/soft-skills.MD" description: "Desenvolva habilidades interpessoais essenciais para sua carreira com Rust. Code review, comunicação técnica, mentoria, apresentações, trabalho remoto e como lidar com a curva de aprendizado." date: "" author: "" --- # Soft Skills para Rustaceans: Habilidades Além do Código Desenvolva habilidades interpessoais essenciais para sua carreira com Rust. Code review, comunicação técnica, mentoria, apresentações, trabalho remoto e como lidar com a curva de aprendizado. Ser um excelente programador Rust não depende apenas de dominar ownership, lifetimes e traits. As habilidades interpessoais -- chamadas de soft skills -- frequentemente são o diferencial entre um desenvolvedor que escreve bom código e um profissional que realmente transforma equipes e projetos. No ecossistema Rust, onde a comunidade é um pilar central, essas habilidades são ainda mais valorizadas. Este guia aborda as soft skills mais relevantes para quem trabalha com Rust, desde a arte do code review até como mentorar colegas enfrentando a famosa curva de aprendizado da linguagem. ## Code Review: A Arte do Feedback Construtivo Code review é muito mais do que encontrar bugs. É uma oportunidade de compartilhar conhecimento, manter padrões e fortalecer a equipe. Em projetos Rust, code reviews tendem a ser especialmente detalhados por causa da riqueza do sistema de tipos e dos padrões idiomáticos da linguagem. ### Princípios Fundamentais **1. Critique o código, nunca a pessoa** Em vez de dizer "Você fez isso errado", prefira "Esse trecho poderia ser simplificado usando..." | Evite | Prefira | |-------|---------| | "Isso está errado" | "Que tal considerar esta abordagem...?" | | "Você deveria saber que..." | "Uma alternativa idiomática seria..." | | "Por que você não usou X?" | "O padrão X poderia simplificar isso. O que acha?" | | "Isso é feio" | "Poderíamos melhorar a legibilidade aqui" | **2. Seja específico e ofereça alternativas** Não basta dizer "melhore isso". Mostre como: ```rust // Em vez de: "Esse match está errado" // Diga: "Podemos simplificar usando if let aqui, já que // só tratamos um caso:" // Antes match resultado { Ok(valor) => processar(valor), Err(_) => {}, } // Sugestão if let Ok(valor) = resultado { processar(valor); } ``` **3. Equilibre rigor com pragmatismo** Nem todo review precisa ser perfeito. Considere: - **Bloqueante**: bugs, falhas de segurança, violação de APIs - **Sugestão**: melhorias de estilo, performance marginal - **Nitpick**: preferências pessoais, formatação menor Rotule seus comentários para que o autor saiba o que é obrigatório e o que é sugestão: ```markdown [bloqueante] Esse `unwrap()` pode causar panic em produção. Considere usar `?` ou tratar o erro explicitamente. [sugestão] Poderíamos usar `map()` em vez de match aqui para ficar mais conciso. Mas o atual também está correto. [nit] Prefiro o nome `processar_dados` ao invés de `proc_data`, mas é questão de gosto. ``` ### Dicas Específicas para Rust **Pontos comuns para verificar em reviews Rust:** 1. **Uso desnecessário de `.clone()`**: muitas vezes indica que o autor não encontrou a borrowing correta 2. **`.unwrap()` em código de produção**: quase sempre deve ser substituído por tratamento adequado 3. **Lifetimes desnecessárias**: se o compilador não exige, não adicione 4. **Falta de `#[must_use]`**: funções que retornam `Result` devem ser anotadas 5. **Testes ausentes**: especialmente para lógica de negócio 6. **`pub` excessivo**: exponha apenas o necessário ```rust // Review: este clone é necessário? // Se dados não for usado depois, podemos passar ownership diretamente let resultado = processar(dados.clone()); // clone suspeito // Melhor: verificar se podemos passar por referência ou por ownership let resultado = processar(&dados); // se só precisa ler let resultado = processar(dados); // se não precisa mais de dados ``` ### Como Receber Code Review Receber feedback é tão importante quanto dar: 1. **Não leve para o lado pessoal**: o review é sobre o código, não sobre você 2. **Agradeça o feedback**: "Boa observação, não tinha pensado nisso" 3. **Pergunte se não entendeu**: "Poderia elaborar? Não estou vendo o problema" 4. **Aprenda com cada review**: anote padrões que surgem repetidamente 5. **Implemente prontamente**: não deixe reviews abertos por dias ## Escrita Técnica e Documentação A habilidade de escrever texto técnico claro é uma das mais subestimadas e mais impactantes para um desenvolvedor. ### Documentação de Código Em Rust, a documentação é cidadã de primeira classe. `cargo doc` gera documentação navegável automaticamente, e exemplos em doc comments são testados pelo `cargo test`. **Princípios de boa documentação:** 1. **Comece pelo "por quê"**: explique o propósito antes dos detalhes 2. **Inclua exemplos funcionais**: um exemplo vale mais que mil palavras 3. **Documente panics e safety**: se a função pode entrar em pânico, documente quando 4. **Use links**: conecte conceitos relacionados com `[`links`]` ```rust /// Divide o texto em parágrafos, respeitando linhas em branco. /// /// Esta função é útil para processamento de texto onde parágrafos /// são separados por uma ou mais linhas vazias, como em Markdown. /// /// # Exemplos /// /// ``` /// let texto = "Primeiro parágrafo.\n\nSegundo parágrafo."; /// let paragrafos = dividir_paragrafos(texto); /// assert_eq!(paragrafos.len(), 2); /// assert_eq!(paragrafos[0], "Primeiro parágrafo."); /// ``` /// /// Linhas em branco consecutivas são tratadas como um único separador: /// /// ``` /// let texto = "Um.\n\n\n\nDois."; /// let paragrafos = dividir_paragrafos(texto); /// assert_eq!(paragrafos.len(), 2); /// ``` /// /// # Panics /// /// Não entra em pânico sob nenhuma circunstância. pub fn dividir_paragrafos(texto: &str) -> Vec<&str> { texto.split("\n\n") .map(|p| p.trim()) .filter(|p| !p.is_empty()) .collect() } ``` ### Escrevendo RFCs, Design Docs e ADRs Conforme você cresce na carreira, escrever documentos técnicos se torna cada vez mais importante. **Estrutura de um Design Doc:** ```markdown # Design Doc: [Título do Projeto] ## Resumo Uma ou duas frases descrevendo o que será construído e por quê. ## Contexto e Motivação - Qual problema estamos resolvendo? - Por que agora? - Quais são as limitações atuais? ## Proposta Descrição detalhada da solução proposta. ### Alternativas Consideradas - Opção A: [descrição] -- descartada porque [motivo] - Opção B: [descrição] -- descartada porque [motivo] ### Trade-offs - Ganho: [o que ganhamos] - Custo: [o que perdemos ou complicamos] ## Plano de Implementação 1. Fase 1: [escopo e prazo] 2. Fase 2: [escopo e prazo] ## Métricas de Sucesso Como saberemos se a solução funcionou? ## Riscos O que pode dar errado e como mitigamos? ``` ### Escrevendo Mensagens de Commit Claras Commits bem escritos contam a história do projeto: ``` feat(auth): implementar autenticação JWT com refresh tokens Adiciona middleware de autenticação que valida tokens JWT e suporta refresh automático quando o access token expira. - Novo middleware `AuthLayer` compatível com Tower - Endpoint POST /auth/refresh para renovar tokens - Testes de integração cobrindo fluxos de login e refresh - Configuração via variáveis de ambiente (JWT_SECRET, TOKEN_TTL) Resolve #142 ``` **Formato recomendado:** ``` tipo(escopo): descrição concisa (imperativo, até 72 caracteres) Corpo opcional explicando O QUE mudou e POR QUÊ (não COMO). O "como" está no código. Quebre linhas em 72 caracteres. Footer: referências a issues, breaking changes, etc. ``` ## Mentoria de Desenvolvedores Rust Mentorar colegas que estão aprendendo Rust é uma das contribuições mais valiosas que você pode fazer para a equipe e para a comunidade. ### Entendendo as Dificuldades Comuns | Fase do Aprendizado | Dificuldade Principal | Como Ajudar | |---------------------|----------------------|-------------| | Primeira semana | Sintaxe diferente | Comparar com linguagens que conhecem | | Primeiro mês | Ownership e borrow checker | Pair programming, diagramas de memória | | Meses 2-3 | Lifetimes e generics | Exercícios gradativos, code review detalhado | | Meses 3-6 | "Fighting the borrow checker" | Mostrar padrões idiomáticos alternativos | | 6+ meses | Async e macros | Projetos progressivos, leitura de código | ### Técnicas de Mentoria Eficaz **1. Pair programming com narração** Programe junto com o mentorado, mas deixe ele digitar. Explique seu raciocínio em voz alta: > "Aqui o compilador está reclamando porque estamos tentando usar `dados` depois de mover para `processar()`. Vamos pensar: precisamos de `dados` depois? Se sim, podemos emprestar com `&`. Se não, o move está correto." **2. Revisão guiada de erros do compilador** Em vez de resolver o erro para o mentorado, guie-o: > "O que a mensagem de erro está dizendo? Veja a seta apontando para a linha 15. O compilador sugere uma correção -- consegue entender o que ele está propondo?" **3. Construção gradual de complexidade** ``` Semana 1: "Implemente uma struct Aluno com nome e nota. Adicione um método que retorna se passou (nota >= 7.0)." Semana 2: "Agora crie um Vec e implemente funções para calcular média, encontrar melhor nota e filtrar aprovados." Semana 3: "Refatore para usar traits. Crie um trait Avaliavel que possa ser implementado tanto por Aluno quanto por Projeto." Semana 4: "Adicione tratamento de erros adequado. O que acontece se a nota for negativa? E se o nome estiver vazio?" ``` **4. Celebre progressos pequenos** A curva de aprendizado do Rust pode ser desanimadora. Reconheça conquistas: - "Você resolveu esse erro de lifetime sozinho? Excelente progresso!" - "Seu uso de pattern matching ficou muito idiomático aqui." - "Parabéns por pensar no tratamento de erro desde o início." ### O que Evitar na Mentoria 1. **Não resolva tudo para a pessoa**: guie, não faça 2. **Não use jargão sem explicar**: "move semantics" pode ser óbvio para você, mas não para quem está começando 3. **Não compare com outros mentorados**: cada pessoa tem seu ritmo 4. **Não ignore frustração**: "eu sei que o borrow checker pode ser frustrante, vamos trabalhar isso juntos" 5. **Não sobrecarregue**: três conceitos novos por sessão é o máximo ## Apresentações Técnicas sobre Rust Dar talks sobre Rust, seja em meetups ou conferências, é uma excelente forma de consolidar conhecimento e construir sua reputação profissional. ### Escolhendo um Tema **Temas que funcionam bem:** | Tipo | Exemplo | Público | |------|---------|---------| | Tutorial | "Ownership em 30 minutos" | Iniciantes | | Estudo de caso | "Como migramos de Python para Rust" | Intermediários | | Deep dive | "Como funciona o borrow checker" | Avançados | | Comparação | "Rust vs. Go para microsserviços" | Misto | | Show & tell | "Construí um game engine em Rust" | Todos | | Experiência | "Lições de 2 anos usando Rust em produção" | Intermediários | ### Estruturando a Apresentação ``` 1. Gancho (2 min) - Comece com um problema, uma pergunta ou uma história - "Já tiveram um segfault em produção às 3 da manhã?" 2. Contexto (3 min) - Por que esse tema é relevante? - O que o público vai ganhar? 3. Conteúdo principal (15-20 min) - 3 a 5 pontos-chave - Exemplos de código curtos e legíveis - Demonstrações ao vivo (se possível) 4. Lições aprendidas (5 min) - O que deu certo e o que deu errado - Conselhos práticos 5. Conclusão e perguntas (5 min) - Resumo em 3 bullets - Chamada para ação - Recursos para aprofundamento ``` ### Dicas para Apresentar Código 1. **Fonte grande**: mínimo 24pt para código em slides 2. **Syntax highlighting**: use temas de alto contraste 3. **Destaque incremental**: mostre o código progressivamente 4. **Menos é mais**: 10 linhas de código por slide no máximo 5. **Compile na hora**: se demonstrar ao vivo, tenha um backup ```rust // RUIM para slides: muito código, difícil de ler // BOM para slides: foque no conceito fn exemplo_ownership() { let s1 = String::from("olá"); let s2 = s1; // s1 movido println!("{}", s2); // OK // println!("{}", s1); // ERRO! } ``` ### Lidando com Nervosismo 1. **Prepare-se excessivamente**: saiba o conteúdo 2x mais do que vai apresentar 2. **Pratique em voz alta**: falar sozinho é diferente de falar para o espelho 3. **Grave-se**: assista e identifique manias 4. **Comece com meetups pequenos**: 10 pessoas é um ótimo começo 5. **Respire**: uma pausa para respirar é muito melhor do que gaguejar ## Comunicação em Equipes Remotas O trabalho remoto é dominante no mercado Rust, especialmente em posições internacionais. Comunicar-se efetivamente sem o benefício do contato presencial exige habilidades específicas. ### Comunicação Escrita Eficaz A maioria da comunicação em equipes remotas é textual (Slack, GitHub, email). Escrever bem é uma superpotência. **Princípios:** 1. **Contexto primeiro**: nunca envie apenas "não funciona". Inclua o que tentou, o que esperava e o que aconteceu 2. **Formatação importa**: use bullet points, código formatado, headers 3. **Assíncrono por padrão**: não espere resposta imediata 4. **Timezone-aware**: mencione fusos horários em convites **Bom exemplo de pedido de ajuda:** ```markdown ## Problema com lifetime em trait object **O que estou tentando fazer:** Criar um trait que retorna um iterador sobre referências internas. **Código:** ```rust trait DataSource { fn items(&self) -> Box>; // ^^^^ // ERROR: missing lifetime specifier } ``` **O que já tentei:** - Adicionar `'_` -> mesmo erro - Adicionar `'a` no trait -> preciso de GATs? **Pergunta:** Qual é a abordagem idiomática para isso? Estou usando Rust 1.75. ``` ### Reuniões Produtivas **Antes da reunião:** - Envie a pauta com antecedência - Inclua links para código/documentos relevantes - Defina claramente o objetivo: decisão, brainstorm, informação? **Durante a reunião:** - Comece no horário, termine no horário - Tome notas compartilhadas - Se tiver código para discutir, compartilhe tela com fonte grande - Dê espaço para todos falarem **Depois da reunião:** - Envie resumo com decisões e action items - Atribua responsáveis e prazos - Documente decisões técnicas em ADRs ### Feedback em Contexto Internacional Muitas vagas Rust são em empresas internacionais. Considere diferenças culturais: - **Direto vs. indireto**: americanos tendem a ser diretos; japoneses, mais indiretos - **Formalidade**: europeus costumam ser mais formais no início - **Tempo de resposta**: respeite fusos horários e períodos de descanso - **Idioma**: se trabalhando em inglês, seja claro e evite gírias brasileiras traduzidas literalmente ## Lidando com a Frustração da Curva de Aprendizado O Rust é famoso por sua curva de aprendizado íngreme. Como profissional, você vai enfrentar frustração em si mesmo e em colegas. Saber lidar com isso é uma soft skill essencial. ### Reconhecendo os Estágios ``` Estágio 1: Entusiasmo "Rust é incrível! Segurança de memória sem GC!" Estágio 2: Frustração "O borrow checker não me deixa fazer NADA!" Estágio 3: Negociação "Ok, vou clonar tudo até entender ownership..." Estágio 4: Compreensão "Ah, agora entendo POR QUE o compilador reclamava!" Estágio 5: Fluência "Eu desenho o código pensando em ownership desde o início." ``` ### Estratégias para Superar a Frustração 1. **Aceite que é normal**: todo mundo passa por isso, inclusive os experts atuais 2. **Quebre o problema**: se o compilador dá 5 erros, resolva um de cada vez 3. **Leia a mensagem de erro completa**: o compilador Rust tem as melhores mensagens de erro do mundo 4. **Tire uma pausa**: 15 minutos longe do código podem resolver o que 2 horas não resolveram 5. **Peça ajuda sem vergonha**: a comunidade Rust é acolhedora por design 6. **Celebre pequenas vitórias**: compilou sem erros? Isso é progresso real ### Quando Você é o Líder da Equipe Se você é tech lead de uma equipe adotando Rust: 1. **Defina expectativas realistas**: produtividade vai cair nos primeiros 2-3 meses 2. **Invista em treinamento**: workshops, pair programming, tempo dedicado para aprender 3. **Não force Rust em tudo**: identifique onde Rust traz mais valor 4. **Monitore burnout**: frustração constante com o compilador pode desmotivar 5. **Compartilhe histórias de sucesso**: "olha o bug que Rust preveniu em produção" ## Construindo Confiança Através de Código Confiável Uma das soft skills mais poderosas é construir a reputação de que seu código é confiável. Em Rust, a linguagem já ajuda bastante, mas existem práticas que elevam essa confiança. ### Práticas que Constroem Confiança **1. Testes como documentação viva** ```rust #[cfg(test)] mod tests { use super::*; // Testes nomeados descritivamente #[test] fn usuario_com_email_invalido_retorna_erro() { let resultado = Usuario::novo("Ana", "email-sem-arroba"); assert!(resultado.is_err()); assert_eq!( resultado.unwrap_err().to_string(), "Email inválido: email-sem-arroba" ); } #[test] fn deposito_negativo_e_rejeitado() { let mut conta = ContaBancaria::nova("Ana"); let resultado = conta.depositar(-100.0); assert!(resultado.is_err()); assert_eq!(conta.saldo(), 0.0); // saldo inalterado } } ``` **2. Tratamento explícito de todos os casos** ```rust // Em vez de ignorar erros silenciosamente let _ = arquivo.write_all(dados); // RUIM: erro ignorado // Trate ou propague explicitamente arquivo.write_all(dados)?; // BOM: erro propagado // Se realmente quiser ignorar, documente o motivo let _ = tx.send(msg); // OK se receptor já fechou, mensagem é best-effort ``` **3. Comunicação proativa** - Avise antes de quebrar APIs - Documente limitações conhecidas - Responda issues rapidamente, mesmo que seja para dizer "vi, vou analisar" - Quando errar, assuma e corrija rapidamente **4. Consistência** - Siga os padrões da equipe mesmo quando discorda - Entregue no prazo ou comunique atrasos cedo - Mantenha o mesmo padrão de qualidade em código "urgente" ## Resolução de Conflitos Técnicos Divergências técnicas são inevitáveis e saudáveis. O que importa é como são resolvidas. ### Framework para Resolver Conflitos 1. **Defina o problema claramente**: "Estamos decidindo entre X e Y para Z" 2. **Liste critérios objetivos**: performance, manutenabilidade, prazo, curva de aprendizado 3. **Avaliem juntos**: cada opção contra cada critério 4. **Aceite dados sobre opiniões**: benchmark > "eu acho" 5. **Comprometa-se com a decisão**: mesmo que não concorde 100%, dê suporte total ```markdown ## Decisão: Axum vs. Actix-web ### Critérios (por ordem de prioridade) 1. Compatibilidade com ecossistema Tower (essencial) 2. Performance (importante) 3. Facilidade de teste (importante) 4. Curva de aprendizado da equipe (desejável) ### Avaliação | Critério | Axum | Actix-web | |----------|------|-----------| | Tower | Nativo | Adaptador | | Performance | ~igual | ~igual | | Testabilidade | Alta | Média | | Curva | Média | Média | ### Decisão: Axum ### Responsável: [nome] ### Data: [data] ``` ### Quando Discordar e se Comprometer Há situações em que a equipe vai em uma direção diferente da sua preferência. Nestes casos: 1. **Expresse sua opinião claramente** durante a discussão 2. **Apresente dados e argumentos**, não apenas preferências 3. **Uma vez decidido, apoie totalmente** a decisão 4. **Não diga "eu avisei"** se algo der errado -- ajude a resolver 5. **Reavalie periodicamente**: se os dados mudaram, proponha revisitar a decisão ## Conclusão: O Desenvolvedor Completo As habilidades técnicas em Rust abrem portas. As soft skills as mantêm abertas e criam novas oportunidades. O profissional que combina domínio técnico com comunicação clara, empatia na mentoria, presença construtiva em reviews e capacidade de resolver conflitos é raro e extremamente valorizado pelo mercado. **Pontos-chave para levar consigo:** 1. **Code review é ensino, não policiamento**: aborde com generosidade e especificidade 2. **Documentação é investimento**: código bem documentado economiza tempo de todos 3. **Mentoria multiplica impacto**: um sênior que mentora cria outros sêniores 4. **Comunicação escrita é superpotência**: especialmente em equipes remotas 5. **Frustração é temporária, habilidades são permanentes**: a curva de aprendizado do Rust recompensa quem persiste 6. **Confiança se constrói com consistência**: código confiável, comunicação transparente, entregas previsíveis Invista tempo nestas habilidades com a mesma seriedade que investe em aprender async/await ou lifetimes. O retorno sobre esse investimento é enorme e acumulativo ao longo de toda a sua carreira.