Usar documentação como programador faz-me parecer pouco profissional?

Não, na verdade significa o contrário… pois não está a perturbar os seus idosos fazendo perguntas que se podem facilmente encontrar na Internet ou através de documentação.

A maioria de nós devs não se lembra de milhares de linhas de documentação… todas as vezes, specialmente quando mudamos de tecnologia

Também estou a pedir o futuro; por exemplo, se tiver de escrever código durante uma entrevista para outro trabalho, acho que não deve usar a documentação.

A maioria das empresas razoáveis gostariam de testar a lógica/estrutura que se apresenta num teste de codificação… não tanto sobre sintaxe.

Alguém me disse uma vez algo do género: “Um cirurgião não pode ler os seus livros sempre que tem de operar um paciente.”

Quem lhe disse isso não sabe como funciona a cirurgia. A menos que seja um procedimento muito comum que o cirurgião tenha praticado cem vezes, os bons passam muito tempo a estudar antes de cada paciente que vêem. Também passam muitos anos na faculdade de medicina a estudar uma matéria que não mudou muito em vários milhares de anos.

Está no seu primeiro ano numa indústria onde todas as semanas estão a ser inventadas novas formas de fazer as coisas. Você é inexperiente, por isso é de esperar que tenha de procurar as coisas com frequência. Desde que tenha as bases para saber se as soluções que encontra realmente resolvem o seu problema e que aprenda com a experiência, não há nada de errado com isto. Sou engenheiro de software há 15 anos e ainda preciso de procurar as coisas quase todos os dias. Um profissional utiliza todos os recursos de que dispõe para fazer o trabalho.

Profissionalismo e conhecimento são duas coisas completamente diferentes.

Olhar para as coisas a partir de fontes de terceiros significa que lhe falta conhecimento, não falta profissionalismo. A falta de conhecimento é um tópico por si só, mas em geral não há ninguém que saiba tudo.

Se sabe da sua falta de conhecimento e lida com ela procurando coisas de fontes de terceiros, isto significa que tem uma estratégia profissional para resolver o seu problema específico de falta de conhecimento.

Não procurar coisas enquanto não sabe que as coisas não são profissionais, mas este não é o seu caso.

Leitura adicional sobre um efeito que contrasta com a sua “estratégia de utilização de documentação”: O efeito Dunning-Kruger

Usar documentação como desenvolvedor faz-me parecer pouco profissional?

Não. Lembrar detalhes minuciosos e arbitrários é um desperdício dos seus recursos. Teria de se lembrar de muitos destes tanto em PHP (que não tem um pouco de consistência) como no desenvolvimento web em geral, se se familiarizar com várias linguagens e uma dúzia de frameworks.

Sou ridicularizado por usar SO/Documentação tão frequentemente o que faz duvidar das minhas capacidades

Esta pode não ser a forma mais eficiente de resolver as suas tarefas.

Utiliza algum IDE? Os seus colegas utilizam alguma? Porque a pesquisa desses detalhes minuciosos pode ser apagada na função de auto-completar do IDE. Utilizar o autocompletar é mais eficiente do que mudar a sua atenção para o browser e procurar uma resposta lá.

Se os seus colegas utilizam o autocompletar do IDE e você utiliza o Google, então isso pode parecer pouco profissional - não porque consulte os documentos mas porque o está a fazer de forma ineficiente.

Se os seus colegas confiam na memória deles e você confia no autocompletar, você será capaz de os oupterformar em tarefas que utilizam alguma estrutura com a qual nenhum de vocês está familiarizado, o que não é assim tão raro na web.

Domine as suas ferramentas e mostre desempenho, isso é profissional.

Outros têm dado respostas sólidas, mas ninguém aborda esta questão de frente; a ênfase ousada é minha:

A razão para fazer esta pergunta é que Fico gozado por usar o Stack Overflow/documentação frequentemente ** o que faz com que outros duvidem das minhas capacidades.**

Quem são estas pessoas que “gozam” consigo e como sabe que “…faz com que outros duvidem das [suas] capacidades?”

