Como você sabe se o conselho de um desenvolvedor sênior é ruim? [fechadas]


266

Recentemente, iniciei meu primeiro trabalho como desenvolvedor júnior e tenho um desenvolvedor mais sênior encarregado de me orientar nesta pequena empresa. No entanto, há várias vezes em que ele me aconselha sobre coisas com as quais eu simplesmente não concordo (isso vai contra o que aprendi em vários bons livros sobre o tópico escrito pelos especialistas, as perguntas que fiz em alguns sites de perguntas e respostas também concordam comigo) e, dada a nossa agenda lotada, provavelmente não temos tempo para longos debates.

Até agora, tenho tentado evitar o problema ouvindo-o, levantando um contraponto com base no que aprendi como boas práticas atuais. Ele levanta seu ponto original novamente (na maioria das vezes ele dirá as melhores práticas, mais sustentável, mas não foi além), tomo uma nota (já que ele não levantou um novo ponto para contrariar meu contraponto), pense sobre e pesquise em casa, mas não faça alterações (ainda não estou convencido). Mas, recentemente, ele se aproximou de mim mais uma vez, viu meu código e me perguntou por que não o mudei para sua sugestão. Esta é a terceira vez em 2-3 semanas.

Como desenvolvedor júnior, sei que devo respeitá-lo, mas ao mesmo tempo não consigo concordar com alguns de seus conselhos. No entanto, estou sendo pressionado a fazer mudanças que, na minha opinião, piorarão o projeto. É claro que, como desenvolvedor inexperiente, eu posso estar errado e o caminho dele pode ser melhor, pode ser um desses casos de exceção.

Minha pergunta é: o que posso fazer para avaliar melhor se o conselho de um desenvolvedor sênior é bom, ruim ou talvez bom, mas desatualizado no contexto atual? E se for ruim / desatualizado, que tática posso usar para não implementá-lo à sua maneira, apesar de suas 'pressões', mantendo o fato de que eu o respeito como mais velho?


26
Você aprende mais com erros do que sucessos.
StuperUser

45
Você pode dar um exemplo de uma das questões sobre as quais discordam? Sei que essa é mais uma questão teórica, e você provavelmente deseja evitar debates técnicos, mas seria interessante ouvir o que acabou o desacordo.
Adam Rackis 23/05

140
Eu vejo uma bandeira vermelha neste post. Você teve que ser solicitado a fazer algo três vezes. Uma vez deve ser suficiente. Se você não quer fazer algo, precisa convencer seu mentor de que não é necessário. Se você não puder fazer isso, segure o nariz e faça-o ou encontre um novo emprego.
PeterAllenWebb

6
@peterallenweb, na verdade, é ruim ser perguntado 3 vezes, independentemente da qualidade do conselho. Acho que pelos comentários aqui, tenho muito a aprender em termos de trabalho em equipes diferentes. :)
learnjourney

33
Além do que Peter disse: Considere o ponto de vista dele: você pede ao novato que faça alguma coisa, faça uma discussão técnica, não faça mais objeções e, depois de uma semana, ele descobre que ele simplesmente ignorou sua solicitação. E não é a primeira vez que isso acontece. (Não se preocupe demais - você certamente não é a primeira pessoa que sai da faculdade a cair nessa armadilha. Contanto que você conheça esses problemas e trabalhe neles, ficará bem.)
Martin

Respostas:


233

Primeiro, como desenvolvedor sênior, espero que os juniores que lidero em projetos tragam suas preocupações para mim de maneira direta e direta. Se eles discordam, está tudo bem comigo. Em alguns casos, tomarei medidas sobre suas preocupações. Na maioria dos casos, suas preocupações são deixadas de lado, com uma breve explicação do raciocínio , não por desrespeito ao desenvolvedor, mas por algum outro motivo, como:

  1. O júnior não tem todas as informações em mãos para entender a decisão como foi tomada. Em alguns casos, uma pequena explicação pode ajudar o desenvolvedor a superar a preocupação e a lidar com uma situação não-ideal.
  2. O júnior tem informações ruins. Não esqueça que você é, de fato, um júnior. Isso é o equivalente a ser adolescente em termos de software. Tenho certeza que você tem muitas ótimas idéias, mas é possível que você não saiba tudo. Acho que os desenvolvedores juniores mais resistentes são os que acreditam firmemente que sabem o que é melhor para o código, a empresa e o mundo. Esses desenvolvedores são melhor atendidos adquirindo humildade.
  3. A decisão de fazer algo de uma maneira particular foi tomada acima da cabeça do idoso. O idoso ainda trabalha para outra pessoa no final. Na verdade, pode haver uma maneira melhor de fazer algo, uma maneira mais eficiente de escrever algo ou um software / hardware melhor para ajudar a fazer o trabalho. O negócio ainda dirige as decisões. Gerentes de negócios, diretores, vice-presidentes etc. geralmente tomam decisões que impactam o processo de desenvolvimento. Eles estão fora do controle do idoso e, quando os juniores reclamam, tudo o que estão fazendo é aumentar o estresse do idoso.
  4. O idoso simplesmente não tem tempo para levar isso em consideração. Existem prazos e, às vezes, a mudança de padrões, práticas e comportamentos no meio do processo é onerosa para esse prazo. Como é o pescoço dele no bloco de desbaste, geralmente é mais importante deixar o produto funcional e pontual do que "perfeitamente escrito".

Estas são apenas as coisas que eu consigo pensar em cima da minha cabeça. Existem várias razões pelas quais uma idéia, prática, conceito pode ser descartada ou descartada por alguém mais alto que você. Muitos deles são desagradáveis, mas todos se resumem ao fato de que somos todos humanos e todos temos opiniões. A opinião dele apenas é numericamente superior à sua no momento.

Tendo esses conceitos em mente, você deve continuar trazendo suas preocupações para o desenvolvedor sênior. Encontre outro desenvolvedor sênior que possa preencher os espaços em branco. Muitos desenvolvedores seniores estão onde estão, porque são melhores com software do que com pessoas. Alguns estão onde estão, porque sabiam de quem é a bunda para beijar quando eram estagiários. Encontre alguém que realmente entenda o que significa mentorear alguém e obtenha sua opinião honesta. Eles podem discordar de você e preencher os espaços em branco que você não possui. Eles podem concordar com você e ajudar a reunir sua causa ou melhorar sua situação.

