O maior fator que me impede de ser um desenvolvedor estelar é a minha confiança nos outros. Sinto que faço muitas perguntas porque temo as consequências de quebrar tudo e segurar todos. Portanto, sou muito cauteloso ao fazer tantas perguntas que, basicamente, recebo as respostas depois de bastante questionamento. Eu reconheci que isso é ruim, mas eu quero parar com isso. Parte disso acontece em momentos em que eu simplesmente não conheço o código (ou é um ramo com o qual nunca trabalhei ou é um produto totalmente novo), mas quero confiar menos nos outros. Como prefácio, esses tipos de perguntas não são sobre padrões ou linguagens genéricas: geralmente minhas perguntas giram em torno de como codificamos em nossa empresa e como fazemos as coisas funcionarem em nosso ecossistema. Quero poder tirar especificações e rolar com elas sem ter que sentir que preciso obter ajuda a cada passo do caminho. Isso é normal? Você já passou por isso e, em caso afirmativo, como superou isso?
fonte
Respostas:
Vejo alguns novos desenvolvedores entrarem em um emprego e imediatamente me sinto inadequado. Eu fiz o mesmo no início da minha carreira. Acho que há pelo menos dois grandes problemas que os mais espertos precisam superar: percepção do tempo e sua própria capacidade natural.
Percepção do tempo Pessoas
espertas estão acostumadas a resolver problemas de forma relativamente rápida. Lembro-me de estar horrorizado quando tive que passar uma hora em um único problema de cálculo. Passar 60 minutos em um problema não é mais nada. Esses dias acabaram ... enterre-os e diga adeus. A complexidade e o tamanho da maioria dos softwares hoje em dia é escandalosa. As pessoas não entendem todas as ferramentas que precisam usar para realizar as tarefas por mais tempo. Um dos principais homens da linguagem JavaScript, Douglas Crockford, disse:
"Misapplication of standard tools...is the new standard."Simplesmente não há tempo suficiente no mundo para aprender todas as ferramentas de desenvolvimento.
Habilidade natural
Sua inteligência, capacidade de resolução de problemas e habilidades naturais levaram você a todo o show do desenvolvedor em primeiro lugar. Simplesmente não há espaço para nada menos neste campo. Então, o que você faz com 100.000 linhas de código, linguagens e estruturas que você mal conhece, padrões de design e paradigmas que as pessoas estão empurrando para você, caras que sabem a maior parte do tempo como as costas da mão, clientes que querem ontem e um chefe quem espera o seu mundo? Surpreenda-se, pois sua capacidade natural falha.
Sim, isso é normal. Eu ainda enlouqueci com algumas das coisas que são jogadas no meu caminho.
O que pode ser feito?
É hora de melhorar essas habilidades naturais com um bom trabalho à moda antiga. Trabalhe para dividir os problemas em partes menores. E perceba que, diferentemente de muitas coisas que você pode ter feito no passado, esses problemas levam muito tempo para serem resolvidos. Portanto, não desista após apenas 15 minutos de examinar um problema complexo. Em vez disso, divida os problemas e pare de assistir ao relógio. Depois de um tempo, 30 minutos trabalhando com um problema realmente não é mais o que costumava ser.
A autoconfiança desempenha um papel importante na capacidade de se autogovernar. O mesmo acontece com a equipe, especialmente os idosos mais experientes. É bom ter cuidado para não quebrar as coisas, mas isso não significa que você precise fazer um fluxo constante de perguntas.
Em vez disso, use o controle de origem. Contanto que você não verifique uma alteração, não poderá quebrar o produto principal e irritar outros desenvolvedores. Além disso, faça alterações que você possa entender e testar e certifique-se de testá-las bem antes do check-in.
Até tenho um pequeno projeto de teste que uso para escrever programas simples e únicos, para não precisar me preocupar com todos os acontecimentos no aplicativo principal.
Por fim, lembre-se de que toda decisão vem com algum nível de troca e devolução. Não há como avançar sem fazer algum tipo de sacrifício em algum nível. Não lute pela perfeição, lute pela grandiosidade e lembre-se de suas ações. Porque você sempre precisa estar preparado para receber críticas e explicar suas idéias e por que você as criou. Orgulhe-se das decisões que você toma. Mesmo quando estão errados, há muito a ser aprendido.
fonte
A primeira coisa é não ter medo de fazer perguntas. Já vi arquitetos seniores fazendo perguntas sobre código. Não se espera que eles saibam tudo; espera-se que eles saibam o suficiente para fazer o trabalho e possam descobrir o resto.
Provavelmente, as melhores táticas seriam:
fonte
Não tenha medo de fazer perguntas "gerais"
Eu costumava tentar encontrar a menor pergunta que eu pudesse fazer e ainda ser capaz de prosseguir com o meu trabalho, com medo de ser considerado incompetente se fizesse perguntas gerais que todo mundo parece saber a resposta. Não entendi a diferença entre ignorância e incompetência. Ignorância significa apenas que você ainda não aprendeu algo e é perfeitamente aceitável desde que não persista. Fingir não ser ignorante é muito pior.
Se você achar que as respostas das pessoas estão apenas levando você até agora, peça que elas ensinem você a pescar, em vez de lhe entregar outro peixe. Pergunte como sua parte se encaixa no todo. Se sua pergunta parece tão básica quanto "o que é o SQL mesmo assim", faça-a mais cedo ou mais tarde. Você pode parecer um pouco tolo agora, mas parecerá muito mais tolo depois.
Dê a si mesmo um período de espera
Não faça perguntas assim que as tiver. Dependendo da complexidade, aguarde de meia hora a um dia para tentar descobrir por conta própria. Muitas vezes você vai resolver isso sozinho. Caso contrário, você poderá dizer ao colega o que não funcionou, o que pode ajudá-lo a dar uma resposta melhor.
Além disso, se o seu colega não souber uma resposta em sua cabeça, preste atenção em como ele chega a ela. Muitas vezes você não precisa de tanta ajuda quanto pensa. Se eu não tiver tempo para fazer uma pergunta, frequentemente aponto alguém para uma direção vaga e digo que vou seguir um minuto, e eles geralmente o resolvem quando chego lá.
Jogue fora alguns rascunhos
Não tenha medo de escrever um código que nunca será lançado. Quanto mais experiência obtiver, mais cedo você será capaz de dizer que está seguindo o caminho errado, mas o caminho errado ainda acontece. Muitas vezes o valor de uma solução não é aparente até que você a tenha visto da maneira errada primeiro.
fonte
Auto-suficiência viria com
Fazer perguntas com frequência correria o risco de mostrar que você não possui as duas.
Se você alterar seu domínio, tecnologia, plataforma e idioma, retornará à estaca zero (quase sem contar com a sua maior capacidade de lidar com problemas semelhantes e conhecimentos transferíveis)
Não fazer perguntas quando realmente necessário desperdiçaria muito tempo valioso de produção.
Pode funcionar a seu favor ao escrever uma palavra sobre sua suposição sobre a extensão de um possível dano, se você fizer errado. ou o que você acha que pode quebrar para obter uma avaliação real de suas suposições. Muitas vezes, pode revelar pontos e ângulos perdidos.
Ser cauteloso é bom. Mas o melhor é começar a determinar a natureza de suas perguntas. É melhor anotá-lo em papel e examinar sua dificuldade / valor.
fonte
Eu diria para examinar as coisas em que você está trabalhando e começar a tomar decisões por si mesmo (mantendo as especificações do aplicativo, é claro). Até agora, você deve ter uma boa noção do que é uma mudança de longo alcance e do que é uma mudança simples. Comece com os mais simples. Se você acha que está fazendo certo, faça.
Você cometerá erros e esses são inestimáveis. Aprenda tudo o que puder com eles quando eles acontecerem, o que fará com que você faça um trabalho melhor na próxima vez.
Quando estiver familiarizado com as decisões menores, comece a tomar as maiores. Você precisará decidir até onde ir com isso com base no seu projeto / ambiente / equipe.
Esse é o lado da tomada de decisão. A outra coisa que você precisa fazer é continuar alimentando seu cérebro para que ele possa ajudar a orientar suas decisões. Siga sites que cobrem sua tecnologia. Existem tutoriais on-line de quase tudo o que existe, cobrindo tudo, do simples ao bizarro complexo. Não tenha medo de perguntar às pessoas por que elas tomam certas decisões - como buscadoras de informações, para não serem confrontadoras. A maioria das pessoas fica feliz em explicar as coisas e você pode aprender um pouco com elas.
Depois de ter o conhecimento técnico, o resto é sabedoria e confiança, e eles vêm com experiência.
fonte
Quando eu era novato, fazia perguntas e tentava sempre obter uma resposta parcial, usando as ferramentas disponíveis; e quando chegasse o mais longe possível, descobriria exatamente como formular minha pergunta para ser o mais claro e conciso possível, sob a suposição de que a pessoa a quem eu estava pedindo ajuda estava ocupada. Com esse preparo, acho que ninguém se importou de me fazer perguntas e, na verdade, tive a impressão de que eles gostaram. Mais tarde, quando me tornei especialista em domínio, também gostei de ajudar as pessoas que deixaram claro que respeitavam meu tempo.
A outra coisa que fiz foi, todos os dias, escolher a arquitetura do sistema. Outros pôsteres comentaram sobre o que é uma empresa massiva em sistemas modernos, quão difícil é lidar com eles. Então, eu fazia turnês pelo código: começava em algum ponto de entrada sensato e depois o rastreava, fazendo anotações para mim mesmo sobre como funcionava, fazendo perguntas que às vezes eu respondia por mim, às vezes perguntava a outras pessoas. Esse tipo de familiaridade abrangente e competência em domínio leva tempo, mas você pode acelerar; e quanto mais você faz, mais cedo será auto-suficiente da maneira que desejar.
fonte