Recentemente, comecei minha carreira como desenvolvedor web para uma empresa de médio porte. Assim que comecei, tive a tarefa de expandir um aplicativo existente (mal codificado, desenvolvido por vários programadores ao longo dos anos, lida com as mesmas tarefas de maneiras diferentes, estrutura zero).

Então, depois que eu estendi com sucesso esse aplicativo com a funcionalidade solicitada, eles me deram a tarefa de manter completamente o aplicativo. Claro que isso não era um problema, ou assim eu pensei. Mas então soube que não tinha permissão para melhorar o código existente e me concentrar apenas nas correções de erros quando um bug é relatado.

Desde então, tive mais três projetos, como o acima, que agora também tenho que manter. E eu tenho quatro projetos nos quais me foi permitido criar o aplicativo a partir do zero e preciso mantê-los também.

Neste momento, estou começando a ficar louco com os e-mails diários dos usuários (gerenciadores de leitura) para cada aplicativo que tenho que manter. Eles esperam que eu lide com esses e-mails diretamente enquanto também trabalho em outros dois novos projetos (e já existem mais cinco projetos alinhados depois deles). O triste é que ainda não recebi um relatório de erro sobre qualquer coisa que eu mesmo tenha codificado. Por isso, recebi apenas solicitações de mudança ocasionais, vamos fazer coisas-180 graus diferentes.

Enfim, isso é normal? Na minha opinião, estou fazendo o trabalho equivalente a toda uma equipe de desenvolvedores.

Eu era um idiota quando inicialmente esperava que as coisas fossem diferentes?

Eu acho que este post se transformou em um grande discurso retórico, mas por favor, diga-me que isso não é o mesmo para todos os desenvolvedores.

PS Meu salário é quase igual, se não inferior ao de um caixa de um supermercado.

Durante um dos meus estágios , descobri que passava muito tempo corrigindo bugs. Você precisa perceber que, como funcionário de nível básico, não terá o trabalho mais sexy, terá o trabalho duro que ninguém mais quer. É lamentável, mas é como é em todos os trabalhos.

Além disso, você deve perceber que, para uma empresa, ter um código que funcione é mais importante do que ter um código limpo. Do ponto de vista da sua empresa, você altera a estrutura existente para desperdiçar dinheiro em refazer algo que já está feito e potencialmente introduzir ainda mais erros. Normalmente, esses tipos de empresas não são empresas de computadores / software; portanto, nenhum gerente suficientemente alto possui a formação técnica para saber que, às vezes, é necessário realizar essas grandes revisões. Dito isto, se sua empresa é administrada por pessoas tecnicamente competentes e elas entendem o valor de um bom código, você pode ter mais liberdade, embora às vezes precise escolher suas batalhas (o principal objetivo de uma empresa ainda é ganhar dinheiro, afinal de contas) )

Dito isto, você não é irracional em querer deixar sua marca no software e em querer um trabalho mais significativo. Também é lamentável que você tenha que lidar com tantos projetos de uma só vez enquanto atende a pedidos de tantos gerentes diferentes.

Como programador, é um fato da vida que você passará mais tempo mantendo e modificando o código de outras pessoas do que escrevendo o seu próprio a partir do zero. Se isso é um problema para você, talvez você deva se dedicar ao desenvolvimento como hobby e seguir uma carreira diferente. Se você concorda com a manutenção do código, mas sente que não está sendo usado com eficiência ou está sobrecarregado, é um assunto que precisa ser discutido com seu gerente. Se seus problemas forem mais graves do que isso ou se você sentir que seus gerentes não sabem como gerenciar efetivamente seu conjunto de habilidades, seria uma boa idéia considerar encontrar uma posição em uma empresa diferente. Dado o seu baixo salário, este é provavelmente o seu melhor curso de ação.

Parece que o gerenciamento tem um problema ao gerenciar sua carga de trabalho e priorizar tarefas. Você deve conversar com seu gerente e fazê-lo entender que você está sobrecarregado e não poderá realizar um trabalho eficaz se todos continuarem bombardeando você com solicitações que desejam que sejam atendidas imediatamente.

Isso faz com que você pule de uma tarefa e projete para outra, perdendo muito tempo trocando de marcha em sua mente. Para um trabalho eficaz de desenvolvimento de software, deve-se ser capaz de mergulhar em uma tarefa e se concentrar totalmente nela. Quanto mais interrupções ocorrer, mais tempo será desperdiçado pela alternância de contexto. Pesquisas mostram que leva cerca de 15 minutos para mergulhar e chegar ao estado de fluxo em que nossa mente trabalha com mais eficiência. Se você recebe interrupções a cada 15 minutos, nunca flui, o que é um tremendo desperdício para você e a empresa.

Portanto, você deve tentar negociar um modo de trabalho mais sensato com seu gerente . Isso deve incluir a priorização das solicitações recebidas e o planejamento antecipado até certo ponto . Todas as solicitações de usuários devem ser mantidas em uma lista, ordenada por prioridades. E as prioridades não devem ser decididas pelo solicitante (como todos pensam que sua solicitação é a mais importante do mundo), nem por você, mas por alguém com conhecimento comercial suficiente e visão geral de toda a gama de produtos que você está mantendo ( o proprietário do produto ).

Idealmente, todas as solicitações recebidas devem ser inseridas em um rastreador de problemas como o JIRA ou o Mantis . Ou pelo menos enviado para o proprietário do produto, não para você. E ele / ela deve lidar com todas as reclamações dos usuários sobre "por que minha solicitação ainda não está pronta ?!", permitindo que você se concentre no trabalho de desenvolvimento. Se isso for inatingível, você deve pelo menos negociar algumas janelas de tempo ao examinar as solicitações recebidas e lidar com elas, reservando uma parte ininterrupta do seu tempo exclusivamente para desenvolvimento.

Se isso for possível, o próximo passo pode ser planejar em certa medida. Ou seja, estime o tempo necessário para implementar as solicitações de prioridade mais alta e programe seu tempo em sprints , que podem levar uma ou mais semanas cada, e aloque tarefas suficientes para o próximo sprint para cobrir seu tempo.

Você provavelmente deseja manter uma parte do seu tempo para receber solicitações de emergência, mas o restante pode ser planejado com antecedência. E você também pode preferir organizar o trabalho em projetos diferentes em "faixas" separadas, ou seja, trabalhar no projeto A na segunda-feira, projeto B na terça-feira-quarta-feira, projeto C na quinta-feira pela manhã e D na tarde etc. reduzir a alternância de contexto.

Dessa forma, você tem uma idéia aproximada do que deve fazer nas próximas uma ou poucas semanas. Além disso, isso também fornece um roteiro para seus clientes: eles podem ver quando recebem qual solicitação implementada. Você pode ou não querer mencionar a palavra "ágil" para seu gerente aqui - isso é basicamente desenvolvimento ágil , mas algumas pessoas se opõem ao ágil sem realmente saber o que é :-)

