O trabalho de manutenção dedicado dificulta a carreira de um programador? [fechadas]

A maior parte do meu trabalho nos últimos três anos tem sido em grande parte a manutenção de sistemas legados que precisavam de reparos ou de uma reforma ocasional antes de serem vendidos novamente.

Entendo o papel crítico que os programadores de manutenção dedicados desempenham em empresas com um grande número de projetos e desenvolvedores limitados à mão.

Mas, ao julgar meu progresso atual na carreira e olhar para meus colegas; empreiteiros e desenvolvedores corporativos; Sinto como se estivesse ficando para trás desde que ganhei uma grande amplitude em termos das áreas em que toquei, mas não em profundidade. Comecei a abordar isso iniciando um blog, trabalhando em meus próprios pequenos projetos git-hub e reagendando minha vida para ter tempo para fazer codificação pessoal após o trabalho regularmente.

Sinto que, se eu fosse entrevistar outras empresas para escapar do trabalho de manutenção, teria de me apresentar como sendo bastante iniciante em nível de habilidade, pois não teria a profundidade do nível de conhecimento exigido de uma pessoa com três anos de experiência focada em um determinado caminho no desenvolvimento de recursos faria. Portanto, metade da minha experiência atual de trabalho não vale nada a longo prazo.

Mas isso me leva às minhas principais perguntas, desculpas se isso parecer muito centrado no meu dilema pessoal:

As funções dedicadas de programação de manutenção acabam prejudicando o início de uma carreira? Outros programadores estão certos em evitar papéis como esses? Fazer essa linha de trabalho o impede de realizar tarefas semelhantes, a menos que você esteja preparado para começar de novo como júnior?

As funções dedicadas de programação de manutenção acabam prejudicando o início de uma carreira? Outros programadores estão certos em evitar papéis como esses? Fazer essa linha de trabalho o impede de realizar tarefas semelhantes, a menos que você esteja preparado para começar de novo como júnior?

Primeiro, você deve saber que é considerado júnior por um bom tempo. Você pode receber promoções arbitrárias porque é bom e esta é a única maneira de oferecer um aumento de salário decente, mas você ainda será considerado um júnior ao seguir para o seu próximo emprego.

Segundo, se estou contratando alguém com 2 a 4 anos de experiência, realmente não me importo se o trabalho deles foi apenas de manutenção. Se você passou 10 anos em manutenção e eu estou contratando um projeto greenfields, posso ter perguntas, mas, nos primeiros anos, sinceramente espero.

Por outro lado, se eu estiver contratando alguém que NUNCA trabalhou em manutenção, ficarei mais desconfiado. Tive muitos candidatos a empregos que passaram os primeiros quatro anos pulando de um emprego "bom" para outro e cada um não aprendeu nada sobre o que contribui para o código sustentável. E, não se engane, se estou contratando um projeto greenfields com o qual pretendo continuar, não me importo se você deseja manter o código, mas sim que você saiba como deixá-lo em manutenção para futuros desenvolvedores.

Esses outros programadores que você menciona, que evitam trabalhos como esses, geralmente os evitam porque são menos divertidos, não porque isso dificulta sua carreira.

Finalmente, você deve saber que uma porcentagem muito grande (eu acho que em cerca de 80%) dos trabalhos de desenvolvimento de software são mais de 50% de manutenção.

Então, para esclarecer tudo isso e responder à sua pergunta: Não, acho que não vai atrapalhar sua carreira. A menos que você fique lá por muito tempo. A regra geral é "quando você começar a sentir que está recebendo o mesmo ano de experiência todos os anos, é hora de partir". Se você sente, a cada ano, que é um desenvolvedor melhor do que no ano passado, está bem (e isso vale para mim, 20 anos na minha carreira, tanto quanto você).

Em qualquer trabalho, a experiência que você obtém é específica para o que está fazendo, o que limita seu leque de possibilidades ao se candidatar a outros trabalhos com base nessa experiência. Não é específico para manutenção. Eu acho que outras perguntas são mais relevantes do que saber se algo é manutenção ou desenvolvimento de novo software:

