Despedido pela terceira vez de um trabalho de desenvolvimento de software. O que fazer?

Passei muito tempo a refacturar e a tentar eliminar a dívida técnica. Recebi um aviso verbal por mau desempenho antes de ir de férias.

Parece que aqui estavam a trabalhar em algo que não foi pedido. Isto é geralmente muito mau, e pode levar à rescisão. Se pensa que o projecto precisa de ser refacturado, e confio que o fez, deve vendê-lo à direcção antes de o poder fazer. Se o tivesse feito, suponho que a direcção teria agido de forma diferente.

Pode ter dito a si próprio que não pode completar a sua tarefa sem o código para estar limpo. A verdade é que o código da maioria das empresas não o é. Trabalham com legado, tentam avançar com o que têm…

Fui colocado para trabalhar com uma tecnologia não relacionada com o que assinei para

…e quase todas elas vão esconder o legado por detrás de novas tecnologias mais apelativas quando forem entrevistadas.

Não creio que isto seja em si mesmo um sinal de que se deve mudar de carreira. Penso que não se tem aversão à engenharia de software quando esta é feita correctamente. Mas a engenharia numa empresa é sempre uma questão de lidar com software feito de forma errada, com a gestão a avançar. Se quiser durar numa empresa, deve estar preparado para aceitar isto.

Atualização : Uma vez que editou a sua pergunta com detalhes mais relevantes sobre como e porque foi despedido, preciso de fornecer uma resposta actualizada.

Em ambos os casos 2 e 3 os seus empregadores tinham grandes expectativas da sua capacidade de adaptação a coisas novas com base na sua experiência. Em todos os locais onde trabalhei, isto seria muito insuficiente para motivar o despedimento de alguém, mas estou disposto a admitir que em algumas culturas da empresa o capital humano não é muito valorizado. Isto é uma vergonha e um erro estratégico; mas isto é outra história.

Suponho que deve ler outras respostas, uma vez que elas fornecem múltiplas saídas criativas para si agora. Aqui estaria o que eu considero um conselho valioso:

1. Introspect
2. Reconstruir a confiança
3. Se optar por voltar a trabalhar como programador, escolha sabiamente a sua gestão. Refine as suas expectativas salariais se tiver a certeza absoluta.

Eu pessoalmente prefiro pequenas empresas, a sua gestão tende a ser mais humana.

Hoje fui despedido de uma empresa de software… pela 3ª vez em 1,5 anos. Escusado será dizer que sinto que cheguei ao fundo do poço e que é impossível sair sem mudar de carreira. Devo mudar de carreira? Será possível encontrar um emprego agora?

Yup, isso é muito mau. Mas lembre-se que não tinha a certeza se alguém o contrataria depois de ter sido despedido antes - no entanto acabou com este terceiro emprego.

Penso que precisa de olhar para dentro e determinar por si próprio porque é que isto está a acontecer.

Não culpe aqui a “má gestão”. Algo está a acontecer em cada caso que resultou num mau desempenho da sua parte. Em outras perguntas mencionou que foi despedido por não fazer perguntas suficientes e por não realizar trabalho de alto nível. Esperemos que possa aprender com tudo isso.

Pode ser que esteja a escolher empregos e/ou gestores de má qualidade. Pode ser que não tenha aprendido como trabalhar arduamente, concentrar-se no que é importante e ter um bom desempenho, apesar das questões no trabalho. Pode ser que esteja a disparar para um cargo de nível demasiado elevado e que seja mais adequado para o trabalho de nível júnior. Ou pode ser simplesmente que não esteja bem adaptado para este tipo de trabalho.

Passe algum tempo em introspecção. Tente chegar a uma conclusão antes de agir. Provavelmente não pode voltar a cometer o mesmo erro.

Pode considerar a hipótese de dar uma facada no trabalho temporário. Esses podem ser trabalhos mais fáceis de conseguir na sua situação. Talvez se possa motivar para ter um bom desempenho quando os projectos são pequenos e limitados no tempo. A sua experiência passada parece sugerir que poderia.

Estou na casa dos 30 anos sem um lugar de apoio, sem família por perto e sem muitos amigos.

Isso é algo em que vai querer trabalhar independentemente dos seus problemas de trabalho. Todos nós precisamos de amigos. E um bom grupo de apoio ajudá-lo-ia quando tem problemas de trabalho.

Continue a tentar ser amigável e a fazer mais amigos. Junte-se a um clube. Socialize-se com as pessoas do trabalho. Pelo menos tente.

Compreenda porque é que está a ser despedido

Você mesmo o disse. Estás a concentrar-te na reescrita, quando não é isso que estás lá para fazer. Você tem um really mau caso de síndrome de Not Invented Here. No que diz respeito à gestão, o problema parece ser se está preparado para fazer o que o seu gestor lhe diz e fazer o seu trabalho, ou se vai brincar com coisas que pensa que gostaria de fazer. E perante um novo desafio, parece que foge.

Quando ultrapassar isto, então estará empregável. Até lá, francamente, só estás a causar danos aos teus empregadores e à tua própria reputação. Os seus empregadores normalmente conseguem sobreviver a isto, mas você não.

Vamos ver o seu currículo…

Caso 1: Despedido de uma empresa fintech no 2º mês por falta de desempenho… falta de motivação.

Se sabia que isto não era algo em que se pudesse concentrar, porque aceitou o emprego? E se não sabia, porque não se demitiu com dignidade em vez de desperdiçar o tempo de todos? Este é o que realmente me preocupa.

Caso 2: Despedido de uma empresa de plataforma web por não desempenhar… tecnologia sem relação com o que assinei…

A natureza de um trabalho técnico é que haverá always coisas em que nunca trabalhou antes. Se não parece que já tenha trabalhado antes, seja dono dessa tecnologia e certifique-se de que as estimativas são ajustadas em conformidade.

Mas “não executar” normalmente não significa que não cumpriu os prazos, normalmente significa que foi apanhado a descuidar-se em vez de trabalhar. Num trabalho técnico, esperaria que alguém estivesse entusiasmado com a aprendizagem de novas competências, ou pelo menos que fosse diligente. Se vai fugir de algo que ainda não sabe, então encontre uma nova carreira.

Caso 3: … passou muito tempo a refacturar e a tentar eliminar dívidas técnicas… Tem tendência para limpar código sujo, refactor e garantir que as coisas são bem testadas…