Observe que, mesmo que sua posição atual pareça pouco valorizada por sua empresa, quanto mais projetos você estiver mantendo, maior poder de negociação terá .

Encontrar e treinar um novo contratado para manter todos esses projetos leva um tempo considerável (= dinheiro) para a empresa. E você pode apontar, com razão, que seu código é muito melhor do que as partes herdadas desses aplicativos; portanto, não é possível que eles possam encontrar facilmente um candidato de recursos semelhantes pela mesma quantia de dinheiro. Sem mencionar que, se eles não melhorarem as condições de trabalho, farão com que o próximo cara fique cansado e pare tão rápido quanto você ... Tente fazê-los entender que é do interesse deles mantê-lo, e para mantê-lo feliz onde está :-) Isso pode lhe dar algum poder para negociar as condições acima e / ou solicitar um aumento salarial.

Quanto poder de negociação você tem - essa é uma grande questão. Sua gerência pode ou não estar aberta a essas idéias e pode ou não respeitá-lo o suficiente para levar seus pedidos a sério. Mas se você jogar bem suas cartas, terá uma chance. E se eles recusarem ... você sempre pode procurar um local de trabalho melhor. Essa situação não é a mesma para todos os iniciantes, embora (infelizmente) suas experiências sejam bastante típicas. Mas realmente existem melhores locais de trabalho por aí . A qualidade do local de trabalho está apenas vagamente correlacionada com a localização geográfica, mas sinto que no norte da Europa você tem chances acima da média. Portanto, se você não conseguir melhorar notavelmente suas condições atuais, comece a procurar imediatamente , antes de ficar completamente cansado e queimado.

É imensamente melhor procurar um emprego enquanto você ainda tem um; portanto, você não precisa aceitar a primeira oferta apenas porque precisa de dinheiro imediatamente. Eventualmente, você encontrará um lugar melhor :-)

PS Meu salário é quase igual, se não inferior, ao de um caixa de um supermercado.

Heh, eu queria escrever algo sobre como negociar até ler isso. Agora tudo o que posso dizer é sair! Supondo que seja metade do que um desenvolvedor com um diploma geralmente ganha. E, supondo que as coisas melhorem e elas ofereçam imediatamente um aumento de 10%, você pode descobrir quanto tempo leva para chegar lá. Também parece que você não aprende nada no trabalho e não parece estar cercado por engenheiros brilhantes, então é uma perda de tempo.

Eu também estava em uma situação semelhante, e posso lhe dizer que, se você permanecer nessa pista, isso nunca acaba. A gerência continuará trabalhando com você, porque ... eles podem.

Existem algumas idéias adicionais que tenho sobre esse tópico.

1. Faça o que você ama. Se você não o ama, prepare-se para tentar encontrar o que você pode amar.

2. Comunicação. Comunique claramente suas incapacidades para atender a expectativas irreais. Em minha experiência semelhante, o arquiteto (que trabalhou mais com a pá) disse: "você precisa gerenciar as expectativas dos outros".

3. Esgotamento. Se você não experimentou o desgaste, não tente o destino. Suga sua vida e alma da sua mente. Apesar de seu esforço, seu objetivo de trabalho se torna cinza, sombrio e sem sentido. Dou esse conselho porque você deve, a todo custo, evitar o desgaste.

4. Treinamento. Aqui está o forro de prata. Seu treinamento e experiência, embora frustrantes e talvez mal pagos, são de fato muito valiosos para sua carreira. Esta é a sua graça salvadora para perceber isso, porque você pode aproveitar o máximo de aprendizado possível e adiar qualquer teto de vidro inevitável.

Concentre-se em quais talentos e habilidades você está desenvolvendo ... Isso o levará pelas próximas oportunidades de sua carreira.

Você está lidando com vários problemas aqui ... Vamos começar com o óbvio ...

Isso é normal?

De jeito nenhum. Mas ... isso é comum? Infelizmente sim.

Em relação à frustração de correção de bugs

Embora isso não desculpe o resto da bagunça com a qual você tenha que lidar e os vários projetos com os quais eles sobrecarregam, eu só quero fazer uma anotação rápida de que a "correção de bug" apenas se aproxima, embora seja frustrante para você como desenvolvedor , pode ser uma abordagem perfeitamente sensata para a empresa e sua administração.

Superfície para mais bugs e custos

Quanto mais código você digitar, maior a probabilidade de introduzir bugs, mesmo que sua intenção seja melhorá-lo. Isso significa tempo de desenvolvimento estendido, tempo de teste e custos. E se passar para um release de serviço com defeito médio a alto, isso é uma grande bagunça para eles.

Ruído / névoa em seus registros

Do ponto de vista do SCM, também faz sentido se você trabalhar diretamente fora da ramificação de um release de serviço, pois deseja ter uma visão clara das alterações relacionadas à correção de bugs. Se houver 15 confirmações com milhares de alterações em torno de uma correção de bug que realmente exigiu talvez uma alteração no código de 1 linha, é um pouco irritante.

Portanto, sendo um novo contratado, é ainda mais sensato pedir que você abstenha-se de refatorar e / ou aprimorar o software, e que, no meu sentido, seja o mais "cirúrgico" possível com suas correções. Apenas mantém as dores de cabeça afastadas.

Você pode fazer algo sobre isso?

Agora, isso NÃO significa que haveria maneiras de alcançar a sanidade do código e a sanidade da mente das pessoas envolvidas. Sendo júnior, eles devem ter alguém para revisar suas alterações, especialmente correções de bugs, e certificar-se de que sejam aprovadas antes de fazer o lançamento do serviço. Isso impediria ou limitaria mudanças radicais e seria mais seguro.

O Projeto Do Inferno

Código de porcaria, rebanho de programadores, duplicação, arquitetura de porcaria

Novamente, o advogado do diabo está aqui, mas apenas mostrando que seu pedido inicial contém alguns bits não-consequenciais.

Meu ponto é este: Eu realmente realmente realmente raramente assumiu uma base de código que não estava neste estado. E, com a pouca chance que eu fiz, eles foram recentemente projetos ou protótipos que foram iniciados por programadores bastante estelares. Mas a maioria surpreendentemente vasta deles parecia uma porcaria, e um número assustador deles era uma porcaria de verdade. Mesmo os iniciados por bons ou ótimos programadores podem acabar sendo péssimos, prazos e outros compromissos ajudando ...

Bem-vindo à engenharia de software industrial da vida real!

E você sabe o que é divertido? Muitas vezes, é muito pior no mundo do desenvolvimento web. Desfrutar! :)

Muitos projetos e solicitações, pouco tempo e mãos

O problema está aqui provavelmente em:

• sua gerência (talvez inconscientemente) abusar de você ,
• seus colegas (talvez inconscientemente) abusando de você ,
• você (talvez sem saber) não está cobrindo sua bunda e travando suas batalhas o suficiente .

Seus gerentes devem estar cientes de que você está trabalhando em muitos projetos para gerenciar. Se não estiverem, verifique se estão o mais rápido possível. Certifique-se também de que eles saibam que não era tudo uma brincadeira no parque e que você se sentiu pressionado e que ele precisa parar.

