“Mentor” um programador sênior ou colega sem insultar

36

Eu não tenho grandes habilidades sociais. Como muitos programadores que conheço, as habilidades sociais são algo que é trabalhado e desenvolvido com o tempo, porque não é um traço natural e "inato".

Quando um computador está fazendo algo errado, você pode informá-lo e 'corrigi-lo' para que ele funcione corretamente da próxima vez.

Não vai reclamar. Não vai se sentir insultado. Na verdade, tenho a tendência de pensar que é "mais feliz" porque não está se desfazendo num beco sem saída.

Acho muito mais complicado trabalhar com outros programadores no nível ou acima do meu nível, de modo a permitir que eles trabalhem melhor mais rápido sem parecerem condescendentes, insultantes ou com o "sabe-tudo" do grupo.

Eu sei que alguns programadores olham para isto objetivamente e simplesmente dizem: "Já que é para o bem do grupo eu os informarei, e se eles forem insultados, isso é problema deles". Este não é um método ruim - todos os programadores com os quais trabalhei tomam e agem de acordo com as críticas. É quando eles estão tendo um mau dia / semana / mês / ano / vida que eu acho difícil abordá-los sem uma reação emocional reativa.

Eu realmente gosto de trabalhar com aqueles que me rodeiam, e não quero desenvolver sangue ruim.

  • Que habilidades, técnicas e até mesmo fora das atividades de trabalho você dedica para que você seja um suporte e um recurso sem a tensão que pode ser criada nessas situações?

  • Ou, em outras palavras, como você orienta alguém sem parecer que os orienta?

Suponho que a pergunta também pode / deve ser invertida - como você se mantém "aberto" e aprende de tal forma que não assusta as pessoas que têm informações úteis para você? Como você se mantém no topo das habilidades para que o último graduado da faculdade não seja necessariamente melhor que você em termos de padrões de design, tecnologia, fluxo de trabalho, etc?

    
por Adam Davis 15.12.2008 / 20:14
fonte

20 respostas

59
Pessoalmente, não suporto perguntas que começam com "Por que você não" ... Como "Por que você não usa genéricos para isso?". Como devo responder isso? Ou é "porque eu tenho uma boa razão para não", ou "porque eu não sou tão inteligente quanto você e não penso nisso".

Em vez disso, gosto das sugestões "Você já tentou ...". "Você já tentou fazer essa classe genérica?". Então a resposta é "não, não tenho, conte-me mais".

Perguntar dessa maneira não pressupõe nada. Você não está supondo que você sabe a resposta certa ou está em posição de orientar a outra pessoa. Você está simplesmente começando uma conversa.

Editar

Gostaria de esclarecer algo em resposta a alguns comentários e outras postagens. A ideia aqui é mais do que apenas reformular uma pergunta para evitar pressionar os botões de alguém. A ideia é iniciar uma conversa com um colega de trabalho em vez de confrontá-lo com uma diferença de opinião. Existem muitas maneiras sutis de fazer isso. Como outra pessoa apontou, reformular uma pergunta de "Por que você não" para "Por que você" tem o mesmo efeito. Você está fazendo uma pergunta legítima sobre uma decisão que a outra pessoa tomou, em vez de afirmar suas próprias idéias. Lembre-se: pode haver uma boa razão pela qual a outra pessoa fez algo de uma determinada maneira, e você pode aprender algo novo hoje.

Certamente, devemos estar igualmente cientes disso quando estivermos do outro lado da mesa. Quando um colega pergunta o que interpretamos como uma questão de confronto, devemos responder de maneira construtiva. Apenas não assuma que todos farão o mesmo.

    
por 15.12.2008 / 20:23
fonte
40

A chave não é estar na "mentalidade de mentoring". Com isso quero dizer, se você tem um sentimento de humildade sobre suas idéias e sugestões, então você não estaria chamando de mentoria, você diria que está discutindo. Há uma presunção de que você é o professor e eles o aluno. Se você abordar a situação com uma mentalidade igualitária como um colega, suas idéias serão muito mais palatáveis.

Além disso, eu realmente não gosto da atual resposta mais popular aqui .. Mudar o texto de como você diz algo para parecer menos conflituoso (por exemplo, "Você já tentou ..." vs "Por que você não ...") é muito mais irritante do que simplesmente ser direto. É passivo-agressivo. Ugh. Desenvolvedores de software enxergam esse tipo de coisa.

