Inspirando um colega de trabalho a adotar melhores práticas de codificação?

24

Na pergunta Como lidar com meus colegas de trabalho antiquados , várias pessoas discutiram estratégias para lidar com colegas de trabalho que não desejam integrar seu fluxo de trabalho ao da equipe.

Eu gostaria, se possível, de aprender algumas estratégias para "ensinar" um colega de trabalho que é apenas ignorante das técnicas e ferramentas modernas, e possivelmente um pouco apático.

Comecei a trabalhar com um programador que, até recentemente, trabalhava em relativo isolamento, em uma parte diferente da empresa. Ele possui amplo conhecimento de domínio e, mais importante, demonstrou boas habilidades para resolver problemas , algo que muitos candidatos parecem não ter.

No entanto, o código (C #) real que eu vi é um retrocesso para os dias do VB6. Estrutura processual, notação húngara, variáveis ​​globais (abuso de static), sem interfaces, sem testes, não uso de genéricos, jogando System.Exception... você entendeu.

Esse programador é um pouco mais velho do que eu e, pelo menos pelas primeiras impressões, não busca ativamente mudanças positivas. Não vou dizer que é resistente à mudança, porque acho que é em grande parte uma questão de como o tópico é abordado e quero estar preparado.

Os programadores tendem a ser pessoas teimosas, e entrar com armas em punho e instituir análises de código rip-it-to-shreds e políticas rigorosamente aplicadas provavelmente não produzirá o resultado final que eu quero. Se fosse um novo contratado, um programador júnior, eu não pensaria duas vezes antes de adotar uma postura de "mentor", mas sou extremamente cauteloso ao tratar um funcionário experiente como um novato sem noção (o que ele não é - ele simplesmente não acompanhou certos avanços no campo).

Como posso elevar o padrão de qualidade de código desse desenvolvedor da maneira Dale Carnegie, por meio de persuasão suave e incentivos não materiais? Qual seria a melhor estratégia para efetuar mudanças sutis e graduais, sem criar uma situação adversa?

Outras pessoas - especialmente desenvolvedores líderes - já passaram por esse tipo de situação? Quais estratégias foram bem-sucedidas em estimular o interesse e criar uma dinâmica de grupo positiva? Quais estratégias não foram bem-sucedidas e seria melhor evitar?


Esclarecimentos:

Eu realmente sinto que várias pessoas estão respondendo com base em sentimentos pessoais sem realmente ler todos os detalhes da pergunta. Observe o seguinte, que deveria estar implícito, mas agora estou explicitando:

  • Este colega de trabalho é apenas meu "mais velho" em virtude da idade. Eu nunca disse que seu título, esfera de influência ou anos na organização excedem os meus e, de fato, nenhuma dessas coisas é verdadeira. Ele é um programador de LOB que foi absorvido pela principal loja de desenvolvimento. É isso aí.

  • Não sou um novo contratado, programador júnior ou outro idiota ingênuo com grandes planos de transformar a empresa da noite para o dia. Eu sou basicamente responsável pelo processo do software, mas, como muitos que trabalharam como "leads" sabem, as responsabilidades nem sempre se correlacionam com precisão com o organograma.

  • Estou não pedir às pessoas como fazer do meu jeito, venha o inferno ou água alta . Eu poderia fazer isso se quisesse, com o resultado líquido sendo que essa pessoa ficaria ressentida e / ou desistir. Por favor, tente entender que estou procurando um método social e cooperativo de promover mudanças.

  • A menção de "... variáveis ​​globais ... sem testes ... jogando System.Exception" teve como objetivo demonstrar que os problemas não são apenas superficiais ou estéticos . Práticas que podem funcionar para aplicativos CRUD relativamente pequenos não funcionam necessariamente para aplicativos corporativos grandes e, de fato, nenhum dos códigos até agora passou nos testes de integração.

Por favor, tente aceitar a pergunta pelo valor de face, aceite que eu realmente sei do que estou falando e responda à pergunta que realmente perguntei ou siga em frente.

PS: Minha mais sincera gratidão àqueles que - ofereceram conselhos construtivos em vez de discutir com a premissa. Vou deixar isso em aberto por mais algum tempo, pois espero ouvir mais no caminho das experiências do mundo real.

Aaronaught
fonte
9
Eu já estive nessa situação e nunca vi isso realmente resolvido com sucesso. Muitas pessoas, como você descreveu, deixaram de pensar em programação anos atrás; neste momento, eles estão interessados ​​apenas em soluções para o domínio de negócios. Não vou me juntar às bandwagons deste site que condenam essas pessoas; na verdade, eu acho que eles são o sal da terra. Se eles estiverem trabalhando no seu código, você deve pressionar pelo menos para que suas convenções sejam respeitadas. Não tive dificuldade em vender que as pessoas seguissem as convenções existentes se elas contribuíssem para um projeto.
Jeremy
11
O que seu chefe disse quando você levantou essa preocupação com ele?
2
@Aaronaught, já que o código dele funciona, este não é um problema técnico, mas político, e provavelmente um que precisa ser imposto de cima, se você quiser mudar alguma coisa. Em outras palavras, do seu chefe. Tenha bons argumentos prontos!
2
@ Thor: Então você acha que é absolutamente impossível que o estilo dele seja simplesmente o produto de baixas expectativas, nenhuma revisão por pares e uma vida agitada que não se presta bem ao aprendizado independente durante o seu tempo pessoal? Não se importar não é um traço de personalidade, é um produto do ambiente e pode ser alterado. Não saber é ainda mais fácil mudar, mas ainda precisa ser abordado com algum nível de diplomacia.
Aaronaught
11
@Aaronaught, ou você falhou miseravelmente em ser uma inspiração (que não pode ser descartada) ou ele não quer ser inspirado. Você consideraria codificar seus testes de unidade em Lisp ou Haskell se houvesse um colega mais jovem dizendo que isso é muito mais inteligente do que o que você faz agora?

Respostas:

10

O ponto de partida é conhecer o seu público . Parece que você já entendeu isso porque sabe a diferença entre orientar um colega de trabalho júnior e influenciar um colega de trabalho sênior.

Você ainda precisa descobrir o que motivará esse indivíduo em particular. O que funciona em um velhote antigo (como eu) pode não funcionar no seu velhote antigo.

Se ele gosta de orientar / ensinar outras pessoas, você pode abordar um problema fazendo perguntas como "por que você faz dessa maneira?" Isso pode gerar um diálogo em que você pode pedir que ele avalie abordagens mais recentes e dê sua opinião.

Se isso não funcionar, você pode apontar erros que podem ser evitados usando as práticas ou estilos que você gostaria que ele adotasse. Isso requer muito mais trabalho, porque você precisa encontrar os bugs e mostrar como os comportamentos que você deseja incentivar ajudariam.

Se ele parece disposto a ajudar os outros, você pode apelar ao desejo dele de ajudar os novatos . Explique que "as crianças de hoje" não estão acostumadas a ver seu estilo de codificação e terão mais probabilidade de quebrar seu código por causa disso.

Às vezes, você pode ter que entrar na cara dele e forçar o problema. Você precisa escolher essas batalhas com cuidado. Certifique-se de começar com um tópico em que saiba que pode provar a ele que você tem uma maneira melhor.

jimreed
fonte
Essas parecem algumas boas estratégias gerais. Devo deixar claro que isso tem apenas o VB6, e não o COBOL. Talvez 5-7 anos atrás, não 20-30 anos. Portanto, não um velhote / dinossauro.
Aaronaught
11
Eu não perguntaria "Por que você faz dessa maneira?" Isso pode ter um efeito adverso - colocando-o na defensiva imediatamente. Pode ser que o colega simplesmente não saiba e você não queira que ele se sinta ignorante. Em vez disso, pergunte "você já considerou esse método?"
iAbstract
@IAbstract Se ele gosta de ensinar, não fica na defensiva, ele terá a oportunidade de ensinar. Tom e atitude farão uma grande diferença. Se parece que você pode adicionar facilmente "Idiota" no final da pergunta, não está fazendo certo? :-) Na minha experiência, a maioria das pessoas está disposta a responder perguntas sinceras.
11111 jimreed
@IAbstract: Tenho certeza de que, se perguntasse algo como "você considerou a injeção de dependência aqui?" a resposta seria "hein?" É claro que há uma chance de eu ficar agradavelmente surpreendido, mas acho que jim está certo, é melhor começar a perguntar "o que fez você decidir usar um Fooobjeto de escopo global aqui?" Não prevejo que seja interpretado como um ataque; sou eu tentando entender o design existente.
Aaronaught
@Aaronaught: justo o suficiente;) Embora a reação ao DI possa ser "hein?", Poderia desencadear uma conversa interessante como "bem, eu já ouvi falar disso, mas ..." ... minha preocupação é principalmente o tom (como jimreed aponta) Certamente, como diz jimreed, você deve escolher suas batalhas - às vezes significa carregar um graveto, outras vezes, brincar juntos na caixa de areia.
iAbstract
4

