Tornando-se um “desenvolvedor de manutenção” [duplicado]

35

Então, eu tenho me irritado com a atual posição em que estou, e adoraria receber informações de outros desenvolvedores sobre isso.

Estou no meu atual emprego há cerca de 11 meses. Quando comecei, estava trabalhando em todos os novos recursos. Eu basicamente trabalhei em um projeto web totalmente novo para os primeiros 5-6 meses em que estive aqui. Depois disso, fui transferido para um papel mais orientado a serviços (o que ainda era ótimo, todas as coisas novas para mim), e eu estava nessa função há cerca de 5 a 6 meses. É aqui que entra o problema.

Basicamente, um par de dias atrás eu me tornei o cara de suporte / manutenção. Agora, nós temos uma equipe de suporte de TI, então eu não estou falando desse tipo de suporte, eu estou falando mais de um cara de suporte de segundo nível (quando os caras na superfície não conseguem realmente chegar à raiz do problema) , juntamente com o trabalho em problemas de manutenção que permanecem no backlog por um tempo. Para mim, um desenvolvedor com cerca de 3 anos de experiência, isso é meio desanimador.

Com o tipo de local de trabalho, eu não ficaria surpreso se esses problemas de suporte ocupassem a maior parte dos meus dias e eu mal conseguisse trabalhar em problemas de manutenção. Além disso, a maioria desses problemas de suporte nem está relacionada ao código, eles estão mais ou menos apenas conhecendo a arquitetura do sistema, trabalhando para garantir que os serviços estejam sendo executados / iniciados adequadamente, manipulando / corrigindo dados inválidos, etc. desenvolvedor, então essa parte é uma droga. Além disso, mesmo quando eu tenho tempo para trabalhar com manutenção, estas são basicamente apenas correções de bugs / melhorando o código ruim, então isso é uma droga também, mas pelo menos está relacionado à codificação.

Estou errado por ficar com raiva aqui? Eu não quero realmente reclamar sobre isso, mas para ser honesta, eu não falei sobre isso ou nada, eu meio que apenas enviei um e-mail me avisando que eu sou o cara para esse tipo de coisa e foi isso. Toda a equipe demorou alguns minutos para me dar a conversa "que chupa", porque eles sabem como é chato apoiar o tipo de trabalho que fazemos, então eu sei que não sou o único cara que sabe que não é essa grande oportunidade.

Eu só estou meio em cima do muro sobre como seguir em frente. Obviamente, vou continuar trabalhando por enquanto, não adianta causar má impressão em ninguém, mas gostaria de saber como vocês abordariam essa situação, ou como você acha que eu deveria estar me sentindo em relação a isso / como vocês se sentiriam.

    
por yannis 09.10.2011 / 21:10
fonte

7 respostas

43

Você pode ver isso como um tempo no limbo; ou você pode transformá-lo em uma oportunidade de crescer.

A idéia principal de ser um desenvolvedor de manutenção é se livrar de um trabalho . Cada vez que você tem que consertar alguma coisa; reserve um tempo para entender o problema bem o suficiente para que sua solução (que pode acontecer algumas semanas depois de apagar o fogo) signifique que você (nem qualquer outra alma viva) terá que resolver o problema novamente.

Já que é um sistema legado que você está apoiando, normalmente você pode conseguir algumas soluções que não seriam "ok" para produtos mainline; você pode usar cron para reiniciar periodicamente os serviços com bugs; Você pode codificar uma lógica excepcional para clientes específicos, pois o número de clientes que usam esse produto não aumentará.

Outra parte é extrair conhecimento útil do sistema; Você provavelmente não quer fazer isso, não é muito divertido; mas documentando o que o sistema de trabalho faz (mesmo que isso seja errado), você pode facilitar a tarefa de manter essa parte do pedido uma ordem de magnitude (dez minutos para ler dois parágrafos que explicam um módulo, em vez de três dias) lendo o código do módulo). Melhor ainda, essa mesma documentação pode ser usada para implementar a funcionalidade no produto mainline, assim você pode parar de suportar o sistema legado (pelo menos esse recurso).