Eu acho que o meu ponto é que, se a sua humildade é insincera, então não importa o que você faça, vai ser ofensivo. Quanto mais você tentar criar uma indireta em torno disso, mais irritante será para o cara que você está "orientando".

Eu prefiro o método mais simples possível. Eu realmente amo a frase "Por que você não .." porque isso vai direto ao ponto. Você, o revisor, olha para o código e cria a pergunta em sua mente. "Por que ele não fez do jeito que eu faria?" Então, o desenvolvedor pode responder à pergunta real "Por que você não fez isso da maneira XYZ?" e pode simplesmente explicar por que ele escolheu fazer isso de forma diferente, ao invés de ter que inventariar todas as coisas que ele pode ou não ter tentado, sem explicações sobre por que ele deveria estar pensando sobre isso, ou tentando isso ...

Quando me encontro nessa situação, por exemplo, em uma revisão de código, ou quando encontro o código de outra pessoa que não é o que eu esperava, certifico-me de que sei porque me oponho a isso primeiro. Eu me certifico de ter um conjunto de razões e uma opinião sobre uma solução melhor que seja consistente com esse raciocínio. Então eu vou dizer "Eu notei que você está fazendo XYZ na classe ABC. Essa não parece ser a melhor maneira de fazer isso, por causa de [ inserir razões aqui ]. Para evitar esse problema , Eu costumo fazer [<> insira as opiniões aqui ]. O que você acha? Existe uma razão pela qual você está fazendo dessa maneira? "

Agora, meu colega de trabalho tem motivos, uma solução e uma oportunidade para me explicar por que minha solução pode não fazer tanto sentido quanto a deles. Isso pode resultar em uma longa conversa em que descobrimos que ou eu estava errado, eles estavam errados ou ambas as soluções estavam erradas. No processo, todos aprendemos algo.

Então, eu acho que minha resposta de uma linha é: "Não mentore, explique ou diga a alguém o que fazer, ofereça suas observações e soluções, e discuta-as como iguais". Se você não pode entrar nessa mentalidade, você vai irritar as pessoas, não importa o quanto você esteja certo.

    
por 15.12.2008 / 21:16
fonte
11

contanto que seu ego esteja investido em seu código, você não será nem um bom mentor nem aprecia outros que o orientam

a humildade é uma virtude, especialmente em outras pessoas; -)

sério, se ele não quer ser orientado, você não pode fazê-lo aceitar isso. Se você precisar fazer "sugestões úteis", faça isso de forma discreta e apenas uma vez, depois solte-a. Se o aluno estiver pronto, ele retornará para mais.

EDIT: Eu endosso cordialmente admoestação de Troy para não estar na "mentalidade de mentoring", porque isso coloca você em um plano acima de seu colega de trabalho, o que pode ser ruim para as relações de equipe, mesmo que seja feito apenas em sua cabeça e temporariamente . "Discuta questões técnicas como iguais" é um excelente conselho. Para isso eu adicionaria "escolha suas batalhas", ou seja, não escolha nada, mas concentre-se apenas nos erros potencialmente sérios ou em técnicas questionáveis.

    
por 15.12.2008 / 20:27
fonte
9

Se você acha que algo está errado, faça uma pergunta sobre esse pedaço de código onde, para o qual a resposta inclui o erro. Faça isso de uma maneira educada e honesta, e não tire sarro da resposta. Esteja preparado para fazer outra pergunta quando seu colega errar o alvo.

P: Por que você está usando um Hashmap aqui?

A: Porque aqui é ... erhm ... espere um minuto ... isso está errado!

Ao fazer isso, você está muito seguro. Se você estava errado, você parece apenas ter feito uma pergunta, e ter obtido o anser para que você possa pensar e falar sobre o assunto. Se você estava certo, você também terá uma resposta e uma oportunidade para descobrir a solução juntos.

Comentários começam brigas. Perguntas iniciam conversas.

    
por 15.12.2008 / 21:00
fonte
9

Eu diria que você deu o primeiro passo: reconhecendo que boas relações com outros desenvolvedores são importantes. Muitos desenvolvedores nunca percebem isso, e muitos que decidem que não valem o esforço de aprender como orientar / direcionar.

Eu tive a oportunidade de trabalhar com muitos desenvolvedores ao longo dos anos, alguns mais antigos para mim, principalmente júnior. Eu acho que todo desenvolvedor sênior lida com o reflexo "Eu não tenho tempo para isso" quando mentoring.

