Nunca apresente apenas um problema

Dei uma olhadela rápida no seu perfil e reparei que já está na comunidade StackExchange há algum tempo. Certamente já notaram aqui que as perguntas que recebem as melhores respostas por aqui são as que apresentam o problema e o raciocínio que já tomaram numa tentativa de responder à pergunta.

A vida profissional é exactamente assim. Se está a fazer uma pergunta, então quer ter a certeza de lhes dizer também o que já fez para tentar respondê-la você mesmo. Isto beneficia-o de várias formas:

• ** Mostra que não está a perguntar desnecessariamente.** Se expuser o seu raciocínio, então está a deixar a pessoa saber que está a fazer uma tentativa antes de fazer uma pergunta e não apenas a ser preguiçoso.
• ** Provavelmente irá receber um feedback que irá beneficiar os seus processos de pensamento. ** Se um colega vier ter comigo com um problema e expor como tentou responder a uma pergunta, não só ajudará a guiá-lo no caminho certo, como também o ajudarei a compreender como poderia ter pensado sobre a pergunta para lá chegar pessoalmente. Quanto mais expuser o seu processo de pensamento e raciocínio, mais outras pessoas o poderão ajudar a construir sobre eles para problemas futuros.

Há aqui alguns pontos para desempacotar.

Assumi que todos os outros numa empresa de tecnologia gostavam de falar de tecnologia…

Não necessariamente. […] Se passarmos o tempo de outra pessoa a falar de coisas que não são relevantes para o que ela está a fazer, então quando lhe fazemos uma pergunta relevante, podemos descobrir que ela sente que já perdeu produtividade suficiente connosco.

Eu tento sempre resolver os problemas sozinha durante pelo menos uma hora. Isto é demasiado curto?

Em muitos casos, sim, é demasiado curto. […] […] Não é insuperável, mas há algumas coisas em que precisa de pensar.

• Salve questões técnicas hipotéticas para a sala de almoço. Não é apropriado, a menos que conheça bem as pessoas, desperdiçar o seu tempo e o de outras pessoas em questões irrelevantes.
• Saiba como aplicar melhores termos de pesquisa na web. Se lhe estão a dizer que está a fazer demasiadas perguntas e a demorar muito tempo a fazer, então está claramente a fazer as perguntas erradas.
• Quando fizer uma pergunta, mostre o que tentou. Mentalidade clássica de Stack Overflow. Se não tem nada para mostrar como um esforço concertado para resolver um problema, então não se esforçou o suficiente. […] E por último;
• Salve questões para questões específicas do negócio. Não pergunte como conduzir a sua ferramenta de programação, mas do pergunte sobre questões específicas de domínio ou ambientais que não serão do domínio público.

Há aqui muitas coisas que pode fazer para melhorar. Pode descobrir que o PIP pode ser uma ferramenta muito valiosa para o ajudar a tornar-se um melhor programador :)

O problema é que, quando se interrompe o trabalho de alguém, ele não só perde os 5-15 minutos que demora a responder. Perdem muito mais tempo, uma vez que precisam de recuperar a concentração. E isso pode ser bastante frustrante.

Eu estava numa situação semelhante à vossa. Costumava ir ter com as pessoas e fazer-lhes perguntas logo de seguida. Mesmo quando eles faziam algo que me bloqueiava. Isso pode até ter interrompido outras pessoas próximas.

O meu gerente deu uma solução: usar o e-mail e as mensagens instantâneas, mesmo quando a pessoa está sentada ao seu lado. Dessa forma, pensará mais como formular a pergunta, e durante esse processo poderá responder a si próprio. Além disso, o outro lado pode responder-lhe quando tem algum tempo livre.

Outra opção é marcar uma reunião, onde todas as coisas são esclarecidas.

Vou tentar responder do ponto de vista da empresa. Não sou essa empresa, por isso pode haver coisas que não vejo, mas já vi isto antes na minha própria empresa.

Too Many Questions

A maior parte da sua confusão parece advir do facto de não ter percebido que fazer perguntas é um jogo perigoso. **É!!!!

Quando fazes uma pergunta, estás a admitir que não sabes nada, e que não consegues perceber. Como programador de software, uma das suas tarefas é descobri-lo. Está a insultar a equipa de desenvolvimento “actual”, basicamente perguntando: “Então escreveu aqui um código de merda tal que não consigo perceber como o ler ou o que está a fazer, por isso vou precisar que me explique”

Agora a parte complicada aqui, é que algumas vezes é exactamente esse o caso e você devia estar a fazer perguntas. É apenas importante lembrar que, aconteça o que acontecer, há um lado negativo nessas perguntas.