Em nenhum momento você deve montar qualquer tipo de insurreição. Mesmo se você acredita em seu coração que seu caminho é o certo, você recebeu uma instrução a seguir e deve segui-la (a menos que seja ilegal, obviamente). Se você tiver problemas para seguir essas instruções, tente descobrir o motivo, porque descobrirá que esse padrão de comportamento é muito prevalente em muitas empresas que produzem qualquer tipo de software.

Sua melhor opção é continuar fazendo seu trabalho ética e profissionalmente. Obtenha o software que você deve executar de maneira exemplar e escape da situação sendo promovido a partir dele. Se as promoções não acontecerem, você terá muitas referências e experiência para buscar oportunidades em outros departamentos ou empresas.


47
@ Joel Boa resposta, mas cuidado com as preocupações "jogando de lado". As preocupações sempre devem ser reconhecidas, mesmo que sejam inválidas, mesmo que a melhor resposta que você tenha seja "Entendo sua preocupação, mas agora precisamos fazer o X por causa de Y". A dispensa superficial de idéias sérias é um assassino moral e pode acabar destruindo até as culturas mais saudáveis.
Rein Henrichs

42
@ Joel: Muitos pontos positivos, mas isso é um pouco condescendente: "Isso é o equivalente a ser adolescente em termos de software". O respeito que um sênior ganha dos desenvolvedores juniores é conquistado ao se tomar boas decisões de maneira consistente - não pelo mero fato de idade ou antiguidade.
Neil G

26
Não chega nem perto de responder como você sabe se um desenvolvedor sênior é "bom" ou não. A resposta, como afirmada aqui, parece ser "não importa apenas fazer o que ele diz". Não estou dizendo que esse é um conselho errado; Só estou dizendo que não responde à pergunta. Pelo que vale a pena, acho que a única resposta certa é que você saberá se ele é bom em 5 anos quando você for mais velho.
Kevin

2
@ Kevin: Eu não posso discutir com esse comentário, e certamente não posso recomendar a um desenvolvedor júnior qualquer método para determinar uma maneira de responder a essa pergunta específica. Muitas vezes, os idosos não conseguem responder com precisão um sobre o outro. Minha resposta foi honestamente voltada para alguns dos outros aspectos da questão dos OPs que me pareceram mais pertinentes do que como identificar um desenvolvedor sênior de baixa qualidade.
Joel Etherton #

11
Parece que a resposta carece da humildade de que você fala. Os jovens geralmente pensam que sabem tudo, mas os idosos não compartilham o mesmo vício? Isso é exagerado em nosso setor - grande parte do conhecimento que temos será menos relevante em alguns anos. (exemplo da vida real - eu tenho um mentor em um projeto de médio porte que disse que deveríamos "criar alguns botões e escrever SQL neles, para economizar tempo". Ele ficou bastante impressionado quando eu lhe mostrei o LINQ to Entity e o asp.net página sem código )
Kobi

35

Respeite o desenvolvedor sênior. Ele está mais comprometido com o sucesso do projeto do que você. Como ele tem a responsabilidade, ele também recebe a autoridade. Se ele diz mudar alguma coisa, faça-o.

Dito isto, não hesite em apresentar suas preocupações quando encontrar um problema como você já tem.

Por fim, sente-se com ele e explique-lhe a mesma pergunta que você postou aqui. Talvez você esteja perdendo algo grande, talvez ele se abra mais às suas sugestões, de qualquer forma, não o deixe no escuro se você acha que o conselho dele é ruim.


29
OP - vocês dois são profissionais, mesmo que tenham menos experiência, então converse com ele sobre as coisas que você questiona. Se ele não está disposto a falar sobre o porquê de suas instruções, ele não é muito mentor.
DaveE 23/05

10
+1 Para "Ele está mais interessado no sucesso do projeto do que você". Quão verdadeiro é. Eu sei que vocês, desenvolvedores juniores, não apreciam a sorte que você tem por não ter esse tipo de estresse, porque eu certamente não tinha quando era desenvolvedor júnior. Agora saia do meu gramado!
maple_shaft

1
Eu também sugeriria que se / quando você seguir as sugestões dele, mantenha um documento de suas preocupações com relação à alteração - se ela ocorrer mais tarde, você poderá apontar para isso para mostrar que previu o erro.
Daenyth

4
@DaveE: Parece que eles já tiveram a discussão e o OP simplesmente não teve contexto suficiente para entender atualmente a sabedoria do idoso. Às vezes, há tanta coisa que você pode explicar que o restante precisará vir da experiência.
Martin York

2
@ Niphra: Possível. Mas, sem informações mais exatas, estou mais inclinado a acreditar que este é apenas um aprendiz ingênuo que sabe menos do que pensa. A maioria dos idosos sabe o que está fazendo (você não se torna um engenheiro sênior, se for estúpido, entra na gerência).
Martin York

24

Quando isso acontece, o que você precisa fazer é conversar com o desenvolvedor sênior . Talvez ele saiba algo que você não conhece sobre o código ou os requisitos técnicos / comerciais. Se sim, você deve aprender.

Faça isso em particular. Pode ser visto como uma autoridade desafiadora, e é melhor fazer essas coisas individualmente. Mostre vontade de comprometer e colaborar reconhecendo e respeitando sua antiguidade, mas seja persistente em obter respostas para suas perguntas. Aborde a situação de uma estrutura colaborativa, não combativa. Você pode pedir a ele para orientá-lo.

No final do dia, você precisa equilibrar suas próprias idéias (que, para ser justa, são relativamente novas e não testadas) com as dele. Talvez você esteja realmente certo, mas você deve fazer o possível para aprender com pessoas mais experientes para poder tomar uma decisão mais informada. Um bom desenvolvedor sênior congratula-se com a oportunidade de colaborar, orientar e aprender, mesmo com desenvolvedores juniores, e com o desafio de desafiar suas idéias de maneira construtiva, porque eles também sabem que às vezes estão errados.


4
+1 por ter uma conversa. O desenvolvedor sênior pode ser mais capaz (e responsável) de equilibrar preocupações diferentes, mas deve ser capaz de explicar seus motivos. Explicar-se para os juniores, para que eles possam aprender, é uma grande parte de ser um idoso. E se você, como júnior, não sente que está aprendendo, talvez seja hora de mudar de emprego.
Jaap

+1 para o melhor feito individualmente. O momento do desacordo está a portas fechadas. Quando a porta se abre e a discussão termina, não deve haver brigas, nem pensamentos nem lamentos. Não abra a porta até chegar a esse ponto. Se você ainda não concorda, diga ao idoso na cara dele que pretende elevar isso ao supervisor dele.
Michael Riley - AKA Gunny