Tente dar uma olhada e garantir que seus colegas não desviem mais tarefas e projetos para você, diretamente (dizendo realmente "X será capaz de cuidar disso") ou indiretamente ("Não sou a pessoa certa para isso, encontre outra pessoa "-> acaba sendo você).

Anedota pessoal aqui: fiz um estágio há alguns anos e, no meu último dia, quando recebi minha avaliação, meu chefe me disse, apesar de estar muito satisfeito com meu trabalho geral, que um dos gerentes tinha a sensação de que eu estavam descarregando algumas "tarefas não tão divertidas" em outro estagiário quando eles esperavam que eu as pegasse. Eu estava mortificado por tê-los sentidos desapontados, e com a ideia de que eu iria me perder, quando minha intenção era exatamente o oposto: eu estava tentando pegar as tarefas mais difíceis e fazer o outro estagiário mais jovem lidar com menos cabelo questões. Mal sabia eu que, se estivesse na posição dele, ficaria entediado com a falta de desafio e provavelmente me sentiria do jeito que ele se sentia. O ponto é que você precisa se comunicar para garantir que ninguém faça suposições falsas sobre três coisas muito distintas:

• o que você pode fazer ,
• o que você quer fazer ,
• e o que você está disposto a fazer .

Portanto, também é parcialmente sua culpa deixar isso acontecer. Mas é normal, é uma lição que todos precisam aprender. Que detém em duas letras: N - O .

Você costuma empregá-lo como prefixo para uma resposta mais longa, mas não muito mais cobrada: Não, não posso fazer isso. Não, eu não sei como fazer isso. Não, não tenho certeza se sou a pessoa certa para isso. Não, eu nunca fiz isso.

No início, é muito fácil sentir que você pode simplesmente dizer "sim, eu irei (eventualmente) fazê-lo" e empilhar as coisas e fazê-las, talvez colocando algumas horas extras. Está tudo errado. Você precisa entender que seu tempo é, depois de suas habilidades, o seu bem mais valioso, para você e sua empresa. Se for mal utilizado, afeta os projetos, prazos e orçamentos . Tão simples como isso.

Além disso, parece um pouco preocupante que você tenha muitas pessoas para reportar. Não há problema em ter vários clientes com os quais lidar e vários proprietários de projetos ou mesmo principais partes interessadas com as quais você precisa se comunicar. No entanto, em geral, especialmente quando você é um novo contratado, deve se reportar principalmente a apenas alguns gerentes (e provavelmente apenas ao seu gerente direto, e possivelmente a um desenvolvedor líder ou sênior). Como ficou assim? Eu não sei. Pode ser um problema organizacional na sua empresa ou pode ser o resultado de você fazer um favor e depois ser contatado diretamente e não dizer "não". Ou pode ser que seu gerente direto tenha problemas com tarefas de despacho, pelo que sei (estou realmente supondo, mas o padrão é reconhecível e bem conhecido).

Eu recomendo que você faça o seguinte rapidamente: converse pessoalmente com seu gerente direto, explique que outros gerentes podem ser um pouco insistentes ou (provavelmente menos chorosos) que você tem muitas coisas acumulando de muitas pessoas e que você precisa da contribuição dele (e possivelmente também deles) para saber quais priorizar.

Solicitações de alteração de 180 graus

Estes são outro grande problema. Provavelmente, a culpa não é sua, mas você pode tentar ajudá-los a resolvê-lo.

As "solicitações de alteração de 180 graus", como você as chama de maneira bonita e precisa, são um sinal claro de que os requisitos são pouco claros desde o início e que ninguém se esforça o suficiente para tê-los esculpidos e limpos ao longo do tempo.

Geralmente é quando alguém precisa telefonar (ou melhor, ficar de pé) e agarrar as partes interessadas pela mão e dizer claramente: "é onde estamos, é para onde você quer que vamos, você confirma que estamos indo na direção certa? ". Não há problema em não obter respostas claras no início, mas quanto mais o tempo passa, mais claras elas devem se tornar ou esse projeto é um desastre esperando para acontecer.

Normalmente, eu diria que pegue todas as partes interessadas ao seu alcance, coloque-as em uma sala, conduza-as por questões litigiosas e tente gradualmente resolvê-las - e obtenha prioridades enquanto estiver nisso. No entanto, no seu caso, talvez essa já não seja sua decisão. Mas você menciona que eles realmente lhe deram a responsabilidade dos projetos; então, se esse é realmente o caso, assuma a responsabilidade e faça isso. E NÃO coíbe de dizer "NÃO PODEMOS FAZER ISSO " , ou mesmo " NÃO FAZEMOS ISSO" . É realmente importante limitar o escopo de um projeto.

Se não houver escopo, não haverá requisitos bem definidos no final da discussão.

Sobrecarga de email

As pessoas tendem a se comportar de maneira diferente com base no meio de comunicação que usam. Pessoalmente, embora eu seja uma pessoa de fala mansa (e tenho trabalhado principalmente em países estrangeiros, então também não gosto muito de falar ao telefone), eu preferiria em ordem de preferência com base na produtividade:

• conversando com as pessoas cara a cara ,
• conversando com pessoas ao telefone,
• conversando com pessoas via IM,
• conversando com as pessoas por e-mail.

Os e-mails são ótimos para rastrear, obter confirmações e enviar notas.

Para agendar, planejar e discutir pontos problemáticos, eles são quase inúteis. Bata na porta do sujeito até que ele a abra e sente-se com um bloco de notas e uma cópia da sua documentação para esclarecer as coisas. Quando terminar, envie um e-mail e peça confirmação. Se voltar com uma resposta negativa ou uma tentativa ligeiramente escondida de esconder algo mais no envelope, vá fazer o cerco ao escritório do seu interlocutor novamente.

Isso é engenharia de software. Muitas vezes, é mais produtivo quando você não digita em um teclado e pode realmente reduzir a porcaria com a qual você precisa lidar.

Fazendo o trabalho de uma equipe

Você está fazendo o equivalente ao trabalho de uma equipe? Talvez.

Você está fazendo o equivalente ao trabalho da sua equipe? Provavelmente não.

O que quero dizer é que sua equipe provavelmente está ocupada trabalhando e você está sobrecarregado. E esse é o problema: você está sobrecarregado com coisas que devem ser retiradas dos prazos atuais do projeto ou entregues a alguém com tempo disponível.

Eu era um idiota quando inicialmente esperava que as coisas fossem diferentes?

Não; apenas novo para a festa. É como uma primeira ressaca ou relacionamento. Você vai superar isso.

Eu acho que este post se transformou em um grande discurso retórico, mas por favor, diga-me que isso não é o mesmo para todos os desenvolvedores.

É o mesmo para todos os desenvolvedores de organizações caóticas, sejam elas startups ou gigantes bem estabelecidos, e sem experiência ou confiança para fazer com que as coisas avancem um pouco e inclinar suas chances de sobrevivência no lado direito da escala.