E é aqui que o vemos a brincar com coisas de que não precisa. Chama-lhe “código desarrumado”. O resto da empresa chama-lhe “código de trabalho”. Eu venho de uma formação em engenharia relacionada com a segurança. Nesta linha de trabalho, as pessoas podem ser disciplinadas para corrigir bugs. A sério. O problema de “consertar” um bug é que você precisa provar que a sua correção não quebrou mais nada. No contexto do reteste de um motor e transmissão de um carro inteiro, um bug menor que talvez cause um erro de 1% no abastecimento de combustível para um tick de processamento após uma hora de funcionamento é muito provavelmente completamente aceitável, mas o custo em dinheiro e tempo de um reteste completo de todo o sistema provavelmente não é. Isso é antes mesmo de chegarmos a corrigir o código “confuso”, onde as suas alterações alegadamente não funcionais podem acabar por ter efeitos secundários devido a uma vírgula perdida ou algo igualmente tolo.

Em suma, está a ser contratado para fazer um trabalho profissional. Até agora, tem demonstrado que não é capaz de ser profissional. Quando pode ir a uma entrevista e apresentar essas falhas como experiências de aprendizagem que o ajudaram a mudar a sua mentalidade, então está pronto para ir… Consegues fazer isso…?

Tenho tendência para limpar código sujo, refactor e assegurar que as coisas são bem testadas - algo que pode ser visto por muitos como um desempenho lento.

Vou sair de um limbo e assumir que isto é mais do que o habitual “boys scouting”. Portanto:

Tenho tendência para escolher para limpar código sujo, refactor e assegurar que as coisas são bem testadas, _ quando estão “adjacentes” a algo que estou a escrever, e para dar prioridade a isto em relação ao transporte, independentemente daquilo com que fui encarregado._

Os testes e refactoring são óptimos, mas nunca é 100% uma chamada de uma pessoa para a ênfase que recebe. O código é um meio para atingir um fim - não está lá apenas para seu prazer, está lá para servir as necessidades do negócio, e as pessoas que trabalham mais perto dessas necessidades (a gerência) estão em melhor posição para estabelecer prioridades. Além disso, tudo o que se muda é algo que se pode potencialmente quebrar, com ou sem testes - para não falar do fardo adicional de revisão.

Em relação a uma mudança de carreira, penso que há duas coisas a considerar. A primeira é que, se for constantemente insubordinado, não importa em que carreira se está. Os cozinheiros de linha que “melhoram” as receitas também são despedidos. Por outras palavras, estás potencialmente a ser despedido por não te concentrares. A tua impulsividade pode facilmente seguir-te para uma nova carreira, por isso a mudança só compensa se te concentrares primeiro. O segundo é o que mencionou sobre a falta de motivação. O que pode estar a causar uma falta de concentração é se talvez não gostar_ de codificar para além da limpeza das coisas existentes, o que é completamente compreensível. Mas se for verdade, isso significa que um quarto trabalho de desenvolvimento estaria apenas a inscrever-se para mais tortura (assumindo que está a trabalhar numa equipa e numa base de códigos existente).

Mas eu faria fazer o que dizes que vais fazer a tua prioridade máxima, e ir a partir daí. Feito correctamente, isto também significa não assumir obrigações que acha que não consegue cumprir. Quem sabe, talvez descubras que preferes cozer pão. (É apenas um exemplo, mas penso que é um bom exemplo - é um ofício, envolve resolução de problemas, recompensa o perfeccionismo, e geralmente fá-lo você mesmo do princípio ao fim)

De qualquer forma, o importante é que se lhe pedem para fazer um trabalho, e você o aceita, então fá-lo você mesmo. Mais tarde, se se verificar que não é para ti, então curva-te graciosamente e tenta outra coisa. Mas fazer essa “outra coisa” no cêntimo de outra pessoa, enquanto eles pensam que estás a fazer o que eles te pediram, só vai irritar as pessoas, em qualquer linha de trabalho.

Auch*

Não precisa que lhe diga que isto não é bom, por isso não vou desrespeitar o objectivo, mas vale a pena dar uma vista de olhos aos três disparos:

Caso 1: Despedido de uma empresa fintech no 2º mês por não actuar. Isto estava correcto porque eu tinha uma falta de motivação.

Nada a dizer aqui - sabes que fizeste asneira. Algo me diz que a falta de motivação não será um problema para si agora!

Caso 2: Despedido de uma empresa de plataforma web por não actuar. Fui colocado para trabalhar com uma tecnologia não relacionada com o que assinei, por isso isto parece ser uma má gestão do meu lado.

Apesar de não ser a gestão ideal para colocar novas contratações em tecnologia a que não estão habituadas, eu teria receio de culpar tudo por isso - são precisos dois para dançar o tango como diz o ditado e ficaria surpreendido se não houvesse mais nada que pudesse ter feito para evitar isto como um despedimento, mas vamos chamar-lhe 80-20 por culpa deles.

Caso 3: Despedido no 6º mês por mau desempenho. Durante o período de experiência recebi um feedback positivo. Depois disso, mudei de projecto e passei muito tempo a refacturar e a tentar remover a dívida técnica. Recebi um aviso verbal por mau desempenho antes de ir de férias. Nos 4 dias que tive, tentei corrigir isso, ficando horas extraordinárias e terminando todo o trabalho devido. Contudo, quando voltei das férias, recebi uma carta de rescisão.

Desculpem, mas esta é tudo por vossa conta - a refactoring à medida que vão andando não é má por si só, e pode ser uma forma muito eficiente de limpar uma base de códigos sem parar completamente o desenvolvimento durante vários meses. Mas fazê-lo quando não tem direcção ou pelo menos aprovação para o fazer (incluindo o tempo adicional que leva) não é uma boa ideia. Do ponto de vista do empregador, parece que você trabalhou para passar pela experiência e depois descuidou-se (eu percebo que não foi isso que você fez - mas é isso que preocupa-nos).

Geralmente a questão como a vejo, é que tenho uma tendência para limpar código sujo, refactor e assegurar que as coisas são bem testadas - algo que pode ser visto por muitos como um desempenho lento.

Identificou a causa provável das opiniões de “mau desempenho” mas parece não ter chegado lá ao ponto de perceber que este é realmente mau desempenho. Não fazer estimativas (assumindo que essas estimativas sejam realistas) não é apenas “visto” como um desempenho lento, é, por qualquer definição do termo “desempenho lento”! Se uma história/ticket/ou seja o que for que tem uma estimativa de 6 horas para completar e leva 12 horas porque passou mais 6 horas a fazer a actividade X, então não importa realmente _ o que_ actividade X é, se estava a refacturar ou a ver vídeos de gatos no tubo, ainda demorava mais 6 horas a fazer a tarefa que lhe foi atribuída.

A boa notícia é que basicamente tem as capacidades e talento que precisa para ter sucesso na codificação - só precisa de apoiar um par de coisas na sua abordagem. Encontrar algo que possa beneficiar de um refactor quando se está a trabalhar numa tarefa? Óptimo! Essa habilidade pode ser voltada para a sua vantagem em vez de um espinho do seu lado - tudo o que tem de fazer é falar com o seu gestor/líder de equipa ou com quem gere o planeamento e a alocação de recursos e dizer o que encontrou, que benefícios pensa que isso pode trazer ao negócio e quanto tempo pensa que vai demorar a fazê-lo.

