Bem, detesto rebentar-te a bolha, mas se é a terceira vez que isto acontece, quase exclui “não és tu, são eles”. O teu título diz que foste despedido por seres “indispensável”, mas para além de isso ser um oximoro, também não foi o que aconteceu. Foi despedido por escrever código que os seus colegas não conseguem compreender, o que é uma questão crítica de performance para um programador.

Código bom é código legível , ou seja, código facilmente compreensível, _ mesmo para os novatos_. As situações em que é necessário um código complexo e bem escrito que deve ser escrito e mantido por verdadeiros especialistas são muito raras hoje em dia e, evidentemente, não se trabalhava para esse tipo de empresas. O que descreve soa mais a código “chique”, que é tipicamente demasiado complexo, cheio de truques de programação esotéricos e leva muito tempo a descobrir e a depurar. É uma falha comum para as pessoas que foram classicamente treinadas e que, normalmente, estão para um despertar rude assim que entram num ambiente produtivo.

Não é uma brincadeira, não suportaria que isto acontecesse uma quarta vez, está a afectar-me mentalmente.

Esta linha é importante, porque mostra que se sente que é altura de mudar. Mostra que você reconhece isto como um padrão e gostaria que o padrão parasse. Esse desejo é provavelmente a parte mais importante da solução. Resolver este tipo de situações implica muitas vezes mudar a forma como você, você mesmo, pensa. É impossível para alguém fazer isso por si, por isso o seu desejo de mudar será a única coisa que fará a mudança acontecer.

Para alguns antecedentes, já estive em situações semelhantes “demasiado bom a codificar para o meu trabalho”, embora nunca na medida que você descreve. Eu poderia curar o cancro com meta-programação de modelos em C++, mas muitos com quem trabalho mal são versados no básico do Design Orientado a Objectos. Eu escrevi código que abusava SFINAE e que se contrapunha ao texto exacto das especificações do C++, quando muitos projectos em que trabalhei ainda usavam versões antiquadas e buggy do gcc. A minha abordagem foi simplesmente mostrar-lhes como estas ferramentas são espantosas, e todos os problemas que poderiam resolver. Adorei explicar pequenas dicas de programação às pessoas, e elas gostaram muito.

Isso soa familiar?

“Sim, mas deve-se ter um bom nível para entender [o código Mik] porque os componentes são inteligentemente desacoplados”

Considerem esta afirmação de uma perspectiva baseada no risco. O seu chefe precisa de manter as coisas a funcionar, não importa o que aconteça. Se você sair para ir atrás de alguma oportunidade de trabalho fantástica, o seu chefe ainda tem de se certificar de que o código é mantido. O que o seu colega de trabalho acabou de dizer foi que, se tiverem de o substituir, precisam_ de encontrar um programador muito competente, porque quem não for assim tão bom não será capaz de o manter. Isto é um risco. E se não conseguirem encontrar um programador suficientemente bom, ou não conseguirem pagar-lhes o suficiente?

Pode ter produzido aquilo a que chamaria “bom código”, mas a definição de “bom código” é muito muito dependente do contexto. O que é “bom código” no Google, com as suas formas de pensar vanguardistas, pode ser um código muito mau para alguém que trabalha na FAA, que está predominantemente preocupado com a fiabilidade em vez de se manter a par da vanguarda. A definição de “bom código” do seu chefe inclui a capacidade de o manter em todo o tipo de situações, inclusive sem si. Se os seus colegas de trabalho não se sentem à vontade para manter o seu código, então você é subitamente uma fiabilidade para a empresa, porque você produz um produto que eles não podem manter se você decidir ir para outro lugar.

Nesta perspectiva, pode-se argumentar que você está a forçá-los a aceitar a sua definição de “bom código”. Instintivamente, isto pode parecer uma coisa boa, mas está cheio de dificuldades, tal como esta forma de pensar baseada no risco que pode não ter pensado.

Temos uma frase, “pôr o carro à frente dos bois”. Um dos muitos significados associados a ela é colocar o conteúdo que mais lhe interessa (ser capaz de usar as suas técnicas avançadas) sobre as forças que deveriam estar a puxá-la para a frente (a compreensão que o seu colega de trabalho tem destas técnicas). Você escreveu o código neste estilo avançado, e depois encorajou os outros programadores a “apanhar” este estilo. Isto pode ser eficaz, mas se alguma coisa lhe acontecer antes de eles “recuperarem o atraso”, a empresa fica subitamente em risco porque ninguém consegue manter o código.