Eu seria o primeiro a admitir que nem sempre fiz um bom trabalho quando fui mentor. Eu encontrei sucesso com algumas habilidades básicas de comunicação:

  1. ESCUTE. Seu trabalho como mentor é entender o nível de compreensão de seus colegas e identificar onde sua compreensão é incompleta.
  2. Liderar pelo exemplo. Se você tiver uma amostra de código disponível que ofereça uma solução, forneça uma explicação.
  3. Conheça os limites do seu colega. Se eles não forem receptivos à sua crítica, não a ofereça. Se eles são um subordinado direto e não respondem de forma consistente às revisões de código, você pode ter tomado uma decisão ruim de contratação.
  4. Evite as declarações "Você" "você cometeu um erro", "você precisa corrigir isso". Isso pode soar clichê e bobo, mas ajuda a frase sua crítica em geral: "Isso deve ser X em vez de Y". "X é um erro comum, Y funciona melhor".
  5. Compartilhe seus métodos. Se você é especialmente bom em alguma coisa, ou seja, padrões de design, pesquisa, uma estrutura específica, documente-a e envie-a. Isso ajuda se você é a PME reconhecida pelo tópico.
  6. Seja específico. Não diga apenas "isso não vai funcionar", explique por que você acha que uma maneira diferente seria melhor.
Permanecer aberto a críticas pode ser difícil - acho que isso acontece porque, como estamos discutindo, é difícil oferecer uma crítica construtiva sem parecer condescendente. Eu acho que é muito útil receber críticas se você já criticou honesta e talvez duramente seu próprio trabalho. Quando alguém aponta uma falha que você já identificou (e todos sabemos que não existe um software sem falhas!), Ela é muito menos emocional. Além disso, tento avaliar com calma as críticas recebidas, decidir se tem mérito e seguir em frente. Você não precisa concordar com seus críticos e nem sempre precisa dizer quando discordar. Sorria e acene com a cabeça, todo mundo é um crítico! :)

    
por 15.12.2008 / 20:49
fonte
8

Esta é uma preocupação tão comum, e com razão. É uma sensação muito estranha ter que dar feedback a alguém no ambiente de trabalho. Estes nem sempre são seus amigos, com quem você pode brincar. Muitas pessoas levam o feedback muito a sério, pois podem se sentir ameaçadas ou preocupadas em perder o emprego.

É muito importante estabelecer relações positivas com seus colegas de trabalho. Fazer isso exigirá esforço de sua parte. Você precisa ter uma compreensão geral da personalidade de cada pessoa. Eu mesmo sou relativamente quieto; Eu guardo para mim a maior parte do tempo. Alguns dos meus colegas de trabalho mais próximos são exatamente o oposto: são pessoas muito extrovertidas. Se você entender como eles querem ser tratados, isso permitirá que você estabeleça bons relacionamentos.

Algumas pessoas participam de reuniões e querem ir direto ao assunto. Me dê os fatos, poupe o buço. Outras pessoas (e estas podem ser pessoas na mesma reunião) são muito orientadas para as pessoas, e têm dificuldade em se concentrar antes de fazer o seu 'como foi seu fim de semana' spiel. Para cada um deles. Muitas vezes é difícil tentar reunir essas pessoas para chegar a uma agenda comum.

O que estou tentando dizer é o seguinte: não há uma fórmula para tratar as pessoas ou dar feedback a elas. Eu? Eu gostaria de ouvir "Ei, cara, eu entendo que você é um recurso valioso, mas você poderia tentar fazer o seu trabalho dessa maneira, em vez disso. Aqui está o porquê." No entanto, algumas das pessoas que aprendi precisaram se envolver mais em uma conversa. "Bob, você poderia me explicar por que está fazendo assim? Ajude-me a entender a lógica envolvida aqui; eu nunca vi isso antes." Então, talvez sugira maneiras diferentes, se você acha que seus métodos são melhores.

Por último, e mais importante: se alguém está te frustrando, dê um passeio pelo corredor! Parece óbvio, mas funciona. Não há mais socos na cara!

    
por 15.12.2008 / 20:23
fonte
6

Portanto, esta questão parece ter três partes:

1. Como você critica as pessoas sem ofendê-las? É tudo sobre tornar isso seguro para a outra pessoa. Dê-lhes espaço para salvar o rosto, se for o caso, e faça perguntas em vez de fazer declarações firmes. Se é extremamente precário, peça permissão: "Eu tenho algo que eu gostaria de falar com você sobre isso é um pouco delicado, mas acho que vale a pena. Tudo bem?"