Eu acho que você tem a atitude certa. Apenas certifique-se de apontar todas as coisas legais que você já disse - Ótimas habilidades para resolver problemas, compreensão do negócio, etc. e apenas peça um pouco do seu tempo para mostrar os padrões atuais de que o grupo é. usando e dê a ele a chance de fazer algumas perguntas sobre eles.

Quando você se reunir, traga-lhe um café ou algo assim, e deixe-o saber que trabalhar com os padrões o beneficiará, facilitando o suporte ao código existente e facilitando a ajuda de alguém, caso ele fica coberto de trabalho (uma grande vantagem para alguém que trabalha isoladamente) etc.

Certifique-se de que ele esteja noivo e obtenha boas explicações sobre por que você faz as coisas que você faz e não se concentre em por que ele não deve fazer as coisas que ele estava fazendo. Posicione-se disponível posteriormente, se ele tiver alguma dúvida e acompanhamento com alguns lugares aos quais ele pode se referir para obter exemplos de seus padrões.

Se ele não estiver interessado depois disso, você pode consultar a primeira pergunta que você vinculou.

DKnight
fonte
4

É realmente o trabalho do seu gerente

  1. Perceba que a empresa deve ter um padrão de codificação. Toda empresa um tanto profissional tem isso, não importa o tamanho da empresa.
  2. Faça com que todos se sentem juntos e comecem a elaborar um padrão. Dessa forma, todos podem dar a sua opinião e ficarão mais motivados a seguir o padrão.