Tudo isto me soa como uma variedade de jardim (também conhecido por: comum) a praguejar. Se você é um desenvolvedor júnior está naturalmente numa hierarquia onde outros o testarão e apertarão botões como parte do seu próprio comportamento de hazing. Isto acontece quer estejam conscientes disso ou não; é apenas um par para o curso.

No final do dia, todas as pessoas no mundo usam ferramentas de referência para fazer o trabalho. Os advogados e médicos não têm toneladas de referências e livros aos quais se referem constantemente? A programação não é diferente.

O seu trabalho como programador é fazer a ponte entre os desejos de um projecto e a realidade do próprio código. O teu trabalho não é memorizar disparates arcanos e se chegares ao ponto de te lembrares - e até visualizar - disparates arcanos, então parabéns! Mas isso não acontece da noite para o dia e às vezes não acontece de todo para alguns.

FWIW Eu tenho feito trabalho de computador há mais de 20 anos e só nos últimos anos eu posso literalmente visualizar soluções na minha cabeça sem escrever uma linha de código. É uma habilidade em que se cresce e que não se pode exigir que alguém tenha a pedido.

Embora isto não o faça parecer pouco profissional a um profissional (a grande maioria das vezes), talvez queira usar de cautela perante um cliente ou gestor ingénuo. Tal como você, com quase um ano de experiência em programação, não tem a certeza se os profissionais precisam de procurar coisas, também as pessoas com experiência ainda menos relevante podem não ter a certeza.

Na verdade, defendi outros programadores em algumas ocasiões quando um cliente de um compromisso de consultoria disse algo do género “porque é que estou a pagar bom dinheiro para alguém que nem consegue escrever código sem o procurar na internet?”

Isto tem sido raro, mas é claro que não sei quantas pessoas ficaram com má impressão, mas mantive-me em silêncio.

Não é certamente pouco profissional procurar as coisas quando não se está familiarizado.

No entanto, ** se não se está a reter esse conhecimento e se se está continuamente a procurar as mesmas coisas** , então pode haver um problema. Isso é ineficiente. Torna-o mais lento e isso pode ser a causa da zombaria. É preciso aprender os princípios básicos da sua profissão a ponto de não precisar de os procurar sempre.

É muito mais profissional ler a documentação e acertar o seu código do que adivinhar e errar. Isto é especialmente verdade para uma linguagem como PHP, onde a biblioteca padrão é desenhada ao acaso, difícil de memorizar e cheia de gotchas.

Tome, por exemplo, a função mail() . Sabia que…

additional_headers não tem protecção de cabeçalho de correio. Portanto, os utilizadores devem certificar-se que os cabeçalhos especificados são seguros e contêm apenas cabeçalhos. Ou seja, nunca inicie o corpo do correio colocando múltiplas novas linhas.

Se não está ciente desta advertência, então acaba por introduzir uma vulnerabilidade de segurança .

Quando envia correio, o correio deve conter um cabeçalho De. Este pode ser definido com o parâmetro additional_headers, ou pode ser definido por defeito em php.ini.

Isso significa que o comportamento da sua aplicação pode depender de uma configuração global. Isto é útil para saber, para que possa evitar escrever código que parece funcionar correctamente numa máquina, mas não é portátil para outra.

• O parâmetro $to deve estar em conformidade com RFC 2822 .

Claro, pode ser capaz de arrancar mais código não lendo a documentação cuidadosamente, mas provavelmente não seria um código de qualidade profissional. Não há vergonha em verificar a documentação frequentemente para ter a certeza que está a utilizar correctamente a língua e as bibliotecas.

Olhar para coisas sobre as quais não tem a certeza, poupa tempo e também lhe permite verificar melhores formas de fazer algo. Ficar preso a fazer sempre a mesma coisa de forma ineficiente quando existe uma forma melhor apenas por verificar a rede não é bom.

Há uma diferença entre “profissional” e “conhecedor”. Se há alguma informação que eu preciso de saber, e tenho a opção entre sentar-me estupidamente na minha cadeira e ficar preso, ou verificar a documentação, então eu verifico a documentação. Isso é absolutamente profissional.