18

A maneira como você costuma contar é através de uma abordagem de senso comum. Lembre-se de que o desenvolvedor sênior pode saber mais sobre o projeto, mas pode não saber mais sobre a maneira correta de fazer as coisas. Você tem que avaliar o que ele diz para você fazer - ele está lhe dando um mau conselho se o que ele diz foge do que afirmam seus apostadores (ou seja, pessoas mais altas que ele; não necessariamente na sua empresa ... estou falando sobre desenvolvedores conhecidos de "celebridades" que frequentemente publicam ou escrevem livros sobre a maneira correta de desenvolver software ou, pelo menos, as melhores práticas aceitas pelo setor.

Aqui está um exemplo de "maus conselhos" de um desenvolvedor sênior (ou de qualquer desenvolvedor): se eles são totalmente ignorantes sobre o que é um acoplamento solto e por que é uma coisa boa, e você é instruído a escrever todo o código, digamos, o código Por trás de um arquivo ASPX, é óbvio que o desenvolvedor sênior não tem noção e seu conselho não deve ser ouvido.

Se, por outro lado, ele está lhe dizendo como um módulo específico no sistema funciona, geralmente é melhor escutá-lo novamente, o que ele está dizendo não cuspe diante dos princípios de desenvolvimento adequados.

Aqui está minha regra de ouro: um desenvolvedor sênior de uma empresa pode simplesmente ser o desenvolvedor com maior tempo de permanência; ele pode não ter nenhuma habilidade real. Ele está dizendo coisas que vão contra o que dizem alguns dos desenvolvedores mais respeitados em seu campo (pessoas com muito mais experiência que ele e que são muito mais competentes e respeitadas)? Se ele é, é provável que o conselho dele seja ruim, a menos que haja circunstâncias muito extremas.

Esperando votos negativos / desacordos para um ponto de vista extremamente tendencioso.


Devo admitir que estou realmente chocado por ter sete votos positivos (a partir de agora) e nenhum voto negativo. Eu teria pensado que minha atitude / pessimista tom vista / ranty não teria sentado bem com as pessoas :)
Wayne Molina

No Slashdot, anunciar que você esperava ser modificado era uma técnica testada e comprovada na prostituição de carma.
Carson63000

Vou ter que tentar isso mais vezes j / k :)
Wayne Molina

11

Pode ser difícil entender o ponto de vista do desenvolvedor sênior, e sim, ele pode estar liderando as coisas no caminho errado; no entanto, quando se trata de grandes projetos, a consistência é mais importante.

Ter 50 desenvolvedores, todos seguindo seus próprios estilos de codificação, padrões, metodologias e padrões de design, seria um caos absoluto. Se as coisas estão sendo feitas errado, é sempre melhor estar sempre errado do que muitos tipos diferentes de coisas erradas e algumas que foram feitas corretamente.

Quando chega a hora de executar a manutenção, adicionar recursos ou corrigir o que está "errado", é muito mais fácil se os problemas com o design existente forem conhecidos antecipadamente.

É bom discordar respeitosamente, mas no final é melhor você se alinhar. Quem faz parte de um time que fica desonesto não é visto como um jogador de equipe.


11

Se o idoso não puder fornecer boas razões para ignorar as melhores práticas do setor, não perca seu tempo lá. Você nunca avançará porque é muito ameaçador e, de qualquer forma, deseja gastar tempo mantendo uma pilha de códigos incorretos?

A maioria dos desenvolvedores para de ler quando sai da faculdade. Você não tem, então você já está entre os 10% melhores. Atualmente, existem muitas oportunidades. Se não houver mercado de trabalho em sua cidade, procure uma cidade melhor.


9
Apenas dizer cegamente "precisamos fazer as melhores práticas do setor" pode não ser a melhor maneira de abrir uma discussão. Pode haver uma boa razão para fazer algo mais do que a maioria dos outros.

7
Eu acho que este é o mais próximo ainda de uma resposta real. Um desenvolvedor sênior deve ser capaz de fornecer razões convincentes de que os métodos que advogam são razoáveis. Você não será capaz de melhorar sob a orientação de alguém que não pode. Agora, se você se encontra na sua terceira empresa e todos os desenvolvedores seniores de todos eles eram idiotas na sua opinião, talvez seja hora de olhar mais atentamente no espelho.
PeterAllenWebb

2
@PeterAllenWebb, "deveria poder", sim, mas você não necessariamente quer discutir horas e horas detalhando detalhadamente por que achou que uma determinada prática é ruim para você. Ocasionalmente, "por quê?" Pode ser respondido com "Porque!"

@ Thorbjørn Ravn Andersen: Concordo, desde que seja ocasional.
PeterAllenWebb

11

Uau, é uma oportunidade maravilhosa para você brilhar e mostrar suas habilidades. No início de minha carreira, eu tinha alguém que era meu supervisor, incapaz de tomar uma decisão, qualquer decisão, então aproveitei a oportunidade para aprender a fazer o trabalho do próximo nível superior. Isso me promoveu. Você deveria fazer o mesmo.


Agradeço seu pensamento, mas tenho medo do futuro e é especulativo, pois pode haver situações mais difíceis, nas quais a postagem em fóruns pode não ajudar. O que devo fazer então?
developer123

4
Mergulhe nos livros e aprenda em profundidade. A Internet não é a única maneira de aprender. Participe de um grupo de desenvolvedores local e faça contatos com pessoas mais seniores que você pode orientar.
HLGEM

essa é boa.
developer123

9

Como desenvolvedor sênior, esse tipo de nitidez agressiva passiva me deixaria louca e, depois de confrontar, você me levaria a fazer uma crítica ruim. A solução perfeita é aquela com a qual a equipe pode conviver.

Quanto ao estilo, isso deve ser determinado pelo guia de estilo e pelas melhores práticas determinadas pela sua origem. Se você é apaixonado, discuta, mas uma vez tomada a decisão, viva com ela e trabalhe dentro dos limites da equipe em que está.


6
Como desenvolvedor júnior, esse tipo de ditadura me deixaria louca. Eu votei para baixo, desculpe.
Kizzx2

9

Você está em uma situação não tão boa, mas, como HLGEM apontou, pode transformar essas posições em bênçãos disfarçadas. Sua pergunta é multifacetada, então abordarei em partes.

Eu suspeito, ele não sabe. Ao mesmo tempo, ele tenta me mostrar arrogância, para que eu não apareça muito com ele para perguntas.