Se o seu gerente não perceber isso sozinho, ele não estará qualificado para o trabalho. E se sim, você deve dar alguns empurrões acima dos dois acima. As vantagens de ter um padrão de codificação são muitas, não há realmente nenhum argumento contra ter um. (Se alguns programadores sentem que são "artistas" e não devem ser restringidos pelos limites do profissionalismo, eles devem conseguir um emprego fazendo artes plásticas.)

O padrão de codificação em si deve, em primeiro lugar, concentrar-se na proibição de práticas perigosas e funções perigosas da biblioteca. Trabalhe em direção a um subconjunto mais seguro e puro do idioma que você está usando. Mantenha o padrão de codificação livre de "estilo de codificação", porque o estilo de codificação é muito mais difícil de concordar e não é tão importante. É bastante clássico que uma empresa decida estabelecer um padrão de codificação e, em seguida, imediatamente fique presa em uma discussão sem sentido sobre onde colocar os aparelhos.

Para referência, confira como os padrões MISRA-C / C ++ e CERT C / C ++ / Java são gravados.


fonte
Isso está assumindo (incorreto) que eu trabalho para um editor de software com uma estrutura vertical. Menos de 10% dos desenvolvedores trabalhar para editores de software e é não necessariamente a responsabilidade de um gerente executivo ou média para micromanage os desenvolvedores.
Aaronaught
2
@ Aaronaught Bem, então essa é a verdadeira fonte do seu problema. Se você não está em uma equipe com um padrão de codificação e pelo menos um programador veterano para liderar e orientar os outros, essa é uma organização ruim. Todos irão codificar aleatoriamente, pensando que são "artistas", apresentando resultados medíocres, instáveis ​​e insustentáveis, e não aprendendo a melhorar.
2

Antes de tudo, você precisa esclarecer POR QUE deseja mudar o modo de trabalhar dessa pessoa. Se for apenas por razões estéticas, acho que você deveria reconsiderar, porque essa pessoa demonstrou que sua maneira de trabalhar realmente funciona.

