Soft Skills para Rustaceans: Habilidades Além do Código

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…”

2. Seja específico e ofereça alternativas

Não basta dizer “melhore isso”. Mostre como:

// 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:

[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

// 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]

/// 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:

# 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

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<Aluno> 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:

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

// 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:

## 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<dyn Iterator<Item = &str>>;
    //                                         ^^^^
    // 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

// 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

## 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.