Se eles concordarem que vale a pena o investimento de tempo que podem dedicar ao tempo extra, não se passa por cima da estimativa e parece-se com uma estrela do rock por ser proactiva na ajuda à empresa.

I love ter codificadores a reportar-me que fazem isso!

No entanto…

Tem de aceitar que por vezes eles vão dizer “Não” ou “Agora não” a estes pedidos - isso é porque consideram que os prazos para completar a tarefa original são mais valiosos neste momento, e como eu digo, tem de aceitar essa resposta porque não há nada de mal em que eles façam essa chamada, porque é para isso que eles são pagos.

A menos que tenha 110% de certeza de que a não implementação imediata da sua proposta de refactoring terá consequências desastrosas para a empresa, então não adie, não discuta. Faz-se o que se está a ser pago para fazer, se a empresa explodir mais tarde então, francamente, é responsabilidade da pessoa que decidiu não o fazer - mais uma vez é para isto que lhe pagam!

** Então para onde vai a partir daqui? **

Não acho que precises de mudar de carreira neste momento - como digo, parece que tens as capacidades e, embora o teu recente historial profissional seja, para ser franco, bastante condenável, não é irreparável e com algum trabalho árduo e um pouco de sorte consegues acertar o navio e voltar ao bom caminho como se isso nunca tivesse acontecido.

Eis o que eu faria se fosse a si:

• Ir contratar (esta seria a minha recomendação) - o historial de trabalho é menos importante do que ter as competências na palavra contrato, e é mais provável que as pessoas aceitem um trocadilhoalguém por um contrato, então é para uma posição permanente, uma vez que é mais fácil deixá-los cair e arranjar outra pessoa se tomarem uma má decisão de contratação. Você tem um buffer fantástico de poupanças que lhe dará tempo para tentar - estabeleça um prazo: se não conseguir encontrar (e ser bem sucedido) num contrato em 3 meses, então pode alargar a sua pesquisa para incluir posições perm. Até agora não demorei mais de três semanas para garantir uma posição contratual, e estou appalling em entrevistas, por isso pode fazer isso! Um bom contrato de 6 meses e muito poucas pessoas se vão importar com os seus últimos três empregos permanentes! E ainda por cima, mesmo que tenha de olhar para o segmento inferior do mercado em termos de taxa diurna para o seu primeiro par de contratos, provavelmente estará a ganhar muito bom dinheiro em termos reais.

ou se contratar não é realmente algo que queira fazer:

• Fique permanente - dê um passo para baixo na escada salarial

Neste momento, ter um bom histórico de trabalho é mais importante do que maximizar os salários. Trabalhe a quantidade mais baixa realista de que precisa para viver e comece a candidatar-se a empregos nesse escalão. Há sempre empresas cuja ambição na contratação excede o seu orçamento, e tendem a ser menos exigentes. Mesmo que esteja a tirar um corte de 5 mil libras esterlinas ao seu potencial, conseguirá ganhar isso a longo prazo, bastando para isso aguentar-se durante ~2 anos e ter um bom desempenho. Não estou a dizer que seria divertido, ou fácil, mas seria muito eficaz.

Não desista - você pode fazer isto!

Sei que já existem aqui 16 respostas, muitas delas excelentes, mas não parecem ter abordado a possibilidade de haver outras razões para ser despedido.

Pode ser apenas que estas tenham sido desculpas convenientes para o seu despedimento. Nunca é agradável apontar isto, mas vale a pena examinar se se está a adaptar a um nível pessoal.

Conheci (de) algumas pessoas que passaram por vários empregos em pouco tempo e não conseguem ver porquê. Para mim (e para outros) tem sido óbvio - eles têm um hábito ou traço que gruda nas pessoas que os rodeiam. Para um dos rapazes, este era um hábito de limpar a garganta a todo o momento, associado a não levar a dica quando as pessoas queriam terminar uma conversa. Trabalhei no mesmo gabinete que ele e posso dizer-vos que o ambiente depois de ele ter saído era muito mais agradável. Outro tipo, era um problema de higiene. Ambos foram despedidos por aquilo que parecia razoável, mas você sabia no fundo da sua mente que estes outros traços definitivamente tinham sido tidos em conta.

Não estou a dizer que você tem alguma destas características, pode até ser um choque cultural, não algo que até é culpa sua, mas como outras respostas sugerem, um período de introspecção é muito valioso aqui. Eu alargaria isso para olhar para coisas como hábitos e traços pessoais para verificar se eles podem ser a causa oculta.

Suponho que não ouvir é um problema fundamental. Não apenas ouvir palavras, mas compreendê-las e levá-las a sério.

Isto salta-me para cima:

Geralmente a questão, como eu a vejo, é que eu tenho uma tendência para limpar código confuso, refactor e assegurar que as coisas são bem testadas - algo que pode ser visto por muitos como tendo um desempenho lento.

“Isso pode ser visto por muitos como tendo um desempenho lento” não é a parte importante. A sua empresa disse-lhe que o seu desempenho é lento , porque o despediram. Se o seu chefe diz para fazer alguma coisa, faça-a. Se o seu patrão diz para não fazer algo, não o faz. Se não tens a certeza, então pergunta à tua chefe e faz o que ela diz.

Como novato no mundo dos negócios, não te compete a ti decidir o que a empresa deve fazer. Quando decides por ti próprio ir fazer limpeza de códigos, estás a dizer-lhes que a empresa que conheces é melhor do que eles. Não faça isso.

Como desenvolvedor há 32 anos, sei que pode ser frustrante deixar dívidas tecnológicas, deixar código sujo ou não documentado. Mas se é isso que a empresa quer que você faça, então faça-o.

Pode sempre ensinar informática no liceu se achar que o seu percurso profissional na indústria é limitado. Há outras coisas que também podes fazer como gestão de projectos.

Mas quando te candidatas a outro cargo, não expliques os teus despedimentos como problemas de gestão. Mesmo que o gestor tenha sido completamente responsável pelo que aconteceu, darás a impressão de que não és capaz de avaliar os teus próprios erros e fraquezas.

Escreve uma carta de apresentação com as tuas novas candidaturas e explica o que aconteceu. Assuma a responsabilidade por isso, independentemente das razões. Explique por que razão as coisas serão diferentes.

Poderá ter de aceitar contratos durante algum tempo. Confie em mim, já vi muitos empreiteiros entrarem e saírem.

Uma vez restabelecido, pode começar a construir a sua carreira como um empregado de sucesso.

NUNCA pense que as suas opções são limitadas porque isto apenas limitará as suas opções. É clicado, mas tem de manter uma atitude positiva.