• Quão difundidas são as tecnologias específicas com as quais você está trabalhando? Se você mantiver algo obsoleto e raramente usado em outros lugares, isso limitaria suas futuras oportunidades de carreira (mas o desenvolvimento de novos softwares para um sistema / plataforma / tecnologia que não é amplamente utilizado).
• Como o seu trabalho atual o equipa para o trabalho que deseja fazer no futuro? O trabalho de manutenção, como você apontou, é importante e sempre estará por perto. Não há nada errado em ter uma carreira focada nesse tipo de programação; sempre haverá muitas possibilidades para os mantenedores do sistema. Mas talvez não seja o que você quer fazer. É preocupante se o seu trabalho atual não o estiver preparando para o que lhe interessa.

No entanto, eu não ficaria muito preocupado. Uma coisa que você diz é:

Ganhei uma grande amplitude em termos das áreas em que toquei, mas sem muita profundidade.

Não pense nisso como um problema, porque pode ser usado para sua vantagem. Ter uma vasta experiência significa que há uma grande variedade de coisas para as quais você pode dizer "sim, eu fiz isso". Muitos empregos exigem experiência em várias tecnologias e tarefas diferentes. Você provavelmente teria uma vantagem sobre um desenvolvedor que possui uma experiência muito profunda em uma tecnologia.

Além disso, muitos trabalhos envolvem uma mistura de manutenção e desenvolvimento. Se você quiser fazer mais novos desenvolvimentos, poderá usar sua experiência de manutenção existente para fazer a transição para uma função mista que fornecerá mais experiência em desenvolvimento.

Em conclusão, seu currículo provavelmente é melhor do que você pensa. Muito disso se resume a quão bem você analisa os pontos fortes de sua experiência e depois os comunica no processo de inscrição e entrevista.

As funções dedicadas de programação de manutenção acabam prejudicando o início de uma carreira?

Mais frequentemente do que não - SIM, assumindo:

• essa carreira aqui significa experiência em muitas habilidades técnicas diferentes.
• que você passa mais de X anos lá, onde X é suficiente para "definir" suas formas de pensar.
• que você não faz nada de lado.
• que "mantenedor dedicado" (ver EDIT, abaixo) significa que não codificam para manter , bem como código de coisas novas, mas que quase sempre o código para manter ou mesmo trabalhar em um projeto no modo de manutenção - sem novos recursos, necessários menos alterações no código para corrigir o erro.

Isso não significa que é sempre o caso.

As pessoas que mantêm software raramente são incentivadas (veja EDIT, abaixo) a fazer pesquisas, raramente podem conectar uma nova biblioteca ou banco de dados e passar alguns dias descobrindo como ele funciona. É (geralmente) um trabalho constante que requer alterações mínimas na base de código existente e, portanto, "molda" a maneira como você aborda os problemas posteriormente. Posso citar algumas empresas que têm uma política para manter software que declara explicitamente "menos alterações no código = melhor", apesar das coisas ruins que isso pode trazer.

Outros programadores estão certos em evitar papéis como esses?

Conheço mantenedores muito bons que gostam de seus empregos e não gostariam de se candidatar a outra coisa precisamente porque é confortável onde eles estão. Nem todo mundo gosta de aprender coisas novas de vez em quando. Portanto - evite ou procure, dependendo de suas preferências.

Fazer essa linha de trabalho o impede de realizar tarefas semelhantes, a menos que você esteja preparado para começar de novo como júnior?

Mais frequentemente do que não - SIM. Porque você já tem experiência em fazer isso, porque você já "conhece as cordas", etc. Mas a mudança é definitivamente possível e pode acontecer sem se candidatar a uma posição júnior. Você já começou a fazer as coisas de lado, continue! Isso realmente vale a pena e pode reduzir a 'lacuna de habilidades' que você notou.

EDIT: Dan indicou (com razão) que as tarefas de manutenção geralmente podem ser realizadas com a pesquisa. Isso é verdade. Alterei a resposta acima em dois lugares para melhor resolver isso.

