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

Non, cela signifie en fait le contraire… car vous ne dérangez pas vos aînés en leur posant des questions que l'on peut facilement trouver sur internet ou dans la documentation.

La plupart d'entre nous, les développeurs, ne se souviennent pas de milliers de lignes de documentations… Je demande aussi pour l'avenir ; par exemple, si je dois écrire du code pendant un entretien pour un autre emploi, je suppose que vous ne devriez pas utiliser la documentation. La plupart des entreprises raisonnables voudraient tester la logique/la structure que vous trouvez dans un test de codage… pas tant 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 une centaine de fois, les bons passent beaucoup de temps à étudier avant chaque patient qu'ils voient. Ils passent également de nombreuses années à l'école de médecine à étudier une matière qui n'a pas beaucoup changé en plusieurs milliers d'années.

Vous êtes en première année dans un secteur où de nouvelles façons de faire sont inventées chaque semaine. Vous êtes inexpérimenté, et il faut donc vous attendre à devoir consulter fréquemment des documents. Tant que vous avez les bases nécessaires 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 en informatique depuis 15 ans et je dois encore faire des recherches presque tous les jours. Un professionnel utilise toutes les ressources dont il dispose pour faire son 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, et non de professionnalisme. Le manque de connaissances est un sujet en soi, mais dans l'ensemble, personne ne sait tout.

Si vous êtes au courant de votre manque de connaissances et que vous y remédiez en consultant des sources tierces, cela signifie que vous disposez d'une stratégie professionnelle pour résoudre votre problème spécifique de manque de connaissances.

Ne pas consulter des sources tierces sans savoir que les choses ne sont pas professionnelles, mais ce n'est pas votre cas.

Lecture complémentaire 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 non professionnel ?

Non. Se souvenir de détails arbitraires infimes est un gaspillage de vos ressources. Vous devriez vous en rappeler beaucoup, tant en PHP (qui manque un peu de cohérence) que dans le développement web en général, si vous vous familiarisez avec plusieurs langages et une douzaine de frameworks.

On se moque de moi parce que j'utilise SO/Documentation si fréquemment que je doute de mes capacités

Ce n'est peut-être pas la façon la plus efficace de résoudre vos tâches.

Utilisez-vous un EDI ? Vos collègues en utilisent-ils ? Parce que la recherche de ces détails minutieux peut être déléguée à la fonction d'autocomplétion de l'IDE. Si vos collègues utilisent la fonction de saisie automatique de leur EDI et que vous utilisez Google à la place, cela peut paraître peu professionnel - non pas parce que vous consultez des documents, mais parce que vous le faites de manière inefficace. Si vos collègues se fient à leur mémoire et que vous utilisez l'autocomplétion, vous serez en mesure de les surpasser dans des tâches qui utilisent un cadre qu'aucun d'entre vous ne connaît, ce qui n'est pas si rare sur le web.

D'autres ont fourni des réponses solides, mais personne ne s'attaque vraiment à ce problème ; je mets l'accent sur le fait que :

La raison pour laquelle je pose cette question est que on se moque de moi parce que j'utilise fréquemment le débordement de piles/documentation 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 ressemble à du bizutage de variétés de jardin (alias : commun) pour moi. Si vous êtes un développeur débutant, vous vous trouvez naturellement dans une hiérarchie où les autres vous testent et appuient sur des boutons dans le cadre de leur propre comportement de bizutage. Cela se produit qu'ils en soient conscients ou non ; c'est tout à fait normal.

Au bout du compte, chaque personne dans le monde utilise des outils de référence pour faire son travail. 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 consiste à faire le lien entre les désirs d'un projet et 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 bravo ! Mais cela n'arrive pas du jour au lendemain et parfois même pas du tout pour certains.

FWIW Je fais du travail informatique depuis plus de 20 ans et ce n'est que depuis quelques années que je peux littéralement visualiser des solutions dans ma tête sans écrire une ligne de code. C'est une compétence que l'on acquiert et que l'on ne peut pas exiger de quelqu'un sur demande.

Bien que cela ne vous fasse pas passer pour un non-professionnel à un professionnel (la grande majorité du temps), vous pouvez faire preuve de prudence face à un client ou un directeur naïf. Tout comme vous, qui avez près d'un an d'expérience en programmation, vous n'êtes pas sûr que les professionnels aient besoin de faire des recherches, de même les personnes ayant une expérience encore moins pertinente peuvent être incertaines

En fait, j'ai défendu d'autres développeurs à quelques reprises lorsqu'un client d'une mission de conseil a dit quelque chose du genre “pourquoi est-ce que je paie cher quelqu'un qui ne peut même pas écrire de code sans le chercher 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.