PS Meu salário é quase igual, se não inferior, ao de um caixa de um supermercado.

Fiz salários decentes em trabalhos que pareciam ruins. Não é o número do cheque que conta, é o contexto. O que você faz, sua idade, onde você mora e trabalha, etc ...

Dito isto, se você é mal remunerado, trabalha demais e não é totalmente júnior, peça um aumento ou obtenha um novo emprego!

É simples:

• se eles valorizam o que você faz, eles concordam em aumentar,
• se não o fizerem, o futuro desta empresa não parecerá muito positivo (pelo menos para você, o que importa), portanto, não se sinta mal por sair.

Esteja ciente de que pedir um aumento é uma coisa boa, mesmo que você não estivesse disposto a pensar assim no início. Isso prova que você acompanha o que faz e sugere que fica de olho em outras opções enquanto ainda está disposto a permanecer a bordo. E é bom se acostumar a solicitá-las, pois são como entrevistas de trabalho ou barganhas em geral: é algo que requer prática, e elas não caem do céu se você não as procurar. Algumas empresas distribuem aumentos regularmente sem que isso seja solicitado, mas isso é apenas porque eles são espertos o suficiente para saber que isso o deixa meio feliz e menos disposto a mudar, e querem cortar a grama sob seus pés (a maioria das pessoas sentiria pouco à vontade para aumentar uma oferta de aumento que eles foram oferecidos diretamente).

Como prosseguir com essa solicitação está um pouco fora do escopo deste projeto aqui, então não entrarei em detalhes. Mas eu recomendo que você prepare um registro dos seus IDs de confirmação do SCM, de seus bugs e conquistas corrigidos e também prepare relatórios comparando-os com o esforço geral da equipe. Deste jeito:

• você pode avaliar por si mesmo se efetivamente fez muito mais do que seus colegas ou não,
• você pode se defender se eles disserem que sua solicitação não é justificada.

Além dos comentários de outras pessoas:

1. Sim, é normal que um funcionário iniciante receba os trabalhos que ninguém mais quer fazer.

2. Você deve ver isso como um bloco de construção para sua futura carreira.

Então o que você deveria fazer? Para provar que você é um desenvolvedor profissional, você precisa garantir que seu trabalho seja estruturado e planejado; caso contrário, você pode achar difícil desenvolver as coisas boas que está fazendo no momento - por isso, tente fazer o seguinte (se você ainda não está).

1. Registre seu trabalho com precisão, para cada projeto. Portanto, se você passar uma hora consertando um bug no projeto A, faça logon dessa vez. Isso será útil para mostrar ao seu gerente se você deseja discutir cargas de trabalho.

2. Escreva testes de unidade. Você mencionou que alguns dos projetos que mantém são cheios de bugs, portanto, acho que existem poucos (se houver) testes de unidade. Para cada relatório de erro, escreva um teste de unidade que replique o erro e corrija-o. Isso ajudará a garantir que não ocorram regressões, melhore a qualidade do código e servirá como uma plataforma para refatorar o código, se você tiver a chance (por exemplo, isso pode ajudar a convencer os envolvidos que a reescrita de algumas partes pode melhorar qualidade sem introduzir novos bugs, devido ao conjunto de testes de unidade).

3. Procure um novo emprego - você trabalha em muitos projetos ao mesmo tempo, escreve código do zero e provavelmente já passou por todo o ciclo de vida do projeto - essas são boas experiências para aplicar em outros lugares.

Sua situação é um pouco nervosa, mas ainda normal. Mas a maneira como você lida com isso é muito ruim. Aqui está o que você precisa fazer:

• Tente confrontar seu chefe. Você deve ter algumas provas (números) de quanto tempo a base de código incorreta realmente custa. Se ele não entender coisas como dívida técnica, pare de mencionar. Isso estragaria sua cabeça, e você poderia ser marcado como um cara de 'má atitude'. Não é seu trabalho ensinar seu chefe a fazer o trabalho dele.

• Mantenha sua própria lista de pendências (Kanban). Quando novas tarefas chegarem, encerre-as e informe o tempo estimado de conclusão.

• Aumente seu tempo de resposta, verifique seu e-mail apenas duas vezes por dia. Normalmente antes do almoço e antes de sair. (A verificação do e-mail não deve ser seguida de codificação, pois isso pode prejudicar sua cabeça).

• Faça pequenos aprimoramentos de código como parte de cada tarefa. É simplesmente seu trabalho melhorar o código, as habilidades e as ferramentas que você está usando. Também aumentará sua moral a longo prazo.

• Nenhuma troca de projeto durante o dia. Hoje você está simplesmente trabalhando no projeto X e iniciará outra tarefa para Y amanhã.

• Aloque uma hora por dia para manter os portões. Significa pequenas tarefas que são triviais para executar. Se essa tarefa demorar mais de 10 minutos (não importa qual seja o motivo), ela entrará na lista de pendências e você notificará o gerente de que haverá atraso.

Agora vem a parte difícil. Atualmente, os gerentes não se comunicam e assumem que você terminará seu próprio projeto com a máxima prioridade. Isso traz muito estresse à sua cabeça, porque você está no meio de discussões. Você precisa forçar os gerentes a começar a coordenar seu trabalho. No final, você deve ter uma lista de pendências simples e agradável, e os gerentes devem se intimidar sem você.

Então, vamos fazer algumas dramatizações simples. Existem três gerentes e projetos (Xavier no projeto X, Yvonne no projeto Y e Zed no projeto Z). Você tem um backlog por duas semanas, 5 dias para X e 5 dias para Y.

• Z pede para você fazer alguma tarefa (1 dia)
• Você responde que isso será feito em 11 dias.
• Z responde que é uma tarefa simples e não deve demorar mais de um dia (observe que Z aplica uma pequena pressão).
• Você responde que está atualmente trabalhando para X e, posteriormente, para Z. Você pode fazer o trabalho dela depois disso.
• Z responde que você deve executar sua tarefa imediatamente de qualquer maneira (aumento da pressão, violação direta do território X e Y).
• Você responde que fazer a tarefa dela atrasaria o trabalho para X e Y. Ele deveria perguntar primeiro. Você também CC X e Y.

Agora existem duas extremidades:

• Os gerentes começam a latir uns para os outros, muitos e-mails, provavelmente algumas reuniões ... Você deve ficar longe e deixar que o vencedor lhe atribua uma tarefa.

• Nada vai acontecer, Z perguntará, dois dias depois, onde está sua tarefa. Você responde que está trabalhando para o X atualmente e ele não mencionou nada sobre o projeto Z. Novamente CC X.

Agora, esse tipo de comportamento pode fazer com que você seja demitido. Mas sua situação é insustentável e você provavelmente desistirá em breve. Essa solução só funciona se os gerentes estiverem competindo entre si (muito comum). Você também deve manter registros de seu trabalho (lista de pendências), caso alguém se queixe, de que você está diminuindo.