Se você é o "vá para o cara" para um projeto, mesmo que seja uma manutenção legada, você provavelmente (ou pelo menos, deveria) tem uma latitude considerável para abordar os problemas do seu próprio jeito. Isso pode significar reescrever seções em sua linguagem ou plataforma favorita, sugerindo soluções alternativas em vez de soluções ou apenas respondendo a problemas com "não consertar, usar produtos suportados".

Edit: Você pode estar interpretando mal a intenção do seu chefe; A manutenção requer um conjunto diferente de habilidades de outras partes do ciclo de desenvolvimento; Ele pode estar colocando você em um emprego porque ele acha que, dentre todas as pessoas que ele tem disponível, você é o melhor para essa função; não porque ele acha que você não é hábil o suficiente para outra coisa.

A manutenção requer um foco no código leitura , mais do que qualquer outra função que você possa ter. Se você é bom em ler, você será bom em manutenção. Existem muitos desenvolvedores, mesmo aqueles com muitos anos de experiência, que simplesmente não têm o knack para ler o código de outras pessoas (ou pior, o próprio), mesmo que sejam brilhantes em outras coisas. .

Quando você se coloca fora do trabalho de manutenção, você não está convencido de que você seria bom o suficiente para fazer algo mais importante, você está literalmente tirando o trabalho de manutenção dos vivos. Quando você para de fazer esse trabalho, é porque não há mais nada a fazer. Todos os problemas foram resolvidos porque foram migrados para fora do aplicativo legado, porque as tarefas manuais agora são automatizadas ou você convenceu o cliente de que ele não quer ou precisa dele e nunca o fará. Se o seu chefe interpretar isso como "ele é bom nisso, melhor mantê-lo aqui", sem fazer nada, então ele é um tolo.

    
por 09.10.2011 / 21:26
fonte
16

Sendo um desenvolvedor de manutenção! = sendo deixado no banco. O trabalho de desenvolvimento de manutenção pode ser um dos trabalhos mais frustrantes, dolorosos e irritantes do mundo, pois você corrige os problemas estranhos que o desenvolvedor original perdeu.

Também pode ser um dos trabalhos mais gratificantes, tanto pessoais quanto profissionais, e educativos que você pode fazer. Se você puder remover um bug que existe no sistema por 6 meses ou mais e causar uma queda direta em 10% da base de clientes que seus chefes irão adorar, 10% da base de clientes também o amarão. Melhorando o software de forma incremental e consertando bugs que demoram uma semana para rastrear efetivamente, você estará aumentando o seu conhecimento não apenas desse sistema, mas de quais bugs você pode ver sob condições específicas, e então você leva isso em consideração e se torna um melhor desenvolvedor.

Eu amo criar sistemas de novo, mas a maioria dos truques na minha mala de programação veio de fazer o trabalho de manutenção e vir a calhar mais vezes do que eu gostaria de pensar.

    
por 10.10.2011 / 11:21
fonte
8

Não bata nele. Eu fiz muito tempo como programador de manutenção. Se o produto é interessante e os outros desenvolvedores bons, você pode aprender alguma coisa. E, se forem ruins, você aprenderá o que torna o código inatingível e poderá usar essa experiência ao escrever seu próprio código. E depois de um tempo, você será o cara para quem eles precisam saber algo sobre o código, porque você saberá tudo, não apenas o pequeno silo de alguém.

Depois de aprender o código, você saberá quais partes precisam de refatoração e podem propor projetos para fazer isso, o que, é claro, você estará perfeitamente preparado para liderar.

    
por 09.10.2011 / 22:44
fonte
5
Vale a pena notar que o papel do engenheiro de manutenção não é um, em uma organização inteligente, dado a alguém porque não é bom o suficiente para outra coisa ... é dado a eles porque eles são bons o suficiente para lidar com o particular. Função. Manter os sistemas existentes em funcionamento é um papel extremamente importante e, dependendo da empresa, muitos milhões de dólares podem se equilibrar na ponta do (s) engenheiro (s) fazendo bem o seu trabalho.