Tais tarefas certamente poderiam ser feitas dessa maneira e se forem - ótimas! No entanto, a maioria dos mantenedores DEDICADOS do AFAIK dos sistemas LEGACY tem políticas ou expectativas e prazos de gerenciamento que - novamente, mais frequentemente do que não - os obrigam a resolver o problema com o mínimo de alterações possível. Freqüentemente, a pressão é alta o suficiente para que, mesmo que você possa fazer dessa maneira, não queira. Especialmente se não for o SEU código: sem a teoria (conforme Ryle e Naur) por trás disso, você corre o risco de danificar mais do que conserta.

No entanto, deve-se notar: não tenho dados globais rígidos, falo por experiência própria - trabalhei em uma situação de OP, recrutei pessoas com 4-10 anos de experiência como mantenedores, conversei com muitos mantenedores e eu conhecer pessoas que trabalham como mantenedores dedicados . Não apenas pessoas que codificam coisas novas, mas também codificam para manter um projeto - mantenedores dedicados, cuja única tarefa é fazer bugs e patches e nem mesmo um novo recurso, porque é um projeto antigo e agora está apenas no "modo de manutenção".

Eu teria que me representar como sendo bastante júnior no nível de habilidade, já que não teria a profundidade do nível de conhecimento exigido de uma pessoa com três anos de experiência focada em um caminho específico no desenvolvimento de recursos.

Corrigir. Você não seria capaz de dizer "3 anos de experiência na criação de sistemas do zero usando X, Y e Z", seria necessário dizer "3 anos de experiência na MANUTENÇÃO de sistemas do zero usando X, Y e Z", a menos que queira mentira certa em seu currículo.

Sinto que, se eu fosse entrevistar outras empresas para escapar do trabalho de manutenção, teria de me apresentar como sendo bastante iniciante em nível de habilidade, pois não teria a profundidade do nível de conhecimento exigido de uma pessoa com três anos de experiência focada em um determinado caminho no desenvolvimento de recursos seria

Se você quiser dizer "Eu projeto e construo sistemas do zero", então sim, você teria que se classificar como júnior.

O que é bastante comum em TI (e não estou dizendo que é isso que você está fazendo) é que as pessoas pensem que, por estarem trabalhando há X anos, têm X anos de experiência e depois de {número indeterminado de anos} deve ser considerado um desenvolvedor sênior do {Widget}.

Agora, não me entenda mal, não há nada errado com o trabalho de manutenção, todo mundo precisa fazer isso em algum momento ou outro, mas o que você percebeu é que ficar preso por muito tempo provavelmente dificultará a execução. afaste-se desse papel no futuro. Isso geralmente anda de mãos dadas com o fato de "ficar preso" sem aprender novas tecnologias / ferramentas / métodos.

Idealmente, você deseja uma mistura de "novo" trabalho do sistema e trabalho legado.

Em uma nota positiva, você presumivelmente viu muitas arquiteturas diferentes (boas e ruins), abordagens diferentes, como decisões ruins podem fazer com que os programadores legados trabalhem muito mais tarde. Estes são todos positivos que podem ser acentuados.

Boa sorte!

Vendo isso de outro ângulo, acho que vender a si mesmo como especialista em manutenção é uma oportunidade comercializável.

Como proprietário de uma empresa de software que possui vários projetos em movimento, um dos maiores riscos que tenho que minimizar são os desenvolvedores que abandonam o mercado e a manutenção subsequente de seu código.

Então, supondo que você seja capaz de se apaixonar pelo trabalho de manutenção (o que eu acho que seria o caso, já que você está preparado para publicar um blog sobre sua experiência), se você vier a mim oferecendo seus serviços como um guru da manutenção - garantindo a polidez de todos dos vários projetos de meus desenvolvedores refatorando, otimizando e documentando seu código para manutenção a longo prazo - e você tinha um histórico de backup de sua garantia, eu o contrataria rapidamente.

Meu conselho seria fazer uma tentativa adequada. Posicione-se como um especialista em manutenção e cultive seu blog. Você pode estar envolvido.