Ne vous inquiétez pas: vous êtes un professionnel et vous agissez comme tel.

Les professionnels utilisent toutes les ressources disponibles pour faire le travail, y compris la documentation, le code écrit par d'autres (bibliothèques), l'aide d'experts, etc.

Il n'est pas non plus professionnel d'avoir besoin de consulter une ressource externe. En fait, il ne serait pas professionnel de ne pas utiliser la documentation si vous n'êtes pas sûr de la façon dont quelque chose fonctionne.

Votre niveau de dépendance à la documentation montre-t-il une inexpérience? Bien sûr, dans une certaine mesure. Mais vous êtes inexpérimenté . Après seulement quelques mois de travail, vous n'en saurez pas autant qu'une personne ayant de nombreuses années d'expérience. C'est juste un fait, et personne ne vous en voudra.

Cependant, même les développeurs avec 20 ans d'expérience vérifieront la documentation pour certaines choses. Cela fait toujours partie de la boîte à outils d'un développeur.

Les tests de programmation sont une chose légèrement différente.

Puisqu'ils sont conçus pour évaluer vos propres connaissances et capacités, vous devrez souvent les compléter sans documentation. Ce n'est pas parce que la documentation est mauvaise; c'est juste que, dans l'environnement artificiel d'un bref test qui tente d'évaluer votre capacité globale, les ressources externes peuvent confondre cette image.

Cependant, les tests de programmation typiques sont de nature conceptuelle . Ils concernent généralement votre capacité à créer un algorithme, à concevoir une solution à un problème et à suivre de bonnes pratiques de codage. Ce ne sont pas des choses que vous obtiendriez de toute façon de la documentation. Une erreur de syntaxe mineure occasionnelle n'affectera probablement pas beaucoup votre évaluation.

Est-ce que l'utilisation de la documentation en tant que développeur me fait paraître peu professionnel?

Non, cela signifie en fait le contraire ... car vous ne dérangez pas vos seniors en posant des questions que l'on peut facilement trouver sur Internet ou via la documentation.

La plupart d'entre nous, les développeurs, ne se souviennent pas de milliers de lignes de documentations ... tout le temps, spécialement lorsque nous basculons entre les technologies

Je demande aussi l'avenir; Par exemple, si je dois écrire du code pendant une entrevue pour un autre travail, je suppose que vous ne devriez pas utiliser la documentation.

La plupart des entreprises raisonnables aimeraient tester la logique / structure que vous venez de créer dans un test de codage .. pas tellement sur la syntaxe.

Quelqu'un m'a dit un jour quelque chose comme: "Un chirurgien ne peut pas lire ses livres à chaque fois qu'il doit opérer un patient."

Celui qui vous a dit cela ne sait pas comment fonctionne la chirurgie. À moins que ce ne soit une procédure très courante que le chirurgien a pratiquée cent fois, les bons passent beaucoup de temps à étudier avant chaque patient qu'ils voient. Ils passent aussi de nombreuses années à la faculté de médecine à étudier un sujet qui n'a pas beaucoup changé depuis plusieurs milliers d'années.

Vous êtes dans votre première année dans une industrie où de nouvelles façons de faire sont inventées chaque semaine. Vous êtes inexpérimenté, il faut donc s'attendre à ce que vous deviez rechercher fréquemment des choses. Tant que vous avez les bases pour savoir si les solutions que vous trouvez résolvent réellement votre problème et que vous apprenez de l'expérience, il n'y a rien de mal à cela. Je suis ingénieur logiciel depuis 15 ans et je dois encore chercher des choses presque tous les jours. Un professionnel utilise toutes les ressources dont il dispose pour faire le travail.

Le professionnalisme et les connaissances sont deux choses complètement différentes.

Rechercher des informations auprès de sources tierces signifie que vous manquez de connaissances, pas de professionnalisme. Le manque de connaissances est un sujet pour lui-même, mais dans l'ensemble, personne ne sait tout.

