Ele sempre foi muito esperto, mesmo quando era criança. Mas uma coisa é ser esperto, outra é ser sábio. - George R. R. Martin
Aí vão algumas situações em que um programador acaba vacilando, isto é, situações em que acha que está sendo esperto, mas está cometendo um baita de um erro.
Bancar o Conhecedor Especializado
Quem nunca viu aquele cara que começa a falar com uma pessoa não-técnica, usando siglas e jargões da área da programação? Do outro lado, o interlocutor ignora totalmente o que ele está falando e repete perguntas ou o corta para que ele traduza o que está dizendo.
O erro está em pensar que está passando a impressão de que é bom na área, quando está acontecendo o contrário. Eu nunca contrataria um advogado que não fosse capaz de me explicar em termos leigos a causa e a solução do meu problema.
Não Repassar Conhecimento
O cara não repassa conhecimento, pois tem medo de perder o status de indispensável. Com isso, não contribui para o desenvolvimento e crescimento da empresa, portanto dificulta a sua própria passagem de bastão e obtenção de uma posição de liderança no futuro.
Fazer Código que só Ele Entende
Esse é tão grave que até empresas pouco profissionais fazem isso!
Entregam um produto mal documentado, um código ilegível de dificílima manutenção para novamente garantir seu status de insubstituível.
O problema é que essa estratégia só funciona a curto prazo. Depois disso, seus clientes ou seus colegas de trabalho vão perceber o que você faz e ninguém irá te recomendar.
Só Trabalha com o que Sabe
O programador quer se mostrar o fera da empresa de tão rápido que programa e isso funciona para as situações que conhece. Algumas vezes, entretanto, surgem oportunidades de encarar o desconhecido mesmo que sua produtividade vá para baixo.
A maioria desses desafios acabam sendo declinados por esses caras tão preocupados com reputação. O irônico é que o resultado é o inverso.
Trabalhar com o conhecido tende a ter prazos mais rígidos e conhecidos. Se você atrasar algo com motivo, porque o caos resolveu falar com você aquele dia, vai ter que se virar para explicar.
O contrário acontece quando você trabalha com o desconhecido e o temido. Se você atrasar, será compreendido. Se você adiantar, surpreenderá a todos.
Dizer Sim Para Tudo
Aqui o cara acha que está evitando conflito e se dando bem com a chefia.
Esse cara pode ter ajudado bastante a inflar o ego da chefia, ganhando uma posição especial no curto prazo, mas depois projetos atrasam e problemas acontecem e o que parecia um grande amigo não era bem isso.
Dizer Não Para Tudo
O cara acha que está provando seu valor ao discordar toda hora mesmo de coisas pequenas, mas na verdade está queimando suas fichas quando sua discordância for realmente importante.
Moral da história: É necessário deixar os outros ganharem para continuarem brincando com você. Portanto, admita seus erros assim quando cometê-los ou deixe os outros ganharem mesmo quando estiver certo em pequenos agravos.
Ficar na Moita
Isso aqui no processo de Scrum onde é necessário estimar as horas, acontece muito.
De um lado, você tem um cara que acha que a atividade é muito fácil de fazer. Do outro, o cara preocupado com detalhes não especificados nos requisitos e imprevistos técnicos. No meio, está o "isentão" que estima as horas para não mostrar desconhecimento técnico. O problema dele é não passar vergonha.
Moral da história: Ficar na moita tem suas vantagens, há um capítulo do livro 48 Leis do Poder que trata sobre isso. Entretanto, se você não está interessado a jogar o jogo político pelo restante de sua vida na empresa, então é melhor escolher seu time; caso contrário, corre o risco de desagradar os dois.
Fazer Hora Extra Sempre que Solicitado
O cara não quer se recusar a fazer hora extra para não parecer rebelde. O resultado é que faz hora extra desmotivado, não entrega quase nada e chega cansado nos outros dias. Ao final, o projeto atrasa de todo jeito, mas sai mais caro.
Para o gerente leigo, faltaram mais homens, mais dias da semana ou mais horas do dia. Portanto, já sabemos, próxima vez vai todo mundo trabalhar mais desde o princípio.
Moral da história: só faça horas extras em projetos de GRANDE importância para a empresa e que também lhe tragam satisfação pessoal de ajudar ou individual de fazer algo bem feito.
Só fica focado na atividade diária
O cara fica tão vidrado nas suas atividades diárias para não decepcionar ninguém que não agrega nada de novo para a equipe ou para empresa.
Moral da história: Se distancie um pouco das suas atividades diárias para ver quanta coisa pode melhorar!
Só estuda programação
Programação tem dessas coisas. O cara vai lá, estuda dezenas de padrões de componentização ou como testar uma aplicação, mas não consegue colocar em prática.
O problema é que o desenvolvedor não consegue encaixar essas tarefas em um processo adequado que permita a demonstração da sua importância. Como o nome diz, é um processo, melhor que seja estabelecido gradualmente sem desviar o foco da entrega de valor para o produto e usuário final que só estão sedentos por novas funcionalidades.
Moral da História: Também valorize comunicação e processos
Software Muda, a Lamúria Não
Convenhamos, software muda o tempo todo. Se não mudasse, se chamaria hardware!
Não fique, então, derramando lágrimas de que vai ter que jogar fora o que fez na semana passada.
Isso agora é inútil e você reclamar só vai fazer você ser mal visto. O que você pode fazer é ter a atenção necessária aos detalhes e ao problema maior que deve ser resolvido, antecipando mudanças, erros e demandas.
Assim, quando as mudanças acontecerem, você pode ficar tranquilo de que fez o possível para que retrabalho fosse desnecessário. Além disso, pode gravar estes acontecimentos para serem utilizados em outras situações. Não para dizer de maneira insolente: "eu te avisei". Mas para dizer: "olha aqui, erramos aquela vez, vamos errar de novo?"
Conclusão
Essas dicas são transferíveis para qualquer tipo de carreira, o importante é ficar atento. Ter uma capacidade de auto-percepção boa é o primeiro passo para não ser um vacilão para sempre.
Já diziam os estóicos para enxergarmos nossas próprias experiências como se distantes de nós mesmos!