Como sugerir mudanças como funcionário recém-contratado? [fechadas]

Recentemente, fui contratado em uma grande empresa (milhares de pessoas, para ter uma idéia do tamanho). Eles disseram que me contrataram por causa do meu rigor e porque, apesar da minha juventude (tenho 25 anos), experimentei como programador de C / C ++.

Agora que estou dentro, vejo que todo o sistema é antigo e geralmente usa tecnologias obsoletas. Não existe uma convenção de nomenclatura (arquivos, funções, variáveis, ...), eles não usam o Controle de Versão, não usam exceções ou polimorfismos e parece que quase todo mundo perdeu a paixão (alguns deles têm apenas 30 anos de idade) )

Eu gostaria de sugerir algumas mudanças, mas eu não quero ser "o cara novo que quer mudar tudo só porque ele não quer se encaixar". Tentei me encaixar, mas, na verdade, leva uma semana para fazer o que faria em uma tarde, apenas por causa das ferramentas precárias que somos forçados a usar. Muitos colegas nunca olham para as novas "coisas" e técnicas que as pessoas usam hoje em dia. É como se eles tivessem desistido. A situação é realmente frustrante.

Você já esteve em uma situação semelhante e, em caso afirmativo, que conselhos você me daria? Existe uma maneira sutil de mudar as coisas sem se tornar a ovelha negra aqui? Ou devo desistir de minha paixão e energia também?

Obrigado.

Atualizações

Seguindo seus preciosos conselhos, pude sugerir mudanças e agora estou encarregado da equipe que deve criar e implantar o Subversion: D Obrigado a todos!

6 meses depois

Saí e encontrei um ambiente muito mais interessante, com salários muito melhores e desafios mais interessantes. Eu não voltaria por nada.

Eu estava em uma situação semelhante na minha empresa anterior, onde eu estava por 5 anos. Quando entrei em 2004, eles eram:

• ainda usando o Microsoft Access para seus bancos de dados (mesmo os críticos para os negócios)
• usando o Visual Basic 6 ou Access / Excel VBA para desenvolvimento
• usando muitos terceiros em vez de usar recursos de desenvolvimento internamente (os gerentes de negócios lideraram seus próprios projetos de desenvolvimento e 90% do tempo licitavam contratos sem o conhecimento da TI)
• suspiro sem controle de versão.

Quando saí no ano passado, a empresa era:

• usando .NET e C # exclusivamente
• baniu todo o desenvolvimento do Access
• usando SVN para controle de versão
• tinha 2 caixas robustas do SQL Server e estava migrando bancos de dados existentes do Access para SQL
• todo o desenvolvimento veio através das equipes internas e só foi licitado se o recurso fosse limitado

Na época, eu não fazia muito 21 anos e o próximo mais novo da equipe de desenvolvimento tinha 30 anos. Eu não fiz tudo sozinho. O gerente de TI ingressou na empresa ao mesmo tempo e queria trazer todo o desenvolvimento por meio da TI.

SVN foi minha primeira conquista. Eu tive uma reunião com meu gerente de linha e destaquei algumas situações em que o código foi colocado no ar ou alterado que causou problemas, e enfatizei o fato de que não havia responsabilidade - ele não podia culpar ninguém, basicamente - e depois disso ele começou a ouvir.

Em seguida, montei uma apresentação para a equipe e expliquei o conceito de controle de versão e demonstrei algumas situações em que o SVN poderia nos ajudar a desenvolver. Os mais novos o levaram como um pato para a água, os mais velhos não muito, mas tentaram e não se queixaram daqueles que o usavam.

Outra grande conquista foi trazer um sistema completo internamente - encabeçava um projeto que economizava US $ 120 mil por ano em licenciamento. Passei cerca de 2 meses do meu tempo livre escrevendo um novo sistema e o apresentei ao gerente de TI e expliquei a economia de custos. Ele então me permitiu apresentá-lo aos negócios e explicou como poderíamos implementar o que quisessem no sistema - não mais sendo restrito a sistemas "prontos para uso".

4 semanas depois, meu sistema estava em teste em 10 locais e 6 meses depois foi lançado. Um ano depois, eles cancelaram o contrato de terceiros, removeram todos os vestígios da rede e procuraram um grande requisito de aprimoramento em nosso sistema interno.

Meu conselho para você:

