Estou curioso para saber se minhas experiências atuais como estagiário são representativas da indústria real.
Como pano de fundo, eu já passei pela maior parte de duas áreas de computação e uma de matemática em uma grande universidade; Eu já participei de todas as aulas e adorei todas elas, então gostaria de pensar que não sou péssimo em programação. Fiz um estágio em uma das principais empresas de software e, no meio do caminho, fiquei chocado com a extraordinária qualidade do código. Os comentários não existem, é tudo código de espaguete e tudo o que pode estar errado é ainda pior. Eu fiz muitas aulas particulares / aulas de reforço, por isso estou muito acostumado a ler códigos ruins, mas os principais produtos do setor que tenho visto superam tudo isso. Trabalho 10 a 12 horas por dia e nunca sinto que estou chegando a lugar algum, porque s inúmeras horas tentando descobrir uma API não documentada ou determinar o comportamento de alguma outra parte do produto (completamente não documentado). Até agora, deixei o trabalho odiando o emprego todos os dias e quero desesperadamente saber se é isso que está reservado para o resto da minha vida.
Eu desenhei um pouco sobre os estágios (os salários absurdamente grandes sugerem que não é uma posição de baixa qualidade), ou é assim que o mundo real é?
fonte
Respostas:
Eles chamam isso de Mundo Real ™ por um motivo.
99% do que você encontrará no mundo corporativo real será considerado uma porcaria, e por uma boa razão que explicarei. O 1% que não é considerado porcaria se tornará uma porcaria eventualmente.
# 1 Write Code, # 2 ????, # 3 Profit!
Os primeiros negócios existem para dar lucro, eles não existem para gerar montanhas de códigos acadêmicos perfeitamente concebidos e puramente teoricamente limpos, alojados em repositórios de ouro da perfeição. Nem de perto, nem os que vendem o código fonte que produzem.
No mundo dos negócios, o código é um meio para atingir um fim . Se algum código resolver um problema de negócios e ganhar mais dinheiro do que custa para criar e manter, é desejável para os negócios. Empregá-lo para escrever código é apenas uma maneira de a empresa obter código.
Teoria 0 - Prática ∞
Idealmente, a manutenção deve ser mais uma preocupação, mas geralmente não é, porque a curto prazo não vence financeiramente. A longo prazo, o software geralmente tem um ciclo de vida relativamente curto, especialmente aplicativos baseados na Web, eles são obsoletos rapidamente e reescritos com mais frequência.
As aplicações domésticas de linha de negócios são aquelas que se desenvolvem como o que são percebidas como intermináveis projetos zumbis devido a muitas razões baseadas no momento. Esses projetos são, na verdade, sucessos e continuam porque continuam lucrando os negócios.
Em teoria, arquiteturas perfeitamente limpas e perfeitamente planejadas, com 100% de cobertura de código, devem economizar dinheiro das empresas; na prática, nem chega perto de oferecer algo próximo a um retorno válido do investimento.
Física do ciclo de vida do software
Também existe uma força de entropia super poderosa em ação no mundo do software. É um buraco negro de inevitabilidade que condena todos os softwares a degenerarem em uma grande bola de barro .
Quanto mais longe você começar de um BBM , melhor, mas todos os sistemas de software chegarão lá com tempo suficiente. A rapidez com que você se aproxima de 100% da entropia é determinada por onde você começa e com que rapidez acumula dívidas técnicas e quão alto é o interesse nela.
Os sistemas de software degeneram e apodrecem por causa da manutenção, não por falta dela. Um sistema que existe há anos sem alterações de código por definição atende a todos os seus requisitos e metas e é um sucesso.
São os sistemas que exigem mudança constante, porque começaram mais perto da entropia máxima, são os que são constantemente cutucados e estimulados, e é a manutenção que acelera a mudança negativa.
Bom o suficiente é bom o suficiente
Sistemas de ciclo de vida curto, como sites que mudam constantemente, não se beneficiam da enorme cobertura antecipada de 100% do código em testes de unidade, porque o tempo de amortização é muito curto para recuperar os custos.
Sistemas de ciclo de vida longo, como a linha interna de aplicativos de negócios acima mencionada, também não se beneficiam de investimentos maciços de 100% dos testes de unidade de cobertura de código, porque a taxa de variação ao longo da vida do projeto se aproxima de uma constante que é quase zero em um moda não linear.
É por isso que os planos de fim de vida útil são mais importantes e os sistemas de substituição devem ser planejados exatamente quando algo está sendo lançado, e não depois de ultrapassado por alguns anos e sem suporte, para que um novo sistema seja implementado rapidamente.
Eles não ensinam sobre BBM, tanto quanto eu sei, nunca encontrei um graduado recente em CS que sabia o que era, muito menos por que isso acontece.
É por isso que Bom o suficiente é Bom o suficiente , algo mais ou menos não é.
Slumlords de software
Existem senhores de favelas imobiliárias por um motivo, eles lucram com a degradação dos prédios de favelas que possuem. Eles obtêm mais lucro do que gastam em manutenção incremental da propriedade degradada. Se não o fizessem, demoliriam o prédio e o substituiriam. Mas não, porque os custos incrementais são muito menores do que revisar ou substituir todo o edifício. Também existem clientes (inquilinos) que estão dispostos a pagar por propriedades degradadas.
Nenhum proprietário de edifício, senhor de favela ou não vai gastar dinheiro em uma propriedade apenas por causa de alguma noção acadêmica de perfeição que não se traduz em um lucro substancial sobre o custo associado.
Nenhum cliente pagará por atualizações de um sistema de software que esteja funcionando de maneira aceitável para eles. Nenhuma empresa gastará dinheiro apenas escrevendo e reescrevendo códigos, sem lucro substancial tangível.
A Microsoft é a mais dominante e bem-sucedida favela de software que existe. O Windows não começou a receber grandes reescrições fundamentais até muito recentemente. E eles ainda não descartaram todo o código legado do kernel. Não faz sentido para os negócios, as pessoas estão mais do que dispostas a aceitar a baixa expectativa que estabeleceram na última década.
Prognóstico
Esse é um padrão há mais de 20 anos em que desenvolvo software. Não vai mudar tão cedo. Não é assim que as pessoas querem que isso aconteça em algum sistema de crenças, é uma realidade de forças externas nos negócios. Os negócios impulsionam a tomada de decisões, os lucros não são maus, eles pagam seu salário, a visão de curto ou longo prazo é irrelevante; este é um setor de curto prazo, em constante mudança por definição. Quem argumenta contra o suficientemente bom para obter lucro não entende os negócios.
Passei 15 anos consultando e aprendi rapidamente que bom o suficiente era apenas isso, qualquer outra coisa estava me custando dinheiro. Sim, eu queria que as coisas fossem perfeitas, mas, a menos que você esteja vendendo uma base de código, 99,99999% do tempo em que está vendendo uma solução , todo esse código limpo e elegante organizado é perdido e você perde seu tempo e nunca mais será reembolsado. .
Progresso e esperança
Metodologias ágeis são um bom passo na direção certa, pelo menos filosoficamente. Eles abordam o caos e as constantes mudanças como cidadãos de primeira classe e o aceitam. Eles rejeitam práticas dogmáticas, reconhecendo que as metodologias e práticas devem mudar, assim como os requisitos e tecnologias.
Eles aceitam a entropia que é introduzida pela falta de tempo ou alterações nos requisitos, mudança de equipe e vivacidade de um sistema de software com o conceito de dívida técnica.
Mas o Agile não é uma panacéia, não vai mudar as leis fundamentais da física e as bases de código apodrecerão independentemente. Cabe à gerência planejar lidar com a podridão antes que ela fique completamente fora de controle e seja incontrolável.
O Agile, quando feito corretamente, ajuda a gerenciar a entropia, reduz a velocidade, rastreia, mede e lida com ela de maneira planejada. Não vai parar!
Decisão de carreira
Se esse é um problema filosófico real para você, você provavelmente deve considerar outras opções de carreira, porque a maneira como as coisas funcionam tem mérito comercial válido por trás disso. Projetos de código aberto não têm um histórico melhor e, em muitos casos, o código é ainda pior do que a maioria dos códigos corporativos que já vi.
fonte
Não não é. É representativo do seu nível de carreira e experiência. Tudo faz parte do aprendizado sobre como as empresas trabalham a partir de uma perspectiva interna de controle de qualidade.
Suas habilidades, sua experiência e sua educação não têm impacto na qualidade do trabalho realizado por outros. Simplesmente porque você não tem autoridade para mudar essas práticas. Não importa se você era bom ou ruim na universidade. Isso não muda a maneira como a empresa em que trabalha atualmente opera. Portanto, embora seja ótimo, você tem todo esse histórico. É realmente para seu próprio benefício e não o deles. Por isso é importante estudar o que você ama.
O que aprendi nos meus muitos anos de programação é que há uma diferença entre "qualidade do código" e "código aceitável". A verdade é que alguém com autoridade encontra o código fonte em condições aceitáveis ou o considera inaceitável, mas necessário. Seria bom se todos pudéssemos limpar os projetos nos quais nos envolvemos. Geralmente, não é do interesse ou orçamento das empresas alocar recursos para esse trabalho. Argumentos lógicos podem ser feitos até o sol nascer no dia seguinte por que isso seria uma coisa boa a ser corrigida, mas quando a gerência decide que o estado atual é "aceitável", pouco pode ser feito. Está tudo diretamente relacionado a quem dirige as coisas. Ou eles valorizam a boa qualidade interna ou não. Você o valoriza claramente e, portanto, esse estado atual o incomoda.
Você encontrará exemplos desse tipo de problema em qualquer setor que dependa do controle interno de qualidade. Desde o desenvolvimento de software até a fabricação. Você precisa aprender a ver isso não como um problema, mas simplesmente como a condição atual do código fonte. É assim que é, leva X um número de minutos para encontrar algo, leva X um número de minutos para consertar algo.
A empresa ou não se importa com esse tempo extra ou considera aceitável.
Por que era aceitável você passar longas horas na universidade para estudar uma matéria, mas agora não é aceitável passar longas horas para estudar o código-fonte? Tenho certeza de que o empregador o contratou porque eles pensaram que você poderia lidar com isso.
Deixe-me dar alguns conselhos. Bons desenvolvedores sabem quando pedir ajuda aos seus colegas de equipe. Não pense que as respostas estão sempre no código. Economizei horas de tempo simplesmente fazendo algumas perguntas às pessoas. Parece que você precisa de ajuda para acelerar.
Em segundo lugar, não sabemos as condições de trabalho. Trabalhar longas horas é um fato da vida em muitos setores. Você precisa resolver por conta própria, mas posso lhe dizer. Odiar o seu trabalho nunca é um bom sinal. Você deve lidar com esse sentimento e chegar à raiz dele. Lamento que você ache essa experiência negativa.
Você estava indo muito bem na escola, mas agora tem um estágio e não está indo tão bem. Parece que você já está no mundo real. Isso faz parte da vida. A questão é: o que você vai fazer sobre isso? Que meu amigo, é a única coisa que importa. Não podemos dizer o que fazer. Você tem que se decidir.
Posso dizer-lhe que parece que sua experiência na sua idade foi muito melhor do que todas as oportunidades que tive. A vida para mim nos anos 90 foi uma luta para pagar aluguel e encontrar meu próximo contrato. Considere-se com sorte.
fonte
Após 25 anos e várias empresas e setores, posso dizer:
Sim, é bastante comum.
É por isso que os engenheiros são bem-pagos geralmente, eles precisam ser bons em encontrar bagunças e ainda fazer mudanças enquanto resistem ao desejo premente de refatorar a coisa toda e descobrir o que diabos realmente deveria ser fazendo. Eu joguei a emoção para você lá - é normal se sentir assim sobre o código que você encontra!
O código que você vê frequentemente passa por interações intermináveis de diferentes programadores, com diferentes abordagens e padrões e diferentes convenções de nomes, etc. etc.
O que acontece, porém, é que a pressão dos dólares está sempre ativa. É sempre tentador descrever como e por que um código melhor é o único caminho a longo prazo, mas em muitos trabalhos o tempo está correndo para uma solução de correção rápida a curto prazo. Leva apenas um engenheiro para destruir padrões em um projeto. É preciso um gerente muito bom que saiba como evitar isso e defender a abordagem correta (quando razoavelmente possível) para realmente abordá-la.
Uma coisa é certa, o termo 'bom código' é subjetivo demais para ser útil. Não é subjetivo para você, é claro, você pode listar os motivos / itens específicos. No entanto listar outras pessoas diferentes itens e prioridades, alguns nem mesmo técnico, que eles acham que são importantes, e, portanto, é subjetiva.
Como Drekka, isso está começando a parecer deprimente, então deixe-me tentar me tornar um pouco mais positivo, porque certamente é verdade que: -
Finalmente, como Anthony Blake aponta, sempre existem três fatores - tempo, custo e qualidade.
Eu gosto da expressão relacionada: "pick 2" !
fonte
Há muitas opiniões sobre isso, porque as experiências de todos são diferentes.
Os meus são que cerca de metade dos desenvolvedores que encontro são bem-intencionados, mas com capacidade média. Há um pequeno grupo de pessoas brilhantes no topo e um pequeno grupo no fundo que está tentando, mas basicamente deve fazer outra coisa, porque na verdade não entende. Infelizmente, há também outro pequeno grupo de tolos incompetentes que se consideram muito mais espertos do que todos os outros e geralmente estão bem na sua frente sobre como você deve segui-los.
Em termos de projeto, participei de muitos trabalhos e fui imediatamente convidado a "cuidar" de um projeto estabelecido, geralmente um que a empresa acabou de descobrir que realmente precisa depois de perder o último desenvolvedor. Normalmente, encontro exatamente o que você descreveu acima - espaguete de buggy sem documentos, com excesso de engenharia. Às vezes eu posso consertar, às vezes eu apenas começo de novo. Ele nem precisa ser um código antigo, descobri isso em novos projetos nos quais me pediram para "ajudar" também.
Você precisa se animar com o fato de a maioria das empresas oferecer aos estagiários empregos de baixa qualidade. As divertidas acontecem depois que você faz duas coisas: 1 - provou a si mesmo e 2 - teve tempo para trabalhar em outras coisas além de corrigir os erros de outras pessoas. Em outras palavras, você tem que mostrar habilidade e iniciativa.
O verdadeiro truque para lidar com códigos incorretos é descobrir o que é recuperável e o que não é. Isso vem da experiência e pesquisa.
A outra opção de carreira que você tem é parar de trabalhar para empresas estabelecidas e procurar trabalhar em startups. Portanto, não haverá código legado porcaria a ser mantido, assim você terá a chance de ajudar a criar algo melhor. A desvantagem é que a pressão a ser aplicada nos projetos de inicialização geralmente significa que atalhos e hacks são usados quando não deveriam.
Com frequência, os programadores estão dispostos a assumir dívidas de tecnologia para entregar com antecedência ou no prazo. Infelizmente, o impacto dessa dívida tecnológica é frequentemente encoberto, minimizado, ignorado ou descartado pelos desenvolvedores e pela gerência até que seja tarde demais e eles estejam com problemas.
Desculpe se isso parece deprimente. Tenho certeza que alguém pode fazer uma peça mais positiva. :-)
fonte
Há algumas ótimas respostas aqui, mas deixe-me adicionar minha parte;
Bem-vindo ao mundo real - infelizmente isso é muito comum.
Consulte o diagrama abaixo;
Com o software corporativo, você pode escolher apenas 2 ou acima e deve sacrificar um.
Como você parece ter descoberto, a maioria do mundo corporativo combina com velocidade e preço.
fonte
Não é totalmente indicativo da indústria, mas da minha experiência limitada de 5 anos ou mais. Eu trabalhava no seu estágio e tomava o máximo de lições possível com a experiência. Procure por marcas e indicadores. Por exemplo, para sua próxima posição, você sem dúvida terá que passar por uma série de entrevistas. Esse processo é uma via de mão dupla e permite que você tenha uma ideia de uma empresa. Isso é de vital importância e provavelmente levará à sua própria felicidade e bem-estar.
Para resumir, localize os sinais de contar histórias;
Então viva e aprenda e pense em seu próximo papel. Ter uma experiência ruim não é tão ruim assim, porque você terá uma melhor educação sobre o mundo do trabalho e dos negócios.
fonte
Bem, estou na minha segunda década no ramo, e posso lhe dizer que o código limpo perfeito raramente acontece e, quando isso acontece, não fica muito tempo assim. De um modo geral, você se encontrará constantemente tentando reparar os erros do passado, enquanto (infelizmente) é forçado por restrições de tempo e pouca liderança a cometer os erros do presente.
A menos que você esteja em um tipo muito específico de negócio de software, a pressão para obter um produto funcional ultrapassa todas as outras preocupações, e a otimização além de um certo ponto é considerada inútil. Se o programa for executado em 5 minutos, e só precisamos ser executados em 5 minutos, ninguém lhe dará algumas semanas para reduzir o tempo de execução para 2 minutos.
Se, por algum milagre, você tiver aquela confluência perfeita de gerenciamento competente, uma meta, dinheiro, talento e tempo claros, e produzir um produto limpo e superiour ... A única maneira de permanecer desse jeito é se você nunca tocar em de novo . A manutenção e a extensão quase sempre têm prioridade muito baixa, as alterações são sempre necessárias com efetivamente zero aviso prévio e acabam sendo excluídas erraticamente.
Eu estava pensando neste projeto ontem. Foi um sonho tão óbvio para mim que joguei um pedaço de lixo realmente minimamente funcional pela porta. Eu o via como um desperdício de tempo e recursos.
Bem, surpresa, surpresa, todo mundo adorou e funcionou bem. Então eu pulei de volta para a prancheta e fiz tudo certo. E a nova versão foi incrível! Porém, houve uma rotatividade na administração e tudo foi descartado em favor de uma "nova direção de negócios".
A segunda iteração teve uma implantação realmente meia-boca na empresa, e eu nunca ouvi outra coisa sobre isso, o que é divertido porque sei que pelo menos ~ 10 unidades de negócios ainda a estão usando (o software que estamos contratando para fazer o trabalho) está quase 2 anos atrasado) e aparentemente nunca quebra.
Isso nos leva ao meu ponto final. Mesmo que você produza algo milagroso, o fato de funcionar tão bem significa que NINGUÉM estará familiarizado com isso, e quando ele quebrar (geralmente porque eles fizeram algo estúpido), eles amaldiçoarão seu nome pior do que eles. amaldiçoar aquele idiota que escreveu aquilo que quebra toda terceira terça-feira.
fonte
É difícil dizer o que você considera um código de qualidade horrivelmente baixa, mas sim, poucos programadores são muito bons (por definição). À medida que o software evolui, as pessoas cometem erros. Com o tempo, isso aumenta e a pressão dos negócios (e a preguiça / ignorância do programador) torna a refatoração ... Incomum.
fonte
Realmente não posso falar por todos, mas aqui está o que posso dizer.
Não trabalho há mais de 30 anos no domínio, mas vi o suficiente para dizer algumas coisas. Um projeto tem uma vida parecida com um ser humano. O design inicial pode não atender às necessidades atuais de, digamos, um projeto após 20 anos de desenvolvimento. Dito isso, nesse período, muitas pessoas mudaram o código e adicionaram coisas que não deveriam ser possíveis a princípio.
Não é realmente difícil imaginar códigos feios em projetos herdados ou em projetos bastante antigos. Não podemos esperar que todos compreendam completamente os projetos iniciais. É triste, mas é assim que é.
Dito isto, você deve ter em mente que a refatoração de um projeto herdado nem sempre é possível e às vezes nem é desejada. Eu trabalhei em uma empresa onde eles estavam desenvolvendo a substituição do projeto em que eu estava trabalhando. Não me foi permitido refatorar muito meu projeto, com medo de que funcionasse melhor do que o novo projeto. Tenho certeza de que não há como esse projeto funcionar melhor do que um novo. a frase era um pouco como "Não faça melhor, apenas faça funcionar".
Eventualmente, você não terá esse tipo de projeto com frequência, como eu sempre leio e ouço. Você deve tentar encontrar trabalho com startups em vez de grandes corporações. As startups são bastante interessantes e você pode seguir em frente rapidamente, se perceber que não está indo do jeito que você quer.
Também uma coisa que você pode fazer, eu realmente não prometo nada, mas se você sentir que o código é realmente tão ruim e precisar de refatoração. Compartilhe com a equipe. Lembre-se de que as pessoas que escreveram esse código feio podem estar trabalhando com você. Não se trata de ferir o sentimento das pessoas, mas se você perceber que o projeto em que está trabalhando entrará em colapso após algum tempo e as pessoas passarão mais tempo entendendo o que fazem, em vez de melhorá-lo. É melhor falar e comunicar o problema do que mantê-lo para si mesmo. Se você tiver sorte o suficiente, poderá acabar refatorando o projeto.
Se você refatorar o projeto, poderá acabar sendo a pessoa indicada para más escolhas de design! E então você pode entender por que a refatoração não acontece com tanta frequência. Felizmente, se toda a equipe precisar refatorar, ninguém será apontado. Eles vão demitir todo mundo =)
fonte
Eu tentaria resumir a resposta a essas perguntas com uma simples citação:
All code turns to crap given enough time and hands.O resto são apenas histórias ...
fonte
A qualidade do código depende principalmente de dois fatores.
Primeiro é sempre dinheiro. As empresas com alta pressão de sobrevivência geralmente pagam salários baixos, envolvem desenvolvedores menos experientes, têm cronogramas apertados e nem tempo nem dinheiro para alavancar seus desenvolvedores.
O segundo são as pessoas. Antes de tudo, quem decide sobre orçamentos deve optar por gastar com a qualidade do código, depois precisa envolver as pessoas que desejam "vivê-lo". Como você pode imaginar, pode ser difícil converter um programador Delphi de cinquenta anos de idade bem pago (sem intenção de estereotipar, desculpe) em um desenvolvedor Java atualizado que cria o CI Builds e produz código fracamente acoplado. Muitos desenvolvedores têm aversão às lições de colegas (talvez mais jovens), eles não gostam de alguém pescando em seu lago - ou sacudindo seu trono.
Então, com isso dito, e também considerando o fato de você ter um código legado próximo a todas as empresas, eu diria que você obtém muito disso na vida real. O que você pode fazer é se comportar como um escoteiro: entre na floresta, pegue um pouco de lixo e limpe-o. Da próxima vez, você terá menos confusão para percorrer.
fonte
Bem-vindo ao código com um orçamento! Há uma grande diferença quando o desenvolvimento é impulsionado pela gerência para ser feito muito cedo, sem planejamento e com vantagens. Tive uma experiência semelhante de choque no mundo real quando consegui meu primeiro trabalho de programação na faculdade. Sem documentação! Com o tempo, aprendi muitas vezes, escrever e manter a documentação formal atualizada é apenas uma perda de tempo. Felizmente para mim, essa foi uma equipe incrível. Era liderado por um cara que sabia o que estava fazendo e os outros membros da equipe realmente se importavam em escrever o código da maneira certa. Desde então, minhas experiências têm sido semelhantes às suas. Muitos códigos horríveis, muitos códigos ruins, muitos "desenvolvedores" sem noção. Para todo bom desenvolvedor, parece haver 100 ruins.
Você não está condenado a odiar seu trabalho para sempre. Você só precisa encontrar uma empresa inteligente o suficiente para reconhecer os benefícios a longo prazo que está disposto a investir um pouco na frente. Consegui provar que fazer as coisas da maneira certa, em vez da maneira mais rápida, é benéfico e me tornei muito respeitado e confiável nas empresas em que trabalhei. Com o tempo, o código do espaguete é fixo ou fica obsoleto e seu código assume o controle. Apenas esteja preparado para se comprometer. Às vezes, a maneira mais legal ou robusta de programar algo é apenas um exagero e não há problema em fazê-lo da maneira mais rápida e suja.
fonte
Nem todas as empresas são iguais. Você encontrará equipes e bases de códigos de software ruins na maioria das empresas. Mas você também pode encontrar ótimas equipes e ótimas bases de código.
Acho que o pessoal do Solaris fez uma descrição muito boa e honesta do tipo de base de código que você encontrará em grandes empresas: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris
Não, eu codigo há mais de 15 anos e ainda o amo.
Isso não quer dizer que tudo tenha sido perfeito. Eu já vi algumas bases de código horríveis e também algumas ótimas. O truque é encontrar o lugar certo para você.
Uma grande empresa é muito diferente de uma pequena. Na mesma equipe da empresa A, às vezes, é muito diferente da equipe B. Encontre a que tem o equilíbrio certo para você (por exemplo, projetos desafiadores, uma cultura que você gosta, bom salário etc.)
Boa sorte!
fonte
Eu já vi coisas parecidas com você. Eu tenho duas experiências de casos quando isso ocorre.
É triste, mas é assim que é em alguns lugares.
Veja se você pode fazer uma pequena alteração para melhor, se acostumar ou mudar para outra empresa e pedir para exibir algum código na entrevista :-)
fonte
Essa será uma resposta curta.
A educação é muito útil para fazer você se sentir qualificado e idealista. Isso é uma coisa boa, e você deve tentar se apegar ao idealismo.
Se você tem algum objetivo e pode olhar para o seu próprio trabalho no futuro, não será uma experiência muito gratificante. A menos que você minta para si mesmo ou não aprenda nada, verá muitas maneiras de melhorar o que fez.
Em geral, o mundo inteiro está fazendo isso ao seu redor. Então, quando você olha para o trabalho do passado, com exceção das exceções, ele parecerá inferior e precisa ser aprimorado. Se você não se sente assim, significa que está fazendo o trabalho errado ou está pagando muito bem.
A boa notícia é que você pode se beneficiar dos erros dos outros e da comparação com o passado. Se todos os aplicativos funcionassem bem e fossem fáceis de manter, novos desenvolvedores não seriam necessários. Na minha opinião, manter alguns outros desenvolvedores é uma experiência de aprendizado útil e deve ser um elemento de treinamento obrigatório para todos os desenvolvedores do blue sky.
fonte
Sua experiência negativa é típica das grandes empresas de marcas conhecidas que muitos desenvolvedores aprendem a abordar com muito mais cautela e apreensão do que na primeira vez em que tiveram a oportunidade de trabalhar em uma. Basicamente, quanto mais camadas de gerenciamento você tiver, mais mediocridade será defendida. Os gerentes de nível intermediário não reportam aos gerentes de nível superior a qualidade do código. Eles relatam os recursos entregues em X por um período de tempo e fazem apresentações em powerpoint no recurso neato da interface do usuário que esperam que funcione apenas o tempo suficiente para obtê-los. Se tudo entrar em colapso um mês depois, isso geralmente é problema de outra pessoa e eles sabem disso.
Então, sim, os desenvolvedores que são levantadores nesses locais tendem a não se importar muito. Eles não poderiam sobreviver lá se sobrevivessem. Ouvi dizer do Vale do Silício que se você quiser ser preguiçoso, trabalhe para um dos grandes nomes. Se você quer um trabalho empolgante, procure uma startup mais recente que ainda não seja um nome familiar. Eu trabalho em Chicago e posso garantir um fenômeno semelhante aqui.
Como regra geral (com muitas exceções, tenho certeza), você encontrará uma maior valorização do código de qualidade em empresas menores e gerenciadas ou pertencentes a pessoas que também continuam a escrever código. A compensação é muitas vezes menor, mas o trabalho geralmente é muito mais gratificante na minha opinião.
Como desenvolvedor iniciante, é pouco provável que você tenha muito controle sobre quem trabalha, mas vou dizer que ter um grande nome em seu currículo por um ano ou mais definitivamente excita os recrutadores e o pessoal de RH. Além disso, você pode aprender bastante e, caso contrário, não aprenderia a trabalhar para alguém completamente horrível nos primeiros seis meses ou mais, além de ajudá-lo a entender melhor quais práticas realmente importam e por que e quais são apenas técnicas. modismos.
E, é claro, ao trabalhar com ferramentas corporativas populares mais populares, você tenderá a descobrir que os níveis médios de talento serão muito ruins. Se suas habilidades principais são uma combinação de Java e C #, expanda seus horizontes um pouco. Você pode encontrar um nicho mais feliz na escrita de nível intermediário Erlang ou Python ou: o JavaScript.
E não deixe ninguém lhe dizer algo diferente. Você pode não ter escolha em como proceder, mas o código de porcaria é caro!
fonte
Sua pergunta se concentrou em estágios. Eu nunca tive uma programação, mas estagiei em uma estação de rádio, que não é realmente aplicável aqui.
Sua pergunta também mencionou suas experiências durante seus estágios. Suas experiências de estágio e as respostas que você recebeu até agora resumem bastante minhas experiências, depois do que são agora 27 anos de software de escrita (iniciado em meados de junho de 1985).
Eu nunca acreditei muito durante a escola, quando nossos instrutores disseram que há mais pensamento do que realmente escrever código. Eles estavam certos. E, se você está tentando descobrir o código de outra pessoa, é pior sem comentários e quase tão ruim quanto com comentários. Tente manter um sistema municipal de cobrança de impostos, sem comentários, documentação, construção formal e controle do código-fonte.
Sempre que você puder se sair bem, sem que isso seja uma violação direta de pedidos padrão, faça-o bem. Lembre-se sempre de que é mais fácil pedir desculpas por fazer algo que você não pediu permissão do que ter permissão não concedida e ir contra uma ordem direta.
Não esqueça os padrões que você aprendeu na escola. Eles não são inúteis, mas é mais do que provável que esses padrões sejam as assíntotas nos limites do cálculo. Você sempre pode tentar abordá-los, mas nunca poderá alcançar o valor deles.
Boa sorte.
fonte