Como posso evitar isto no futuro?

A correcção disto pode ser uma coisa terrivelmente difícil de fazer porque envolve abordar o problema de uma forma diferente da que normalmente lhe é confortável. Em vez de primeiro escrever o código neste estilo avançado, e depois ensinar os seus colegas de trabalho a pensar dessa forma, deve virá-lo ao contrário. Ensine os seus colegas de trabalho a gostar desse estilo de codificação, e depois comece a escrever código nesse estilo. Pode parecer ao contrário, mas é muito mais estável. Do ponto de vista do patrão, há pouco ou nenhum risco de a equipa aprender a codificar melhor. Uma vez codificado melhor, o estilo em que se quer desenvolver é subitamente menos arriscado.

Entretanto, terá de escrever um código que, pelos seus padrões, é “menos bom”, mas não faz mal. O seu código não é o seu único produto aqui. O seu outro produto está a ajudar a ensinar os outros programadores, e o valor disso pode facilmente exceder o valor de escrever “código perfeito”.

Claro que pode ser difícil dizer quando é seguro escrever código no estilo em que quer escrever. Se fosse fácil de dizer, já o teria descoberto! Uma técnica poderosa que pode utilizar é deixar os outros pressionarem pelos estilos avançados de codificação, em vez de o fazer você mesmo. Uma coisa é ensinar a alguém a diferença entre herança e composição. É uma coisa completamente diferente ensiná-los suficientemente bem que eles defendem a mudança da sua base de códigos existente para ser mais claro quando ela os usa. Este último caso permite realmente que se saiba que eles não só entendem o conceito, mas abraçá-lo verdadeiramente.

Um ideal para ensinar tais conceitos é não ensinar nada. Deixe os alunos descobrirem algo, e depois aponte-os numa direcção em que a descoberta possa ir. Talvez um deles descubra alguma coisa de bom sobre a herança e você pode apontá-los para o padrão de design do Visitante baseado no que eles descobriram. Não lhes dê apenas um Visitante, mas dê-lhes um sentido de orientação para que eles próprios possam sair e encontrar o Visitante.

É uma abordagem muito mais difícil, e certamente vai querer encontrar um meio de comunicação feliz entre isso e a sua abordagem actual, mas pode ser muito gratificante. Mais importante para a sua resposta, pode trazer valor para a empresa sem o risco. Se está a dar valor a uma empresa, e não a colocar em risco, praticamente nunca_ será despedido. E nos poucos casos em que ainda pode ser despedido, a gerência fornecerá uma razão para isso (tal como uma recessão na economia, ou uma mudança na direcção da empresa). Se o fizer muito bem, verá que a gestão, em vez disso, começará a moldar o seu caminho, tal como molda os seus colegas de trabalho, e encontrará uma tendência curiosa para ter aprendido apenas a habilidade certa apenas quando eles mais precisam dela.

Há sempre razões.

Um empregador anterior fez isto com um colega meu. O seu nível de competências estava muito para além das nossas competências. Então, ele foi deixado ir.

Porque é que isto faz sentido?

1. Ele era o único que podia manter o seu código
2. Ele não era colaborativo
3. Ele não seguia os padrões da loja
4. Enquanto ele entregava mais do que o necessário, isto não era uma coisa boa
5. Simples, eram necessárias soluções em vez de soluções complexas.

Diz-se tantas vezes que é quase um cliché, mas tem de se ser um “bom ajuste” para a equipa.

A codificação é apenas uma parte da equação. Tens de ser personalizável, comunicativo, humilde até um certo ponto, arrogante quando necessário, manter os padrões das lojas, relacionar-te com os teus colegas de trabalho, ser acessível e rápido a ajudar quando necessário.

Todas estas competências transversais são importantes e não tê-las irá causar-te problemas.

Um bom código é fácil de compreender, mesmo para engenheiros pobres. Um conselho que recebi frequentemente é “programa como se a pessoa que vai manter o seu código fosse um programador medíocre e um psicopata perigoso que sabe onde vive”.

E é verdade. Programação demasiado inteligente é má, porque a manutenção é mais longa _ quando não se sabe o código_. Na manutenção, tem frequentemente fogo por todo o lado, milhares de clientes bloqueados, e uma solução mais inteligente e eficiente pode muito bem manter o mantenedor preso por mais tempo do que um código parvo cheio de repetições.