Isso poderia muito bem ser verdade. Há uma série de desenvolvedores que estão no setor há décadas e não são líderes de software capazes - do ponto de vista de desenvolvimento ou orientação (há uma diferença). A experiência vem do enfrentamento de novos desafios, da tentativa de novas idéias e do aprendizado de novas habilidades, mas a maioria dos programadores passa a vida em uma ala do The Corporate Office, trabalhando no The Payroll Application com suas fiéis ferramentas Visual Basic e Java, nunca vendo o mundo correr pelo escritório frio e cinza.

Não há nada de errado nisso . Para muitos desenvolvedores, tudo o que eles sempre quiseram e estão perfeitamente contentes com a situação - não é, no entanto, uma situação ideal para promover uma futura geração de programadores, muito menos liderar desenvolvedores.

A bravura e a arrogância podem ser um mecanismo de defesa, tentando encobrir inadequações. Como você lida com isso? Não o enfrente de frente - se sua liderança é incompetente e o chefe não está disposto a corrigir a situação, você terá que conviver com ela . Isso não significa rolar e morrer, mas você não pode forçar alguém a ser uma boa liderança.

No entanto, ele apenas analisa meu código e a maioria dos comentários está relacionada a diretrizes de codificação

É isso que me faz pensar que você está certo, pois ele pode não ser um bom programador. Isso não quer dizer que ele não seja um programador melhor do que você no momento (pelo menos ele terá mais experiência e exposição por estar na indústria por tanto tempo), mas, novamente, isso não se traduz em um chumbo eficaz. As diretrizes são boas e boas, mas são secundárias à função, eficácia e eficiência do código.

O que devo fazer em tal situação?

Informei meu gerente sobre essa situação e solicitei que ele mudasse de posição, embora ele diga sim sempre, mas ele não toma nenhuma ação séria.

Você enumerou todos esses pontos específicos para o gerente e com exemplos específicos para fazer o backup? Se você simplesmente foi até ele e disse: "Preciso de uma nova pista", ele não levará você a sério e a perceberá como um "problema interpessoal", e não um problema técnico. A reação de muitos chefes nessa situação é ignorá-la na esperança de que "se resolva".

Aqui estão algumas sugestões.

  1. Não se irrite com a sua situação - o teste de fogo, embora não seja divertido, ensina algumas habilidades críticas de pesquisa para mais tarde em sua carreira.
  2. Comece a empurrar sua liderança para se envolver mais. Faça isso com cuidado e respeito . Continue pressionando e seja persistente até que ele desista (isso realmente funciona para muitas situações da vida).
  3. Se o seu lead não se envolver, verifique se há outros que possam ajudá-lo. A menos que você esteja trabalhando em uma loja de suor que se preocupe apenas com as horas de ordenha, sua empresa não se importará com outro desenvolvedor com mais experiência em mostrar algumas dicas e revisar seu código.
  4. Comece a ficar de olho em um novo emprego. Eu não diria que você está em uma situação "deve sair", mas não faria mal à sua carreira estar em um lugar que leva o seu desenvolvimento como programador mais a sério.

Muito obrigado, seus pontos são realmente agradáveis ​​e atenciosos. Voto a favor para você
developer123

Obrigado, selecionei sua resposta, pois combina o melhor.
developer123

7

Se você tem uma maneira melhor de resolver um problema específico, basta fazê-lo .

Deixe seu código / solução ser seu melhor argumento. Caso contrário, atenha-se ao que foi informado.

Caso em questão

quando eu era júnior, tive uma situação em que uma seção específica do código não era a melhor possível. Em vez de apenas debater sobre isso, simplesmente a melhorei. ENTÃO mostrei os resultados ao meu mais velho. Ele aceitou, porque o código é sempre rei.


11
@maple_shaft: que tipo de equipe você é se o código (e todos os que o mantêm) sofrem para proteger os sentimentos dos desenvolvedores seniores?
Jaap

1
@ Jaap, Antes de tudo, estou falando de um líder técnico ou de projeto, isso não precisa necessariamente ser um desenvolvedor sênior. Em segundo lugar, não se trata de sentimentos, mas de avançar em direção a um objetivo comum como grupo. O líder deve ter alguma aparência de controle sobre seu grupo, independentemente de estar errado. O líder é quem assume a responsabilidade pelo código de bugs, características incompletas e prazos perdidos; portanto, se ele for um tolo, sofrerá. Se a empresa não reconhecer que ele é um tolo, ela sofrerá.
maple_shaft

2
Se ele já foi instruído a alterá-lo, falhou na revisão do código. Apenas tentar reenviar significa que ele será informado de que isso já falhou.
Martin York

2
@ Darknight, supondo que este não seja um problema minúsculo, mudar paradigmas em uma base de código existente pode ter sérias reprecussões. O que vem à mente quando penso sobre esse tipo de debate é a estrutura do banco de dados. Mudanças como essa certamente não serão apreciadas.
Morgan Herlocker 23/05

1
Isso se aplica apenas a unidades de trabalho muito pequenas. Digamos que você trabalhou por duas semanas e o código foi rejeitado - como você obterá financiamento para essas duas semanas?

7

É claro que, como desenvolvedor inexperiente, posso estar errado e o jeito dele pode ser melhor, então minha pergunta é como posso fazer para julgar melhor se um conselho de desenvolvedor sênior é bom ou ruim / desatualizado.

Você pode se tornar um desenvolvedor experiente. Enquanto não fizer isso, você estará mal equipado para julgar se sua intuição como júnior estava certa ou não e, a essa altura, não terá importância.

Enquanto isso, leia a resposta de Joel Etherton.


7

Eu sugeriria fortemente não tentar "não implementá-lo à sua maneira".

Até agora, parece que você fez a coisa certa. Você foi humilde e levantou um contraponto. Não pude dizer da sua pergunta se você simplesmente discordou do método dele ou se discordou e apresentou uma alternativa. No final das contas, sempre ofereça uma alternativa clara e pensada ao tentar abater a abordagem de outra pessoa . Como ele pode ver, você tem uma boa ideia que pode funcionar, e ele tem uma ideia que funciona.

Em qualquer posição, somos forçados a fazer coisas abaixo do ideal o tempo todo. Se você realmente não gosta, pode fazer o que quiser e trazer à tona. Depois disso, é o caminho do chefe ou a estrada. No lado positivo, você está isolado de muito do risco de más decisões quando júnior.


6