• se você se importa com a empresa, aguarde. Se outras pessoas não gostam da sua abordagem, deixe-a levar consigo - é tudo uma questão de compromisso
• Adapte sugestões à pessoa com quem você está conversando - os gerentes gostam de ouvir sobre como eles podem: a) economizar dinheiro; b) culpar com precisão as pessoas quando as coisas estão erradas; mas os desenvolvedores gostam de ouvir como podem: a) economizar tempo; por si mesmos, por exemplo
• se você é apaixonado por mudanças (o que parece ser você), mostre seu entusiasmo às pessoas e não fique desanimado quando elas estiverem menos do que entusiasmadas
• Não fale sobre fazer alterações. Faça-os. Quando você começa a produzir trabalhos fantásticos em menos tempo do que os caras mais experientes, as pessoas começam a perguntar "por quê?"

Eles disseram que me contrataram por causa do meu rigor e porque, apesar da minha juventude (tenho 25 anos), experimentei como programador de C / C ++.

Provavelmente porque você é mais barato.

Você já esteve em uma situação semelhante

Sim.

que conselhos você me daria

Sair.

Existe uma maneira sutil de mudar as coisas sem se tornar a ovelha negra aqui?

Pode ser. Introduzir mudanças e demonstrar como elas melhoram as coisas para todos. Depois de ter feito isso várias vezes, você poderá ser apreciado por aqueles que não estão perdidos.

Ou devo desistir de minha paixão e energia também?

De jeito nenhum. Você é jovem e precisa aproveitar as oportunidades. Não perca anos "em algum lugar". Olhe para esta posição e entenda se isso lhe dará uma experiência valiosa para impulsionar sua carreira ainda mais. Se você vir oportunidades, explore-as. Se não houver nenhum e for apenas "um emprego", saia. A prática mostra que aqueles que perderam a paixão (ou nunca a tiveram) não podem recuperá-la. Procure uma equipe de pessoas apaixonadas e junte-se a elas.

Lidere pelo exemplo . Mudança incrementalmente pequena no momento. Puxe um colega e mostre algo a ele. Se eles não entenderem, não se preocupe, tente novamente outra vez.

Isso levará tempo. Apenas não puxe as pessoas para longe de suas zonas de conforto muito rapidamente.

Triste, mas é por isso que você está aqui e não.

Por exemplo. Configure o controle de versão localmente e mostre a eles como ele pode ajudar. Depois, forneça a eles alguns recursos (leitura simples) que podem ajudá-lo.

Outra coisa sobre ferramentas . Às vezes você tem que gastar seu próprio dinheiro comprando ferramentas melhores. Sei que não é "a coisa feita", mas, enquanto converso com outros negócios, encontro muitos engenheiros "reais" que fazem moda / compram seus próprios conjuntos de ferramentas para fazer melhor seu trabalho. Eu sempre fiz isso onde posso ver que me salvo da atrofia das habilidades.

Eu sou um homem velho (51) e tive esse mesmo problema em todos os empregos que já tive. Talvez isso venha de sempre ser o cara mais inteligente da sala! :-) Sério, porém, quando você sabe como fazer o que é certo e ele não o faz, você costuma pensar: "Ei, mostrarei a todos essa técnica nova e aprimorada e todos ficarão impressionados e quererão entrar em ação para usá-lo. " Mas na vida real, 90% do tempo, você mostra às pessoas uma maneira melhor e elas apresentam uma longa lista de desculpas para explicar por que a maneira como elas têm feito isso o tempo todo é melhor. Quando você demonstra que os motivos deles não são válidos, eles apresentam novos motivos, mesmo que inferiores. Já tive muitas vezes que

Mesmo se você é realmente um gênio, precisa aceitar que ninguém mais sabe que você é um gênio até provar isso. Lembro-me de Kris, um amigo meu que começou um novo emprego depois de passar 10 anos em uma empresa. Logo após iniciar o novo trabalho, ele estava em uma reunião em que discutiam algum problema técnico e começou a oferecer sua solução sugerida. Então alguém interrompeu e disse: "Sim, obrigado. Bob, o que você acha?" A princípio, ele ficou irritado: sabia a resposta certa, mas ninguém se importava! Em vez disso, eles foram com a opinião de alguém que sabia muito menos do que ele. Mas então ele percebeu, ei, no meu antigo emprego, eu havia construído uma reputação de alguém que sabia do que estava falando; então, quando eu falava, as pessoas ouviam. Aqui, eu ainda não tenho uma reputação, então ninguém se importa com o que eu penso.

Estou no meu emprego atual há 2 anos e é apenas nos últimos meses que minha opinião mima começou a ter peso real. Você tem que ser paciente.