Claro que código totalmente parvo também é mau. Há um bom equilíbrio a encontrar entre burro e génio: eficiente, e ainda legível. É mais uma arte do que uma ciência. É por isso que conceitos inteligentes, como herança múltipla não são normalmente aconselhados . Mesmo que eles sejam o máximo.

Você tem que levar em conta o contexto. Se você trabalha numa pequena empresa que contrata apenas o melhor, você provavelmente pode pagar algumas coisas exóticas e brilhantes. Se trabalha para um banco francês que depende apenas de consultores de, errrm, qualidade aleatória (às vezes têm sorte, às vezes não), e onde cada consultor tem um domínio de milhões de LOC para manter, então por todos os meios torne-o suficientemente simples para que um medíocre o compreenda à primeira vista. Sem indicações, sem herança múltipla, sem truques espertos, etc…

É pouco provável que seja despedido por ser demasiado bom. Acho que isso é apenas uma desculpa.

É muito mais provável que seja uma questão de comportamento, ou o patrão simplesmente não gosta de si por razões que não pode dizer-lhe sem criar fundamentos para um processo judicial. É também possível que você seja o mais caro e que eles acreditem em FTEs (ou seja, todos os trabalhadores são iguais).

Se realmente é assim tão bom, pode tornar-se indispensável de uma boa maneira:

• Mentor os programadores júnior. Conte os benefícios e desvantagens de diferentes abordagens e deixe-os cometer os seus erros em vez de lhes dizer qual a abordagem a adoptar.
• Escreva um bom código que seja fácil de manter por outras pessoas.
• Defenda as melhores práticas de forma a aumentar a produtividade, por oposição a culto à carga melhores práticas, que soam bem no papel mas matam a produtividade.

Demitir pessoas indispensáveis é, na verdade, uma boa estratégia de gestão. Quando a sua empresa depende de uma única pessoa continuar a fazer o seu trabalho e mais ninguém na empresa tiver os seus conhecimentos e/ou capacidade, isso cria uma enorme responsabilidade: e se essa pessoa for atingida por um autocarro e morrer (daí o termo “factor autocarro”) ou simplesmente optar por deixar a empresa para um novo desafio? Agora a sua empresa está presa numa situação terrível porque ninguém pode substituir imediatamente o funcionário indispensável e você não tinha controlo sobre o tempo!

Para evitar esta situação, a empresa tem duas opções. Ou pode tentar disseminar o conhecimento e/ou aumentar a capacidade dos colegas de trabalho da pessoa indispensável, ou pode retirar o auxílio de uma só vez, despedindo a pessoa indispensável num momento de escolha e recuperar da perda do trabalhador quando este estiver preparado para esse processo.

Como nem sempre é prático colmatar uma grande lacuna de conhecimento e especialmente de capacidade, despedi-lo pode ser a escolha mais lógica.

Como colaborador, deve sempre tentar prevenir tornar-se indispensável. Partilhe os seus conhecimentos com os seus colegas e certifique-se de que existem pessoas que podem fazer o seu trabalho quando você não está presente. Certifique-se de que as suas práticas são adequadas aos trabalhadores com o nível médio de competências na sua empresa. Se achar que o nível médio é demasiado baixo, trabalhe com a direcção para tentar aumentar esse nível. Certifique-se de que tudo o que criar está bem documentado e que essa documentação tem um nível suficientemente elevado para que qualquer um dos seus colegas possa utilizá-la para continuar o seu trabalho.

Se a única coisa em comum entre as três situações é você, então tem de considerar que algo que está a fazer é um problema.

Já falou com os seus antigos colegas de trabalho e pediu-lhes que o criticassem? Não o seu código, mas o seu comportamento no escritório. A forma como comunica com os seus colegas de trabalho, a forma como comunica com o seu chefe, a forma como faz documentação, como se comporta nas reuniões, etc.

Já se colocou na posição do seu supervisor? Pensou realmente no que eles têm de fazer, quais são as suas responsabilidades, o que os faz sentir bem quando desligam a luz do escritório e vão para casa? Há muitos, muitos exemplos em que alguém escreve um código incrível da perspectiva de outros engenheiros de software, mas a empresa falha.

Olhei para o seu perfil, dizia “o seu código deve ser mais limpo do que você”. Também pelos seus comentários, “passou muito tempo a explicar conceitos”, e “criticar faz parte do meu trabalho como engenheiro”… Penso que está interessado em dar conselhos e os seus conselhos simplesmente não são apreciados pelos seus colegas de equipa.