Si vous connaissez votre manque de connaissances et que vous le gérez en recherchant des informations auprès de sources tierces, cela signifie que vous avez un stratégie professionnelle pour résoudre votre problème spécifique de manque de connaissances.

Ne pas chercher les choses sans savoir que les choses ne sont pas professionnelles, mais ce n'est pas votre cas.

Lectures supplémentaires sur un effet qui contraste avec votre "stratégie d'utilisation de la documentation": l'effet Dunning – Kruger

Est-ce que l'utilisation de la documentation en tant que développeur me fait paraître peu professionnel?

Non. Se souvenir de petits détails arbitraires est un gaspillage de vos ressources. Vous devrez vous en souvenir à la fois en PHP (qui manque un peu de cohérence) et dans le développement Web en général, si vous vous familiarisez avec plusieurs langages et une douzaine de frameworks.

On me moque si souvent d'utiliser SO / Documentation, ce qui fait douter de mes capacités

Ce n'est peut-être pas le moyen le plus efficace de résoudre vos tâches.

En utilisez-vous IDE? Vos collègues en utilisent-ils? Parce que la recherche de ces moindres détails peut être supprimée dans la fonction de saisie semi-automatique de l'IDE. L'utilisation de la saisie semi-automatique est plus efficace que de déplacer votre attention vers le navigateur et d'y rechercher une réponse.

Si vos collègues utilisent la saisie semi-automatique de leur IDE et que vous utilisez Google à la place, cela peut sembler non professionnel - non pas parce que vous consultez des documents, mais vous le faites de manière inefficace.

Si vos collègues comptent sur leur mémoire et que vous comptez sur la saisie semi-automatique, vous serez en mesure de les surpasser dans des tâches qui utilisent un cadre que vous ne connaissez pas, ce qui n'est pas cela rare sur le Web.

Maîtrisez vos outils et montrez des performances, c'est professionnel.

D'autres ont fourni des réponses solides, mais personne n'aborde vraiment cette question de front; Je mets l'accent en gras:

La raison pour laquelle je pose cette question est que je me fais moquer d'avoir utilisé fréquemment Stack Overflow / documentation ce qui fait douter les autres de mes capacités.

Qui sont ces gens qui «se moquent» de vous et comment le savez-vous «… fait douter les autres de [vos] capacités?»

Tout cela semble comme le bizutage de variété de jardin (aka: commun) pour moi. Si vous êtes un développeur junior, vous êtes naturellement dans une hiérarchie où d'autres vont vous tester et pousser des boutons dans le cadre de leur propre comportement de bizutage. Cela arrive qu'ils en soient conscients ou non; c'est tout simplement normal pour le cours.

En fin de compte, chaque personne dans le monde utilise des outils de référence pour accomplir son travail. Heck, les avocats et les médecins n'ont-ils pas des tonnes de références et de livres auxquels ils se réfèrent constamment? La programmation n'est pas différente.

Votre travail en tant que programmeur est de relier les désirs d'un projet à la réalité du code lui-même. Votre travail n'est pas de mémoriser des absurdités obscures. et si vous arrivez au point où vous pouvez vous souvenir - et même visualiser - des absurdités obscures, alors félicitations! Mais cela ne se produit pas du jour au lendemain et parfois pas du tout pour certains.

FWIW Je travaille sur ordinateur depuis plus de 20 ans et ce n'est que depuis quelques années que je peux littéralement visualiser des solutions dans mon head sans écrire une ligne de code. C'est une compétence dans laquelle on se développe et on ne peut pas exiger que quelqu'un possède à la demande.

Bien que cela ne vous fasse pas paraître non professionnel pour un professionnel (la grande majorité du temps), vous voudrez peut-être faire preuve de prudence devant un client ou un responsable naïf. Tout comme vous, avec près d'un an d'expérience en programmation, ne savez pas si les professionnels ont besoin de faire des recherches, les personnes ayant une expérience encore moins pertinente pourraient également être incertaines.