Por outro lado, as pessoas novas geralmente têm um milhão de sugestões de melhorias realmente impraticáveis, porque ainda não sabem o suficiente sobre a organização e, portanto, não sabem por que as coisas estão sendo feitas do jeito que são. Às vezes, as pessoas continuam fazendo algo da mesma maneira por 20 anos, porque é assim que sempre é feito e ninguém nunca pensou em procurar um caminho melhor; mas às vezes as pessoas continuam fazendo algo da mesma maneira por 20 anos, porque a experiência mostra que é uma boa maneira de fazê-lo e toda vez que tentam algo diferente, é um desastre. Portanto, não seja rápido demais para concluir que todas essas pessoas são idiotas. Descubra por que eles estão fazendo isso da maneira antiga antes de apresentar sua nova e brilhante sugestão. Eu tive muitas vezes na minha vida quando eu '

Encontre aliados que também querem melhorar a empresa.

Há algo a ser dito para sair agora e deixá-los apodrecer. No entanto, ficará incrível em seu currículo se você defender com êxito o controle de versão e outras melhorias.

Use o teste Joel durante suas futuras entrevistas. Lembre-se de que você está entrevistando a empresa também.

Meu primeiro conselho é não tentar mudar muito cedo. Primeiro, obtenha a reputação de um bom desenvolvedor confiável que pode fazer as coisas. No momento, como novato, tudo o que você sugere é suspeito; eles ainda não o conhecem e respeitam. Obtenha esse respeito como seu primeiro passo. Chegou a hora de começar a introduzir mudanças.

Escolha seu chão com cuidado. Comece com o controle de versão, não com novas tecnologias. Porque realmente essa é a mudança mais importante. Você pode até fazer isso apenas com o seu código e, em seguida, certifique-se de que, quando precisar reverter para uma versão anterior ou copmpare para descobrir o que mudou, deixe as pessoas saberem como foi fácil na conversa casual.

Use seu conhecimento mais atual para ser a pessoa que brilha e as pessoas começam a perguntar como você está fazendo isso. Quando os computadores chegaram ao local de trabalho, eu trabalhava para uma agência de auditoria do governo. Os idosos eram totalmente contra ter seus próprios computadores (porque isso era trabalho para as secretárias). Os juniores pegaram todos os primeiros computadores e começaram a fazer coisas que os idosos não podiam fazer com o Lotus 1-2-3 e a Harvard Graphics e, de repente, as pessoas mais velhas estavam interessadas porque seus jovens estavam chamando a atenção da gerência muito sênior.

Mudar para uma cultura organizacional não é uma questão técnica, é uma questão política. Faça algumas leituras sobre como gerenciar políticas de escritório. Você precisará de apoio político em alto nível.

Eu encontrei uma situação semelhante no meu trabalho atual. Fui contratado direto da escola para trabalhar em uma equipe formada principalmente por engenheiros que estão aqui há mais de 15 anos. Fazer alterações não foi fácil (ainda estou pressionando para que algumas coisas sejam feitas), mas é possível.

Por exemplo, minha equipe estava mantendo, atualizando e usando um utilitário de teste do DOS de 16 bits. O utilitário foi um incômodo para atualizar, porque o aplicativo levou os limites do vinculador de 16 bits a um ponto em que, se você adicionasse código, teria que remover algo mais para que ele se encaixasse. Quando perguntados por que estávamos desperdiçando tanto tempo e energia no código de 16 bits, a resposta deles foi "porque precisamos que ele seja executado no DOS para que possamos executá-lo em uma unidade flash inicializável". Tentei convencê-los a portar o utilitário para o Linux de 32 bits, mas o gerenciamento não queria investir tempo para fazê-lo (já tínhamos muito trabalho a fazer como era). Então, fui em frente e portou o utilitário no meu tempo de inatividade (15 minutos aqui e ali no almoço, nos fins de semana ou enquanto eu esperava outro código para compilar). Ao longo de alguns meses, Eu tinha o utilitário completamente portado, aprimorado com todos os tipos de coisas que o aplicativo original de 16 bits não suportava e inicializando em uma unidade flash Linux. As pessoas notaram quando eu comecei a usá-lo e comentavam como eu poderia fazer as coisas mais rapidamente e como meu utilitário gerava uma melhor saída de depuração. Logo, a gerência ouviu falar sobre isso. Depois de ver os benefícios (e o mais importante, que o trabalho já estava concluído), eles não se opunham mais à idéia.

A lição que aprendi dessa história é a seguinte: Se você acha que pode melhorar alguma coisa, converse com seu gerente sobre isso. Se eles não querem gastar os recursos com isso, faça por conta própria e prove a eles que sua ideia é válida e útil. É muito mais fácil dizer não a uma idéia que alguém propõe do que a algo que você vê à sua frente que tem um valor óbvio.