Isto pode dever-se ao que está a dizer, ou à forma como o está a dizer, provavelmente alguns dos dois.

Escrever um código produtivo e de fácil manutenção não o vai fazer ser despedido. Você será despedido se não se der bem com a equipa. Este é o seu problema, não (como você imagina) o seu código é demasiado bom. O teu código pode ser muito bom - mas é mais provável que seja um problema de choque de personalidade.

O meu conselho para ti, é que não sejas a cauda que tenta abanar o cão. Mantenha a cabeça baixa, diga às pessoas como codificar, siga a direcção, trabalhe bem com os outros, escreva um código que possa ser mantido. E depois não será despedido.

Eu também registo com interesse este comentário revelador do seu manager:

“Mas será realmente bom como ele finge?”

O que isto lhe está a dizer é que o seu manager não confia em si, o seu manager pensa que você não é autêntico e pensa que você é arrogante e/ou tem mais consideração pelas suas próprias capacidades do que você realmente tem. As relações dependem da confiança para sobreviver. Tome nota aqui que o seu problema é não um problema técnico. O seu problema tem muito pouco a ver com a qualidade do seu código. O que você tem é um problema com a maneira como você se relaciona com seus colegas e seu gerente.

As pessoas não são frequentemente despedidas por serem indispensáveis porque é que as pessoas são despedidas ); Esta é uma afirmação ridícula. O artigo que refere qualifica claramente que “despedir” não significa necessariamente deixá-los ir, mas sim torná-los não indispensáveis (movendo-os, forçando-os a não se envolverem num determinado projecto, etc.)

Embora o excesso de qualificações por vezes não o faça ser contratado - também raramente o faz ser despedido. Bons empregados são muito difíceis de encontrar; Nenhuma empresa razoável se vai livrar de um porque são demasiado bons (a não ser que trabalhe apenas para um idiota - então eles estão a fazer-lhe um favor).

As pessoas são despedidas porque Pensam que são indispensáveis e melhores do que os seus pares e por isso recusam-se a fazer as mudanças que precisam de ser feitas ao homem do espelho para funcionarem bem em equipa.

Se está a construir uma ponte com um monte de nativos e puxar um portátil enquanto o resto está a atar corda - pode ser mais inteligente ou mais educado, mas tornou-se um prejuízo para a equipa e o problema é VOCÊ.

Se é realmente tão bom como se faz entender, seria suficientemente inteligente para ajustar as suas próprias acções de forma a tornar a EQUIPA mais produtiva possível em vez de empurrar dogmaticamente a sua própria agenda (o que provavelmente está a fazer). Se o fizesse, provavelmente teria um trabalho por muito tempo.

Como alguém que está regularmente envolvido no processo de contratação, aceitarei alguém que seja bom e personalizável sobre alguém que é óptimo e um potencial cancro em qualquer dia.

Cada programa é uma comunicação com dois públicos: um compilador ou intérprete que o fará executar, e alguns humanos que o leram e compreenderam. Você pode estar comunicando extremamente bem com o compilador, e ainda estar escrevendo código ruim porque ele não pode ser facilmente compreendido pelos outros humanos envolvidos.

Tipicamente, uma equipe de programação tem um conjunto de linguagens, frameworks, técnicas, etc. que são conhecidas por todos na equipe. Os novos contratados que faltam algumas dessas peças absorvem-nas rapidamente porque qualquer pessoa da equipa pode explicá-las.

Usar algo fora desse conjunto acarreta um custo para o empregador. Por exemplo, suponha que é o único programador do grupo que está familiarizado com a framework X, e que todos os outros estão familiarizados com uma framework Y mais antiga que é usada para algum código existente e é quase tão boa como X.

Usar a framework X seria um erro, a não ser que seja muito melhor que Y que a gerência concorde que os ganhos técnicos da sua utilização são suficientes para justificar o esforço de formação para que todos se familiarizem com X.

Uma técnica que poderia usar é ter o seu código revisto por algumas das pessoas menos experientes que precisam de ser capazes de o ler. Veja o que eles têm para perguntar e considere como você poderia reescrever essas peças para ser mais claro para eles. Quanto mais você tratar a falta de compreensão do seu código como um defeito no código, e não nos leitores, melhor será o seu feedback.