Há sete anos, eu fazia praticamente um trabalho de manutenção a 100% por um tempo e escrevi um artigo sobre o assunto: The Art of Maintenance Programming . Uma parte que você pode achar útil:

1. Comece a gostar

Como alguém pode gostar de programação de manutenção? Os desenvolvedores sonham em ser arquitetos-chefe em suas equipes e, quando acabam mantendo o software existente, parece quase uma punição. Não precisa ser assim: a programação de manutenção tem seu próprio conjunto de desafios e requer muita criatividade, adaptabilidade, paciência, disciplina e boa comunicação. Também pode ser bom para sua carreira: ter entradas bombásticas como "Aplicativo corporativo arquitetado de n camadas 24/7" em seu currículo parece bom, mas os empregadores realmente valorizam as pessoas que resolvem problemas; e a programação de manutenção pode ser uma boa chance de demonstrar suas habilidades de resolução de problemas.

Seu problema parece algo que você ouve com mais frequência. Parece ser um trabalho que poderia caber facilmente no The Daily WTF .

Muitas organizações se concentram mais nas vendas ou na promoção de recursos do que na qualidade. O que essas empresas deixam de ver é que existem mais do que qualidades externas em um pedaço de software. Ward Cunningham cunhou o termo dívida técnica .

Você também pode ler Steve McConnell sobre dívida técnica . Ele tem alguns pontos interessantes. Em um Google Tech Talk, Ken Swaber fala sobre desenvolvimento ágil de software . Uma boa parte é sobre uma história semelhante à sua. Ele fala sobre um projeto de software que se tornou "braindead" após 10 anos de programação por vários programadores, sem nunca fazer nenhuma refatoração . Penso que se vir este vídeo, verá muitas semelhanças com o que descreve.

Qualquer sistema de software irá degradar em qualidade quando estiver sendo expandido. De fato, para sobreviver, será necessário. As leis do Lehman explicam esse princípio muito bem. Por fim, tudo se resumirá à seguinte pergunta: "Como convencer seu chefe a refatorar?" .

Como me aproximei de um problema semelhante:

• Eu confrontei meu chefe e expliquei que a qualidade do código diminui quando continuamos desenvolvendo ( Leis do Lehman ).
• Tentei explicar ao meu chefe o conceito de dívida técnica . E que a maneira como ele permite que você trabalhe é uma maneira que lhe custará dinheiro a longo prazo.
• Para realmente mostrar a ele a gravidade do problema, fiz (no meu tempo) uma análise estática de código. Os chefes não entendem software, mas entendem os números. Embora as métricas de código tenham suas falhas , é bom ter algo mensurável sobre o qual você possa falar. Tente descobrir o que são leituras normais para essas métricas e você ficará surpreso ao comparar isso com sua própria base de código.
• Se nada ajudar e nada mudar, a única coisa que você pode fazer é explicar que um determinado novo recurso exigirá algum retrabalho de outras partes da sua base de código. Explique que, se você tiver um código duplicado e eles quiserem mudar algo, os custos de uma alteração também serão duplicados.
• Uma resposta comum ao ponto anterior será que ninguém pediu e, portanto, não pagou por esse retrabalho. Que "talvez" esse retrabalho seja supérfluo. Você terá que explicar que o software sempre terá que mudar. Como dizem as leis do Lehman ; terá que mudar para permanecer em uso. Caso contrário, outros programas que mudaram sempre sobreviverão. São aqueles que esperam mudanças e podem se adaptar às mudanças que sobreviverão. É disso que se trata o desenvolvimento ágil de software . ( Wikipedia )

Atualmente, meu chefe usa o conceito de dívida técnica para explicar aos nossos clientes que às vezes precisamos refazer partes do software que construímos. Só para provar que - se você tem um chefe razoável, é possível mudar as coisas para melhor.

A situação que você está enfrentando é quase (se não totalmente) a mesma para muitos novatos.

Isso acontece nas fases iniciais de uma carreira. Aqui está o problema: temos que superar esse problema e provar nosso valor para a empresa (seja de tamanho médio ou multinacional ). Deveríamos ser capazes de tomar decisões sobre o que as circunstâncias exigem que façamos. Portanto, não há mal nenhum em colocar esforços no trabalho, desde que você seja notado por ele e permaneça como indivíduo pelo seu trabalho. Se você vale a pena, a empresa notará! Adios e boa sorte.

Na minha opinião, uma empresa que proíbe a refatoração não vale a pena trabalhar. Refatoração é uma habilidade essencial de desenvolvimento de software e ferramentas de controle de versão de torná-lo muito fácil de desenvolver mudanças no isolamento sem corromper o 'tronco' (no caso de um refactor realmente faz quebrar alguma coisa). Como o tio Bob diz (parafraseado): "Você não deve pedir para ser um profissional e fazer o seu trabalho direito".

Programação de manutenção nunca deve significar perpetuar código incorreto.

Recebi este e-mail há cinco anos de um amigo.

Email body:    

Um engenheiro trainee recém-ingressado pergunta a seu chefe "qual é o significado da avaliação?"

Chefe: "Você sabe o significado da renúncia?"

Estagiário: "Sim, sim"

Chefe: "Então, deixe-me fazer você entender o que é uma avaliação comparando-a com resignação"

Comparison study: Appraisal and Resignation
|---------------------------------+----------------------------------| 
|       Appraisal                 |       Resignation                |
|---------------------------------+----------------------------------|
|     In appraisal meeting they   |    In resignation meeting they   | 
|     will speak only about your  |    will speak only about your    |
|     weakness, errors and        |    strengths, past achievements  |
|     failures.                   |    and success.                  | 
|---------------------------------+----------------------------------|
|     In appraisal you may need to|    In resignation you can easily |
|     cry and beg for even 2%     |    demand (or get even without   | 
|     hike.                       |    asking) more than 10-20% hike.|
|                                 |                                  |
|---------------------------------+----------------------------------| 
|     During appraisal, they will |    During resignation, they will |
|     deny promotion saying you   |    say you are the core member of|
|     didn't meet the expectation,|    team; you are the vision of   | 
|     you don't have leadership   |    the company how can you go,   |
|     qualities, and you had      |    you have to take the project  |
|     several drawbacks in our    |    in shoulder and lead your     | 
|     objective/goal.             |    juniors to success.           |
|---------------------------------+----------------------------------|
|     There is 90% chance for not |    There is 90% chance of getting|
|     getting any significant     |    immediate hike after you put  |
|     incentives after appraisal. |    the resignation.              |
|---------------------------------+----------------------------------|

Estagiário: "Sim, chefe, agora eu entendi meu futuro. Para uma avaliação, terei que renunciar ... !!!"

Se eu fosse você, passaria algumas horas depois do trabalho de reconstrução do aplicativo gratuitamente. Provavelmente seria uma tarefa divertida. Quando terminar, mostre ao seu chefe. Se funcionar e você estiver fazendo manutenção, ele não deve ter nada com que se preocupar. Isso tornará seu trabalho muito mais fácil e abriria os olhos dos altos para o seu potencial na empresa.