Depois que sua equipe / gerente implementar sua ideia e começar a ver seus benefícios, será muito mais provável que você ouça suas idéias no futuro. Eu usei o "credito de rua" que ganhei com a reescrita da minha ferramenta de teste para convencer minha equipe de que precisávamos abandonar nosso atual sistema de controle de versão arcaico (que permanecerá anônimo para evitar embaraços) e migrar para o Subversion. Ofereci-me para liderar o esforço de configuração / migração para ajudar a garantir que o gerenciamento o aprovasse.

É um tipo de coisa "um passo de cada vez". Provavelmente há uma tonelada de coisas que você gostaria de mudar, mas escolha algo pequeno (ish) para começar. Demonstre a qualidade de suas idéias de uma maneira que sua equipe e gerente não possam dizer "não". Assim como na sua conta stackoverflow, quanto mais boas idéias você tiver, melhor será sua reputação e mais fácil será a aceitação de suas idéias.

Definitivamente, comece a usar as ferramentas que você deseja ter localmente (onde você pode - algumas empresas também parecem controlar o que você pode instalar na sua caixa com um punho estranhamente apertado). Configure seu sistema de controle de versão favorito e comece a usá-lo. Em qualquer código que você tocar, faça pequenas alterações que tornem o código mais limpo, especialmente onde você escrever um novo código. Se eles o contrataram por seu rigor e experiência, isso significa que eles já o respeitam.

Li recentemente Contratar Ren e Stimpy e achei o exemplo de Stimpy um grande desafio. Se você seguir o exemplo dele, acabará pedindo (de maneira agradável) todos os tipos de perspectivas de seus colegas de trabalho, preparando-o para ter conhecimento que um desenvolvedor sem paixão não. Você passará algum tempo livre imaginando maneiras de fazer melhorias. Se a empresa considerar seu trabalho valioso, você se tornará inestimável. Caso contrário, você provavelmente desejará procurar emprego.

Muitas pessoas responderam com sugestões para focar em uma pequena coisa de cada vez, e várias sugeriram controle de versão. Vou dar um passo adiante: crie repositórios em sua máquina desktop e trabalhe com esses repositórios. Atualize-os regularmente de qualquer repositório principal que a empresa use. Quando (não se) houver uma crise porque alguém danificou o mestre, diga a eles que você pode cortar uma nova cópia do seu repositório pessoal.

No entanto, nunca coloque a empresa em uma máquina que você possui ou leve para casa . Porque então você pode achar que, em vez de ser um herói, está do lado errado da mesa de um advogado (na melhor das hipóteses) ou de aplicação da lei (na pior das hipóteses).

Vindo de outro desenvolvedor júnior ... você tem ótimas habilidades de pessoas? Você tem um excelente senso de autocontrole e um entendimento de quando é e não é apropriado propor uma idéia e como melhor vendê-la? Mesmo que você faça isso, você ainda pode acabar sendo "aquele cara" por dizer às outras pessoas como fazer o trabalho delas sem provar o seu valor.

É assim que AINDA construo minha credibilidade como desenvolvedor júnior: identifico um desperdício de dobras / kludge / tempo. Então eu o corrigo automatizando-o (arquivos em lote, scripts do PowerShell, programa simples, novo freeware, qualquer que seja o fim de semana) sem incomodar ninguém. Faço questão de fazer parte da minha auto-educação técnica contínua, para que eu possa pensar nisso como "dedicar horas extras para me ensinar uma coisa nova E ajudar a empresa".

Se minha correção é particularmente bacana, eu a compartilho e digo "Ei, pessoal, eu fiz essa ferramenta legal, ela automatiza XY e Z e faz outra coisa rapidamente". Mantenha seu nome nele. Repetir. Problema de credibilidade resolvido em alguns meses, se você estiver em uma alta porcentagem de artistas para seu nível, e as pessoas acima de você estarão mais abertas a suas sugestões, se você estiver pronto para explicar por que sua ideia é boa e como ela pode resolver os problemas deles.

Recentemente, pude propor novas idéias à alta gerência que foram aceitas, principalmente porque dediquei um tempo para explicar meu raciocínio, ouvir seus comentários e ter credibilidade em meus trabalhos anteriores.

ADENDO: Se o seu gerente está questionando seu comportamento ... não faça essas coisas, a menos que ele sinta que seu desempenho permanece pelo menos "top 25%", ou seja, verifique se seu chefe está feliz com você antes de começar a tentar criar todos os tipos de correções inteligentes que levam você mais alto a essa% superior, ou ele pensará que você está perdendo tempo. Se você estiver lançando novos utilitários e soluções enquanto obtém feedback positivo sobre o desempenho, mas ele ainda insistir em microgerenciar você, você pode ter um problema que está fora do escopo deste tópico.