A minha leitura sobre este assunto é que o senhor foi destino para este tratamento desde o primeiro dia de trabalho. Você disse que foi contratado porque não tem mais ninguém na organização que o faça (TypeScript, Node). E agora que você se esforçou para produzir uma solução elegante, engenhosa e complexa tudo sozinho, ninguém entende o que você fez, e por isso você é visto como uma responsabilidade pela gerência.

Se tudo isto for verdade, não há realmente outra maneira que isto poderia ter acontecido.

Na minha opinião, o problema é estrutural, não pessoal, e portanto a culpa é da situação e do processo, não da pessoa:

• A organização contratou uma única pessoa com um conjunto de competências completamente diferente de todas as outras, e com um nível avançado dessas competências, para desempenhar uma função crítica. Isto garante que, _ se tiver um bom desempenho_, será o único a compreender o código que é crítico para a missão da organização. (É completamente irrazoável esperar que um recurso de nível superior produza código que instantaneamente faça sentido para as pessoas que não conhecem a linguagem utilizada)
• A organização não o submeteu ao processo de revisão de código regularmente. Se o tivesse feito, o seu código teria sido rejeitado até o ter posto em conformidade com os seus padrões de legibilidade. Uma vez que é o único contribuinte do código, com o seu próprio estilo e utilizando uma pilha de tecnologia diferente, é praticamente garantido que com o tempo o código se tornará cada vez menos compreensível para os outros. A única forma de o evitar seria pedir aos outros que o código fosse revisto fora do processo, constantemente, possivelmente fazendo acusações de perda de tempo dos outros. A falta de um processo de revisão de códigos faz com que se crie um fracasso.

Tenho experiências semelhantes no meu passado. Fui contratado uma vez para preencher uma lacuna de competências. Ninguém mais na empresa tinha uma competência de que subitamente precisasse. Fiz bem o meu trabalho e, após alguns meses, começaram os conflitos. Eu era o único que podia trabalhar com determinados componentes da candidatura. Tornei-me um estrangulamento à medida que o trabalho se acumulava, o que só eu podia fazer. Um dia fui posto de lado, quando a empresa decidiu substituir tudo o que eu tinha produzido por um código completamente novo, fez à sua maneira. O meu orgulho foi ferido na altura, mas em retrospectiva, foi a decisão correcta para a empresa. Passado algum tempo, era tempo de eu seguir em frente, e assim fiz.

Se isto me soa familiar, talvez seja altura de seguir em frente. Talvez a gerência até o reatribua para outra coisa se continuar a valorizar as suas competências. Ou se conseguires aguentar, talvez possas ajudar a reescrever tudo o que fizeste na pilha de tecnologia standard da empresa. Se isso não for possível, basta ir embora. De qualquer forma, o seu código está provavelmente a caminho do caixote do lixo. Isso é provavelmente a coisa certa a fazer, se ninguém mais o entender. E de qualquer forma é a consequência natural das suas escolhas.

Certifique-se de que no seu próximo trabalho, outros da sua equipa estão a aplicar basicamente as mesmas competências que você, e especialmente que eles têm um processo de revisão de código. Quando eles lhe pedirem para alterar o seu código de determinadas formas, faça-o. Não considere o código entregue até que tenha sido aprovado na revisão do código e os seus colegas digam à gerência (se solicitado), sim, o código é bom. Então não há problema. É perfeitamente normal fazer perguntas sobre coisas como esta numa entrevista técnica; já o fiz muitas vezes. Espero que este outro desenvolvedor que estudou o seu código lhe dê uma boa referência.

Como nota de rodapé, se você é pelo menos parcialmente responsável pelas suas circunstâncias de trabalhar sozinho, sem a adesão de outros membros da equipa, então você merece pelo menos alguma da responsabilidade pelo resultado também. (Pressionou para usar o TypeScript / Node quando outros quiseram usar algo mais? Utilizou a biblioteca ou técnica mais recente, mais fixe, apesar de algo mais básico ter feito muito bem? Eu também já fui culpado disto uma ou duas vezes). Se assim for, não se esqueça de tirar uma lição deste resultado. Mas se não, leve esta experiência para a sua próxima posição com a cabeça erguida.