Escolha suas batalhas. Se você estiver falando de uma hora de trabalho, precisará alterar seu código algumas vezes até que você avance. Da próxima vez que você conseguir um grande projeto, peça uma chance de apresentar suas idéias antes de começar. Reserve um tempo extra e faça uma demonstração ou protótipo incrível.


4

Surpreendentemente, o que fiz foi parar de perguntar. Quando é dada outra opção, eu simplesmente discordo e faço da maneira dele, mas adiciono meu próprio toque a ela. Use-o como uma experiência de aprendizado para desenvolver suas habilidades e ainda assim pacificar sua necessidade de mantê-lo à moda antiga.

No final, nem todo desenvolvedor sênior presta atenção a novas maneiras de fazer as coisas. Às vezes, eles têm maneiras antigas que eram ótimas para o idioma em que começaram há 20 anos, mas são consideradas hacky ou "têm um mau cheiro" no mundo de hoje.

Isso pode parecer uma maneira terrível de continuar, e é. Mas também aprendi muito com minha maneira de fazer as coisas com idosos. Mas esta é realmente apenas a minha opinião. No final, você precisa ser feliz em seu trabalho e manter as distrações e a tensão em um nível baixo. E, ao não se opor às coisas, você verá o estresse diminuir.


3

Não confie nos idosos por causa da antiguidade. Desafie a autoridade o mais rápido possível. Uma autoridade competente deve poder responder de forma convincente a qualquer pergunta. É isso que faz dele uma autoridade em primeiro lugar, não é?

Porque alguém mantém crenças supersticiosas por toda a vida não significa que ele esteja certo. Lembre-se de que, na idade média, as pessoas acreditavam que a Terra era plana e algumas dessas pessoas idiotas se sentiam justificadas em matar os que duvidavam. Aconteceu que os que duvidavam estavam certos. Tanto por críticas ruins.

Nunca tema uma crítica ruim. Você confiaria em um cego julgando a cor?


5
A maioria dos gerentes não terá muita paciência para um desenvolvedor júnior que desafia tudo. Se a sua, sacrifique uma galinha em homenagem a Cthulhu, porque você encontrou um ótimo chefe! Caso contrário, esteja preparado para comprar muito até encontrar um.

2

boas respostas acima, acrescentaria que uma resposta como "melhores práticas" ou "mais sustentável" é uma oportunidade para aprender alguma coisa . Você diz: "Você pode me dar um exemplo de por que esse caminho é melhor para que eu possa entender a diferença?" ou "Em que situações dessa maneira seria mais sustentável que de alguma outra maneira, para que eu possa aprender a planejar dessa maneira?"

Se o idoso estiver certo, será fácil dar um exemplo. Se ele é um papagaio ... dê a ele um biscoito para parar de chiar e faça o que achar melhor. Até que seja ordenado o contrário.

Se o papel do sênior for mentor, ele explicará o porquê quando solicitado.


2

Como HLGEM e Jarrod disseram antes, isso é realmente uma bênção disfarçada. Ambas as respostas são ótimas e quero acrescentar alguns pontos.

Como seu lead não está em seu domínio, você toma algumas das decisões importantes para sua parte do aplicativo, pois ele não conhece muito sobre middleware. Você também encerra com seu gerente sobre como o aplicativo deve ser, o que os usuários do produto desejam e como o gerente deseja lidar com uma situação apresentada a ele pela equipe de produto. Diga-me quantas pessoas obterão esse tipo de conhecimento em um aplicativo.

Quando você está em uma equipe grande, com certeza terá a ajuda de seus colegas de equipe e / ou de seu líder, mas não terá o conhecimento de como seu gerente pensa ou a equipe de produto pensa, porque esse tipo de coisa geralmente passa por sua liderança e pode ser alguns desenvolvedores seniores em uma equipe. Concordo que os projetos de uma pessoa são difíceis de realizar, mas se o outro lado da moeda é tão bom, por que perder uma chance? Aprenda o que você pode aprender, aproveite o quanto puder e, se ficar muito difícil, convencer seu gerente, como Jarrod disse, ou encontrar um novo emprego / projeto, dependendo da situação.


Obrigado a você, HLGEM e Jarrod, por apontar as partes positivas.
developer123

1

Você vai lidar com pessoas assim durante toda a sua carreira. E haverá muitos com quem você discordará sobre a melhor abordagem para qualquer problema de codificação. A melhor coisa que acho que funcionou para mim ao longo dos anos é que, se eles continuarem pressionando um problema, seja sincero com eles e diga que você considerou a solução deles entre as várias soluções possíveis e que sentiu que a solução era sua. resolvido foi o que você achou que era a melhor abordagem nessa situação.

Agora, se você escolher sempre os conselhos deles, ocasionalmente poderá ceder e usar os "conselhos" de vez em quando apenas para suavizar algumas plumas. Contanto que eles não sintam que você está rejeitando a entrada deles todas as vezes, isso ajudará bastante a manter a paz entre vocês.

Considere também que eles são um desenvolvedor sênior e trabalham nesse ambiente há mais tempo do que você. A codificação da vida real geralmente não combina com as melhores práticas ou padrões aceitos pela comunidade. Pode haver uma razão pela qual eles recomendaram que você faça algo de uma certa maneira que eles não consigam articular completamente. Portanto, mesmo que você não concorde com eles, não deixe de lado o conselho deles com base no fato de que você acredita que sua solução é melhor.

É tudo uma questão de equilíbrio. E não apenas o equilíbrio da codificação, mas o equilíbrio da equipe. Muitos projetos falharam não porque os desenvolvedores não foram capazes de fazê-lo, mas porque não conseguiram encontrar maneiras de trabalhar em conjunto de forma amigável.


1

Gostaria de fornecer algumas informações da minha experiência pessoal, que devem ser consideradas como uma resposta suplementar a uma postada aqui por jzd ...

  1. Pergunte a outro desenvolvedor sênior,
  2. Pesquise por conta própria.

Em uma consulta profissional, eu deveria ser orientado por alguém mais velho. Ele sabia algumas coisas, mas sinceramente não tanto, infelizmente ele não sabia, então estava ultra confiante em suas respostas. De alguma forma, senti que o que ele disse estava errado. Eu tinha algumas evidências de quando as coisas que ele fez foram contra as melhores práticas mencionadas na certificação da MS que tirei :-). Depois disso, comecei a perguntar a outras pessoas que trabalhavam em outras empresas (o stackexchange não estava funcionando naquela época) e comecei a ler blogs para comparar respostas.