Outra coisa que acho que sinto no seu PO é que está a fazer perguntas muito cedo demais. É absolutamente correcto que um novo programador se sente ali a ler, e a pesquisar durante um dia inteiro, para escrever 2 linhas de código. Na verdade, com 14 anos de experiência, ainda acabo por fazer isso. Escrever código profissional não é sobre “quanto” se faz, é sobre “quão bem” se faz, e poder repetir esse sucesso. Duvido que alguém se preocupe consigo por demorar 100 vezes mais para fazer um décimo do trabalho como programador formado e estabelecido. De facto, quando contrato alguém, deixo de esperar um trabalho real no primeiro mês, e nos primeiros seis meses não espero muito.

Não gaste tempo suficiente sozinho

Isto é demais!!! Quando você pede ajuda a um membro da equipe, você está puxando para baixo a produtividade dessa pessoa também. Está a ter impacto no processo deles e a insultá-los (ver acima) ao mesmo tempo. Não há forma de ganhar, se tiver de pedir ajuda. Pense em cada pedido, como uma batalha perdida. Ainda podes ganhar a guerra, mas perdeste esta batalha.

Há algumas coisas que podes fazer para mitigar o problema:

1. Pergunta por email, nunca em pessoa ou chat. O chat pode ser a forma preferida de o fazer “oficialmente”, mas o email é mais agradável porque o receptor pode lidar com ele no seu próprio tempo.
2. Aborde-o a partir de uma posição “inferior”. Você é o suplicante aqui. Faça um pouco de grovelling. Está tudo bem. Um pouco não te vai fazer mal e vai mostrar ao receptor que te preocupas com o tempo deles, ou seja, “Sei que estás muito ocupado, mas parece que não consigo perceber como integrar com o teu API. Quando tiveres alguns momentos, podes mostrar-me o que estou a perder?” Mostra que você está no errado, não eles. É importante.
3. Liste os passos que deu por si próprio. “O documento API diz para passar numa String representando a identificação do utilizador. Eu tentei passar a propriedade user.id e o nome do utilizador, nenhum dos dois funcionou”. Isto mostra que pelo menos tentou algo e que, em geral, está a começar a “obter” o produto.

Better Judgement When asking questions

This, to me, sounds like you “whined” to someone, and they didn’t have a nice way of saying, “You’re annoying everyone with your lame questions. Pare com isso!” Por outras palavras, acho que isto não é uma questão. Depois de corrigir as suas outras questões, isto vai desaparecer.

Mal documentação

Ahem! Isso é outro insulto pessoal. Nunca diga isso. TUDO!!!! Mais uma vez estás a dizer que a qualidade do código deles é tão má que não consegues perceber. A resposta deles vai ser sempre “Funciona para todos os outros, por isso deves ser tu o idiota, não eu!”

Também, isto é um pouco de “bem-vindo ao mundo real”. No mundo real, os clientes pagam por aplicações que funcionam e não por código ou documentação (na maioria das vezes), por isso é muito comum a documentação degradar-se com o tempo.

Se acha que a documentação é pobre e precisa de ser tratada, então fale disso, calmamente, com a sua equipa à frente. Deixe-os decidir.

Eu vou dizer isto. Por muito má que seja a documentação, com o código fonte mesmo à sua frente, não deve precisar dela. É muito bom ter, não me interpretem mal, mas can work without it.

Being Late

Obviamente, não se atrasem. Isso é um “no brainer”. Na verdade, na sua situação neste momento, esteja 30 minutos adiantado!! Sem desculpas. Estás a arruinar qualquer esperança de encontrar o teu próximo emprego com este. Se eu ligasse para o departamento de RH e perguntasse sobre a sua presença, e eles dissessem “Ele atrasou-se frequentemente” ou “Ele foi escrito por se atrasar”, isso é uma bandeira vermelha instantânea. Menciono isto, porque quer mantenha este emprego ou consiga um novo, isto mais do que qualquer outra coisa vai impedi-lo de conseguir o próximo emprego.

Código de baixa qualidade

Isto é provavelmente verdade. Dado o problema da pergunta, provavelmente não está a escrever um bom código. Mas você é novo, e isso é de esperar. Eu acho que as faculdades não ensinam nada sobre codificação do mundo real. Nunca contratei alguém que saísse directamente da faculdade e conseguisse um “bom programador”. Isso não significa que eles não tenham continuado a ser bons programadores. Eles simplesmente não começam dessa forma. Escrever um bom código significa estar a par das últimas tendências e técnicas. Está constantemente a aprender. O momento em que se pára é o momento em que se começa a chupar.

Em conclusão

Este post tem sido duro, mas eu queria mostrar, claramente, qual pode ser a posição de uma empresa. Muitas vezes eles (as empresas) embrulham os seus comentários em tanta “linguagem de gerente” que pode ser difícil de entender. Tentei reduzir ao máximo o discurso do gerente neste cargo, mas isso significa que é um pouco rude.