Conheço a sensação de querer passar muito tempo a melhorar a qualidade do código para aumentar a velocidade do desenvolvimento. Podem absolutamente poupar imenso tempo, até, inclusive, tornar os projectos complexos exequíveis em primeiro lugar. No entanto, eu teria o cuidado de os introduzir lentamente ao iniciar um novo trabalho.

Espero que sejam necessários meses para construir um contexto suficiente (tanto de programadores, utilizadores e gestores como de código) para aprender onde estão os mais grandes (e não apenas os grandes) pontos de dor. Assim que tiver uma compreensão sólida destes deverá ser capaz de apresentar um caso ao seu gestor para trabalhar em um deles durante um período de tempo curto para melhorar massivamente algum aspecto do código. E quando você prega um destes, você realmente mostra porque eles devem mantê-lo. Não é preciso ser um programador fantástico para fazer isto - toda a gente com um pouco de experiência tem capacidades que o resto da equipa não tem.

Antes de tudo isso, no entanto, eu concentraria-me em fazer as coisas do dia-a-dia. Já trabalhei em locais onde a garantia de qualidade dos programadores era tão fraca que passávamos quase todo o nosso tempo a apagar fogos. Não é divertido, mas a menos que consiga fazer o dinheiro rolar em faster management não vai estar interessado em limpar as coisas.

Como nota final, tive vários maus trabalhos como programador de software, mas outros têm sido muito divertidos. Pessoalmente eu recomendaria instituições de investigação e empresas mais pequenas, uma vez que elas são, na minha experiência, flexíveis na forma como trabalham e pelo menos um pouco interessadas em GQ.

Então, eu vim aqui para encontrar todas as respostas que lhe dizem para se comportar, manter a cabeça baixa, aceitar as críticas, trabalhar nas tarefas atribuídas e melhorar a comunicação.

Em primeiro lugar - você absolutamente deveria melhorar as suas capacidades de comunicação. É algo em que você can trabalhar e melhorar e eu consideraria fazê-lo se fosse você.

Depois vi o seu perfil GitHub

Isto fez-me mudar de ideias. O seu código lá está de facto muito acima da média e indica que você começa a ser muito exigente. Para ser claro - o seu perfil não é incrível, mas certamente o coloca acima do desenvolvedor médio que vem à entrevista quando eu entrevisto candidatos no meu livro.

Você não necessário para justificar ser demitido 3 vezes

A indústria de software está em um lugar onde ter um perfil GitHub como este lhe dá entrevistas e ofertas de emprego mesmo que você tenha sido demitido 3 vezes.

Você pode dizer que os lugares em que trabalhou foram maus encaixes culturais porque eles não valorizavam tanto a excelência técnica como você (o que é verdade) e entrevista em lugares que do valorizam a excelência técnica.

Muitos desenvolvedores não podem pagar isso - mas você pode absolutamente.

Idealmente você trabalharia no que o seu chefe lhe disse, o que é uma coisa boa, mas é inteiramente possível para você encontrar um lugar com valores que se alinhem com os seus.

Descubra o que você realmente quer

Parece que os últimos 3 lugares foram todos maus para ambos os lados. Uma vez que você é exigente eu procuraria um lugar que:

• Trabalha com novas e modernas tecnologias que o excitam
• Tem uma cultura de valores que lhe interessa
• Resolve problemas que lhe interessam

Em vez de se concentrar em como explicar porque foi despedido - concentre-se em o que quer realmente realizar no seu trabalho.

A programação excita-o o suficiente para o fazer no seu tempo livre - o que é que isso o excita?

Encontra um lugar que se ajuste bem

Conheço alguns programadores nas suas situações (que foram despedidos 3-4 vezes num ano) até encontrarem um lugar que os pudesse conter. Eles são bastante opinativos, um pouco barulhentos e preocupam-se muito em usar padrões modernos e fazer as coisas da maneira certa.

Todos eles estão agora felizmente empregados em locais que os podem conter.

Muito do que eu normalmente diria já foi dito. Mas há pelo menos um caminho aberto para si que penso que ainda ninguém lhe deu como resposta.

Considerar contrair / trabalhar por conta própria.

Muitas das outras respostas centraram-se na forma como se pode vender ao seu próximo empregador, como pode explicar a sua curta estadia nas suas três últimas funções e o que pode fazer de diferente para manter o seu próximo emprego. Tudo isto é verdade, mas encontrar outro empregador não tem de ser a única opção. E se o seu próximo empregador fosse… você?

Pros:

• Não precisa de explicar nada nem justificar o que aconteceu a mais ninguém.
• Se for realmente bom naquilo que pode fazer, as suas competências serão procuradas, a um preço compensador.
• Já tem seis meses de poupança - é tempo suficiente para encontrar clientes e começar a trabalhar.
• Assim que tiver alguns clientes, pode escolher o que quer trabalhar (ou seja, quais os clientes a contratar), em vez do que o seu empregador lhe disser para trabalhar.

Contras:

• Terá de gerir o seu próprio negócio e resolver os seus próprios impostos, bem como desenvolver software.
• Se não for tão bom como pensa - ou se não conseguir encontrar motivação para fazer o que os clientes querem - ou se perder todo o seu tempo a fazer código limpo e sem dívidas técnicas quando o cliente só quer software de trabalho - pode queimar todas as suas poupanças e acabar exactamente onde está agora, excepto que as suas poupanças se foram. ** Este é um risco real.** Terá de olhar para o espelho de uma forma longa e dura antes de seguir por este caminho. Mas suspeito que terá de o fazer, aconteça o que acontecer.

Aguente-se aí. Muitas pessoas chegam aos seus 30 anos e descobrem que as coisas não saíram como esperavam. Não é demasiado tarde.

Parece-me que o seu problema é que faz as coisas à sua maneira. Têm este padrão de comportamento em que a forma como estão a fazer as coisas é “a forma correcta” e tudo o que indique que precisam de mudar isso salta por cima. Felizmente, a sua maneira é bastante boa, tem uma forte ética de trabalho, boas maneiras de trabalhar e não se engana ao dizer que é a maneira certa. A questão é quando isto colide com as prioridades do seu empregador.

O seu primeiro despedimento foi por sua própria admissão uma falta de motivação, a FinTech é um material bastante seco, não o posso certamente culpar por perder o interesse nisso, tenho a certeza que não iria aguentar o meu. Não lhe vou perguntar porque é que se candidatou em primeiro lugar, eu estava a candidatar-me a empregos na FinTech quando me candidatei ao meu actual local de trabalho, um emprego é um emprego.

Chame-lhe um mau ajuste e lição aprendida.

O seu segundo despedimento deveu-se ao facto de lhe terem pedido para fazer coisas para as quais não foi originalmente contratado (pelo menos pela sua compreensão do seu contrato) e ao facto de não estar satisfeito com isso.
Isto não é invulgar, tive de lidar com trabalhos em que grande parte do meu tempo não foi gasto a fazer o material para o qual fui treinado e qualificado, isto é definitivamente má gestão. No entanto, se é necessário aprender um novo conjunto de competências ou ferramentas no trabalho, isso faz parte do trabalho.