Se eles começarem a ficar ofendidos, recue e deixe-o seguro. "Eu posso ver que estou te esfregando do jeito errado aqui. Isso não é o que eu estou tentando fazer. Eu estou tentando lhe dar uma crítica construtiva - está tudo bem?" / p>

2. Como você se mantém aberto para poder continuar crescendo e receber os que estão ao seu redor? Esteja ciente de quando e como você reage, antes de mais nada. Se você realmente quer colaborar e aprender com os outros, e se você pode evitar que o seu ego se envolva, isso se encaixará.

Há um ótimo livro sobre esses assuntos chamado Conversas Cruciais e outro - e este é ainda melhor - chamado Confrontos Cruciais. Eu recomendo o segundo. Entre outras coisas, trata-se de aprender como evitar que o seu ego prejudique seus relacionamentos ... Particularmente nas situações mais importantes em que muita coisa está em jogo e talvez você esteja no meio de uma descarga de adrenalina.

3. Como eu me mantenho competitivo com as pessoas que estão saindo da escola agora? Experiência! A maioria das pessoas que estão fora da faculdade tem muito idealismo e fogo, mas nenhuma experiência no mundo real. Eles têm muito a aprender, alguns dos quais podem ser muito dolorosos.

Fique curioso e esteja disposto a aprender com eles e lembre-se do valor da experiência.

    
por 15.12.2008 / 20:42
fonte
6

Elimine a palavra "mentor" do seu vocabulário e do seu raciocínio, e você terá um longo caminho em direção a ser menos condescendente.

Eu amo encontrar a melhor maneira de fazer algo. Eu amaria para que alguém compartilhasse dicas de programação e design.

Eu vou lutar se eu achar que o design que você me deu não é tão bom quanto o que eu tenho em mente, ou se eu acho que o tempo envolvido na implementação da sua ideia (ou o tempo envolvido em meramente discussão sua idéia!) não vale a pena. Você deveria esperar isso; É a maneira como chegamos à verdade do assunto. Se você não pode lidar com isso, então eu não acho que você deve iniciar conversas sobre o assunto. :) Isso definitivamente vai ser como um debate e talvez um pouco contraditório, mas isso não significa que eu esteja levando as coisas para o lado pessoal ou que você deveria, e isso não significa que eu não esteja aberto a sugestões. Também não significa que não podemos desfrutar da amizade um do outro, se formos amigos.

Bons programadores querem colaborar com bons programadores, mesmo que nem sempre concordem. Se você tem algo produtivo para sugerir, apenas sugira. Como um par, não como meu "mentor". E esteja disposto a ser corrigido por um colega. :)

    
por 15.12.2008 / 22:34
fonte
6

Se você quer ser o mentor de alguém, primeiro se prove ser um mentor.

Como programador e educador agora bastante "sênior", tenho visto muito mais do que minha parcela de "fotos quentes" e "sei tudo" em todos os níveis.

No entanto, nunca parece mudar uma coisa - e essa é a curva de aprendizado universal:

  1. iniciante - apenas aprendendo, cheio de perguntas, muito humilde, ansioso e sedento por mais.
  2. iniciante avançado - aprendeu algumas coisas, mas ainda sabe que há muito a aprender.
  3. intermediário - ganhando confiança em algumas áreas, mas ainda sabe que existem lacunas.
  4. avançado - confiante em muitas áreas, disposto a aprender coisas novas, mas bastante sólido.
  5. expert - conhece tudo, vê tudo. Nada mais a aprender - vi e fiz tudo.
  6. iniciante - acabou de descobrir o quanto ele não sabe. Volte ao # 1.

Infelizmente, muitos param quando atingem o 5º lugar e se tornam dores no saco para todos com quem trabalham.

Então, se você quiser ajudar os outros (eu também não gosto do termo "mentor" - parece uma espécie de hortelã), então tenha certeza de que você não está operando no nível 5.

Felicidades,

-Richard

    
por 16.12.2008 / 01:57
fonte
5

Eu acho os desenvolvedores muito objetivos. Então você pode realmente fazer uma discussão racional. Apenas seja honesto e alivie os fatos.

Indo para o outro lado, se você não está tentando aprender o tempo todo, então você não é um grande desenvolvedor.

    
por 15.12.2008 / 20:23
fonte
4
  • admita a ignorância. muitas (não?) perguntas não-trival são melhor respondidas com "não tenho certeza, mas eu penso assim e assim. vamos descobrir!"
  • a maioria dos problemas é uma boa desculpa para aprender, ele aprenderá com você, você aprenderá enquanto faz algo novamente com uma nova abordagem.
  • continue produzindo. se os outros respeitarem o seu trabalho, eles não se sentirão insultados.
  • se um ponto é uma pergunta trivial, ou um erro óbvio, tente abordar como um enigma: "qual a fonte de erros que estou supervisionando?" "existe alguma ambiguidade nos documentos?"