Os seus passos mais importantes para corrigir o seu fracasso na carreira:

1. APAREÇA PARA TRABALHAR MAIS CEDO!!!! (Não consigo sublinhar isso o suficiente)
2. Faça perguntas com um conjunto de pensamentos que já está a insultar a pessoa que está a perguntar.
3. Mostre o seu trabalho. Ao fazer uma pergunta diga claramente o que já fez.
4. Passe mais tempo a aprender por si próprio. É importante passar muito mais tempo a pesquisar as coisas do que a perguntar coisas. Honestamente 3-4 dias a pesquisar algo por si próprio, será mais respeitado do que uma pergunta de 30 segundos.

Queria aproveitar esta oportunidade de um ponto de vista de gestão.

Um PIP é uma coisa abrangente

É bastante provável que a melhoria do desempenho seja uma colecção das coisas que a vossa gestão destacou, tudo feito em conjunto. Eu suspeito que se você fosse a pessoa que fez muitas perguntas, mas chegou cedo, ficou até tarde e fez um ótimo trabalho ao escrever o código, a equipe trataria a pergunta como uma questão pessoal, ou que você é excepcionalmente minucioso.

Mas quando a equipa tem de ajudar a encontrar e corrigir mais bugs no seu código, depois de responder mais do que a quantidade habitual de perguntas, e o vêem a trabalhar menos horas ou a chegar atrasado sem aviso prévio, a equipa e o gestor vão sentir que você não está a contribuir para o nível que precisa de estar, e que não está a dar tempo extra para acelerar o processo. A pergunta foi provavelmente levantada à luz dos outros problemas, porque se tentar corrigir a qualidade do código fazendo MAIS perguntas, será insustentável para a equipa.

Cada hora conta

Um novo nível universitário é um investimento em tempo de equipa. Qualquer gerente que lhe diga o contrário ou nunca contratou um novo graduado universitário, ou está a mentir, ou tem uma equipa excepcional a trabalhar para ele. Qualquer nova contratação é um investimento, mas os graduados da faculdade são MAIS tempo. Normalmente a troca vale a pena, no entanto - mas tenha em conta que os licenciados fazem mais perguntas do que os desenvolvedores mais experientes.

No entanto - cada hora conta. Uma equipa de programadores fará mais numa determinada semana, quando todos estiverem a par, conhecerem o código e não fizerem muitas perguntas. Além disso, uma equipa neste estado gelado será capaz de fazer e responder a perguntas muito rapidamente - o que também acelera a produtividade.

Responder a perguntas does leva tempo. E há uma mudança de contexto sempre que um programador deixa de escrever código e começa a responder a perguntas. Por isso, responder a perguntas com um grande impulso de interrupção é muito mais do que sentar-se durante uma hora e responder a um conjunto de perguntas.

Eu estaria seguro argumentando que QUALQUER mudança de contexto custa 1 hora, por isso, mesmo que tenha uma pergunta de 5 minutos, custou uma hora à equipa quando alguém pára para responder à sua pergunta. Isso significa que levar 1 hora e não a receber, então pedir ajuda custa mais tempo do que levar 2-4 horas.

Não existe tal coisa como “só vai levar 5 minutos para o outro tipo me poupar uma hora”. Dada a métrica de pelo menos uma hora por interrupção, é melhor que o outro tipo esteja a poupar 2-4 horas.

Dicas para fazer perguntas Bem:

• Compreenda e faça perguntas de acordo com a urgência - se tem absolutamente de ter um problema resolvido numa hora, então interromper quase todos os que o podem ajudar é uma boa ideia. Se lhe foi dado um prazo de 3 semanas, então interromper menos e resolver mais os seus próprios problemas é uma ideia melhor. Isto significa que, numa emergência, as pessoas fazem frequentemente muitas perguntas que, de outra forma, investigariam por si próprias. Porque é absolutamente essencial ter a resposta o mais rapidamente possível.
• Use fóruns de perguntas para o seu propósito definido, ou intua o propósito das perguntas/respostas existentes. Os Stack Exchanges, por exemplo, têm um conjunto bastante extenso de regras básicas que estão bastante bem documentadas, e uma expectativa particular de que os utilizadores procurem respostas anteriores antes de perguntar. Um fórum diferente pode esperar perguntas repetidas, mas apenas sobre uma área muito restrita.
• Pesquise a sua pergunta. Espere que escrever uma boa pergunta possa levar tanto tempo como dar a resposta - em muitos casos, está a descrever (de forma concisa!) os passos que o levaram ao ponto de não ser capaz de responder ao problema. Também é provável que esteja a documentar todos os sintomas do problema.
• Dirija-se às suas perguntas - descubra quem pode realmente responder às perguntas, quando possível, em vez de perguntar a todos. Nem todas as perguntas merecem discussão.
• Agregar uma grande pilha de perguntas - especialmente quando é novo, tire um dia para rever o problema e o código. Agregue as suas perguntas numa lista de tópicos agregada. Depois pergunte a um mentor ou amigo onde ir para obter ajuda sobre estes. É bastante provável que a maioria das perguntas na hora #1 seja respondida na hora #6. As perguntas que vieram na hora #1-2 e não puderam ser respondidas na hora #8 estão provavelmente no topo da sua lista uma vez que sabe que em 8 horas não conseguiu perceber.
• Código não é “auto documentar” mas muita informação pode ser aprendida lendo-a. Aprendi muitos sistemas indocumentados sentado com um caderno e desenhando a minha versão do desenho à medida que ia avançando. Se não leu vários níveis acima e vários níveis abaixo da área em que está a trabalhar e não leu os documentos das APIs externas que está a utilizar, não pesquisou suficientemente bem.
• Ao tentar descobrir uma resposta, vai muito longe se conseguir sugerir possibilidades, em vez de pedir a resposta. “Seria esta a forma correcta de o fazer?” é melhor do que “Como o faço?”. - mesmo que a resposta seja “estás a fazê-lo completamente mal” - ainda podes perguntar “porque é que o meu caminho está errado?” e quanto mais meta “como é que eu aprenderia a fazê-lo bem repetidamente”? Esta é a abordagem “ensinar um homem a pescar” - aprenda a pescar, não faça perguntas que só lhe dão 1 peixe.
• Evite perguntas que são apenas uma forma educada de discordar. Há uma linha entre “será a minha maneira de fazer isto viável?” versus “não entendo (ou seja, concordo com) porque o fez à sua maneira? Essas conversas são boas, mas é melhor mantê-las informalmente depois de ter conhecido as pessoas.
• Modere as suas grandes perguntas - estas são normalmente as perguntas "porquê”. Novas pessoas estão no seu direito de fazer muitas perguntas “onde” & “quem” (onde estão os documentos, onde está o processo para isso, onde está o lugar no código que posso querer ver? quem pode responder a isso? quem convido para a revisão?) e algumas perguntas “como” - é assim que devo abordar a questão? como posso obter o vosso acordo? Mas “porquê” como em “porque é que o construímos desta forma?”, “porque não documentamos mais o código?”, “porque é que isto não é uma prioridade? - são legítimas, mas enquanto não se tiver mais experiência com o trabalho e o negócio, não são as perguntas mais necessárias. Podem ser GRANDES para um 1 contra 1 com o seu chefe onde não tem outras questões urgentes, mas se o "porquê” excluir o onde, quem e como então não se está a concentrar no seu trabalho.

Esteve exactamente na mesma situação.

Problem

O que descreve é o problema enfrentado pela maioria dos recém-licenciados. A maioria das universidades só lhe ensina conceitos básicos ou conceitos, enquanto que, na prática, precisa de muito mais.

A maioria das empresas quando contrata recém-licenciados tem planos de formação em vigor, os quais, se os seguir, deverá ficar confiante ao fazer o seu trabalho dentro de um ano ou mais. Mas algumas pessoas ficam curiosas, se lhes deres uma tarefa simples para fixar uma pequena componente num sistema, elas só a recebem quando dominam todo o sistema e eu acredito que és um desses…

Penso que fazes perguntas porque,

• Sentes que estás a demorar mais do que o tempo razoável a completar uma tarefa, pois não compreendes alguma parte do sistema.

• Está apenas curioso para compreender completamente o sistema

• A sua empresa não lhe forneceu formação adequada

Solução

Se os meus pressupostos estiverem correctos então pare de fazer perguntas, a menos que tenha de o fazer (ponto final - agora mesmo)

• Comece a gastar mais tempo a compreender o sistema (não apenas 8 horas)

• Use SO ou outros sites relacionados (depois de fazer a sua parte de pesquisa)

• Peça à sua empresa para o treinar correctamente nas áreas em que precisa de ajuda.

Eu segui acima e agora a trabalhar na mesma empresa após 5 anos e posso afirmar que sei mais do que qualquer um aqui.

Já há aqui muitas respostas, mas quero abordar algumas partes específicas da sua pergunta.

Embora também me tenha repreendido por não gastar tempo suficiente a tentar resolver as coisas sozinho antes de pedir ajuda a outros. Mas isto não é verdade, e ** o meu gerente não teria como saber agora quanto tempo vai desde o momento em que encontro um problema até ao momento em que peço ajuda a alguém**. Eu tento sempre resolver os problemas sozinho durante pelo menos uma hora.

Isto é demasiado curto? Qual é o tempo razoável para gastar num problema antes de perguntar a um colega de trabalho que sabe a resposta?