Dito isto, enquanto a maioria dos gerentes entenderá intuitivamente que o papel precisa de um indivíduo capacitado para lidar com isso, a maioria não reconhece as conquistas dos ditos programadores, e pode ser difícil obter reconhecimento pelo seu trabalho. É muito fácil ser colocado no papel porque você é habilidoso, e eles são esquecidos, pois aumentos e promoções são entregues mais tarde ... porque o sinal de que você está fazendo um ótimo trabalho em seu papel é que ninguém percebe que você está fazendo um ótimo trabalho em seu papel.

É possível lutar pelo reconhecimento que você acha que merece por cumprir o papel, mas não tenho certeza se vale a pena o grande esforço envolvido. Em vez disso, recomendo discutir com seu gerente o conceito de (como outros já mencionaram) rotacionar o papel através dos vários desenvolvedores disponíveis para ele. Se possível, tenha pelo menos uma pessoa no papel a tempo inteiro e uma pessoa a tempo parcial. O cronômetro de peça pode aprender sobre os sistemas e o que está envolvido em mantê-los a partir do cronômetro completo. Quando é hora de girar, o temporizador de parte pode assumir o controle como um temporizador completo, e uma nova pessoa entra como temporizador de parte (e aprende com o timer agora cheio).

Se isso faz você se sentir melhor, as pessoas em Ops estão na mesma posição ... o sinal de uma grande pessoa da Ops é que ninguém percebe como eles fazem o seu trabalho. Só que, para uma pessoa de operações, eles não podem realmente girar porque é seu papel principal. Sou um grande fã de sempre elogiar as pessoas da Ops com quem trabalho, publicamente e oralmente, porque o dev é um dos poucos grupos que conseguem ver o quanto melhor fazem a vida de todos os outros.

Essa tangente de lado ... se você girar a posição de manutenção, da próxima vez que você entrar no papel, certifique-se de dar às pessoas antes de suas costeletas, se você ver que elas fizeram coisas que tornam sua vida mais fácil agora que você está de volta ao papel ... faça isso publicamente e vocalmente.

    
por 15.10.2011 / 06:33
fonte
3

A abordagem construtiva recomendada pelos outros comentadores é muito boa. Como Token apontou, você tem muita liberdade nesse tipo de posição, desde que os problemas sejam resolvidos e você não quebre nada.

Se você achar que pode automatizar soluções comuns, ou evitá-las, você pode comprar muito tempo livre - e se as expectativas dos chefes das demandas de seu tempo continuarem desinformadas - para fazer outros tipos de trabalho que você goste mais ou que você acha que seria mais produtivo para a empresa. Meu primeiro trabalho de "programação" acabou sendo um trabalho de entrada de dados, mas logo descobri que muito da entrada de dados era passível de script e, mais tarde, que poderia ser gerada. Liberei cerca de 7/8 do meu tempo e usei-o para reescrever o sistema de entrada de dados do zero, incluindo nele todos os scripts e geradores e UIs mais eficientes. Era um trabalho do governo sem saída de qualquer maneira, mas a experiência acabou por ser inestimável.

    
por 09.10.2011 / 23:21
fonte
1

Converse com seu gerente sobre a rotação de desenvolvedores para a posição (digamos, em um ciclo mensal ou algo assim). Se todo mundo sabe que é uma droga, todo mundo vai entender porque o trabalho está sendo distribuído por toda a equipe. Talvez, ao conversar com seu gerente, você descubra que esse já é o caso, e você acabou de fazer uma reviravolta.

    
por 10.10.2011 / 12:10
fonte
0

Você precisa perguntar por que você foi colocado em um papel que todo mundo acha que é uma merda. Se o seu gerente tiver meio cérebro, ele saberá que ninguém gosta e se ele acha que existem aqueles que o fazem, ele poderia pelo menos perguntar. Descubra quanto tempo esta situação vai durar e se há oportunidades para voltar a um novo desenvolvimento. Você nunca sabe, você pode entrar no escritório no dia seguinte e receber um novo projeto. Coisas estranhas aconteceram.

    
por 10.10.2011 / 02:36
fonte