por 15.12.2008 / 20:23
fonte
4

Uma das melhores abordagens que já vi é mostrar que você está entusiasmado com alguma coisa. "Quer ver algo legal .." ou "Confira isso ..." é uma ótima maneira de compartilhar informações.

Se não quiser parecer que está segmentando uma única pessoa, você também pode fazer isso nas sessões semanais do desenvolvedor (se as tiver) e apresentar as coisas ao grupo como um todo. Provavelmente, isso reforçará a compreensão de todos sobre algo.

Todos podem desenvolver habilidades sociais, no entanto. Leva tempo e trabalho. Um dos maiores obstáculos para ter strongs habilidades de interação social é ter um strong senso de autoconfiança. Se você tem um problema em um ambiente social, ou sente que é algo que precisa trabalhar, concentre-se primeiro em sua autoconfiança. As pessoas podem dizer quando você não está confiante em si mesmo e vai realmente levá-lo como um sinal de que você não tem certeza do que está tentando transmitir.

    
por 15.12.2008 / 22:02
fonte
4

A primeira coisa que faço quando mentoring é recitar o seguinte para os alunos:

There are no stupid questions...just stupid people who ask questions.

Estou brincando !!! :)

Eu fiz um pouco de mentoria nos meus anos no negócio e fiz algumas observações que fiz ao longo do caminho:

  • Nem todo mundo aprende da mesma maneira. Ajuste sua metodologia de ensino para a pessoa, não faça com que ela se ajuste a você.
  • Você não pode libertar um peixe da água. Se alguém não quiser aprender, você não pode forçá-lo. Espere que eles peçam ajuda.
  • Use metáforas e ilustrações o máximo possível. Os programadores tendem a pensar visualmente.
  • Seja paciente! As pessoas aprendem no seu próprio ritmo. Seu trabalho como mentor é ajudá-los a aprender, não a ser um martinet tirânico!
  • Seja entusiasta, é contagiante.

O mentoring é uma habilidade que se desenvolve com a prática, mas a personalidade está embutida!

    
por 15.12.2008 / 22:08
fonte
3

Uma ótima pergunta e uma que eu realmente não tenho uma resposta.

A única vez que descobri que posso ter algum efeito é se tiver uma sugestão muito concreta que tenha um benefício demonstrável.

Por exemplo, no ajuste de desempenho, nossos programadores são como a maioria em que eles a) falam sobre criação de perfil, b) passam a adivinhar e corrigir seus palpites. Eu posso usar minha técnica de interrupção e depois dizer a eles, por exemplo "A propósito, o programa está inicializando a estrutura X três vezes durante a inicialização, e isso é responsável por 40% do tempo." Então eles dizem "Oh. OK. Eu provavelmente posso consertar isso."

Mesmo assim, eles podem simplesmente não fazer isso. Então é melhor ficar quieto e manter a paz.

    
por 15.12.2008 / 21:32
fonte
3

Você faz isso por exemplo. Se você puder encontrar uma maneira de fazê-lo, seja voluntário para trabalhar em co-desenvolvimento de um projeto com a outra pessoa. Concordar com APIs, rever o código do outro, passar o código para frente e para trás. Não critique o trabalho deles, deixe-os cometer erros e deixe-os perceber o erro, e corrija-os eles mesmos. Deixe-os contribuir. Espere que eles perguntem "Como posso melhorar isso?" Esteja aberto para o que eles sabem também, você também pode aprender com eles.

Isto não é uma coisa fácil de fazer e requer acima de tudo paciência. Você precisa estabelecer confiança e aprender apenas a trabalhar junto com a outra pessoa primeiro, se você apenas disser "você está fazendo errado", a lição não vai ficar. Algumas pessoas estão (talvez) além da ajuda, convencidas de que estão sempre certas, não estão dispostas a aprender. Mas a maioria das pessoas realmente quer aprender e ensinar (basta olhar para este site para obter evidências disso), eles só precisam de um ambiente seguro para fazê-lo.

    
por 15.12.2008 / 22:08
fonte
1