A ênfase acrescentada é minha.

Para começar, sim, uma hora é provavelmente demasiado pouco tempo. Mas eu digo provavelmente… depende realmente do problema. E ter um limite de tempo é bom, mas deve confiar mais nos indicadores de que se está numa parede do que apenas num limite de tempo. Mas, o que é importante, quando se está pronto para fazer perguntas, o destinatário das suas perguntas deve poder ver a investigação que colocou no seu problema apenas pelo tipo de pergunta que está a fazer.

E é aí que chegamos à parte ousada da citação. Está tecnicamente correcto. Ninguém a não ser você pode realmente saber exactamente quanto tempo investiu num problema antes de pedir ajuda.

Mas com base em que pergunta faz, que informação fornece com a pergunta, o contexto da pergunta e a facilidade com que consigo encontrar a resposta com uma pesquisa simples no Google, posso fazer uma boa estimativa de quanto esforço investiu para resolver o problema sozinho.

Se fizer uma pergunta, e a primeira pesquisa no Google que eu tento produzir a sua solução como o resultado número um, são basicamente duas tentativas para si. Não importa se você gastou 10 minutos ou 10 meses no problema. Já devia ter estudado essa página e ou resolveu o seu problema, ou está a falar-me desta página e porque é que não resolveu o seu problema.

Mas, além disso, que tipo de perguntas é que está a fazer? Está a perguntar por soluções directas? Ou está a pedir um pequeno empurrãozinho na direcção certa? Por vezes, a parede que está a enfrentar é que desconhece completamente alguma biblioteca ou alguma parte existente da base de código que irá tornar simples a resolução do seu problema.

Eu diria que o senhor aprendeu o que esta empresa espera através da escola das pancadas duras. As perguntas neste local são um não-não.

Penso que o vosso principal problema é a visibilidade. Fazer perguntas sobre folga é algo que muitas pessoas podem ver; mesmo que não se sintam obrigadas a responder, isso ainda pode afectar o seu julgamento de si. Entretanto, se passar um dia a descobrir uma única característica na sua secretária, ninguém vê essa roda a girar. Você aparece para estar fazendo algo errado, em vez de apenas bater as chaves na sua mesa, o que preocupa o trabalho. Claro que, talvez em revisões semanais, mensais ou anuais, a sua produtividade irá reflectir mal. Mas as suas perguntas são vistas várias vezes ao dia, enquanto a sua produtividade real é medida com muito menos frequência.

Eu estava numa posição como a sua. Fui contratado para corrigir bugs em um CMS adequado enquanto o desenvolvedor principal (leia-se: apenas) mexeu como louco para adicionar recursos para os clientes. Estávamos muito atrasados. A base de código não estava em controle de versão, e cada lado tinha a sua própria versão sob medida. Foi uma confusão completa.

Naively, achei melhor ocupar 10, 20 ou 30 minutos meus e o tempo de conversação do lead para que ele me pudesse explicar as coisas, em vez de passar meio dia, um dia inteiro, ou mesmo vários dias para fazer engenharia reversa de uma funcionalidade para descobrir 1. o que era suposto fazer, 2. como era suposto funcionar, e 3. como corrigir o bug.

Acontece que, quando o meu chefe (um dos dois parceiros) descobriu isto, ele pensou que me mostrou mal que eu não era capaz de resolver o problema do código sozinho, e que eu estava a tomar algum do nosso precioso tempo de programador de chumbo. (O programador principal parecia gostar de falar sobre como funcionava a sua base de código - em todo o caso, não se queixou ao meu chefe, como ele me disse). Por isso, deixei de fazer perguntas e a minha produtividade caiu provavelmente para 10% do que era. Fui dispensado cerca de um mês depois.

De qualquer forma, esta empresa está a dizer-lhe, de uma forma pobre, que não valorizam esta eficiência temporal e o efeito secundário da documentação. Portanto não o faça.

Passe um dia a tentar descobrir alguma coisa. Gaste alguns dias… passe uma semana! Quem se importa? Não esta empresa. Façam o que fizerem, não façam perguntas, porque isso é algo com que eles do se importam. Não importa se é a gerência, ou os seus pares a queixarem-se, não importa. A empresa já lhe disse que tipo de cultura está a cultivar.

Portanto, se pensar na sua situação, com atraso e código de má qualidade, baixar a produtividade pode acabar por ser demais. Em vez de esperar que o machado caia, talvez queira procurar um lugar que se adeqúe melhor a si e ao seu estilo. Um lugar que talvez tenha alguns comentários e documentação de código, para começar.