Ce n'est certainement pas manquer de professionnalisme que de chercher des informations lorsque vous n'êtes pas familier

Cependant, si vous ne retenez pas ces connaissances et que vous cherchez continuellement les mêmes informations, alors il pourrait 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 de ne pas avoir besoin de les vérifier à chaque fois.

Il est bien plus professionnel de lire la documentation et de trouver le bon code que de deviner et de se tromper. C'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 gotchas.

Prenez, par exemple, la fonction mail() . 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 ne contiennent que des en-têtes, c'est-à-dire ne jamais commencer 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 de courrier, le courrier doit contenir un en-tête From. Celui-ci peut être défini avec le paramètre additional_headers, ou un défaut peut être défini dans php.ini.

Cela signifie que le comportement de votre application pourrait dépendre d'un paramètre de configuration global. Il est utile de le 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 paramètre $to doit être conforme à la RFC 2822 .

Bien sûr, vous pourriez être en mesure de produire plus de code en ne lisant pas attentivement la documentation, mais ce ne serait probablement pas du code de qualité professionnelle. Il n'y a pas de honte à vérifier fréquemment la documentation pour s'assurer que vous utilisez correctement le langage et les bibliothèques.

En cherchant des choses dont vous n'êtes pas sûr, vous gagnez du temps et vous pouvez aussi vérifier de meilleures façons de faire quelque chose. Il n'est pas bon de se retrouver coincé à faire toujours la même chose de manière inefficace alors qu'il existe un meilleur moyen de le faire simplement en vérifiant sur le net.

Il y a une différence entre “professionnel” et “connaisseur”. S'il y a des informations que je dois connaître et que j'ai le choix entre rester stupidement assis sur ma chaise et être coincé ou vérifier la documentation, alors je vérifie la documentation. Si cette information est quelque chose qu'une personne bien informée dans ma position devrait savoir, alors la recherche peut montrer que je ne suis pas aussi bien informé que je devrais l'être, mais c'est quand même entièrement professionnel - puisque l'alternative est de ne pas le savoir, et de ne pas l'apprendre. Ce qui (la partie qui n'apprend pas) n'est absolument pas professionnel.

Il serait idiot de supposer que vous savez tout ce que vous devriez savoir, parce que chaque jour il y aura quelque chose de nouveau que vous devriez savoir, qui n'était pas là hier. Même si vous connaissez quelque chose, comment savez-vous que votre connaissance est la meilleure possible ? 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 puisse pas résoudre moi-même. Mais cela prend du temps. Si l'on a le choix entre une heure pour le résoudre soi-même et cinq minutes pour utiliser Google, passer une heure n'est pas professionnel.

Comme d'autres l'ont répondu, il n'y a rien de non-professionnel dans la vérification de la documentation, surtout si l'on considère que la programmation est vaste et qu'il y a toujours un détail que l'on peut oublier et que l'on a pour mission de faire en sorte que le code soit correct.

Il y a cependant des cas que je considère comme des abus de documentation.

J'ai un collègue qui est parfois incapable de trouver sa propre solution à un problème donné. C'est pourquoi il consulte parfois le web pour savoir comment résoudre son problème. La dernière fois, par exemple, il a vérifié comment un cadre web architecturait les validateurs et les compteurs d'erreurs parce qu'il avait une caractéristique apparemment similaire à la conception.

C'est un cas où ce que vous cherchez est beaucoup trop abstrait pour qu'Internet puisse vous aider. Pire encore, vous pourriez trouver des solutions qui semblent convenir, mais qui en fait ne conviennent pas, parce qu'elles sont appliquées à un cas d'utilisation différent. En essayant de récupérer du code, de l'architecture ou un modèle préfabriqué, il aurait plus ou moins injecté dans notre base du code qui aurait pu fonctionner, mais qui serait difficile à maintenir parce qu'il a été é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 des fonctionnalités du langage de base (pas de framework) et je suis doué d'une mémoire fiable quand il s'agit de code, mais j'utilise la documentation chaque fois que je suis bloqué sur quelque chose de trivial. Cependant, si je suis bloqué sur quelque chose de plus important, la bonne chose à faire est de demander l'aide d'un collègue plus expérimenté, vous obtiendrez une bien meilleure réponse.

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 bon signe pour votre professionnalisme.

Ne pas utiliser la documentation

Je connais suffisamment de programmeurs qui trébuchent sans véritable plan pendant de longues périodes, essayant ceci et cela par hasard, fouillant dans le vieux code source où tout ce qu'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 conseil et préfèrent continuer comme ça pour toujours, apparemment.