Tenho a certeza que não preciso de lhe dizer que a indústria de software está constantemente a flutuar e manter-se a par das coisas mais recentes é vital para o sucesso. Só este ano tive de aprender Desenvolvimento Web do zero e peguei no Vue.js, JQuery e Bootstrap do zero, no ano passado aprendi Xamarin e tornei-me Developer App. Antes disso estava a construir jogos para telemóvel e Facebook em Unity3d e Flash. Trabalhei em Agile e Scrum, independentemente e em equipas de modelos de cascata. O que eu preciso, eu aprendo. Se actualmente não consegues fazer isso, precisas de aprender a ser adaptável se quiseres ter sucesso na indústria de software.

O teu terceiro despedimento é aquele sobre o qual mais escreves, O problema é muito mais claro lá. Sabia que a forma correcta de escrever código era fazê-lo correctamente na primeira vez, passar o tempo adiantado e poupará tempo e dinheiro mais tarde. Não estás nada enganado. Bom trabalho nisso.

Contudo, foi-lhe dada (presumo) uma tarefa clara e porque passou um tempo fora da tarefa, não conseguiu entregar consistentemente o trabalho que lhe foi pedido.

Ir fora da tarefa para corrigir o código relacionado é algo que eu faço o tempo todo, mas é fundamental não se perder na toca do coelho. Lembre-se que os últimos 10% de um problema demoram 90% do tempo. Abra o código do problema, remende a parte que está causando o problema, adicione um //TODO para corrigi-lo corretamente, escreva uma nota em algum lugar que precise de mais atenção mais tarde e move on. Normalmente 90% é suficientemente bom.

A sua tarefa #1 é _ sempre_ entregar o material que lhe foi dito para fazer, e como novo contratado, tem muito menos autoridade unilateral do que gostaria. Eu próprio me meti-me em sarilhos por esta mesma questão e, por vezes, é difícil passar pelos aros para o conseguir.

Este é provavelmente o seu maior problema. Você precisa de fazer as coisas como o seu empregador quer que você as faça. Se acha que o seu empregador está a subestimar a importância de algo, explique em termos de tempo e dinheiro e se eles still não estão de acordo. Aceite-o. O empregador é seu cliente, e como diz o ditado contundente, o cliente tem sempre razão.

Em conclusão, não desista. Você tem claramente as habilidades e capacidade para ser um grande programador, só precisa encontrar um emprego que lhe interesse e melhorar na triagem de problemas enquanto presta atenção às prioridades da sua equipe.

Hoje em dia, o emprego no mundo da tecnologia é uma espécie de jogo.

Vou adivinhar que a vossa empresa segue a metodologia da AGILE.

A chave não é fazer o que lhe apetece, mas sim fazer o que lhe é atribuído.

E não se acanhe de se levantar para ganhar mais pontos, e pedir mais tempo.

É MUITO melhor exigir mais tempo e obter mais pontos para as suas tarefas no início do que escorregar.

A Gerência tem 0 pista sobre a dificuldade das suas tarefas… eles apenas seguem as estimativas iniciais.

Se você não lutar por pontos no início… você está lixado.

Nenhuma resposta até agora parece considerar a possibilidade de ter tido muito azar e ter conseguido 3 empregos horríveis de seguida. Existem definitivamente alguns empregos horríveis e gestores irracionais por aí. Já tive vários, mas não tantos seguidos. Por vezes são muito difíceis de detectar durante a entrevista; em alguns casos, as descrições de funções e as coisas ditas nas entrevistas são totalmente imprecisas e enganadoras. Portanto, é POSSÍVEL que isto não seja culpa sua; mas só você tem informação suficiente para poder julgar isto.

No final, no entanto, é muito provável que tenha um mau emprego para começar (tedioso, má gestão, baixos salários). Só tem de o tolerar durante alguns anos, por isso pense cuidadosamente no que está disposto a suportar num emprego, e talvez reduza as suas expectativas.

Parece-me que o seu único problema é não poder fazer as tarefas que lhe foram atribuídas. Em todas as suas tarefas que lhe foram despedidas, você declara que não fez a tarefa que lhe foi dada e se concentrou em fazer outra coisa (refactoring, etc.). A menos que fale nestas coisas antes de chegar ao ponto de falhar prazos, eu não o faria.

Lembre-se sempre que as pessoas pensam o pior em todas as situações negativas. Por isso, se falhares o prazo e tiveres vários ficheiros alterados (mesmo que seja preciso menos do que isso), eles não vão pensar nada de bom nisso. Certifique-se de comunicar os problemas que vê e obtenha autorizações para fazer outra coisa do seu gestor antes mesmo de o fazer. Não comece apenas a fazer outra tarefa.

Penso que se seguir esse conselho, terá uma carreira de sucesso. A certa altura, todos confiariam na sua experiência e concentrar-se-iam em tornar o código melhor. Mas como o novo tipo, que ninguém conhece, que não faz uma tarefa simples e refaz um código não relacionado, isso simplesmente não vai voar.

Sei que já há demasiadas respostas a esta pergunta, mas só queria partilhar a minha experiência com base na sugestão de Joe Strazzere: considerar trabalho temporário/contratado.

Disse que está sedeado no Reino Unido, o mercado de empreiteiros está em plena expansão neste momento. Em Londres pode ganhar cerca de £500 por dia. O bom disto é que nunca se cansará do local onde trabalha e começará a arrastar os calcanhares, a cada 3-6 meses terá de encontrar um novo contrato.

Esta pode ser uma solução, mas também pode não estar bem adaptado ao ritmo rápido do trabalho de empreiteiro. Pessoalmente gostei muito e depois dos meus primeiros 6 meses de contrato com a BBC tive poupanças suficientes para trabalhar por conta própria e trabalhar a partir de casa.

O que deve procurar é conseguir bons clientes e trabalhar remotamente. Depois tem total liberdade para refactor o seu código desde que esteja a entregar os projectos a tempo. Pessoalmente, nunca estive tão motivado como quando dirigi a minha própria empresa. Trabalhava 12 horas por dia, 6 dias por semana.

** Mas também tenho a sensação de que não está 100% satisfeito com a sua carreira, talvez seja altura de fazer uma pausa?**

Tem poupanças, porque não ir viajar e passar 3-6 meses a pensar no seu próximo passo? Uma forma fantástica de viajar é usar o trabalho, já fui voluntário em Espanha e no Japão a usá-lo. Vais conhecer muita gente. https://www.workaway.info/299958546294-en.html

Tem problemas em manter o foco e a motivação ao lidar com o código de outras pessoas.