Sou estudante universitário em período integral, trabalhando em um estágio de meio período por US $ 10 por hora. Eu faço coisas de controle de qualidade que são chatas, repetitivas e fáceis. Considero-me extremamente sortudo, porque sei que um dia isso abrirá portas para lugares maiores e melhores.

Sim, você sempre terá que manter aplicativos, escritos por você e por outras pessoas. A única exceção é se você escrever um programa que nunca precise de manutenção. Então é melhor você ficar bom em manutenção.

Eu acho que há uma dica sutil na sua pergunta sobre uma falha na sua abordagem. Ou seja, a correção de bugs não envolve a melhoria do código.

Mas então soube que não tinha permissão para melhorar o código existente e me concentrar apenas nas correções de erros quando um bug é relatado.

Não acredito que alguém tenha lhe dito "você deve corrigir erros sem melhorar o código". Isso é difícil e impossível. O que você não pode fazer é reescrever o aplicativo apenas porque você não gosta, ou acha difícil de entender, a abordagem usada na base de código existente.

Meu conselho é aprender a refatorar. Sempre que você estiver corrigindo um bug, você terá a oportunidade de melhorar pelo menos parte do código. Quanto da base de código é refatorada depende de qual é o erro e de quão bom ou ruim é o código. Mas se você está corrigindo bugs e conscientemente deixando cheiros de código em todo o lugar, não está fazendo seu trabalho e está criando dívidas técnicas .

Na verdade, alguns bugs são corrigidos simplesmente por refatoração e, às vezes, é útil refatorar para ajudá-lo a entender o código . Isso ocorre porque a refatoração deve melhorar a manutenção e a coerência do código.

Quando eu estimar uma correção de erro, geralmente tomarei uma decisão sobre se um grande refator será a melhor maneira de fazê-lo, e levarei isso em consideração. O mesmo com testes de unidade. Ambas as coisas devem fazer parte da maneira como você escreve código, não algo opcional que envolve tempo extra.

Portanto, você não deve estar perguntando "posso melhorar o código quando eu corrigir o bug?" Porque você deveria ser assim mesmo. Você não deveria estar se perguntando "posso usar a refatoração para corrigir o erro?" Como se o código que está causando o erro do aplicativo precisar urgentemente de refatoração, faça-o de qualquer maneira. Você não deveria estar se perguntando "posso escrever testes de unidade quando corrigir esse bug?" Porque você deve escrever um teste de regressão antes mesmo de começar a tentar corrigir o erro.

NB: Sinto que alguma atribuição desta resposta deve ser dada a Jeff Atwood, visto que eu vinculei 3 de seus artigos.

Este é tudo sobre dinheiro. Meu palpite é que, para começar, você provavelmente é muito gentil com clientes que já receberam mais do que pagaram.

Aprenda a cotar um preço para novos pedidos. Isso está longe de ser fácil e os clientes costumam experimentar você. Se puder, solicite a ajuda de um experiente gerente de projeto / produto.

Depois de pensar em termos de dinheiro, a comunicação com a gerência se torna muito mais fácil. Se seus clientes atuais fornecem dinheiro em tempo integral, você não deve adquirir novos projetos. Mas você entenderá que a gerência ainda tentará intimidá-lo a fazê-lo.

Se você é realmente valioso para a empresa, ganhará poder de barganha. Você pode solicitar que contratem mais pessoas, obtenham menos novos projetos, ajudem a reduzir a carga de manutenção ou aumente seu salário.

Não deve ser uma decisão do seu empregador microgerenciá-lo na medida em que você está proibido de melhorar o código existente. Use seu próprio julgamento profissional. Ao estimar o trabalho, eu consideraria um tempo adicional para permitir alguma refatoração, se isso aumentar a produtividade no futuro.

De qualquer forma, parece que você não está se comunicando efetivamente com seu empregador.

1. Você tem evidências de que a refatoração economizará dinheiro. Elabore uma proposta para um projeto de refatoração e demonstre quanto tempo e dinheiro a empresa poderia economizar. Descreva precisamente quais alterações você faria no código e quanto tempo levaria.

2. Mantenha um registro preciso para registrar quanto tempo você gasta em codificação, reuniões e resposta a emails. Isso irá protegê-lo se você ficar atrasado.

3. Desacelere. Isso pode parecer um pouco contra-intuitivo, mas seu tempo só será abusado se você fizer tudo rapidamente. As pessoas respeitarão mais seu tempo se você fizer menos. Por exemplo, eu só verificaria o email uma ou duas vezes por dia. Caso contrário, você corre o risco de esgotar-se.

4. Considerando sua taxa de pagamento, não vale a pena ficar com dor de cabeça. Certifique-se de sair a tempo todos os dias. Não gaste horas extras sem compensação adicional. A exceção é se houver boas opções de avanço, ou se a reputação da empresa aumentar bastante o seu currículo, então você terá que desistir.

Sem saber mais, sugiro que você tente ser mais aberto com seus gerentes. Talvez comece a aumentar suas estimativas de tarefas. Lembre-os constantemente de como sua carga de trabalho está ocupada. Além disso, você deve se reunir com seu chefe e explicar que deseja um aumento salarial dentro dos próximos seis meses e perguntar como você pode melhorar seu desempenho para alcançar esse aumento salarial.

Boa sorte.

Na minha experiência, o mundo acadêmico ou os primeiros 6 a 12 meses de uma start-up orientada para a tecnologia são as duas únicas áreas confiáveis ​​em que você encontrará uma verdadeira placa em branco. Ambos suportam seus próprios custos, mas se você gosta de codificar e geralmente fica horrorizado com a qualidade do código que descobre na natureza, deve começar apontando sua carreira em uma dessas direções.

Tente conversar com seus empregadores e veja se consegue resolver isso. Parece que você está pensando sobre isso e não tem nada a ver com ser um programador ruim.

Empresas menores da web tendem a ter muitos projetos em andamento ao mesmo tempo, o que, de várias maneiras, deixa você em uma situação difícil. Tente tirar o melhor proveito da sua situação ou tente encontrar um novo emprego, se achar que pode. Eu prometo que existem melhores trabalhos de codificação por aí, então não deixe que este primeiro assuste você.

Boa sorte, e espero que você e seus colegas de trabalho compreendam a gravidade ou seus esforços!

Experiência pessoal

Como muitos aqui, também reconheço sua situação. Basicamente, consegui meu primeiro trabalho de codificação com um salário baixo e tive que manter muito código construído com uma estrutura ruim. No começo, achei engraçado aprender coisas novas, mas quando eu tinha muitos projetos para manter, novos projetos para fazer e um quadro branco que crescia cada vez mais a cada dia com pontos que eu não terminava, percebi que não estava funcionando.

Depois de aguentar isso por dois anos, parei e encontrei outro trabalho de codificação alguns meses depois, o que me encaixa perfeitamente.