Se, no entanto, houver uma razão técnica para isso, considere abordar a pessoa com algo como:

Eu tenho uma sugestão de como você pode economizar tempo tedioso para você e dinheiro para a empresa. Você está interessado?

Esteja ciente de que essas frutas devem ser baixas, porque provavelmente exigirão mudanças nos hábitos existentes, que sempre exigem esforço extra.

Mesmo se você tiver gazilhões de sugestões, basta escolher uma ou duas e demonstrar que será uma mudança para melhor.

Ou isso funcionará e você será perguntado se tem mais sugestões ou não, e o dano será limitado a uma ou duas sugestões.

Observe que é muito importante que ele se torne um sucesso e o faça rapidamente.

Além disso, você precisa ter cuidado. Pode haver muito boas razões para fazer as coisas do jeito que elas são feitas, mas que você é muito novo para ter visto o porquê. Portanto, seja respeitoso com seu ancião e pergunte antes de assumir que sua sugestão é melhor. Você pode aprender uma coisa ou duas.

Aaronaught
fonte
Obrigado pela resposta construtiva - embora eu ache que poderia ter acontecido sem o primeiro parágrafo.
Aaronaught
@ Aaronaught, desculpe, mas é realmente muito importante.
Não, não é realmente importante. Está respondendo a uma pergunta completamente diferente e já forneci vários comentários e edições esclarecedoras para indicar que não é relevante. A incapacidade dos usuários neste site (e principalmente apenas neste site) de separar a pergunta "Devo" de "Como faço" é prejudicial à qualidade e coerência gerais do discurso aqui. Sua ressalva é válida, mas irrelevante e um pouco ofensiva. Há até uma meta questão muito votada sobre esse tópico exato.
Aaronaught
11
@aaronaught, a única razão para você querer mudar esse estilo de codificação das pessoas é porque é diferente do resto da equipe e, em seguida, você declara implicitamente o estilo dele, afirmando implicitamente que o seu é melhor. Daí o meu comentário. Se você não puder aceitar o estilo de codificação atual em sua base de código, faça uma reunião pessoal com ele e diga isso, e você está disposto a fazer um grande esforço para ajudá-lo a aprender como você deve ser o código dele.
11
@Aaronaught, para alguém que poderia ter passado sem o primeiro parágrafo, considero sua escolha surpreendentemente ofensiva. Você acha que chamar os outros de patéticos é um exemplo a seguir?
1

Gostaria de desencorajá-lo severamente de ficar na cara dele, pois isso faria com que a situação piorasse muito rapidamente. Sei que foi levantado como um tipo de medida de último recurso, mas, na minha experiência, neste momento, o desenvolvedor parou de participar funcionalmente.

Forçar a questão pode transformar o indivíduo em um inimigo, onde eles estão lutando com todas as suas ações. Isso realmente teria um impacto negativo na equipe e não terminará até que alguém saia ou seja demitido.

Se esse indivíduo realmente tiver conhecimento de domínio que você precisa / deseja, peça que ele documente esse conhecimento.

Ken Brittain
fonte
11
-1 A questão já afirma que o OP não tem intenção de abordar isso de maneira confrontadora. Leia a pergunta do OP minuciosamente e responda a essa pergunta específica , em vez de discutir o tópico em geral.
HedgeMage 01/07
1

Começando com isso para ele gentilmente: eu não sei o quão experiente e quão bem você é versado em dar feedback. Você já pode saber, empregar ou até mesmo ter rejeitado o seguinte, mas aqui vai mesmo assim. Existem algumas diretrizes para fornecer feedback quando você deseja alterar o comportamento de alguém. A estrutura de conversação em que estive pensando e ainda tento empregar em situações em que quero dar feedback (porque funcionam) são as seguintes:

  1. Descreva o comportamento que você vê. Esse deve ser um comportamento concreto. Exemplo: "Vejo que você está usando muitas variáveis ​​estáticas no seu código"
  2. Descreva como isso afeta você / sua equipe. Exemplo: "Acho difícil manter esse código"
  3. Ofereça uma solução razoável . (as possíveis soluções são mencionadas em outras respostas, e depois eu me refiro a algumas delas).
  4. Dê a ele a oportunidade de discutir a solução. Pergunte a ele o que ele pensa sobre a solução. Tome a resposta dele pelo valor nominal. Você deu a ele sua opinião e ele é livre para aceitar ou não. *