Seria ótimo se eu estivesse errado, porque eu apenas mudaria meu comportamento, mas não estava.


5
Quase nunca existe uma razão válida para ignorar as melhores práticas do setor, exceto a ignorância e / ou a falta de vontade de fazê-lo corretamente. Eles são "melhores" práticas por um motivo, e as pessoas que os criam são dez vezes mais inteligentes e até mais seniores do que o desenvolvedor sênior que as ignora ou não as conhece.
Wayne Molina

@Wayne M: Bem dito.
Jim G.

6
@Wayne, você ainda precisa entender por que elas são práticas recomendadas. Se você diz cegamente "esta é uma prática recomendada, precisamos fazer isso!" sem saber por que, você não é melhor.

Eu diria que Wayne deixou espaço suficiente em sua resposta à refutação de Andersen.
C Johnson

@ Thorbjørn Ravn Andersen, @learnjourney - De todos os comentários e respostas, o comentário de Thorbjørn é provavelmente o conselho mais crítico e relevante. Você deve entender os problemas que uma determinada prática recomendada estava tentando impedir ou resolver, caso contrário você nunca saberá se esses problemas ainda se aplicam. Em resumo, você deve entender por que é uma prática recomendada. É assim que você sugere alternativas: esclarecendo os problemas resolvidos pelas melhores práticas. Como o merovíngio da Matrix disse: "Sem" Por que "você não tem nada".
28511 Thomas

1

Eu notei algo nos últimos anos, quase todas as empresas em que estou, quase todos os projetos em que trabalho, quase todos os novos contratados (independentemente do nível de habilidade / experiência) querem fazer algo 'diferente'.

Pode ser os padrões de codificação ou a arquitetura geral ou a linguagem ou a metodologia. Mas é sempre alguma coisa. Muitas vezes, está apenas afirmando o óbvio: 'Não deveria tudo ser melhor documentado para nossos usuários finais?'

Meu conselho para você é não ser esse cara .

Algum dia, você será um cara de nível sênior, contratado e pago para tomar essas decisões. Quando esse dia chegar, vá para ele! Até aquele dia, perceba qual é a sua posição. Eu tenho um chefe, no que me diz respeito, todo o meu trabalho é fazer meu chefe feliz. Não é para adivinhar as decisões tomadas fora da minha folha de pagamento. Se você realmente não tem certeza, converse com seu chefe / supervisor e descubra.

De um modo geral, porém, é muito melhor ter todos a bordo com uma abordagem desatualizada do que metade da equipe seguindo a abordagem desatualizada, 1/4 da equipe seguindo alguma nova abordagem e 1/4 da equipe tentando desenvolver uma abordagem de ponta , abordagem totalmente nova.


17
-1: Eu tenho um chefe, no que me diz respeito, todo o meu trabalho é fazer meu chefe feliz. Não é para adivinhar as decisões tomadas fora da minha folha de pagamento. : Você nunca vai trabalhar para mim. Eu não contratei 'Yes Men'. Quero que meus subordinados diretos ofereçam críticas construtivas quando estou prestes a tomar uma decisão subótima. Se eu não valorizasse a opinião deles, não os teria contratado em primeiro lugar.
Jim G.

7
Eu discordo deste sentimento. Primeiro, se você deseja ser promovido, deve mostrar que é capaz e disposto a assumir as responsabilidades de um cargo sênior; portanto, nesse aspecto, manter a cabeça baixa não é bom para sua carreira de longo prazo. Segundo, não acredito na abordagem 'acima da minha remuneração' para o trabalho. Todo mundo está lá para tornar a empresa bem-sucedida (se não for, você não tem mais um emprego); portanto, se você vê uma maneira melhor de fazer qualquer coisa, acima da sua classificação salarial ou não, você deve salientar. Às vezes, um novo contratado pode fazer boas sugestões porque tem uma nova perspectiva.
Cercerilla

6
Tem que concordar com @ Jim G. Ter a atitude de ser um "Smithers" é a pior coisa que você pode fazer; Achar que seu gerente está sempre certo é uma coisa terrível, porque muitas vezes eles não estão certos. Também concordo com @CodeninjaTim - uma nova contratação, muitas vezes tem melhores sugestões, porque eles não têm a mesma opinião que os caras a longo prazo tem, por isso eles são menos propensos a basta seguir o "status quo"
Wayne Molina

4
@ Jim G: Parece que o OP já levantou sua preocupação "Esta é a terceira vez em duas a três semanas". - Não posso imaginar que você gostaria de empregar alguém que, depois de expressar sua opinião e ser explicado que A é melhor que B (mesmo que ele discorde), ele se recusa a fazer a mudança. Nesse ponto, ele realmente não está 'trabalhando para você'.
Rob P.

3
@Wayne M - Não estou defendendo que acreditamos que nossos gerentes estão sempre certos. Sugeri levantar suas preocupações de maneira apropriada. Mas, depois de ser instruído a fazer algo 3 vezes durante o período de algumas semanas, o OP não está lidando com isso corretamente. Por todos os meios, manifeste suas preocupações, mas perceba que você está EMPREGADO (a menos que não esteja - então ignore isso). Você concordou em trabalhar para outra pessoa em troca de algum nível de compensação. O fato de você ter um chefe implica uma expectativa de que você faz o que lhe é dito, dentro do razoável. Certo ou errado, isso é o que você se inscreveu para como um empregado
Rob P.

1

Há uma subcorrente em tudo isso que acho que deve ser explicitada: não seja combativo . Preserve seu relacionamento com ele. É ótimo seguir o conselho dele com um pouco de sal e validá-lo em livros e em sites como esses, mas não o ataque. Se ele é um desenvolvedor sênior e já passou por muitos projetos, ele não é um idiota, e há muito a aprender com ele. Como parece que você já fez, expresse seu desejo de entender o ponto de vista dele. Mesmo que você tenha certeza de que ele está errado e que você esteja certo, aceite a possibilidade do oposto (parece que você já entende isso). Tente deixar claro que você está discutindo porque quer entender melhor o ponto de vista dele, não porque está tentando provar que ele está errado.

Se ele não responder imediatamente quando você fizer uma pergunta, ou se a resposta dele for vaga e / ou inútil, não pense que ele está te dispensando. Como já foi mencionado aqui, ele pode muito bem estar ocupado e / ou estressado.