En fait, j'ai défendu d'autres développeurs à quelques reprises lorsqu'un client d'un engagement de conseil a dit quelque chose du genre "pourquoi est-ce que je paie beaucoup d'argent pour quelqu'un qui ne peut même pas écrire du code sans regarder sur Internet? "

Cela a été rare, mais bien sûr, je ne sais pas combien de personnes ont eu une mauvaise impression mais sont restées silencieuses.

Il n'est certainement pas non plus professionnel de rechercher des choses lorsque vous n'êtes pas familier.

Cependant, si vous ne retenez pas ces connaissances et que vous recherchez continuellement les mêmes choses , il peut y avoir un problème. C'est inefficace. Cela vous rend plus lent et cela pourrait être la cause des moqueries. Vous devez apprendre les bases de votre profession au point où vous n’avez pas besoin de les consulter à chaque fois.

Il est beaucoup plus professionnel de lire la documentation et de faire le bon code que de deviner et de se tromper. Cela est particulièrement vrai pour un langage comme PHP, où la bibliothèque standard est conçue au hasard, difficile à mémoriser et pleine de pièges.

Prenons, par exemple, le mail () fonction. Saviez-vous que…

• additional_headers n'a pas de protection contre l'injection d'en-tête de courrier. Par conséquent, les utilisateurs doivent s'assurer que les en-têtes spécifiés sont sûrs et qu'ils contiennent uniquement des en-têtes. c'est-à-dire ne jamais démarrer le corps du courrier en mettant plusieurs nouvelles lignes.

  Si vous n'êtes pas conscient de cette mise en garde, vous finissez par introduire une vulnérabilité de sécurité.

• Lors de l'envoi d'un mail, le mail doit contenir un en-tête From. Cela peut être défini avec le paramètre additional_headers , ou une valeur par défaut peut être définie dans php.ini.

  Cela signifie que votre application est le comportement peut dépendre d'un paramètre de configuration global. C'est utile à savoir, afin d'éviter d'écrire du code qui semble fonctionner correctement sur une machine, mais qui n'est pas portable sur une autre.

• Le $ to Le paramètre doit être conforme à la RFC 2822.

  Vous avez vu des milliers d'e-mails, vous pensez donc savoir à quoi ressemble une adresse e-mail acceptable, droite? Lisez les spécifications - vous seriez probablement surpris.

Bien sûr, vous pourrez peut-être créer plus de code en ne lisant pas attentivement la documentation, mais ce ne serait probablement pas code de qualité professionnelle . Il n'y a pas de honte à consulter fréquemment la documentation pour vous assurer que vous utilisez correctement le langage et les bibliothèques.

Chercher des choses dont vous n'êtes pas sûr vous fait gagner du temps et vous permet également de rechercher de meilleures façons de faire quelque chose. Être coincé à faire la même chose encore et encore de manière inefficace alors qu'il existe une meilleure façon de vérifier simplement le net n'est pas bon.

Comme d'autres ont répondu, il n'y a rien de tel que de ne pas être professionnel pour vérifier la documentation, d'autant plus que vous êtes junior, d'autant plus que la programmation est vaste et qu'il y a toujours un détail que vous pouvez oublier et que vous avez une mission pour votre code. correct.

Il y a cependant des cas que je considérerais comme des abus de documentation.

J'ai un collègue qui est parfois incapable de trouver sa propre solution à un problème donné. Par conséquent, il procède parfois à la vérification du Web pour savoir comment résoudre son problème. La dernière fois, par exemple, il a vérifié comment un framework Web architecturait les validateurs et les compteurs d'erreurs, car il avait une fonctionnalité apparemment similaire à concevoir.

C'est un cas où ce que vous recherchez est beaucoup trop abstrait pour qu'Internet puisse vous aider. Pire encore, vous pourriez trouver des solutions qui semblent convenir, mais qui ne le font pas, car elles sont appliquées à un cas d'utilisation différent. En essayant de récupérer du code / architecture / modèle prédéfini, il aurait plus ou moins de code injecté dans notre base qui aurait pu fonctionner, mais serait difficile à maintenir car écrit par quelqu'un d'autre dans un but différent.