Se essa informação é algo que uma pessoa com conhecimento na minha posição deveria saber, então, se olhar para cima pode mostrar que eu não sou tão conhecedor como deveria ser, mas continua a ser totalmente profissional - uma vez que a alternativa é não a conhecer, e não a aprender. O que (a parte de não aprender) é totalmente pouco profissional.

Seria uma parvoíce assumir que se sabe tudo o que se deve saber, porque todos os dias haverá algo fresco que se deve saber, que não estava lá ontem. Mesmo que saiba algo, como sabe que o seu conhecimento é o melhor possível? Consulte a documentação para saber se existe algum conhecimento melhor sobre o mesmo assunto.

É raro que exista um problema que eu próprio não consiga resolver. Mas isso leva tempo. Dada a escolha entre demorar uma hora a perceber por mim próprio e cinco minutos a usar o Google, gastar a hora não é profissional.

Como outros respondem, não há nada como ser pouco profissional para verificar a documentação, especialmente considerando que se é júnior, especialmente considerando que a programação é vasta e que há sempre um detalhe que se pode esquecer e que se tem uma missão para que o código esteja correcto.

Há, no entanto, casos que eu consideraria serem abusos de documentação.

Tenho um colega que, por vezes, é incapaz de encontrar a sua própria solução para um determinado problema. Por isso, por vezes, ele procede à verificação na Internet sobre como resolver o seu problema. Da última vez, por exemplo, verificou como uma estrutura web estava a arquitectar validadores e contadores de erros porque tinha uma característica aparentemente semelhante ao design.

Este é um caso em que o que se procura é demasiado abstracto para que a Internet o possa ajudar. Pior, pode encontrar soluções que aparentemente se encaixam, mas na verdade não o fazem, porque são aplicadas a um caso de utilização diferente. Ao tentar pegar num código/arquitectura/padrão pré-fabricado ele teria mais ou menos injectado código na nossa base que pode ter funcionado, mas seria difícil de manter porque escrito por outra pessoa para um propósito diferente.

Não olho para a documentação muitas vezes porque escrevo código que usa na maior parte das vezes funcionalidades da linguagem central (sem estrutura) e sou dotado de uma memória fiável quando se trata de código, mas uso o doc sempre que estou preso em algo trivial. No entanto, se eu estiver preso em algo superior, a coisa boa a fazer é procurar ajuda de um colega mais experiente, você terá uma resposta muito melhor.

Já têm algumas boas respostas, mas deixem-me acrescentar uma pequena reviravolta…

Eu gosto de pessoas que usam documentação e é um grande sinal para o vosso profissionalismo.

Não usar documentação

Eu conheço programadores suficientes que tropeçam sem um plano real durante longos períodos de tempo, tentando isto e aquilo por acaso, escolhendo através do código-fonte antigo onde o que eles querem alcançar parece já ter sido feito (mas não foi bem feito) e assim por diante. Francamente, eu detesto este tipo de abordagem. Eles nunca vão muito longe, muitas vezes têm de perguntar às pessoas, raramente aceitam conselhos e preferem continuar assim para sempre, ao que parece.

Apenas tutoriais?

As pessoas procuram frequentemente no Google tutoriais ou snippets de código, incluindo SO, Sem alguma vez se referirem a documentação, irritam-me sem fim. Este comportamento é uma grande armadilha, na minha opinião. Conduz a uma espécie de programação alimentada por “conhecimentos” pouco rigorosos, arbitrários e não-sistemáticos. Esses programadores tendem a acabar com muitos preconceitos. É daqui que provêm pepitas como “nunca usar git rebase”, “nunca usar not in em SQL”, “sempre fazer XXX”, “nunca fazer YYYY”. Eles vão ter muita dificuldade em pensar fora da caixa, inventar novas ideias, formar intuição sobre como estruturar as suas aplicações e tudo aquilo que compõe os grandes programadores.

Eu gostaria de vos exortar a resolver qualquer problema primeiro, olhando para a documentação/referência, e então procurar SO ou outros snippets.