Um recurso rápido sobre feedback pode ser encontrado, por exemplo, em http://managementhelp.org/communicationsskills/feedback.htm (embora exista uma pletória desse tipo de coisa na web)

Agora, na parte da solução, pelo que estou lendo em sua resposta, entendo que ele é muito inteligente e tem a mentalidade certa, mas está apenas atrasado nas boas práticas modernas. Isso exige tempo e esforço para dominar, além do aprendizado real sobre eles, para que você tenha a oportunidade de fazê-lo. Isso provavelmente significa reunir recursos de aprendizado (web, revista, livros, o que for) como ponto de partida e fornecer tempo livre para estudá-los. Eu poderia imaginar dar a ele toda sexta-feira à tarde para ampliar seus horizontes no estilo de programação, onde ele pode fazer o que achar que é mais favorável a esses objetivos. As pessoas, inerentemente, querem melhorar a si mesmas. Forneça os materiais e o tempo, e eles farão bom uso dele.

Possivelmente o mais importante, não espere mudanças da noite para o dia. Ele está fazendo as coisas do seu jeito há muito tempo e provavelmente ficou muito bom nisso. Vai levar algum tempo para melhorar a maneira de fazer as coisas, e por um tempo, ele provavelmente não verá muito valor de novas maneiras, porque no começo não há. Seu jeito antigo provavelmente será mais eficaz por um tempo.

* Nota: o engraçado das conversas é que elas são muito difíceis de modelar. Eles têm vida própria, portanto, embora pareça agradável no papel, tende a ficar um pouco confuso.

Martijn
fonte
0

Explique como você deseja que as coisas sejam feitas e mostre a ele como ele funciona com as escolhas de design e arquitetura que você fez para o projeto no início do projeto em que ele trabalhará. Sente-se um a um (e em particular) e explique os problemas que você viu na codificação anterior e por que eles são um problema para este projeto. Pergunte a ele o que ele precisa para melhorar, mas deixe claro que não melhorar não é uma opção.

Em seguida, use a revisão de código como uma ferramenta para fazer com que ele ajuste seus métodos de trabalho. Planeje um bom tempo para o primeiro e fale realmente sobre por que você prefere isso e deixe que ele explique seu raciocínio. Certifique-se de realmente ouvi-lo, as pessoas são mais ameaçadoras de mudar quando sentem que suas preocupações foram tratadas. Espere em seu planejamento (mas não diga isso a ele) que tenha uma reformulação na primeira tarefa e não a aceite até que atenda aos padrões de sua equipe. Uma vez que ele saiba o que você espera e que você não deixará isso escapar no interesse do tempo, ele provavelmente voltará ao seu modo de trabalhar. Mas você pode usar a revisão de código como uma ferramenta educacional para várias iterações. Você não precisa ser desagradável por não aceitar o trabalho até que ele atenda aos seus padrões, mas precisa ser firme e consistente. Don '

HLGEM
fonte
-1

A pergunta de US $ 64.000 é se ele está entregando seus projetos dentro do prazo e atendendo aos requisitos de funcionalidade. Se assim for, ele está fazendo certo. Não existe um objetivo objetivo ou um caminho errado no desenvolvimento de software. Em última análise, trata-se de resolver problemas. E se os problemas forem resolvidos para a satisfação do cliente / cliente, então, por definição , o desenvolvimento de software será feito corretamente.

Torna-se uma questão totalmente diferente, é claro, se seus projetos não estiverem sendo concluídos. Nesse ponto, as mudanças precisam ser feitas por seus supervisores, talvez com a sua contribuição. Mas só porque ele está violando seu senso pessoal de estética do código ou a sabedoria convencional de hoje não significa que o que ele está fazendo está "errado". Você não é o árbitro da definição de 'bom código'. Afinal, ele pode ter uma opinião baixa do seu código.

Então ... a menos que haja realmente um problema com o trabalho dele (que você não indicou que exista), não faça nada. Parte de ser um desenvolvedor de sucesso é aprender a mesclar seu código com os estilos de outros desenvolvedores.