Eu simpatizo com isto - é difícil continuar a empurrar novas funcionalidades para fora da porta sem limpar a casa e ainda sentir que está a contribuir para algo de que se pode orgulhar.

Mas, infelizmente, isso será verdade para a grande maioria das organizações que o vão contratar para escrever código. Não lhe vou dizer para “ultrapassar” - imagino que, a não ser que seja profundamente mau a pensar em si próprio, esta opção já lhe ocorreu.

Em vez disso, sugiro que considere a possibilidade de usar os seus conhecimentos técnicos para uma carreira no desenvolvimento de software que não envolva a escrita de código de aplicação como foco principal.

Poderá encontrar mais prazer, realização e um tempo mais fácil de focalização como Engenheiro de GQ e/ou DIT. Poderá ainda escrever código e resolver muitos dos mesmos tipos de puzzles envolventes, mas o seu foco e responsabilidade CORE está a melhorar a qualidade do produto. Isso parece estar mais de acordo com a iniciativa que mostrou aqui.

É minha experiência que neste tipo de funções, normalmente tem uma equipa mais pequena, uma secção mais pequena da base de códigos pela qual é responsável e, portanto, muito mais latitude para refactor de forma agressiva. Adicionalmente, se fizer bem o seu trabalho, não só escreve código com o qual pode ficar satisfeito, como também ajuda a melhorar de forma mensurável a qualidade daquilo que realmente atinge a produção.

Também é comparativamente fácil vender essa transição para um potencial empregador nesses termos - Teve dificuldades como programador de software porque passou muito tempo a concentrar-se naquilo que essencialmente equivale a controlo de qualidade, por isso decidiu mudar de foco para apenas fazer controlo de qualidade.

Aconselho-o a fazer uma pausa e a trabalhar em si mesmo. Especialmente a falta de um círculo de amigos positivo e de uma vida social inactiva parece ser um enorme factor que contribui para a sua vida. Sente-se queimado ou solitário? Já tentou contactar um terapeuta ou um mentor para verificar se sofre de algum tipo de depressão ou de TDAH? Sente-se à vontade para trabalhar sob autoridade? Já pensou em trabalhar como freelancer ou a tempo parcial? Muitas pessoas atingiram um patamar na casa dos 30/40 anos. E a codificação pode ser um trabalho para sugar a alma, por vezes. Tente explorar os seus passatempos ou um campo relacionado próximo da sua especialidade.

O problema parece ser mais pertinente para a sua personalidade do que para a sua área de trabalho. Aconselho vivamente a fazer uma pausa e ir à procura da alma até encontrar a motivação para fazer parte de outra equipa.

Como desenvolvedor que também valoriza o código limpo, bem testado e despreza o código da dívida, posso entender o seu ponto de vista. No entanto, está a ser pago para completar as tarefas tal como lhe foram atribuídas. Trabalhar não é fazer aquilo que se quer fazer, mas fazer aquilo que o seu empregador espera de si. É um bónus quando se pode encontrar prazer em fazer as coisas pelas quais se está a ser pago. Ter uma boa ética de trabalho requer o desenvolvimento da autodisciplina para se concentrar na tarefa atribuída e fazê-la de forma satisfatória para o seu empregador, quer goste ou não de a fazer, quer encontre satisfação em fazê-lo ou não. As recompensas que pode retirar disto são (1) ser pago, (2) ter alguma segurança de que continuará a ser empregado, (3) talvez aprender algo novo e útil, (4) construir o respeito na organização que poderá eventualmente alavancar para fazer as coisas mais a seu gosto e/ou satisfação.

Se pensa que tarefas importantes estão a ser deixadas por fazer (refactoring, reduzindo o débito do código, melhorando a cobertura dos testes), por todos os meios mencione-o ao seu supervisor. Se isso puder ser feito durante a conclusão de uma tarefa atribuída sem atrasar a conclusão do trabalho atribuído, óptimo. Se só pode ser feito à custa da tarefa atribuída, deixe-a.

Algo mais a considerar: as decisões empresariais são tomadas com base no facto de aumentarem as receitas ou reduzirem os custos, e geralmente têm um horizonte curto. Não é raro as empresas concentrarem-se em resultados para o trimestre corrente ou para o próximo trimestre. Muito dinheiro de investimento é movimentado com base nos resultados trimestrais; é isto que orienta as decisões das empresas. As melhorias que se sentem motivadas para fazer na base de código são um investimento a longo prazo sem um benefício quantificável. Ambos sabemos que é uma coisa boa, e para um negócio que está em actividade a longo prazo, é a coisa direita. No entanto, as empresas não tomam decisões baseadas no que é certo ou melhor a longo prazo, elas servem os seus donos - os investidores.

Se decidir continuar como promotor, e sinto que o faz, pois demonstra orgulho nas suas realizações fora destes três empregos, tome medidas concretas para resolver as suas limitações, de modo a que os seus pontos fortes comecem finalmente a brilhar para os seus empregadores.

Primeiro, posso sugerir que a sua falta de foco é causada por uma falta de organização diária? No seu próximo emprego, certifique-se de que conhece sempre as três principais prioridades que o seu patrão lhe atribuiu (e a sua importância relativa). No início de cada dia de trabalho anote as suas prioridades actuais e, no final do mesmo, resuma o que conseguiu fazer contra elas. Não seja verboso, faça com que cada prioridade e descrição de realização seja tão curta e doce quanto possível, apenas com o mínimo detalhe exigido. Algo como…

Início do dia

1. implemente a nova funcionalidade A
2. Realizar testes unitários para A
3. Criar nova versão A com documentação para os testadores.

Fim do dia

1. Implementado A
2. Escrever testes unitários para A, e corrigir erros de forma a passar todos os testes.
3. Não consegui lançar A, pois passei duas horas a apoiar as vendas num problema prioritário do cliente com o produto.

E no dia seguinte a sua primeira prioridade seria provavelmente

1. Construa o release A e escreva documentação para os testadores.
2. …

Todas as segundas-feiras de manhã faça algo semelhante durante a semana. Primeiro escreva os seus objectivos/prioridades planeados para a semana, e depois refira-se a ele todas as manhãs quando escrever as prioridades diárias para que estejam em sintonia com os seus compromissos semanais.

Também recapitule e resuma o que realizou na semana anterior, utilizando as suas notas de fim de dia. Depois envie-o ao seu chefe como os seus objectivos/acumulações semanais para que eles saibam o que fez e o que planeia fazer. Desta forma eles podem oferecer correcções de curso se você estiver errado ou se as prioridades tiverem mudado. E quando começar o seu novo emprego, nas primeiras semanas pode até enviar as suas prioridades diárias de manhã com recapitulação de ontens ao seu patrão para aumentar a confiança deles em si ainda mais rapidamente.