De qualquer forma, muitas vezes não são apenas os seus projetos que podem ser o problema. Sinto-me mais confortável no local de trabalho quando sou reconhecido e respeitado pelo meu trabalho. O problema com a situação em que você está é que seus empregadores podem perceber apenas os bugs que surgem dos projetos criados, e não o tempo que você leva para remover todos os outros bugs.

Salário

Se você quer mais dinheiro, pode obtê-lo com frequência. Consegui negociar meu salário em menos de dois anos para um aumento de 33%.

Basicamente, pense no valor do seu trabalho e quanto a empresa precisa de você. Se eles não puderem pagar o salário que você ganhou, então a empresa precisa examinar suas despesas ou perceber que seus negócios não estão funcionando.

E, como mencionado por muitos aqui, e eu concordo, você é uma peça muito valiosa do quebra-cabeça da empresa. Inferno, você provavelmente é o único que pode resolver esse quebra-cabeça. :)

Como ainda não posso comentar porque sou um espreitador neste site do Stack Exchange, apenas adicionarei as informações aqui.

1. Como você está apenas começando, seu salário não será estelar, a menos que você trabalhe para uma grande empresa como Microsoft, Amazon ou algo parecido. Mas não deve ser o de um funcionário da mercearia! Não agüente isso por muito tempo, ganhe experiência fazendo o que está fazendo e siga em frente quando surgir uma oportunidade melhor.

2. Para um show de nível básico, isso é normal. Sua carga de trabalho é muito alta, mas o tipo de trabalho é esperado. Para se tornar um desenvolvedor melhor, você deve aprender com os erros dos outros. Quanto mais você vê, melhor você se torna. Mas isso implica que você está procurando coisas para aprender, não aprendendo maus hábitos ...

3. A proporção de manutenção em relação ao trabalho do projeto deve mudar com o tempo. Se não for, isso significa que a empresa em que você trabalha não sabe como manter um bom desenvolvedor; eles pretendem que você faça a mesma coisa dia após dia. Estabeleça uma meta anual para si mesmo sobre onde você gostaria de estar, as expectativas de salário e emprego, e mude de acordo.

4) Se você não estiver feliz, vá embora! A vida é muito curta para lidar com pessoas estúpidas.

Muito bem sucedida.

Você começa a usar um rastreador de problemas para acompanhar sua lista de tarefas.

Isso não apenas ajudará você a acompanhar o que é crítico, mas também ajudará os usuários e seu chefe a ver qual é a sua carga de trabalho atual.

Além disso, se eles contratarem um segundo desenvolvedor (ou você sair e a sua substituição agora ocupar sua carga de trabalho), isso ajudará no gerenciamento da carga de trabalho e você poderá evitar pisar nos dedos um do outro.

A única maneira de quebrar essa cadeia é desenvolver novas infraestruturas projetadas para oferecer flexibilidade e que são testadas com integração total de unidade +.

Se você conseguir vender isso para o gerenciamento (assinar outros desenvolvedores e gerentes para o conceito em reuniões 1: 1), poderá chegar lentamente a um estado em que a maioria do código dos aplicativos está na infraestrutura e é fácil expandir e manter, enquanto os aplicativos atuais são leves e podem ser gravados rapidamente.

O desenvolvimento da infraestrutura pode permitir, a princípio, substituir partes de aplicativos existentes e depois de um tempo (pode levar alguns anos) substituir aplicativos inteiros.

A longo prazo, pode reduzir drasticamente o tempo de desenvolvimento de novos aplicativos e o tempo de manutenção de aplicativos existentes no futuro.

O novo desenvolvimento exigirá pelo menos 80% de dedicação (de preferência mais) com uma equipe de mais de um desenvolvedor (algumas mentes são melhores que uma). Todos os desenvolvedores precisam ser capazes de pensar de forma criativa e quebrar os preconceitos existentes.

Tente definir e projetar em alto nível uma nova infraestrutura, depois apresente a definição aos seus pares e ao gerenciamento.

Conforme suas condições de trabalho, peça para liderar uma nova equipe de infraestrutura que lide com esses problemas (com base em suas definições e design) e convide novos desenvolvedores para manter as coisas antigas enquanto você as ajuda, se necessário (até 10 a 20% dos A Hora). Se a gerência concordar com a ideia, peça para renegociar seus termos. Esteja preparado para encontrar outro emprego se eles recusarem. (Lembre-se, seu trabalho exige habilidades, conhecimentos e experiência, você não é tão fácil de substituir quanto eles estão pagando para você acreditar.)

Seu gerente está ciente de todas essas solicitações de mudança (solicitações de manutenção)? Ele / ela percebe que seu tempo é gasto examinando tais pedidos que você não tem autoridade para sancionar? Ou você apenas faz alterações sempre que um gerente pede?

Parece-me que o seu primeiro porto de escala é colocar tudo na mesa do seu gerente. Ninguém deve vir diretamente para você. Os problemas devem surgir por quem quer que seja, como geralmente uma equipe de suporte. É normal que você suporte seu código por um curto período de entrega - geralmente uma semana ou mais. As alterações devem ser custeadas e cobradas (taxa de transferência) em qualquer empresa que se classifique como "tamanho médio", e isso parece estar sendo ignorado (não é de admirar que elas estejam inundando você - você é como a vagabunda no baile).

Deve haver um procedimento de solicitação adequado para levantar problemas e solicitar alterações. Suporte / manutenção é sobre a correção de bugs e problemas (que se encaixam na especificação original, mas falham devido a um erro no código ou a um evento externo - como um desligamento ou um sistema upstream corrompido, etc.).

Se a sua empresa não oferece nada disso e espera que você lide e seja responsável por essa infinidade de solicitações aleatórias, seriamente, você deve considerar seguir em frente. O salário é sempre baixo - no meu primeiro trabalho de programação (quase 25 anos atrás), passei 8 anos na mesma empresa e meu salário subiu pouco (embora sempre tenha sido muito maior que um caixa!). Depois de dois anos de partida, eu a duplicara - e dois anos depois estava levando para casa mais de dez vezes o que comecei (mas na época era uma contratada independente). Como sempre, ganhe esporas, aprenda seu ofício e embarque para um ambiente mais quente.

Talvez você esteja em posição de procurar um gerente e dizer: "Olha, eu vou ser sincero com você. Meu salário é terrível, eu poderia ter N vezes isso como programador iniciante no X.

Estou fazendo coisas demais com A, B e C. Não posso manter isso. Honestamente, e sem ofensas, vou sair desta sala com isso ou com minha carta de demissão deixada com você. Agora que tudo está no ar, como podemos trabalhar juntos para corrigir isso? "

A resposta é tentar explicá-lo em termos que possam ser entendidos;