Afinal, ele poderia vir aqui e postar uma pergunta semelhante sobre como lidar com um desenvolvedor menos experiente, que está mais preocupado em acompanhar os modismos do que em concluir projetos. É tudo sobre perspectiva.

GrandmasterB
fonte
2
Foi por esse motivo que apontei que ele vem de uma parte diferente da empresa. Ele não teve nenhum problema em atender aos requisitos deles , mas os requisitos deles não são nossos . Especificamente, seus requisitos não foram muito mais avançados que o CRUD. E sim, há é um problema com o código; pode funcionar bem isoladamente, mas não passa nos testes de integração, desempenho ou confiabilidade. Não acredito em metodologias rígidas como XP ou TDD ou o que seja, mas isso não é uma questão de estética ou sabedoria convencional, é uma questão de requisitos de manutenção.
Aaronaught 01/07/19
3
Também estou com o voto negativo não pelas razões acima, mas porque você está fazendo várias suposições injustificadas. (a) não sou menos experiente, (b) nada do que estou falando é justificadamente chamado de "moda" e (c) essa é a suposição mais ridiculamente ridícula - ele não é o desenvolvedor mais produtivo de a equipe e certamente não é mais produtivo do que eu.
Aaronaught
Se há realmente um problema com o que ele produz, então, como eu disse , é um problema para o seu supervisor ou para quem quer que seja o seu supervisor em comum. Mas você não demonstrou que há um problema com o que ele entrega ao cliente, apenas que você não gosta do que ele entrega a você. Qual é o meu ponto, ele não está escrevendo software para você. Então, antes de você causar um rebuliço, eu tenho certeza de que ele não é menos dispensável que você.
GrandmasterB
Quanto aos modismos, fique na indústria por um tempo e você perceberá que sim, as práticas recomendadas de hoje são amanhã práticas ruins no estilo VB6. Quanto à votação, certamente, fique à vontade. Estou apenas respondendo à pergunta como postada. Não posso responder aos detalhes que você não forneceu.
GrandmasterB
11
Não conheço o seu currículo nem os seus colegas de trabalho. Eu só sei o que você colocou na pergunta. Se era uma informação importante, você deveria ter incluído. E, com base nas suas respostas a outras respostas, você pode considerar que ficou um pouco de fora, exigindo, portanto, muitas suposições por parte dos respondentes. Mas se você quiser uma resposta, supondo que você não seja o supervisor dele, o problema é do seu supervisor ou do seu supervisor mútuo, para se preocupar em não causar confusão. Apenas rejeite o código que está causando um problema no teste e relate qual é o problema ao seu colega de trabalho.
GrandmasterB
-1

Como desenvolvedor júnior, conversando com um desenvolvedor sênior, é muito arriscado para você tentar abordá-lo com idéias melhores que as dele.

A melhor maneira de lidar com isso é tentar convencer seu chefe de uma melhor prática e ver se ele fará um decreto de que todo o código deve seguir padrões específicos e ser aplicado a esses padrões através de análises de código por pares.

Uma parcela considerável das pessoas é (mesmo que em um nível subconsciente) vingativa, egoísta e defensiva, mesmo que desconheça completamente seus motivos subconscientes, elas se ofenderão se você tentar alterá-las ou implicar que elas estão erradas. de qualquer forma.

A Cadeia de Comando é o caminho mais seguro a seguir, porque ele tem que ouvir seu chefe, nem precisa gostar dele. Deixe o chefe ser o cara mau, é para isso que ele está lá.

Se você não pode vender o chefe ou ele é o chefe, lide com os erros dele, mas dê o exemplo no SEU código.