Também é ótimo ser paciente. Mantenha uma lista de coisas em sua cabeça que você acha que deveriam ser feitas de maneira diferente e apresente-as no momento apropriado. Verifique se você tem justificativa para a sugestão, além de "é uma prática recomendada". E tome cuidado para fazer as coisas certas e não cometer erros, para que você tenha credibilidade quando argumentar mais tarde.


1

Até agora, eu tenho tentado evitar o problema ouvindo-o, levantando um contra-ponto, ele levanta seu ponto original novamente (na maioria das vezes ele dirá melhores práticas, mais sustentável, mas não foi além), I. .. pense nisso em casa, mas ... ainda não estou convencido. Mas recentemente ele ... viu meu código e me perguntou por que não o mudei para sua sugestão. Esta é a terceira vez em 2-3 semanas.

(Levemente editado para as ações.)

Esta parte me preocupa. Uma maneira de ver se você está correto ou não é entender o que ele está dizendo. O que eu li (com minha própria história, outras podem ser diferentes) é um desenvolvedor júnior que não entende o que o mentor está dizendo e não pede esclarecimentos. Uma maneira de descobrir isso é pedir que ele esclareça: como isso é uma prática melhor do que isso? Ou Por que isso é mais sustentável do que o nosso código? Se você não sabe as respostas para isso, não sabe se ele está dando bons conselhos ou não.

A parte que realmente me preocupa é que ele pediu para você mudar isso várias vezes, e você não. Aqui está uma maneira de parecer do lado dele: ele pede que você faça a alteração, você pergunta por que, ele fornece uma razão (válida, na sua opinião) e você se recusa a fazer a alteração. Você não pede esclarecimentos, então ele assume que você entende o motivo e é preguiçoso ou teimoso demais para mudar isso - nada bom para um desenvolvedor sênior pensar em você. Confie em mim, é muito melhor fazer perguntas do que obter uma reputação dessa maneira.


Pedi esclarecimentos, mas a resposta que sempre recebi é 'é uma prática melhor' ou algo parecido antes que ele voltasse para fazer suas próprias coisas. É uma coisa na minha opinião dizer que é uma prática boa ou melhor, mas o que eu queria saber é 'por que' é melhor, o que ele não foi capaz de me explicar, mas insistir é melhor e já que ele é mais velho , Eu deveria confiar nele. Ainda assim, é ruim da minha parte não mudar, apesar de ter sido questionado 3 vezes sobre isso.
learnjourney

@learnjourney: Concordo que provavelmente haverá um problema se você estiver perguntando o porquê e não obtendo respostas. Eu ainda recomendo que você fique ciente do que pode parecer do outro lado, mas se esse desenvolvedor sênior não puder ajudá-lo, encontre outro e coloque o problema diante deles, com apenas o básico ", disse ele. você pode explicar como isso se aplica aqui? "e sem recriminação. Se isso não funcionar, procurarei algumas das outras respostas que dizem para fazer a alteração de qualquer maneira, mas mantenha sua versão e os motivos à mão. Certifique-se de aprender com isso de qualquer maneira.
Caleb Huitt # cjhuitt

1

Algumas reflexões:

1 / Funciona? O jeito dele está funcionando ou não? Existe alguma razão objetiva pela qual seu caminho seria inferior?

Por razão objetiva, quero dizer algo que pode ser medido sem ambiguidade (desempenho, bugs, comprimento do código ...) Se as soluções dele funcionarem e não houver uma métrica objetiva que indique que é uma solução ruim, faça do seu jeito. O caminho dele é melhor ... porque provavelmente é mais consistente com o restante da base de código e porque será mais fácil para ele usar / reutilizar seu trabalho. Você pode não gostar, mas não é disso que se trata, é?

Se não funcionar, ou apresentar um desempenho ruim em métricas importantes, implemente-o, compare a solução dele com a sua e diga a ele que você tentou o seu caminho, mas não consegue obter um bom desempenho (forneça as métricas) e pergunte a ele se você cometeu um erro na sua implementação ou se há um requisito de que você não estava ciente

Os programadores 2 / Star dizem ... Por que se importar? Você encontrará programadores famosos profundamente em desacordo uns com os outros em muitos assuntos fundamentais, como planejamento, design, POO versus procedimento, teste de unidade, tratamento de exceções, controle de origem e assim por diante.

Se a única diferença de trabalhabilidade entre duas soluções é quem a favor, ignore-a. Você pode se beneficiar do treino mental exigido trabalhando em um paradigma de que não gosta


1

Com base na idéia de que você só deve seguir conselhos de pessoas com quem deseja se tornar, a resposta é que o conselho sênior é bom se você quiser se tornar como ele / ela.


1

Eu resolvi a maioria dos meus problemas postando em fóruns e obtendo respostas de outras pessoas, e tenho sobrevivido por cerca de um ano como este.

O que devo fazer em tal situação?

Para ser honesto, é assim que muitos trabalhos técnicos são. Você precisa ser um iniciante, capaz de resolver problemas difíceis sozinho (com a ajuda da Internet e de seus habitantes), se necessário.

Do ponto de vista de obter revisões de código e obter ajuda com projetos de arquitetura, mesmo quando tive bons gerentes, nunca tive muita revisão de código além de "variáveis ​​estáticas devem ter o prefixo s_".

Aproveite a oportunidade para aprender e aprender a aprender; essas serão habilidades que você poderá usar no futuro.


Sim, é a única coisa otimista que vejo na minha situação.
developer123

1

Se você pensa por um segundo que a gerência não entende o quão capaz você REALMENTE é de realizar o trabalho, provavelmente está errado. A gerência provavelmente também entende que sua liderança agora seria completamente inútil se ele a substituísse e assumisse o seu trabalho.

As REAIS razões pelas quais eles não foram realocados são porque, apesar de todos os desafios que você apresenta a eles, você ainda é a melhor pessoa para o trabalho. Obviamente, eles valorizam demais o seu trabalho, arriscando entregá-lo a mais alguém.

Não subestime a inteligência da gerência ...

Eles são muito mais inteligentes do que a maioria dos desenvolvedores lhes dá crédito. Eu não entendi isso até começar a gerenciar. Eles provavelmente também estão cientes de quão inútil é sua liderança, mas provavelmente não têm poder para resolver esse problema.

Deixe-me pintar uma imagem para você, o lead A com 5 anos de experiência na empresa é incompetente. O gerente sabe disso e recomenda ao seu gerente superior que demitir a liderança A. O gerente superior pergunta por que ele não foi tratado há anos se ele é tão incompetente. O gerente parece ruim agora, especialmente porque o Lead A tem um salário inchado que estava sendo pago sem nenhum benefício ...