• É como mudanças de óleo. Eles não são urgentes .... mas devem ser feitos regularmente, não obstante
• pintar sobre a ferrugem e ficará ótimo. Até que sangre
• Construa uma nova mesa de teto sem reforçar os suportes. Talvez funcione por um tempo. Então ele entrará em colapso e machucará as pessoas e você será responsável.
• a / c é ótimo. Uma unidade de janela é ótima para um ou dois quartos. Tentando colocar 146 aparelhos de ar condicionado em um prédio de apartamentos e você terá ... problemas.
• Ensinar 5 crianças é bom. 10 não é tão ruim. Mas existem limites. Tente ensinar informalmente 75 crianças e você verá isso.

Se estes não são ressonantes. Sair - NO DIA EM QUE VOCÊ OFERECE A ESCRITA, não no dia seguinte! Depois de ter um novo emprego, saia com aviso zero. Literalmente, simplesmente não entre naquele dia. Mas verifique se você tem um colega ou dois que sabem o que você fez. Isso realmente ajudará a empresa, se ela puder ser auxiliada, mostrando a eles que seu desrespeito e arrogância têm um preço. Última empresa, estive em TRÊS DAS QUATRO TECNOLOGIAS ESQUERDAS EM 6 MESES, SEM TRABALHO. Ele fez uma declaração pelo menos e deu à pessoa que saiu uma vez uma boa chance de dizer: 'Sim, é legal você dizer todos os dias, mas está tão cheio disso, que nem estou lhe dando a satisfação do meu aviso.

Finalmente, saiba que essa questão era a NORM e o padrão há 20 anos atrás, antes que o ágil, o tdd, o bdd e a refatoração se tornassem mais do que norma. Você pode estar conversando com pessoas mais velhas que respondem imediatamente "bem, eu mesmo fiz isso e funcionou bem, blá, blá, blá". Bem, seus cavalos e carruagens funcionaram bem há 150 anos. Nas áreas de tecnologia, as técnicas de 20 anos atrás são tão desatualizadas quanto o transporte de 150 anos atrás. Se eles rejeitarem esta multa. Apenas saiba que eles nunca contratarão desenvolvedores de tecnologia atuais decentes que permanecerão por aqui. Eles terão o pior dos piores e isso prejudicará terrivelmente seus negócios. Se eles dependem da tecnologia e não conseguem se adaptar, fracassam e, finalmente, essa pode ser a melhor recompensa para você. Isto'

Parece que seu gerenciamento não o respeita nem compreende sua carga de trabalho.

Você não deve implementar todas as solicitações de recursos recebidas. Seu gerente deve atuar como um buffer entre você e as solicitações recebidas (exceto, talvez, a mais simples das solicitações de interrupção / correção). Em seguida, ele ou ela deve se sentar com você e determinar a viabilidade e a prioridade de quaisquer solicitações aprovadas.

Além disso, você deve ganhar provavelmente 2x (pelo menos) o que eles estão pagando.

Parece que eles provavelmente realmente precisam de pelo menos mais 1 desenvolvedor para trabalhar ao seu lado, mas com o que eles estão pagando isso parece bastante improvável.

Se eles não estiverem dispostos a pagar adequadamente ou ajudá-lo a gerenciar sua carga de trabalho, eu estaria procurando um novo emprego. Você deseja trabalhar em algum lugar em que faça parte de uma equipe e em que seu gerenciamento trabalhe com você para concluir seus projetos. Saia desse navio afundando assim que puder.

Ser um herói em uma equipe só vai te queimar.

Eu sou apenas um estudante (ainda), mas isso é bastante normal (da minha experiência de estágio). É isso que você obtém ao trabalhar em aplicativos da Web e de suporte.

Eu aconselho você a entender o que o cliente (gerente) deseja antes de iniciar a codificação. Isso pode ser complicado, porque às vezes eles não sabem disso, então trabalhem com eles até chegarem a um acordo. Certifique-se de que ambos concordam com a solução final antes de codificá-la.

Além disso, se você é um mantenedor, pode alterar praticamente qualquer coisa no código - apenas certifique-se de que isso não mude o comportamento nem introduza bugs. Espero que os gerentes não 'permitam' que você mude nada, porque eles estão acostumados e felizes com a situação atual e não querem pagar por novas mudanças.

Por fim, não se preocupe se não conseguir lidar com algo porque está fazendo outra coisa. Aconselho que você informe às pessoas que você está sobrecarregado com o trabalho e que a solicitação delas levará tempo. Caso contrário, os gerentes apenas pensariam que você é preguiçoso. Deixe que eles saibam que você já tem trabalho e eles podem contratar mais pessoas. Não há outra maneira de eles saberem que o trabalho é demais para uma única pessoa.

Este é um problema de gerenciamento de projetos. Use algum tipo de gerenciamento de projetos para decidir qual é a maior prioridade para trabalhar.

a) Você precisa de uma lista de pendências de itens para trabalhar. Você coloca seu plano para melhorar o código na lista de pendências.

b) Todos os erros entram no backlog

c) A lista de pendências é priorizada.

d) Você faz tudo em ordem de prioridade.

Os erros podem muito bem ser uma prioridade mais alta, mas se você corrigir tudo o que tiver ciclos para gastar em novos recursos ou no projeto de refatoração.

É mais fácil se você apenas refatorar aprimoramentos de forma incremental, ao passar por seções que têm problemas / bugs para corrigir. Então você pode dizer à gerência: "Eu tive que consertar A, mas B estava fundamentalmente quebrado e tive que fazer a solução C para consertar tudo, para que D fosse mais fácil / mais barato no futuro" Onde A = O bug, B = anti-padrão, C = Solução, D = Ganhos Futuros

Se você não pode justificar o trabalho como um investimento que vale a pena fazer, os empresários nunca o aceitarão.

Isso é negócio como sempre. Você será explorado enquanto continuar trabalhando lá, ao que parece. É do interesse da empresa continuar com esse modelo, em vez de fazer você se sentir feliz com o que está fazendo. Quando se trata disso, eles realmente não se importam. Trata-se de criar um código confiável para eles e, se você é uma banda de um homem, eles certamente estão bancando você. Por que eles mudariam?

A boa notícia disso tudo é que você é um VIP para eles, mesmo que não o conheçam. O que eu sugiro fazer é alinhar mais algumas oportunidades antes de pular de navio e depois agarrá-las pelas bolas e exigir um salário mais alto. Se não, mude para uma oportunidade melhor. Na minha opinião, você deve encontrar algum trabalho mais emocionante em breve. Mire o mais alto que puder. Quando você chegar a uma loja de desenvolvedores, ficará muito mais feliz, como o Google ou alguma startup divertida, onde exista uma cultura colaborativa de desenvolvedores, na qual você realmente se sentirá feliz.

O que eu fiz pessoalmente foi usar uma organização de empreiteiros caçadores de cabeças e rapidamente tive muitas experiências excelentes, mudando de uma para outra enquanto ainda mantinha um emprego estável por parte da contratada. Evita que você fique entediado e desafia você. Eventualmente, no meu tempo livre, construí algumas pequenas empresas que se transformaram em negócios reais e depois deixei de fazer contratos de trabalho.