Erros são apenas o começo
Este artigo foi originalmente publicado em .cult por Patrick Zawadzki . .cult é uma plataforma de comunidade baseada em Berlim para desenvolvedores. Escrevemos sobre todas as coisas relacionadas à carreira, fazemos documentários originais e compartilhamos muitas outras histórias não contadas de desenvolvedores de todo o mundo.
O desenvolvimento de software como carreira explodiu nos últimos dois anos. E com a popularidade dos campos de treinamento e movimentos laterais, é um ótimo momento para se envolver.
No entanto, por trás de toda a confusão e entusiasmo da engenharia de software , há um lado que não é tão glamoroso. E se você é como eu, provavelmente quer saber a verdade suja antes de comprometer tempo, energia e dinheiro.
Em qualquer trabalho, há dias bons e dias ruins. Eu gosto de dizer que se você gosta do seu trabalho pelo menos 70% do tempo, você tem um ótimo trabalho. Pessoalmente, adoro desenvolvimento; Eu não poderia estar mais feliz, mas isso não deveria me impedir de abordar os outros 30%… aqueles dias ruins, aqueles problemas recorrentes, aqueles momentos difíceis.
Pode haver muitos problemas com qualquer trabalho ao longo do tempo, mas com o desenvolvimento, existem alguns recorrentes que sempre parecem aparecer em algum momento da minha carreira. Então, vamos falar sobre as cinco piores coisas de ser um desenvolvedor (sem ordem específica).
1. Problemas de depuração em uma base de código sobre a qual você não tem controle direto
Bugs não são algo que as pessoas querem encontrar. É ótimo quando você faz isso, mas um bug, em última análise, significa que em algum lugar ao longo da linha, uma etapa foi ignorada ou um processo foi mal interpretado. No contexto desses tipos de bugs, eles são o melhor subconjunto de todos os bugs porque pelo menos podemos controlá-los. Podemos encontrá-los na base de código e corrigi-los. Mas e quanto a bugs importados de uma biblioteca ou bugs importados de um fornecedor terceirizado?
Depurar problemas que você não pode acessar facilmente é sem dúvida uma das partes mais desafiadoras e frustrantes de ser um desenvolvedor. Talvez seja uma biblioteca que você importou, mas a biblioteca foi minificada ou compilada tornando-a ilegível ao olho humano. Felizmente, esta biblioteca é de código aberto… certo? Nem sempre, e isso é o pior dos piores nesta categoria. Agora você precisa gastar mais tempo isolando o problema, em um sistema externo, de forma reproduzível para que você possa enviar esse problema para os proprietários da referida biblioteca, na esperança de que eles possam corrigi-lo no cronograma que você precisa.
Esses são desafios enfrentados por muitas equipes diariamente e, em última análise, não são evitáveis. Você pode mitigar esses tipos de preocupações optando por soluções de código aberto ou caseiras ao fazer a escolha de sua base de código. Mas se não houver opções, você está encurralado e tem que morder a bala.
2. Manter um projeto antigo, sem nenhum conhecimento contextual
Imagine isso, você é um sobrevivente treinado e experiente decidindo se juntar a um programa de TV como Alone com algumas reviravoltas. Você fez esse tipo de coisa por milhares de horas, é um especialista no que faz e tem um histórico comprovado de sucesso. Aqui está a reviravolta, nesta temporada, você é pego aleatoriamente e jogado em uma área completamente desconhecida para você.
Para ser um sobrevivente bem-sucedido, você precisa saber para onde está indo, como é lá e talvez até alguns métodos para o sucesso. Você precisa saber por que vai trazer certos itens, como eles podem ser úteis e talvez até conversar com alguns companheiros de sobrevivência que já estiveram em um ambiente como esse antes. O que funcionou, o que não funcionou e talvez alguns truques do ofício que são únicos nesse ambiente. Mas não, esta temporada de “Alone+” vai testar suas habilidades ao máximo.
Ser um desenvolvedor de software lançado em um novo projeto, sem nenhum contexto ou sem ninguém para quem você possa fazer perguntas, é bem parecido com isso. A questão do software é que há uma infinidade de maneiras de abordar um único problema e, às vezes, o caminho das decisões que alguém tomou para escolher sua abordagem foi sistemático e profundamente debatido.
Estar em um projeto sem qualquer contexto ou pessoas para as quais você possa fazer perguntas significa que você pode encontrar coisas estranhas e lutar para entender por que elas estão lá. Foi um desenvolvedor sendo preguiçoso? Era uma solução alternativa ou hack que eles precisavam fazer para cumprir um prazo? Foi devido a alguma restrição externa que força o código a ser projetado dessa maneira? É impossível dizer, está simplesmente perdido no vazio. A reviravolta de tudo isso é que você ainda precisa aprender como ter sucesso nesse ambiente, pois seu próprio sucesso como desenvolvedor depende disso.
Esses tipos de projetos podem, infelizmente, levar muitos desenvolvedores ao extremo e fazer com que algumas pessoas odeiem seus trabalhos. Esses projetos são lentos para começar e parecem tentar navegar cegamente em um campo minado. É por isso que código bem escrito e código com documentação atualizada são tão importantes.
Se você está lendo isso, provavelmente é um desenvolvedor ou quer se tornar um. Tente ser aquele que anota essas esquisitices em sua base de código para que a próxima pessoa que interagir com ela tenha mais facilidade em juntar as coisas, esteja você ou não lá para responder perguntas.
3. Quando as pessoas que NÃO entendem de desenvolvimento de software tomam as decisões
Uma composição típica de uma equipe no mundo do software são os desenvolvedores de software, um gerente de projeto e algum tipo de proprietário do produto. Talvez o gerente de projeto e o proprietário do produto sejam as mesmas pessoas, mas no final das contas há alguém escrevendo o código e alguém com uma visão do que eles querem que o produto seja. Na maioria dos cenários, a pessoa com a visão é a pessoa que faz reuniões com as partes interessadas, estabelece cronogramas e, por fim, “vende” o produto para outras pessoas.
A relação entre esse tipo de indivíduo e o desenvolvedor é crucial para o sucesso de um projeto e, às vezes, para a alegria do desenvolvedor em uma equipe. Com muita frequência, os desenvolvedores são vistos como “macacos de código” em projetos e os requisitos são simplesmente empurrados para eles sem muita discussão e, às vezes, com prazos irreais. Isso leva a produtos apressados, expectativas não atendidas e, em última análise, um produto com falha porque não faz o que a empresa tinha em mente e quebra constantemente.
Como programador, encontrar uma equipe que tenha uma relação de trabalho equilibrada entre gerentes de projeto/proprietários de produto é importante não apenas para o sucesso de um produto, mas para a alegria do programador em sua função.
4. Não ter tempo ininterrupto suficiente no seu dia
Existem muitas tarefas excelentes que abrangem o papel do desenvolvedor, e a maioria dos desenvolvedores tende a valorizar essas partes de seus trabalhos diários. A capacidade de criar rapidamente uma visão e transformá-la em realidade em poucos minutos é uma das partes mais viciantes de ser um programador.
Outra parte realmente incrível só pode ser descrita como “o fluxo”. É a sensação de imersão quase completa que se experimenta ao se aprofundar em seu trabalho e processo de pensamento. É uma parte muito comum de entrar em um lugar de produtividade e progresso profundos e uma parte da programação que muitos desenvolvedores precisam para serem eficazes.
No mundo do trabalho moderno, no entanto, é fácil ser constantemente adicionado a reuniões ou receber mensagens de forma assíncrona com perguntas/preocupações ao longo do dia. A coisa inconstante sobre “o fluxo” é que pode ser difícil entrar, mas fácil de ser retirado.
Além disso, o desenvolvimento de software é um tipo de trabalho altamente individualista, no sentido de que você é um colaborador individual que recebe tarefas e problemas e espera concluí-los. Com comunicação assíncrona constante e reuniões consecutivas, pode ser um desafio encontrar tempo suficiente para entrar no fluxo e permanecer no fluxo tempo suficiente para concluir as tarefas em mãos. A chave aqui é um período “ininterrupto” do seu dia, porque mesmo a mudança de contexto para caber em pequenas tarefas ao longo do dia é excessivamente desgastante.
Encontrar um intervalo de tempo ininterrupto, talvez 3-4 horas, idealmente, onde você possa entrar completamente em sua zona e se concentrar em seu trabalho é incrivelmente importante. Dias repletos de reuniões ou, pior ainda, reuniões esparsas com 30 a 45 minutos de intervalo são prejudiciais à produtividade e eficácia de muitos desenvolvedores em todo o mundo.
5. Síndrome do impostor
Para muitos programadores em todo o mundo, é lamentável dizer que, mais cedo ou mais tarde, eles experimentarão algum nível de síndrome do impostor durante suas carreiras. Talvez seja iniciar um novo projeto, ingressar em uma nova equipe ou apenas uma mistura repentina de emoções ruins em um dia que faz com que a dúvida se infiltre em suas decisões e afete as escolhas que você faz ao longo do dia.
De acordo com Merriam Webster, a síndrome do impostor é definida como:
… uma condição psicológica que é caracterizada por dúvidas persistentes sobre suas habilidades ou realizações acompanhadas pelo medo de ser exposto como uma fraude, apesar da evidência de seu sucesso contínuo.
É um cenário bastante contraproducente e contraditório que muitos lutam para superar. Algumas pessoas experimentam isso com frequência e outras nunca. Algumas pessoas experimentam isso com mais frequência do que esperavam. De qualquer forma, a grande coisa sobre a comunidade de software é que muitos a experimentaram em algum grau em algum momento de sua carreira e muitas pessoas estão dispostas a ajudar.
Resumo
A engenharia de software é um grande campo com muitos benefícios para muitas pessoas e é um campo interessante para se estar com oportunidades aparentemente infinitas. No entanto, cada campo e carreira tem seus prós e contras. Na maioria das vezes as pessoas só falam sobre os prós de uma carreira, mas raramente os contras, sejamos honestos, às vezes os contras podem superar os prós. E os contras para algumas pessoas podem nem ser contras para outras.
Independentemente da sua situação, espero que ver alguns dos lados negativos de um desenvolvedor de software possa ajudar a fornecer uma perspectiva para quem pensa em ingressar no campo e para quem está entrando no campo. Isso não é para assustar ninguém – é mais uma pequena luz brilhando nos cantos escuros que muitas vezes não são compartilhados. Afinal, estar ciente de problemas e coisas que podem afetá-lo é muitas vezes melhor do que não estar ciente.