Aqui está outro cenário potencial: o lead A é amigo íntimo de alguém importante. Ele é quente demais politicamente para assumir,

De qualquer maneira, com um erro de longa duração como esse, é mais fácil para as grandes organizações varrer pessoas incompetentes para debaixo do tapete, dar-lhes trabalho ocupado e poder falso, adequado aos seus anos de "experiência" em que não podem causar MUITO dano. . Infelizmente, muitas organizações preferem fazer isso a lidar com os problemas.

É claro que a razão para isso é que o gerente desse tipo de organização é sempre melhor no curto prazo para lidar com o talento ruim dessa maneira do que tratar dos problemas de longo prazo que esse tipo de pessoa pode trazer para a organização.

Portanto, embora seja míope e potencialmente antiético, você deve admitir que é um pouco mais inteligente do que muitos desenvolvedores realmente dão crédito.


Obrigado pela resposta e por trazer o lado administrativo do pensamento e seus pontos de vista. Voto a favor para você
developer123

0

ughh ahhh. Esta pergunta me lembra muitas coisas. Primeiro, vou dizer que não poderia me dar bem com um dos gerentes no meu último local de trabalho. Não era um problema de personalidade. Foi um problema de comunicação. Eu disse XYZ e esse gerente específico interromperia o que eu estava dizendo como ABC. Eu não seria capaz de me comunicar bem, a menos que trabalhasse com esse gerente por mais de um ano.

Nessa semana passada. Um cara discutiu / discordou de singletons. Eu disse que eles não são bons e NUNCA devem ser usados ​​e absolutamente não há razão para usá-los. Eu o vinculei a http://www.gmannickg.com/?p=24 e o artigo mais aprofundado vinculado aalguns dias após a discussão. O dia de outro programador (DudeB) menciona que ele só usa singletons quando apropriado (ao qual acrescentei 'nunca'). O DudeB não disse nada sobre isso, mas o DudeB disse que o DudeB estava em um projeto que continha memória, porque todos os threads estavam acessando o singleton. Depois de mencionar isso, mostrar o artigo e mencionar a contenção de memória, o cara com quem discuti disse que teríamos que concordar em discordar do que eu concordei porque não gosto de falar sobre singletons (ainda estou escrevendo isso)

O ponto é. Às vezes você pode estar errado como esse cara (talvez alguém discorde de singletons comigo em um comentário). Na minha situação com meu gerente, que era meu programador sênior, acabei de fazer o que me pediram explicitamente e nunca mais levei a sério a qualidade naquele local de trabalho. Eu fiz o que eu prefiro fazer quando permitido, mas sempre fiz o que me pediam, mas se eu discordasse, eu o mencionaria pelo menos uma vez.


1
Re: "talvez alguém vai discordar sobre singletons com me em um comentário" - eu discordo de você; o) Mas vamos concordar em discordar
JW01

0

Eu tenho uma opinião completamente diferente / controversa sobre isso.

Muitas vezes, as pessoas perdem a noção do objetivo final que, para a maioria das indústrias, é maximizar lucros e minimizar perdas. Eu sei que isso soa insensível (daí os pontos negativos), mas a experiência e a sagacidade são muito pequenas se você não estiver produzindo resultados.

As pessoas podem se envolver com coisas extremamente indiretas para discutir sobre o assunto, que têm muito pouco impacto nos resultados diretos da empresa.

Se você acha que está certo sobre algo, sua melhor aposta é mostrar como isso produzirá melhores resultados mensuráveis .


-1: Tão ridículo. // O cerne da sua opinião "controversa" repousa no fato de que o OP está envolvido em minúcias ou trivialidade. Você não sabe disso! Tome a pergunta pelo valor nominal.
Jim G.

A maioria das programações é minuciosa Jim G. E por experiência (eu sou desenvolvedor sênior), existem muitas outras BS envolvidas em estar certo . Quase sempre há uma imagem maior. E as pessoas de cima respondem a um quadro maior (veja a atualização), não para "mas meu design está mais dissociado". Como o OP não deu um exemplo, tive que tomar algumas liberdades.
Adam Gent

0

Inicialmente, eu tentaria insistir, no final do dia a resistência ao idoso provavelmente será inútil pelo menos até você ganhar mais experiência e respeito. Use isso como uma experiência de aprendizado e em mais de 2 anos se você ainda se sentir da mesma maneira - vá para outra empresa. É nesse momento que você pode usar uma combinação das suas boas idéias e dos idosos para impressionar seu novo empregador. É claro que você pode começar a perceber algumas das razões pelas quais considerou más decisões no início de sua carreira e, em algum momento, poderá ter um desenvolvedor júnior trabalhando para você.


5
-1: Por que perder mais de 2 anos trabalhando para um n00b sênior?
Jim G.

@ Jim - mudar de emprego após 6 meses não fica bem no seu currículo. Se você se mudar para outro lugar e o idoso for ainda pior, o efeito no seu CV é exponencialmente ruim! Você também pode aprender a perceber que nem tudo o que eles disseram estava incorreto ou pelo menos havia uma razão para fazê-lo dessa maneira.
Matt Wilko 24/05

1
@ Jim - Enquanto eu concordo na prática, Matt tem razão; as pessoas são estúpidas e estão constantemente tentando encontrar um ambiente adequado para machucá-lo (posso falar por experiência própria). Depende exatamente de qual é o conselho, se ele não é o ideal (por exemplo, não podemos fazer TDD ou usar um contêiner de IoC) ou completamente errado (por exemplo, eu não sei o que é uma interface ou por que você usaria uma em programação). O primeiro é alright "ficar fora", este último é onde você fugir gritando porque o idoso é um idiota (Eu espero que eu tenho esses termos certo .. eles sempre me confundir)
Wayne Molina

0

[Repost: porque de alguma forma eu criei uma segunda conta aqui]

Mas, recentemente, ele se aproximou de mim mais uma vez, viu meu código e me perguntou por que não o mudei para sua sugestão .

Você deve ter certeza se são sugestões ou pedidos / instruções / diretivas / o que for.

Sugestão = Eu acho que é melhor fazer dessa maneira; mas a escolha é sua.

Ordem / etc. = Eu quero que seja feito assim; e é minha escolha.

Se for realmente uma sugestão, faça o que quiser e deixe seu código em pé. Se for uma ordem (e esse mentor tiver autoridade sobre você dessa maneira) - faça o que eles mandarem.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.