Certifique-se apenas de que não faz objectivos semanais demasiado agressivos, que não quer estar constantemente a faltar aos compromissos que o seu patrão vê, mesmo que sejam artificiais que você estabeleça para si mesmo. Divida-os em “Compromissos” que está muito confiante de que vai conseguir cumprir, e “Objectivos de Esticar” que comunica que espera alcançar se a semana correr bem.

Ao auto-organizar-se desta forma, ajuda-o a realizar várias coisas importantes.

1. O início de cada dia será reorientado para as prioridades e compromissos que lhe foram atribuídos, facilitando-lhe a resistência à refacturação e à realização de outros trabalhos não atribuídos.

2. Forçarmo-nos a recapitular as realizações no final de cada dia torna muito claro quando recuamos, ajudando-nos novamente a recentrarmo-nos nas prioridades que nos foram atribuídas.

3. Partilhá-las com o seu chefe ajuda-os a vê-lo como um membro de equipa fiável e previsível que os faz parecer bem ao seu chefe e os ajuda a atingir os seus próprios objectivos.

Eu próprio faço o relatório semanal para o meu chefe todas as semanas, e ele adora isso. Na verdade, reduziu a quantidade de comunicação de que precisamos, pois ele desenvolveu muita confiança em saber o que estou a fazer e pode facilmente redireccionar-me se as prioridades mudarem.

Não faço o planeamento/recapitulação do dia de trabalho diário, mas recomendo-o porque, depois de ler o seu post, percebo que ambos precisamos dele. Tal como vocês, também eu tenho tendência a ser mal direccionado para o código de refactoring e para a resolução de problemas que não são necessariamente grandes prioridades para a empresa. E uma semana é muito tempo, é fácil esquecer alguns objectivos-chave a meio da semana e só nos apercebemos de que não os atingimos quando recapitulamos a semana de segunda-feira. Por isso, ao escrever-vos isto, também me atribuí a mim próprio a repetir lembretes diários para fazer as duas coisas.

Por último, se as minhas recomendações não parecem funcionar para vos manter concentrados nas prioridades certas todos os dias, não faz mal. Mas certifique-se de que encontra outro sistema que o faça. Mesmo que se mude para outra área, concentrar-se todos os dias nas expectativas do seu chefe e da sua empresa é um factor chave para ter sucesso em qualquer percurso profissional que escolha.

Quando tem de explicar porque não teve sucesso nos seus empregos anteriores nas suas próximas entrevistas, uma grande resposta é que sou um perfeccionista que teve dificuldades em manter-se concentrado nas prioridades certas, por isso dediquei-me a transformar essa fraqueza numa força, organizando-me rigorosamente, e é assim que o faço agora e o farei por si.

Finalmente, vai ter sucesso! Já mostrou que tem o que é preciso, fazendo a auto-análise que o levou a escrever este post. Você tem o desejo, tem a capacidade, só precisa de acrescentar o foco e a organização. O problema está a tornar-se claro para si e você tem a capacidade de o resolver. Anseio pelo vosso sucesso futuro e espero que ponham actualizações para que todos possamos partilhar com ele.

Desejo-vos felicidades,

Randy

Edição: Nunca se esqueça que Steve Jobs foi despedido da Apple e as lições que lhe ensinou fizeram dele um CEO muito melhor da segunda vez. Edison foi despedido da Western Union, e falhou mil vezes antes de aperfeiçoar a sua lâmpada. Walt Disney foi despedido pela KC Star por não ser “suficientemente criativo”, por isso iniciou o seu próprio negócio e foi à falência. Ainda é muito jovem, tire as lições que aprendeu e use-as para fazer o seu sucesso.

Ok, então podemos concordar que atingiu “o fundo” do seu caminho de carreira. E depois? Só há uma direcção que podes seguir a partir daí, que é para cima!

Se continuas ou não na tua escolha de carreira actual depende inteiramente do facto de a ENCONTRAR.

Se NÃO gostaste: Recomendo-te que não continues este caminho de carreira. Deve aceitar um pequeno emprego noutro lugar (mesmo que seja um emprego de homens) para angariar fundos para prosseguir algo que lhe interesse mais.

Se realmente gostou do seu trabalho: Está no “fundo do poço”, certo? Então acerte o reset! Comece de novo pelo “fundo”, e desta vez faça-o correctamente. Comece a candidatar-se a empregos de software como programador de nível Jr. (ou mesmo como estagiário, se for necessário) em qualquer empresa de software. Desta vez, trabalhe muito para reconstruir a sua reputação e currículo, bem como impressionar os seus novos empregadores.

Em qualquer dos casos - recomendo que não mencione sequer os empregos de software anteriores no seu currículo - eles não lhe estão a fazer nenhum favor. Uma redefinição difícil é melhor aqui! E não há vergonha nenhuma em tentar novamente e trabalhar arduamente nisso!

Há aqui uma tonelada de respostas realmente fantásticas, mas eu tenho outras ideias que talvez queira ter em mente quando encontrar/manter o próximo trabalho.

Em primeiro lugar, não desista nunca dos seus sonhos. Investiram muito tempo e dinheiro, presumo, para entrar nesta carreira; desistir neste momento não é a coisa certa a fazer.

A melhor coisa que podem fazer agora é juntar giz a tudo isto para experimentar, e fazer melhor da próxima vez. Uma crença comum entre os criadores inexperientes é que as suas capacidades de programação são superiores às dos seus predecessores. Isto pode ser verdade em alguns casos, mas mesmo que isso fosse verdade, outros programadores mais experientes têm muito orgulho no que criaram e ficam ofendidos quando um novo tipo entra e começa a destruir os seus programas.

No mundo dos negócios, o desenvolvimento de software é levado muito a sério e há consequências reais no lançamento de um mau produto. As empresas dependem da fiabilidade dos seus produtos, e um pequeno defeito pode ocorrer em cascata, causando enormes problemas a jusante. Não se quer ser that* gajo. No mundo financeiro, um pequeno erro pode custar milhões, e até mesmo a falência de uma empresa. Por isso… os empresários são normalmente muito protectores do seu código e não querem ninguém a mexer em algo que não devem tocar.

Tente concentrar-se apenas nas tarefas específicas que tem em mãos e tenha uma compreensão clara das expectativas. Não tente ir além do que se espera de si, pelo menos até que a experiência tenha terminado. Basta aparecer todos os dias a horas, fazer o seu trabalho sem afectar os outros e ter uma boa relação com os seus colegas de trabalho, e não será despedido. Lembre-se, não está apenas a ser contratado pelas suas capacidades de programação, isso só o leva a entrar pela porta. Se quer ser bem sucedido, então também tem de trabalhar nas suas competências transversais. O seu sucesso depende de ter uma boa atitude e de se dar bem com os outros.

Não desista!