A maioria das respostas tratou a sua mensagem do ponto de vista da legibilidade ou não do seu código ou da sua qualidade. Mas esta situação pode acontecer e acontece em todas as esferas da vida. Aceitei um emprego na Las Vegas Strip como dealer e floorman 21. As minhas técnicas e velocidade estavam tão à frente do resto do seu pessoal que as pessoas designadas para me vigiarem não conseguiam acompanhar. Por outras palavras, não conseguiam acompanhar as minhas decisões. Uma vez que grandes quantias de dinheiro estavam a ser transaccionadas em minutos, sentiam-se muitas vezes confusos e denunciavam-me ao seu superior, alegando que eu tinha cometido um erro. Eu sempre justificava as minhas acções a essa pessoa, mas a atitude de desconfiança para comigo aprofundava-se.

O meu ego e suspeito que o seu não viu os sinais de aviso e, na verdade, revelei na minha superioridade, despejando-o por assim dizer. Eu terminei e perdi uma posição de pagamento extremamente boa.

A lição é simples, você deve ficar ao nível dos outros. Se eles só conseguem tirar 15 mãos por hora e tu tiras 100, não és um elogio inspirador. Você está inspirando ciúmes e até ódio. Se o teu orgulho não consegue fazer isto, tens de encontrar outra forma de ganhar a vida, porque todos os lugares são essencialmente iguais. As pessoas são pessoas, não se pode mudá-las. Acabei por me instalar noutras linhas de trabalho em que eu também era medíocre e, por isso, não me destacava. Espero que possa resolver isto em seu benefício.

Decidi actualizar o meu comentário para uma resposta:

Documentar muito bem o seu código.

A documentação adequada do código transforma más experiências em que um júnior esmaga a sua cabeça contra uma parede incompreensível durante horas em potenciais experiências de aprendizagem.

É possível que simplesmente não seja tão bom como pensa, mas, a bem da civilidade, parto do princípio de que sabe escrever a quantidade correcta de código complexo para reduzir a complexidade e os requisitos de tempo de toda a base de códigos por uma ordem de grandeza. O facto de isto ser mesmo possível leva muitos idiotas a surpreenderem-se. Eles acham uma proposta incrédula, e a única maneira de convencê-los é mostrá-los.

Mas isso requer requinte, coragem e autocontrole. Você precisa se concentrar em três coisas antes de todas as outras: provar que você não é uma ameaça, fazer os idiotas parecerem inteligentes, e nunca deixar um único idiota perceber que você sabe que ele é um idiota. Se não conseguires fazer estas três coisas, vais falhar, e a culpa será tua. O pragmatismo é uma obrigação e não há lugar para o orgulho.

Embora eu não possa recomendar esta abordagem a todos, o que sempre funcionou para mim é, por vezes, ignorar o que os idiotas hostis me dizem para fazer. Em vez disso, encontro formas de fazer o que quero fazer, produzir o melhor software que muitos deles alguma vez viram o código em muito pouco tempo, e apresento-o de tal forma que os seus chefes os recompensam com elogios brilhantes. Apesar de não terem desempenhado qualquer papel na sua criação. Mesmo quando se opuseram activamente a ele.

Está certo? Não deveria eu receber todo o crédito pelo meu trabalho? Devo mesmo ter de dançar à volta dos sentimentos de todos? Irrelevante. Isto é a realidade. Se eu não me adaptar a ela, então o idiota sou eu.

Há um monte de pessoas inteligentes que pensam que desenvolvedores altamente qualificados são insubstituíveis e é por isso que você do os quer. Mas já viu as outras respostas à sua pergunta - a maioria dos gestores não quer lidar com os problemas de uma equipa com níveis de habilidade muito variados, e não tem a opção de ir puramente alto nível de habilidade. Eles também não estão necessariamente errados, os problemas são reais, e os benefícios de um código de alta qualidade que está para além das capacidades da maioria das pessoas que são capazes de contratar são muito menores.

Se você é tão bom como diz ser, então você está desajustado com o seu trabalho. Parece que deve esforçar-se por trabalhar num local onde possa aprender com os seus colegas de trabalho e os seus colaboradores possam compreender o seu código.

Se perdeu alguns empregos devido a isto, então vai parecer bastante mal aos RH, recrutadores e gestores. Esperemos que consiga trabalhar em rede, encontrando criadores de competências semelhantes que possam garantir que o problema é que o seu nível de competências é realmente demasiado elevado.

Finalmente, tenho de acrescentar que deve fazer o seu melhor para avaliar honestamente se o seu nível de competências é realmente tão elevado. Parece que há provas de que o é, mas a maioria das pessoas acredita que é melhor do que é. Também muitos criadores passam por uma fase em que se tornam muito bons numa abordagem única, mas nem sempre reúnem tudo numa solução globalmente óptima, e ainda carecem de flexibilidade. Por exemplo, por vezes pode ser melhor optar por uma solução inferior que conheça as pessoas que pode manter, se souber que elas não podem manter uma mais sofisticada, e não é provável que contratem mais ninguém que possa.