maple_shaft
fonte
11
Isso está respondendo a uma pergunta completamente diferente da que eu fiz. (a) eu não sou um desenvolvedor júnior, (b) meu chefe já delega a maioria das decisões importantes de design e código para mim, (c) seu código não é conhecido por ser buggy, apenas não está bem estruturado para o POO do C # / paradigma misto funcional e (d) a essência da minha pergunta era como abordar o assunto de tal maneira que ele não se ofenda.
Aaronaught 01/07/19
11
@Aaronaught, a) "Este programador é um pouco mais velho do que eu", assumi a partir desta afirmação que você é o "júnior" dele. b) Parece que você é o líder técnico então, você deveria ter colocado essa informação em sua pergunta, isso muda as coisas consideravelmente. c) Se ele não está seguindo as práticas recomendadas e seu código não está com erros, qual é o problema? Por que abordá-lo sobre alguma coisa? Não conserte o que não está quebrado. d) Novamente, não se aproxime dele se ele não estiver causando bugs com código de baixa qualidade. A verdadeira questão é que você não possui padrões de codificação e desenvolvimento que todos devem cumprir.
Maple_shaft
Eu pensei que isso estava claramente implícito na minha referência a (não) "entrar com armas de fogo e instituir revisões de código rip-it-to-shreds e políticas estritamente aplicadas" - por que eu mencionaria isso se eu fosse um júnior ? E quem disse que não temos padrões? Ele nunca trabalhou com nossa equipe antes e estou tentando introduzir os padrões sem ser um babaca .
Aaronaught
-1 Não respondeu à pergunta.
HedgeMage 01/07
-1

Você não pode.

Você não pode inspirar as pessoas a fazer coisas que elas não conhecem no desenvolvimento de software. Falo por experiência própria, pois tentei fazer isso com frequência em minha carreira, e toda vez que o resultado final é que meu próprio status diminui aos olhos da empresa; Até fui demitido ou parei de frustração depois que nada aconteceu, simplesmente por tentar melhorar a cultura de desenvolvimento ao meu redor para as práticas modernas.

Se o seu colega de trabalho não fosse ignorante, você poderia mostrá-lo. Como eles são, no entanto, não há nada que você possa fazer, pois eles não são capazes nem se preocupam o suficiente com o software como habilidade para se esforçar para adotar melhores práticas de codificação. As chances são de que, se você tentar, elas o ignoram ou se esquivam sem entender realmente, o que, pelo que parece, é o que eles já estão fazendo ("Desenvolvimento de Tentativas e Erros", ou seja, apenas pesquisando o código até que os erros parem) .

Wayne Molina
fonte
4
Agradeço a resposta, no entanto, acho isso difícil de acreditar principalmente porque eu era exatamente esse tipo de programador "apenas faça isso" há vários anos. Ninguém me mostrou - eu tive que descobrir tudo sozinho - mas tenho certeza de que um líder suficientemente persuasivo (se existisse) teria sido capaz de efetuar a mesma mudança. Só porque algumas pessoas aprendem tudo isso de forma independente não significa necessariamente que todo mundo é uma causa perdida.
Aaronaught
2
Isso é verdade, mas, na minha experiência, se as pessoas se preocupam em melhorar, elas precisam de pouca motivação para se inspirarem, porque o desejo já existe - elas podem precisar de uma cutucada ou conselho, mas entendem e querem melhorar, só precisam de orientação. Eu era da mesma maneira; Aprendi maneiras ruins de fazer as coisas e pensei "Tem que haver uma maneira melhor" e comecei a pesquisar. O que eu vi, porém, é que as pessoas que não melhoram ou demonstram desejo de melhorar são causas perdidas porque não querem melhorar. Dito isto, melhor sorte em provar me :) errado
Wayne Molina
11
Eu acho que esse é o tipo de afirmação que precisa ser substanciada. Eu certamente estaria interessado em ouvir (e mais disposto a votar) algumas experiências do mundo real, com relação ao que você tentou sem sucesso (e por que não deu certo).
Aaronaught
11
Às vezes, isso é verdade, por exemplo, " cachorro velho, truques novos " - tente explicar a alguém como as técnicas aumentaram a eficiência da recuperação de dados em 800% e o colega apenas encolhe os ombros.
iAbstract
2
O ponto é que você pode fazer isso e as pessoas o seguirão, mas precisará ter uma classificação mais alta na hierarquia. Você não pode fazer isso como um desenvolvedor simples na maioria das equipes. Muitos colegas só podem receber conselhos não solicitados de alguém mais alto na hierarquia. Se você estiver no mesmo nível, eles se sentirão magoados e atacados. Lembre-se de que o respeito é conquistado. Se você os tratar bem e se comunicar de maneira agradável e agradável, poderá funcionar, se você também estiver no mesmo nível.
Falcon