Je ne regarde pas souvent la documentation parce que j'écris du code qui utilise principalement les fonctionnalités du langage de base (pas de cadre) et je suis doué d'une mémoire fiable en matière de code, mais j'utilise la documentation chaque fois que je suis coincé sur quelque chose de trivial . Cependant, si je suis coincé sur quelque chose de plus haut niveau, la bonne chose à faire est de demander l'aide d'un collègue plus expérimenté, vous obtiendrez une bien meilleure réponse.

Il y a une différence entre «professionnel» et «bien informé». S'il y a des informations que j'ai besoin de connaître et que j'ai le choix entre m'asseoir bêtement sur ma chaise et rester coincé, ou vérifier la documentation, alors je vérifie la documentation. C'est absolument professionnel.

Si cette information est quelque chose qu'une personne bien informée dans ma position devrait connaître, alors la recherche peut montrer que je ne suis pas aussi bien informé que je devrais l'être, mais c'est toujours entièrement professionnel - puisque l'alternative ce n'est pas le savoir et ne pas l'apprendre. Ce qui (la partie non d'apprentissage) n'est pas du tout professionnel.

Il serait stupide de supposer que vous savez tout ce que vous devez savoir, car il y aura chaque jour quelque chose de nouveau que vous devriez savoir, qui n’était pas là hier. Même si vous savez quelque chose, comment savez-vous que vos connaissances sont les meilleures possibles? Vous consultez la documentation pour savoir s'il existe de meilleures connaissances sur le même sujet.

Il est rare qu'il y ait un problème que je ne parviens pas à résoudre moi-même. Mais cela prend du temps. Étant donné le choix entre prendre une heure pour le comprendre moi-même et cinq minutes avec Google, passer l'heure n'est pas professionnel.

Vous avez déjà quelques bonnes réponses, mais laissez-moi ajouter une petite touche ...

J'aime les gens qui utilisent la documentation et c'est un grand signe de votre professionnalisme.

Je n'utilise pas de documentation

Je connais suffisamment de programmeurs qui trébuchent sans plan réel pendant de longues périodes, essayant ceci et cela par hasard, sélectionnant l'ancien code source où ils veulent à réaliser semble avoir déjà été fait (mais pas tout à fait) et ainsi de suite. Franchement, je déteste ce genre d'approche. Ils ne vont jamais très loin, doivent souvent demander aux gens, prennent rarement des conseils et préfèrent continuer comme ça pour toujours, apparemment.

Seulement des tutoriels?

Les gens recherchent fréquemment des tutoriels ou des extraits de code sur Google y compris SO, sans jamais faire référence à la documentation, m'irrite sans fin. Ce comportement est un énorme piège, à mon avis. Cela conduit à une sorte de programmation alimentée par des «connaissances» à moitié cuites, arbitraires et non systématiques. Ces programmeurs ont tendance à se retrouver avec beaucoup de préjugés. C'est de là que viennent des pépites comme "ne jamais utiliser git rebase ", "ne jamais utiliser pas dans en SQL", "toujours faire XXX", "ne jamais faire YYY". Ils auront du mal à sortir des sentiers battus, à trouver de nouvelles idées, à se faire une idée de la manière de structurer leurs applications et de tout ce qui fait de grands développeurs.

Je vous exhorte à résoudre tout problème en regardant d'abord la documentation / référence, et ensuite recherchez SO ou d'autres extraits.

Bien sûr, il y a des exceptions. Si votre problème est de toute évidence quelque chose comme un bogue, ou quelque chose de très, très, très spécial qui est peu susceptible d'être traité dans toute sorte de documentation (par exemple, une combinaison spéciale de bibliothèques / modules, etc.), alors allez-y bien. à SO.

Si c'est quelque chose qui pourrait facilement être compris par la documentation / API, alors je suggérerais de vous asseoir et de travailler sur cette partie particulière de votre langage de programmation / bibliothèques, etc. afin que vos connaissances soient plus précises.

Documentation

Le meilleur type, pour moi, est un programmeur qui, lorsqu'il rencontre un nouveau sujet, prend le temps de vraiment s'asseoir, creuser dedans, avoir une bonne vue d'ensemble et une bonne compréhension technique. Ceci est la plupart du temps réalisé (encore une fois, d'après mon expérience, avec les nombreux langages de programmation avec lesquels j'ai été en contact) en lisant la bonne vieille documentation, y compris les références API et ainsi de suite. Cela ne peut, à mon avis, jamais être remplacé par autre chose.

Je ne trouve pas bizarre de lire, par exemple, les vieux classiques du C ++ (bon vieux papier), le Gang of Four Design Patterns, la (version en ligne du) manuel "Programming Ruby", les pages de manuel Perl extrêmement bien faites, le livre Git, certains RFC, le HTML / XML / etc. spécifications et ainsi de suite d'avant en arrière. Je le ferais et l'aurais fait même pendant mon temps libre et je l'attendrais franchement de n'importe quel programmeur digne de ce nom (en fonction de ce avec quoi ils travaillent, évidemment). Je suis également parfaitement conscient que je suis (au moins dans les entreprises dans lesquelles j'ai travaillé, au cours des dernières décennies) tout à fait seul avec cette opinion.

(NB: vous n'avez évidemment pas besoin de mémoriser listes de références d'API, mais au moins les passer sous silence pour voir ce qui est disponible et ce que semble être «l'esprit» de l'API.)

Après avoir été parfaitement à l'aise avec le sujet, alors est le moment de regarder du code tiers pour vous inspirer, ou de regarder des questions plus anciennes sur le SO (ou de poser de nouvelles questions vous-même).

Vous pourriez aussi trouver cela lorsque vous en avez absorbé une comme celui-ci, il devient très facile de trouver des réponses en zoomant directement sur la viande d'où vous obtenez votre documentation (pages de manuel, etc.). À ce stade, la saisie semi-automatique de votre éditeur peut également suffire déjà. Et vous pourriez aussi bien savoir assez vite quand quelque chose n'est tout simplement pas possible avec l'outil avec lequel vous travaillez, ce qui vous évitera beaucoup de recherches futiles.

Votre compétence en tant que programmeur concerne la façon dont vous pouvez prendre une vue d'ensemble et concevoir des solutions efficaces, et non le nombre d'API que vous pouvez mémoriser. Le but est de faire le travail correctement et efficacement. Si vous deviez rechercher chaque API et chaque détail, je dirais que vous rencontrez des problèmes. Je m'attendrais à ce qu'un bon développeur soit parfaitement familier avec tout ce qui est utilisé fréquemment, récemment et régulièrement, mais ne gaspille pas de cervelle sur des choses rarement utilisées quand elles peuvent être facilement recherchées. Si vous avez visité stackoverflow plus ou moins une fois par jour, ce n'est pas un problème; si vous y êtes presque toute votre journée de travail, ce serait un problème.

Je suis un peu ridiculisé pour avoir utilisé si souvent Stack Overflow / documentation

Les opinions des autres sur vous ne définissent pas vous , elles définir les

Est-ce que l'utilisation de la documentation en tant que développeur me fait paraître non professionnel?

Non ... compétence pour faire le travail. On se moque de vous parce que vos collègues sont des brutes, pas à cause de quelque chose que vous faites de mal.

"Un chirurgien ne peut pas lire ses livres à chaque fois qu'il doit opérer un patient."

Pourquoi pas? Je suis sceptique quant à cette affirmation à moins qu'il y ait un manque de temps inhabituel. Utiliser du matériel de référence ne prend que quelques secondes.

si je dois écrire du code pendant une entrevue pour un autre travail, je suppose que vous ne devriez pas utiliser la documentation

Cela dépend sur les règles de l'entretien, certains le permettent, d'autres non. En particulier, s'il s'agit d'un test, il peut être autorisé. C'est une bonne idée de vérifier d'abord!