Isso é uma coisa difícil de fazer, como você e vários outros notaram, mas ajuda se você escolher o momento certo para fazer as coisas, além de apresentar as coisas de uma forma que não seja negativa. Escolher o momento certo para fazer as coisas significa que você não deve dizer algo que potencialmente chamará alguém (por exemplo, exponha sua ignorância) em um ambiente de grupo. Nas configurações de grupo, mesmo o mais objetivo e aberto para o feedback pode reagir um pouco defensivamente se você estiver chamando-os em um ambiente de grupo. A menos que você tenha que chamá-los para fora na frente do grupo - tente evitá-lo e apenas os puxe para o lado mais tarde.

No âmbito da apresentação do "mentoring" - tudo depende do que você está discutindo e com quem você está falando. Em alguns casos, não importa o que você diga, você estará errado. Sobre a única coisa que você pode fazer nesse momento é conseguir alguém mais alto (por exemplo, chefe, colega de trabalho respeitado, seu mentor) para falar com a pessoa. Se a pessoa estiver aberta à discussão, tente não ser julgadora ou arrogante sobre o que você está discutindo, isso provavelmente fará com que a pessoa desligue você. A partir de minhas próprias experiências, a melhor maneira de abordar alguém é de uma maneira mais "justa" em que você está apresentando uma maneira melhor de fazer alguma coisa. A maioria das pessoas em TI entende que as coisas mudam muito rápido e não leva muito tempo para ficar desatualizado em alguém. Se você abordar as coisas desse ângulo, a maioria das pessoas ouvirá o que você tem a dizer.

    
por 15.12.2008 / 20:34
fonte
1

Como ganhar amigos & Influencie Pessoas http://ecx.images-amazon.com/images/I/51JDKW8TV1L._SS500_.jpg

link

A escolha de palavras tem alguma importância. Mas o que eu sinto é mais importante é o tom que você usa para expressar seus sentimentos. Nunca seja alto e mal-humorado. Você pode usar a frase mais cordial e gritar "CONSIDERAR ESCREVER UM ROTEIRO PARA RECUPERAR REALMENTE TODOS OS ARQUIVOS .BAK EM TODAS AS DIRETÓRIAS DE LOG?" e faz parecer realmente hostil. Claro, não importa o quão polido seja o seu tom, usar "idiota" ou "retardar" não ajudará.

Meu estilo de persuasão é ter uma conversa enquanto diminui a ingestão de chá .

    
por 27.12.2008 / 15:44
fonte
1
A realidade muitas vezes faz maravilhas aqui. Quando a sua ideia muda falhar miseravelmente, indique educadamente e com humildade que você teve uma sugestão alternativa que teria funcionado se eles tivessem escutado você. Eles podem discutir com você em uma tentativa de salvar o rosto. De fato, se for esse o caso, você deve deixá-los vencer esse argumento. Mas eles não serão capazes de escapar do fato de que você estava certo o tempo todo e provavelmente estará mais disposto a ouvir mais tarde.

    
por 15.04.2010 / 20:35
fonte
0

I don't have great social skills. Like many programmers I know, social skills are >something that is worked on and developed over time because it's not a natural and >'inborn' trait.

As habilidades sociais são desenvolvidas ao longo do tempo para todos . Por que é um equívoco tão comum que os desenvolvedores não têm ou precisam trabalhar muito para desenvolver habilidades sociais?

    
por 15.12.2008 / 21:51
fonte
0

De Richards responda a IMHO aqueles que

knows all, sees all. Nothing more to learn - seen it and done it all

não existem, exceto em suas mentes ... é a beleza deste trabalho que nos encontramos em que as ferramentas / ambiente / mercado está sempre mudando ... por isso a capacidade de aprendizagem está sempre lá .. A próxima grande coisa está ao virar da esquina e você não está tão longe de se tornar um dinossauro FORTRAN se você ficar quieto ...

Assim, um conselho que eu tenho é procurar aprender com os outros em sua equipe também ... todos nós achamos que é bom quando nos deparamos com um problema / desafio para arar e resolver nós mesmos, ainda mais fácil agora com a web (por exemplo, stackoverflow) disponível ... mas perguntando à opinião ou à ajuda de seus colegas, eles provavelmente estarão mais abertos a pedir ajuda / orientação na próxima vez que precisarem ... ou a ficarem mais abertos a conselhos / orientações não solicitados. ..

Se eles não têm a resposta, você também pode pesquisá-los juntos e ambos aprenderem, se parecerem colaborativos, eles serão mais receptivos.

    
por 16.12.2008 / 05:00
fonte

Tags