Então, como é que a minha história acabou? Depois de um período de desemprego, arranjei um novo emprego. Para além da base de código ser muito melhor (estamos a usar um CMS standard da indústria, estamos em controlo de versões, temos ambientes de desenvolvimento, encenação e produção, etc.), os meus pares são excelentes e a minha empresa encoraja a aprendizagem. Temos um wiki, onde partilhamos a nossa informação e evitamos reinventar rodas. Conversamos o dia todo em folga, falamos sobre trabalho, fazemos perguntas, fazemos brainstorming, partilhamos notícias, informações e descobertas. Iniciamos projectos para melhorar os nossos processos, como o ágil, vagabundo e a implementação de integração contínua. Ensinamos uns aos outros e aprendemos uns com os outros. Agimos como colegas e colaboradores; não como concorrentes. Temos a bordo e orientação para novas contratações e empreiteiros, que não conseguiríamos ter sem esta cultura. Isso é bom, porque no tempo que aqui estive, passámos de dois (eu incluído) para oito, e também empreiteiros em épocas de muito trabalho.

A nossa empresa envia-nos em formações, conferências, e incentiva-nos a ter tempo para aulas e castings baseados na web. Aprendi mais neste tempo aqui do que em qualquer outro período da minha carreira, especialmente em assuntos nos quais não trabalho. É maravilhoso; estou aqui há 4,5 anos e não vejo muitas razões para sair, a não ser para aprender uma nova tecnologia. A cultura da minha nova casa está realmente orientada para a aprendizagem, compreensão e implementação das melhores práticas, o que leva à produtividade. É um win-win.

A sério, há melhores lugares para trabalhar. Este não é o lugar para si, e você não é a pessoa certa para eles.

Se está a fazer perguntas não relacionadas com o trabalho, então pode ser considerado conversa fiada, o que é uma coisa má aos olhos dos seus chefes, por isso pare de o fazer.

No entanto, fazer perguntas relacionadas com o trabalho é uma coisa boa, pois mostra que está interessado no seu trabalho e quer melhorar a si próprio.

Se foi acusado de desperdiçar o tempo de outras pessoas, eu sugeriria que elas precisam de gerir melhor o seu tempo e dizer-lhe que estão ocupadas, em vez de responderem a perguntas quando deveriam estar a fazer outras coisas. No entanto, uma resposta mais útil seria perguntar se têm tempo para responder a uma pergunta antes de a fazer.

Parece-me que o seu patrão é um pouco burro, ou apenas quer ver-se livre de si por qualquer razão. Vão falhar porque não documentam as coisas que são uma receita para o desastre quando o(s) seu(s) principal(is) revelador(es) sair(em), já lá esteve, já o fez.

Tipos de questões de trabalho:

1. Como faço algo que preciso de aprender para fazer o trabalho.

2. Como faço algo que preciso de aprender a fazer o trabalho, mas já me disseram.

3. Como faço algo que já deveria saber.

4. Como faço algo que está fora do alvo do trabalho, e sei que está fora do alvo.

5. Como faço algo que está fora do alvo do trabalho, e não sei que está fora do alvo.

6. Perguntas engraçadas e conversa fiada.

Por isso…

Você pode perguntar quantos nº 1 quiser. Eles podem pensar que você é irritante, mas é um bom/esperto irritante. Você não seria escrito para isto.

Se você está perguntando #2s então eles pensam que você tem um problema de compreensão. Ou você só gosta de fazer perguntas, mas não ouve. Isto é tolerado até certo ponto e envelhece rapidamente.

Dependendo da sua posição e das coisas estranhas que traz para a equipa #3s pode ser bom - conhece bem uma área específica, é barato, o que quer que seja. No entanto, é melhor não perguntar #2s depois de perguntar um #3.

Não há dúvida de que os #4s não são bons. Pode fugir a perguntar alguns destes mas não como novo funcionário. Os colegas de trabalho esperam que você pergunte #1s (e alguns #2s) muito antes de pensar em #4s. Se estás a pedir muitos #4s eles pensam que estás em todo o lado.

Isto é o pior. Basta perguntar a um par de #5s para te adiar para qualquer membro da equipa. Significa que não o consegues e provavelmente não tens aptidão para o conseguir.

Hmmm… #6s estão dependentes da pessoa. Muitas pessoas podem perguntar toneladas de #6s se são divertidas ou divertidas. Por outro lado, se você não é #6s pode ser muito mau, especialmente se você está perguntando #2-5s.

Se você pensa para si mesmo por que eles não podem apenas ser bons para mim e me ajudar se eu estou tendo problemas e perguntando #2-5s o tempo todo. Porque podem contratar outra pessoa que saiba mais e não faça perguntas estúpidas. Se eu fosse a si começaria a prestar mais atenção, talvez até a carregar sempre consigo um bloco de notas, e quando alguém responde a algo, certifica-se de que tem 100% de certeza de que o recebe ou pede esclarecimentos no local.