Para abordar especificamente a questão,

Como posso evitar isto no futuro?

• Encontrar um capítulo local da Toastmasters, participar activamente e ganhar as conquistas. Algo que parece tão óbvio como um feedback, esperemos que se torne apreciado e afiado numa das suas competências mais valorizadas.

• Pratique sendo o estudante e não o perito. Já viu esta conversa de Jon Skeet sobre o básico ? Pode imaginar quanto mais compreensão pode ser alcançada se todos nós fizermos documentação como esta, beneficiaria todos, a todos os níveis de uma equipa!

• Uma equipa não é um indivíduo. A sua equipa vai crescer e melhorar colectivamente. Você tem de ajudar. Não é uma equipa se cada membro for uma célula que vai em direcções diferentes (por exemplo, você mais alto, e o membro mais novo estagnando). Reuniões de 2 horas é um bom começo. Eu acrescentaria ainda a rotação de pares de N dias. Esta é 1:1 vez que você presente aos seus companheiros de equipa **E eles presente a si. No seu caso, incline-se para o papel de navegador, e deixe o seu parceiro conduzir. Pratique não escrever o código, por estranho que pareça.

• Seja voluntário num Meetup local e Hack-a-thons. Pode obrigá-lo a destilar o seu código porque o objectivo é colaborar, e não construir uma rede eléctrica tolerante a falhas, certo?

• Em cada um destes exercícios, experimente este conceito: liderança servindo. Como pode fazer uma tarefa ou realizar algo para ajudar as necessidades de outro membro da equipa?

• Como referido, contribua para projectos open source para obter mais ângulos sobre o seu código. Eles podem confirmar que você é brilhante, mas também podem reforçar as sugestões que você está ouvindo do seu chefe atual. Na melhor das hipóteses, algumas revisões dar-lhe-ão uma nova ideia.

• Encontre um engenheiro que seja melhor do que você. Não é melhor ser o tipo mais inteligente da sala. Há uma citação (o meu googling está dividido entre Olgivy/Ford/Sorkin) parafraseando como “Não podes aprender mais se te rodeares de mau talento”.

Vou partir do princípio de que a sua descrição da situação é como o senhor diz. Não posso dizer que tive esta experiência exacta, mas há aspectos que me são familiares.

O senhor diz que esta é uma empresa “grande”. Não sei como é em França, mas muitas vezes as empresas maiores não valorizam as competências internas de desenvolvimento, especialmente se não são empresas centradas na tecnologia. Atribuo isto principalmente ao facto de os gestores dessas empresas não serem, muitas vezes, oriundos de áreas técnicas ou se afastarem do desenvolvimento porque nunca foram tão bons nisso.

Há também um aspecto histórico dos vendedores que vendem ferramentas que supostamente eliminam a necessidade de criadores talentosos. Mesmo que a sua equipa não esteja a utilizar uma destas coisas horríveis, há uma hipótese de a gestão da empresa ter sido doutrinada numa noção anti-intelectual de equipas de desenvolvimento. Na verdade, um gestor disse-me na cara que eu era suficientemente inteligente para construir uma determinada solução, mas depois ninguém mais seria capaz de a manter, pelo que precisávamos de comprar algo (shelfware.) Por isso, acredito que isto pode acontecer.

Talvez seja necessário procurar um tipo de empresa diferente. Uma que valorize os criadores altamente qualificados. Mas pode ter de se contentar em não ser o melhor programador. Se fosse um aspirante a chefe de cozinha, provavelmente não ficaria satisfeito por trabalhar no McDonald’s. Eles não precisam de chefes de cozinha. Precisam que as pessoas sigam uma receita. Você pode ser chef material e esta empresa (e outras como ela) é a McDonald’s. A pergunta que tem de fazer a si próprio é porque é que ainda não o fez.

Como posso evitar isto no futuro?

Não trabalhe com ninguém, a menos que tenha a certeza razoável de que o padrão de codificação deles corresponde ao seu. O que significa recusar qualquer trabalho se nenhum dos seguintes se aplicar:

• Eles fazem-lhe perguntas de programação durante o processo de entrevista
• Eles têm exercícios de programação de pares
• Eles pedem uma amostra de código e estão bem com ele
• Pode ver algum do código que produziram