Para acrescentar ao que outros sugeriram: Imagine que estava a trabalhar há X anos numa empresa e apareceu um novo empregado e começou a indicar (através de palavras e acções) que o trabalho existente (em que você e os seus colegas de trabalho estavam a trabalhar há anos) era “desleixado”/“sem valor”/“teve de mudar para que o novo empregado se sentisse confortável”, como acha que você (e os seus colegas de trabalho) responderiam quando os gestores lhe pedissem a sua opinião sobre o novo empregado? Não consigo imaginar ninguém a responder com isso: “Sim, eu adoro trabalhar com ele, e ele sabe mesmo o que faz”. Eu imagino que o feedback seja mais: “Arrogante, sabichão, não parece ser capaz de se integrar com a equipa”

Eu sempre me encolhi quando ouço um novo colaborador dizer algo do género: “O seu código/produto/processo existente é uma porcaria/mau/mau/erro. As minhas ideias/métodos são melhores. Eu sei o certo do errado, mas você não sabe. Eu consigo fazê-lo bem, onde você não consegue”. Tenho sempre a sensação de que um novo colaborador não vai conseguir ultrapassar qualquer período experimental (& raramente me enganei).

Há muitas razões para o código ser como é, incluindo trazer consigo trabalho antigo, restrições de tempo, programadores descuidados, adaptar-se às especificações de mudança, trabalhar com sistemas HW/SW/sistemas antigos, etc. O código é, no entanto, o produto desse grupo/empresa e eles terão algum orgulho de propriedade e provavelmente até alguma prova empírica de que ele funciona “suficientemente bom” para lhes render $. Você pode até estar dispensando os esforços de outros membros do grupo (ou mesmo do gerente). Você pode até mesmo ser pontual na sua avaliação, mas isso pode ser totalmente irrelevante. Programar em posições perm também é trabalhar em conjunto como um grupo (e esse grupo inclui o seu gestor).

Se quiser trabalhar como perm em grupos semelhantes, considere o que pode mudar (no núcleo mentalmente) para que os outros membros do grupo dêem ao seu gestor um feedback que confirme a sua decisão de o contratar, e indique que irá melhorar o grupo com menos surpresas desagradáveis evitáveis (tanto para o seu gestor como para a empresa).

Esta é uma resposta ampla com muitas sugestões:

1. Tente diminuir as suas expectativas, deve haver um posto de trabalho adequado para si em TI.
2. Talvez deva questionar o seu acordo quanto às responsabilidades à primeira vez.
3. Comunique sempre que houver problemas de bloqueio. Fale o que pensa enquanto se mantém profissional.

4. Quando não estiver suficientemente motivado, este é geralmente o seu problema, por isso tente solicitar pequenas vagas dispersas ao longo do ano, em vez de aceitar poucas vagas longas (isto pode ajudar ou não).

5. Pode tentar empregos a tempo parcial sabendo que tem poupanças até 6 meses, depois pode ser alargado a mais! mantendo o espírito competitivo, e um currículo actualizado.

6. Mudar de funções, em grandes empresas é por vezes mais fácil, se fosse possível para si, isto poderia ser muito motivador.

7. Não conheço o seu passado e perfil, mas há missões nas TI que envolvem menos técnicas como promover produtos de TI, organizar sessões de sensibilização sobre novas tecnologias para outras faculdades, escrever documentação, limpar código antigo (para programadores), estabelecer novas provas de conceitos, ideias de projectos, participar em desafios e tentar estar no topo para o nome do seu grupo . … etc etc, ver que há muitas coisas que um desenvolvedor, por exemplo, pode fazer em TI.

Esta é uma lista de mais opções de liberdade que eu posso imaginar por agora.

1. Você percebeu que o código era mau.
2. Agiste sobre ele tentando melhorar o código.
3. Os gestores não apreciaram isto.

Bem, em alguns lugares a sua verdadeira ajuda não será apreciada e eles só querem que você resolva problemas inventados só para alimentar o seu sentido de realização. Esta pode ser uma destas situações - não tenho a certeza. Se for esse o caso, então não há muito que se possa fazer. Percebe-se que se trata de uma patranha e escolhe-se tentar fazer o melhor que se pode que possa beneficiar a empresa.

Eu diria para continuar. Até encontrar um lugar onde isso seja apreciado. Esses lugares existem.

Parece ter uma tendência para não seguir a direcção, e/ou ficar atolado em pormenores que não interessam, de modo a fazer o que prefere fazer. Isso resulta em falta de trabalho de equipa e má gestão de tempo.

Eu costumava ter um colega de trabalho que era contratado para uma posição que ele não queria. Eu podia dizer no processo de entrevista que ele tinha uma aversão a certas tecnologias legadas e plataformas padrão nas quais ele estaria trabalhando. Ele abrigou fortes preconceitos. Até o seu currículo indicava que ele saltava de um lugar para outro. A administração não me deu ouvidos. Nós contratámo-lo na mesma.

Ele não só não queria fazer as tarefas que lhe tinham sido atribuídas e para as quais não estava disposto a aprender, como tentava encontrar outras tecnologias e bases de código para substituir o que tínhamos, ou mesmo, por vezes, tentava assumir as tarefas de outras pessoas.

Ele queria “arranjar” o código de todos os outros e dizer-nos como é que ele “devia” ser feito. Ele queria perder o tempo de todos com revisões de código em projectos já em produção, para nos mostrar uma codificação adequada e uma sintaxe limpa (ou a falta dela). Ele era demasiado perfeccionista e perdeu o seu tempo como resultado.

Talvez estas características não se apliquem a si. Talvez simplesmente não goste de fazer aquilo com que foi incumbido e precise de uma mudança. Mas se se conseguir identificar com estes pontos, não vai durar muito tempo em lado nenhum.

Ironicamente, o meu antigo colega de trabalho conseguiu de facto um trabalho melhor como resultado da experiência a trabalhar na tecnologia/plataforma que detestava. Por isso, por vezes temos de nos forçar a fazer o trabalho que não nos apetece fazer.

Algumas empresas têm taxas de rotação muito elevadas, com mais de metade das pessoas a mudar todos os anos. Quando algumas empresas tentam trabalhar no problema, compreender as razões, mudar algo do seu próprio lado, outras podem disparar imediatamente depois de detectarem sinais mesmo fracos de algo que têm uma política a não tolerar.

Infelizmente, estas empresas de “elevado rendimento” também são as que mais contratam, mesmo que não estejam a crescer - para manter a dimensão da equipa. O anúncio de emprego nunca deixa os quadros de mensagens em portais de emprego populares. Se não observar para onde vai, há hipóteses razoáveis de os atingir repetidamente, mesmo que não sejam a maioria.

Tente encontrar a empresa que é notável mas não tão activa com o recrutamento permanente. Compreenda os motivos para ser despedido (mesmo que pareçam bastante fracos). Evite comportamentos semelhantes que possam desencadear reacções pré-programadas logo que sejam reconhecidos.