Esta resposta é sobre como receber feedback (as outras respostas já cobrem muito bem como fazer perguntas).

Embora também tenha sido repreendido por “seguir o caminho errado” ao tentar resolver um problema que não conhecia, em vez de perguntar a alguém que conhecia. Quando perguntei sobre a contradição, o meu gestor e o meu RH disseram-me que só precisava de usar de melhor discernimento sobre quando fazer perguntas. Nunca percebi que fazer perguntas poderia ser tão perigoso.

Foi uma má reacção da sua parte. Imagine-se no lugar deles por um momento. Sabe que alguns funcionários estão a ter um mau desempenho e está a dizer-lhes o que precisam para melhorar. Sem se preocupar em pensar no que lhes está a dizer, sem mostrar qualquer interesse no seu feedback, quanto mais pedir desculpa por não satisfazer as expectativas, esse funcionário afirma incorrectamente que está a contradizer-se.

Ao receber feedback, em particular se for negativo, deve primeiro ouvir, depois procurar compreender (fazendo perguntas esclarecedoras conforme necessário), e apenas então responder.

Isso é porque, a menos que tenha feito asneira intencionalmente, você e o seu chefe discordam se fez asneira. Ou o seu patrão está errado, ou você está (ou ambos). Deve entreter a possibilidade de ser você, porque é muito improvável que o seu chefe esteja completamente errado, e você está completamente certo - e mesmo que esteja, só pode convencer o seu chefe de que ele está errado, mostrando-lhe onde ele está errado, e isso requer ouvi-lo, também.

Pode também pedir conselhos sobre como pode fazer melhor.

Por exemplo, depois de ouvir que está a fazer demasiadas e poucas perguntas, pode ter perguntado:

Por isso fiz tanto perguntas desnecessárias como não fiz as perguntas necessárias. Como devo determinar que perguntas são necessárias? Isto é, que tipo de perguntas devo fazer mais e que tipo de perguntas devo fazer menos?

A discussão factual que se segue teria provavelmente revelado o que precisa de fazer para melhorar.

Isto é habitual? Não é suposto a nova pessoa numa empresa ser curiosa ou fazer perguntas que não estejam imediatamente relacionadas com o seu trabalho?

Até que ponto fazer perguntas é esperado ou desejado difere entre os locais de trabalho. Pode querer adaptar-se à cultura do seu local de trabalho, que pode descobrir observando os seus pares, tomando nota da forma como as pessoas reagem às suas acções (estão aborrecidas com as suas perguntas, ou encantadas com elas?), ou pedir o seu feedback (“Será que eu podia perguntar isso?”).

Penso que se somos jovens como eu, a nossa mentalidade é poupar tempo e encontrar a resposta e depois passar para o próximo problema. No entanto, com as gerações mais velhas, acho que isso não constitui uma preocupação nem uma prioridade para elas. Portanto, sim, levar uma hora a resolver um problema é demasiado curto para alguém que é mais velho, mas pode parecer-lhe demasiado longo. Sugiro que se observe o fosso geracional e que se siga o exemplo, mesmo que não esteja de acordo. Eventualmente tornar-se-á mais rápido a resolver problemas com mais experiência.

Quanto a arranjar problemas para fazer perguntas, tento usar a explicação de que quero ver como deve ser feito, ou ir pelos padrões da empresa. Mais uma vez reparei que, em gerações mais antigas, isto é irritante por alguma razão. Penso que as pessoas mais velhas tendem a pensar que resolvi isto sozinha e não recebi qualquer ajuda, por isso estão menos dispostas a ajudar. Eles também se sentem interrompidos. Como alguém mencionado acima tenta encontrar o momento certo para pedir ajuda, enquanto acaricia o ego, IE “Ouvi dizer que eras o tipo a quem recorrer….”. “Alguém disse que você é o perito em….”, esperemos que isso os faça esquecer uma interrupção e eles estarão mais dispostos a ajudar, uma vez que você lhes deu algo para provar. Tenha cuidado com esse último conselho, pois tenho a certeza de que, em alguns casos, ele pode sair pela culatra.

Acho difícil definir com precisão, mas trabalhei com alguns jovens, e alguns deles fizeram perguntas que foram muito satisfatórias de responder e outros não. Responder às suas perguntas distrai os seus colegas de trabalho do seu trabalho, e não faz mal, _ se_ algo de bom vier disso e a empresa beneficiar a longo prazo. Isso significa que você precisa perguntar à pessoa certa, fazer a pergunta certa e chegar a um lugar onde você tenha ganhado compreensão que lhe permita fazer progressos significativos. Se tem jeito para isso, as pessoas vão sentir que o tempo gasto a ajudá-lo é tempo bem gasto, e você é um colaborador valioso. Se não o fizerem, podem achar-te irritante.