Claro que existem excepções. Se o seu problema for algo como um bug, ou algo muito, muito, muito, muito especial que é pouco provável que seja tratado em qualquer tipo de documentação (por exemplo uma combinação especial de bibliotecas/módulos, etc.), então vá directamente para SO.

Se é algo que pode ser facilmente descoberto pela documentação/API, então eu sugeriria que se sentasse e trabalhasse nessa parte específica da sua linguagem de programação/bibliotecas, etc. para que os seus conhecimentos fiquem mais apertados.

Documentação

O melhor tipo, para mim, é um programador que, quando se depara com um novo tópico, leva algum tempo para realmente se sentar, escavar, ter uma boa visão geral e uma boa compreensão técnica. Isto é conseguido na maioria das vezes (mais uma vez, pela minha experiência, com as muitas linguagens de programação com que tive contacto) através da leitura da boa documentação antiga incluindo referências API e assim por diante. Isto, na minha opinião, nunca pode ser substituído por outra coisa.

Não acho estranho ler, por exemplo, os velhos clássicos do C++ (bom e velho papel), o Gang of Four Design Patterns, o (versão online do) manual “Programming Ruby”, as manpages do Perl extremamente bem feitas, o livro Git, certos RFCs, as especificações HTML/XML/etc. e assim por diante, da frente para trás. Eu faria e teria feito isso mesmo no meu tempo livre e, francamente, esperaria isso de qualquer programador que valesse a pena (dependendo com o que estão a trabalhar, obviamente). Também tenho plena consciência de que estou (pelo menos nas empresas em que trabalhei, nas últimas décadas) completamente só com esta opinião.

(N.B.: Obviamente não é necessário memorizar listas enormes de referências API, mas pelo menos ignorá-las para ver o que está disponível e o que o “espírito” da API parece ser. )

Depois de estar completamente confortável com o tópico, then é o momento de olhar para o código de terceiros para inspiração, ou de olhar para perguntas mais antigas de SO (ou fazer novas perguntas você mesmo).

Você também pode descobrir que quando você absorveu um campo como este, fica muito fácil de encontrar respostas, fazendo zoom diretamente na carne de onde quer que você obtenha a sua documentação (páginas de homem, etc.). Neste ponto, o auto-completar do seu editor também pode já ser suficiente. E pode muito bem saber muito em breve quando algo não é possível com a ferramenta com a qual está a trabalhar, poupando muita pesquisa inútil.

A sua habilidade como programador tem a ver com a forma como pode ter uma visão completa e desenhar soluções eficazes, não com a quantidade de APIs que consegue memorizar. O objectivo é fazer o trabalho de forma correcta e eficiente. Se tivesse de procurar cada API e cada detalhe, então eu diria que tem alguns problemas. Eu esperaria que um bom desenvolvedor estivesse completamente familiarizado com tudo o que é usado com frequência, recentemente, e rotineiramente, mas não desperdiçar a inteligência em coisas usadas com pouca frequência quando podem ser facilmente pesquisadas. Se visitasse o stackoverflow mais ou menos uma vez por dia, não seria um problema; se estiver a tratar da maior parte do seu dia típico de trabalho, isso seria um problema.

Sou gozado por usar o Stack Overflow/documentação tão frequentemente

A opinião de outras pessoas sobre si não define you, apenas define them

Usar documentação como desenvolvedor faz-me parecer pouco profissional?

Não… parte de ser profissional é a competência para fazer o trabalho. Está a ser gozado porque os seus colegas são rufias, não por causa de algo que está a fazer mal.

“Um cirurgião não pode ler os seus livros sempre que tem de operar um paciente”

Porque não? Sou céptico em relação a essa afirmação, a menos que haja uma crise de tempo invulgar. Usar material de referência demora apenas segundos.

se eu tiver de escrever código durante uma entrevista para outro trabalho acho que não deve usar a documentação

Depende das regras da entrevista, alguns permitem-no, outros não. Em particular, se for um teste, pode ser permitido. É uma boa ideia verificar primeiro!