Seulement des tutoriels ?

Les gens qui cherchent fréquemment sur Google des tutoriels ou des extraits de code, y compris des SO, sans jamais se référer à la documentation, m'irritent sans cesse. Ce comportement est un énorme piège, à mon avis. Il 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 not in en SQL”, “toujours faire XXX”, “ne jamais faire YYY”. Ils auront beaucoup de mal à sortir des sentiers battus, à trouver de nouvelles idées, à se faire une intuition sur la façon de structurer leurs applications et tout ce qui fait les grands développeurs.

Je vous invite à résoudre tout problème d'abord en consultant la documentation/référence, puis à rechercher des bribes de SO ou autres.

Bien sûr, il y a des exceptions. Si votre problème est manifestement un bogue ou quelque chose de très, très, très spécial qui ne sera probablement pas traité dans la documentation (par exemple Si c'est quelque chose qui pourrait être facilement résolu par la documentation/API, alors je vous suggère de vous asseoir et de travailler sur cette partie particulière de votre langage de programmation/des bibliothèques, etc. afin de resserrer vos connaissances. Le meilleur type, pour moi, est un programmeur qui, lorsqu'il rencontre un nouveau sujet, prend le temps de s'asseoir, de creuser, d'avoir une bonne vue d'ensemble et une bonne compréhension technique. La plupart du temps, cela se fait (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 des API, etc. Cela ne peut, à mon avis, jamais être remplacé par autre chose.

Je ne trouve pas étrange de lire, par exemple, les vieux classiques du C++ (bon vieux papier), le Gang des quatre Design Patterns, le manuel (en ligne) “Programming Ruby”, les pages de manuel Perl extrêmement bien faites, le livre Git, certaines RFC, les spécifications HTML/XML/etc. et ainsi de suite du début à la fin. Je l'aurais fait, même pendant mon temps libre et je m'attendrais, franchement, à ce que tout programmeur en vaille la peine (en fonction de ce qu'il travaille, évidemment). Je suis aussi tout à fait conscient que je suis (du moins dans les entreprises où j'ai travaillé, au cours des dernières décennies) tout à fait seul à avoir cette opinion.

(N.B. : Il n'est évidemment pas nécessaire de mémoriser d'énormes listes de références d'API, mais au moins de les survoler pour voir ce qui est disponible et ce que semble être “l'esprit” de l'API. )

Après s'être familiarisé avec le sujet, _il est alors temps de regarder le code d'une tierce partie pour s'en inspirer, ou de se pencher sur des questions plus anciennes de l'OS (ou de poser de nouvelles questions soi-même).

Vous pourriez également constater que lorsque vous avez absorbé un champ comme celui-ci, il devient très facile de trouver des réponses en zoomant directement dans la chair de l'endroit d'où vous tirez votre documentation (pages de man, etc.). À ce stade, l'autocomplétion de votre éditeur peut aussi être déjà suffisante. Et vous pourriez tout aussi bien savoir très vite quand quelque chose n'est pas possible avec l'outil avec lequel vous travaillez, ce qui vous éviterait beaucoup de recherches inutiles.

Votre compétence en tant que programmeur consiste à savoir comment vous pouvez avoir une vue d'ensemble et concevoir des solutions efficaces, et non à savoir combien d'API vous pouvez mémoriser. L'objectif est de faire le travail correctement et efficacement. Si vous deviez rechercher chaque API et chaque détail, je dirais que vous avez des problèmes. J'attends d'un bon développeur qu'il connaisse parfaitement tout ce qui est utilisé fréquemment, récemment et régulièrement, mais qu'il ne gaspille pas son cerveau à des choses peu utilisées alors qu'il est facile de les consulter. Si vous avez visité stackoverflow plus ou moins une fois par jour, ce n'est pas un problème ; si vous y êtes pendant la majeure partie de votre journée de travail habituelle, ce serait un problème.

On se moque de moi parce que j'utilise si souvent le débordement/la documentation de la pile

L'opinion des autres sur vous ne définit pas vous, elle définit seulement eux

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

Non… une partie du professionnalisme est la compétence pour faire le travail. On se moque de vous parce que vos collègues sont des brutes, pas à cause de ce que vous faites 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 n'y ait un manque de temps inhabituel. Utiliser des documents de référence ne prend que quelques secondes.

si je dois écrire un code pendant un entretien pour un autre emploi, je suppose que vous ne devriez pas utiliser la documentation

dépend des règles de l'entretien, certaines 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 !