Como posso evitar isto no presente?

Isto foi coberto por outras respostas.

Se é assim tão melhor, chegue ao nível deles e ensine-os lentamente a serem melhores programadores. A primeira vez que tive de gerir um estagiário quase eliminei todo o código que ele produziu. Fiquei literalmente furioso quando vi o que foi cometido (felizmente não tive testemunha :P )_.

É preciso incentivar a programação por pares, a revisão de códigos. Sente-se com outro programador e tente codificar juntos durante 2 ou 3 horas. Deixar cair conceitos que podem ser demasiado difíceis de explicar (novas funcionalidades avançadas do Java 8, por exemplo), e explicar os que são mais fáceis (herança).

Algumas vezes, quando se fala com outros, tem de se “mudo” para não se ofenderem as pessoas. Especialmente se estiveres bem acima dos outros com quem trabalhas, eles ficam provavelmente ofendidos quando falas de dicas e factos que eles provavelmente deveriam saber, mas não o fizeram.

Eu diria para comentares o teu trabalho muito bem, para que as pessoas que o verificam possam compreendê-lo. Pode até ter de “justificar” porque escolheu esse método de codificação em vez de um método diferente dentro dos seus comentários. Pode ser o melhor codificador, mas se está dentro de uma equipa, tem de trabalhar em equipa.

Se trabalhar em equipa significa trabalhar com uma mão atrás das costas, (com isto quero dizer seguir a preferência de codificação deles), então faça-o. Pelo menos então eles podem lê-lo, compreendê-lo, e a própria equipa está melhor (mesmo que isso signifique que está a gritar por dentro).

Quase onde quer que vá, onde quer que faça parte de uma equipa terá directrizes sobre como eles querem que as coisas sejam codificadas - e precisa de seguir estas directrizes.

Não podemos depender dele a longo prazo num

Esse é o maior problema. Eles não querem depender de si, mas foi contratado porque, na verdade, dependem de si.

Pode tranquilizar a gestão com:

• De qualquer forma, não está a pensar ir para outro lado, por isso podem contar consigo a longo prazo.

Acho que sou desafiado com problemas que mantêm as minhas capacidades usadas, por isso acho que finalmente encontro um local de trabalho de que posso desfrutar durante muito tempo

• Está disposto a dar formação a outros membros da equipa para dar mais valor à equipa.

Notei que o código dos outros não está realmente actualizado com as técnicas de desenvolvimento de software de ponta, não é um problema, posso deixar de usar essas técnicas, no entanto seria benéfico se todos começassem a usar essas técnicas gradualmente para melhorar o desempenho da equipa. Eu posso ajudar com isso.

• Foi-lhe pedido que implementasse as funcionalidades XY, tendo essas funcionalidades enviado dentro do tempo exigido pela sua habilidade, as coisas poderiam ter sido feitas de formas diferentes mas em muito mais tempo e com o risco de bugs adicionais.

Posso ter algum tempo extra para terminar as próximas funcionalidades? Eu realmente trabalhei arduamente para conseguir fazer as coisas correctamente, consegui fazer isso mas receio que nem todos possam compreender isso, em vez disso quero dedicar algum tempo a tornar as coisas compreensíveis para os outros.

Seja honesto, se alguma afirmação não se aplica (não faço agora aquilo que você trabalhou), não minta, nunca.

Se eles vão despedi-lo, então eles não estão realmente dependentes de si. De qualquer forma, pelo menos 2 pessoas da equipa compreendem o seu trabalho: Tu e o teu colega de trabalho. E é provável que mais pessoas o consigam compreender no futuro. Basicamente, você não é um estrangulamento na sua equipa, mas eles temem que você possa vir a sê-lo mais tarde. Devem investir algum tempo no treino, de qualquer forma.

Leia * The Wagon, the Blackbird, and the Saab ***. _ Deve ressoar em si._

Já tive problemas semelhantes no passado; aprendi algumas coisas sobre como lidar com isso, mas ambos temos usado esfregona e balde para tentar limpar a saída de uma mangueira de incêndio.

Não estou aqui a sugerir que mereça um diagnóstico de saúde mental DSM-V, mas estou a sugerir que talvez seja aconselhável que encontre um bom conselheiro e trabalhe em comportamentos e competências sociais não ameaçadores. Pode também ler * Teoria das mentes alienígenas ***.