Obviamente, se há muito que não sabes, isso coloca-te numa situação delicada, mas a atitude e a aptidão fazem uma grande diferença. Ninguém espera que saibas tudo, mas eles preocupam-se com a forma como lidas com isso. Outros aqui já cobriram as coisas que você pode fazer para obter o máximo de lucro quando tem um pombinho sénior, por isso não vou repetir o conselho deles; estou apenas a tentar esclarecer os sentimentos dos seus colegas de trabalho que levaram a esta situação, para que você possa compreender e evitar isso no futuro.

Isto é quase uma sugestão para o seu empregador, mas talvez pudesse fazer com que funcionasse para si.

Será que lhe atribuíram um mentor quando começou? Dar a um novo empregado um mentor designado, alguém a quem ele possa ir com as suas perguntas, é uma boa ideia. Isto dá-lhes alguém que já tem experiência na empresa e evita que o novo tipo esteja constantemente a incomodar toda a gente :-)

O mentor também conhecerá as pessoas certas para perguntar e os lugares certos para procurar coisas como documentação. Por exemplo, alguns projectos podem ter documentos Google Doc, outro tem-nos num servidor de ficheiros interno e um terceiro tem-nos comprometidos dentro do repositório de origem. Enquanto outros projectos não têm quaisquer documentos.

Outra dica é que quando começar a trabalhar num novo projecto peça para uma visita guiada. Um bloco sólido de quatro horas de tempo consigo e com uma pessoa experiente pode pô-lo a par da situação sem exigir essas quatro horas de tempo como interrupções distribuídas ao longo de vários meses.

Uma coisa a lembrar: o código é como a gramática. As pessoas podem saber que o seu não presta, mas não gostam que lhes digam isso. Por exemplo, se eu chamasse a atenção para o facto de ter escrito repetidamente mal “julgamento”, talvez ficasse aborrecido porque eu não estou a acrescentar nada de construtivo. Bem, eu apenas o fiz de qualquer maneira :)

Mas, conjugado com o facto de muitos programadores experientes tenderem a adoptar uma atitude diva. O que se pretende como perguntas sinceras enraizadas na lógica pode ser muito ameaçador para eles. Tenho trabalhado com inúmeros exemplos (e eu próprio posso ser um) que têm mantido o mesmo velho código de merda que não é relevante há 15 anos. Eles sabem que hoje em dia há uma maneira melhor de o fazer, mas não têm interesse ou motivação para aprender coisas novas, por isso a sua simples presença como a próxima geração é uma ameaça para eles. Quando eles puxarem a prima donna act, basta rir para si mesmo e lembrar que você é quem tem o verdadeiro poder - você tem muitos anos pela frente para trabalhar com a tecnologia do futuro e a direção final da sua carreira ainda está nas suas mãos. Normalmente não é esse o caso dos snobs experientes.

Eu concordo com outros que mencionaram que isto não soa como uma boa incubadora para aspirantes a criadores. No entanto, isto é comum. É preciso tempo e experiência para identificar o seu nicho, encontrar um empregador que se ajuste bem a si e determinar o que mais lhe interessa. Por isso, pague as suas quotas lá, pegue nos seus pedaços, planeie a sua carreira e saia depois de alguns anos de trabalho sólido. Para já, basta seguir os conselhos que lhe são dados, não se preocupe com o PIP e lembre-se sempre que a sua situação actual é apenas um meio para atingir um fim. Os seus supervisores esperam que você entre e saia a horas como se tivesse trabalhado na Wendy’s. Não é assim que tem de ser, mesmo para novos criadores inexperientes, para que possa haver um futuro muito mais risonho noutros sítios.

Tentei dizer-lhes exactamente o que vos disse aqui. Eles ficaram furiosos comigo por discutir com eles “com unhas e dentes” e não seguir bem os seus conselhos. Eu disse que só estava a tentar dizer o meu ponto de vista… eles ficaram mais irritados.

Acho que posso explicar porque ficaram irritados: eles simplesmente não querem feedback. O seu manager não o convidou a dar a sua opinião, simplesmente disse, com este plano de “melhorias necessárias”, que você tem um mau comportamento e precisa de o corrigir, “para seu próprio bem”.

Quem decide o que é mau comportamento? As pessoas que te pagam e que te podem despedir, apenas. Quando você critica as suas decisões, elas ficam aborrecidas, pois pagam-lhe para seguir as suas ordens, não questionam as suas ordens. Eles não são “juízes imparciais”, são eles que lhe pagam. E se você os critica no momento em que eles lhe dão um alerta sério e formal “mudar ou sair” (o que eles chamaram de “conselhos para melhorar”), isso pode levá-los a pensar que você não tem redenção.