Se misturar.

Como você disse, você não quer ser a ovelha negra. No entanto, como você (como eu) deseja adicionar algumas alterações úteis:

Agregue valor em segundo plano.

Configure o cronjobs para verificar o código das pessoas em svn / hg / git. Crie suas próprias ferramentas, no seu próprio tempo, o que pode comprovadamente melhorar os esforços de desenvolvimento. Em particular, você deseja fazer melhorias na empresa para mostrar aos idosos em seu próprio cubículo. E aqui está o porquê:

Uau fator

Se você pode dizer "Hey Alice, você sabe como Bob acabou de quebrar a compilação? Posso reverter a edição dele, e a compilação funciona novamente". E quando seu veterano disser coisas sagradas, talvez você acorde paixão suficiente neles para que eles promovam, ou pelo menos incentivem, suas novas práticas.

Aqui está o meu conselho.

Eu estava em uma situação semelhante, devo dizer primeiro, minha empresa é bem pequena, com cerca de 6 desenvolvedores, sou o tipo de programador que gosta de usar a nova tecnologia, novas ferramentas e qualquer coisa que facilite meu trabalho e produza software de melhor qualidade .

Quando comecei, estávamos usando o Visual Studio 2005, quando o VS2008 estava fora há algum tempo, mas convencer meu chefe a gastar o dinheiro com a atualização de todos os nossos desenvolvedores não era fácil, tive que trazer a ideia lentamente, pois mais um "seria bom se pudéssemos fazer isso", mas antes de levá-lo ao meu chefe, garantiria que os outros desenvolvedores fossem bons na ideia, porque seriam eles que o usariam e teriam um grupo de pessoas em favor pareceria menos uma decisão de uma pessoa.

Penso que, em vez de apenas apresentar a ideia ao seu chefe, talvez traga lentamente as possíveis mudanças, porque sinto que se você sugerir idéias que mudarão a empresa de uma maneira melhor, também mostra que você se importa com o seu trabalho e mostra que planeja em fazer uma casa lá.

Isso também dependeria do ambiente de trabalho em que você está e da personalidade de seu chefe, se eles forem descontraídos e o tratarem como uma família e seguirem conselhos, sugira-o, mas se eles o tratarem como um número, eu seria muito cuidadoso em como você se aproxima disso.

Pode ser uma oportunidade de uma vida - mudando a maneira como uma empresa trabalha aos 25 anos. Se eles resistirem e mostrarem animosidade o tempo todo, não é o lugar para você.

Lembre-se, sua entrevista foi um processo bidirecional. Você poderia sentir como eram arcaicos e resistentes à mudança.

Ps, eu tenho 25 anos também e sei como você se sente. Você provavelmente está muito mais ansioso para aprender e experimentar coisas novas do que seus colegas. Enfim, é preciso voltar a este trabalho .NET4 que estou apresentando;)

Leia Como fazer coisas quando você é apenas um grunhido por Joel Spolsky.

... às vezes você não tem o poder de criar mudanças em sua organização por decreto executivo. Obviamente, se você é apenas um programador grunhido na parte inferior do totem, não pode exatamente pedir às pessoas que comecem a criar agendas ou bancos de dados de bugs. E, de fato, mesmo se você é gerente, provavelmente descobriu que gerenciar desenvolvedores é muito parecido com pastorear gatos, mas não tão divertido. Apenas dizer "faça assim" não o faz.

Pode ser frustrante quando você está trabalhando em uma organização com baixa pontuação no The Joel Test . Não importa o quão bom seja o seu código, seus colegas de trabalho escrevem um código tão ruim que você fica constrangido por estar associado ao projeto. Ou a gerência está tomando más decisões sobre qual código escrever, então você é forçado a desperdiçar seu talento depurando a versão AS / 400 de um jogo de planejamento de aposentadoria para crianças.

... lidar com a vida em um time ruim pode ser irritante. Mas existem estratégias para melhorar sua equipe de baixo para cima, e gostaria de compartilhar algumas delas ...

Trabalhar com gerenciamento; não "desonre". Trabalhe dentro do processo e coloque as coisas em termos que as pessoas entenderão, como "implementar o svn nos ocupará espaço em um servidor, dois dias para a instalação, e precisaremos fazer backup, mas obteremos x, y, z , o que pode economizar muito dinheiro ".

Sair. Existem muitos empregos por aí. Não é seu trabalho consertar alguma empresa aleatória que o contratou. Eles gostam do jeito que são, caso contrário, eles contratariam um novo CTO ou algo assim.