Läßt die Verwendung von Dokumentation als Entwickler mich unprofessionell aussehen?

Nein, es bedeutet eigentlich das Gegenteil… denn Sie stören Ihre Senioren nicht durch Fragen, die man leicht im Internet oder durch Dokumentation finden kann.

Die meisten von uns Entwicklern können sich nicht an tausende von Zeilen Dokumentation erinnern… die ganze Zeit, besonders wenn wir zwischen den Technologien wechseln

Ich frage auch nach der Zukunft; wenn ich z.B. während eines Vorstellungsgesprächs für eine andere Stelle Code schreiben muß, sollten Sie die Dokumentation wohl nicht benutzen.

Die meisten vernünftigen Firmen würden gerne die Logik/Struktur testen, die Sie in einem Codierungstest auffinden… nicht so viel über Syntax.

Jemand sagte mir einmal so etwas wie: “Ein Chirurg kann nicht jedes Mal seine Bücher lesen, wenn er einen Patienten operieren muss.”

Wer Ihnen das gesagt hat, weiß nicht, wie eine Operation funktioniert. Wenn es sich nicht um ein sehr häufiges Verfahren handelt, das der Chirurg schon hundertmal geübt hat, verbringen die guten Chirurgen viel Zeit damit, vor jedem Patienten, den sie sehen, seine Bücher zu studieren. Sie verbringen auch viele Jahre im Medizinstudium, um ein Fach zu studieren, das sich in mehreren tausend Jahren nicht viel verändert hat.

Sie befinden sich im ersten Jahr in einer Branche, in der jede Woche neue Methoden erfunden werden. Sie sind unerfahren, daher ist zu erwarten, dass Sie die Dinge häufig nachschlagen müssen. Solange Sie die Grundlagen haben, um zu wissen, ob die Lösungen, die Sie finden, tatsächlich Ihr Problem lösen, und dass Sie aus den Erfahrungen lernen, ist daran nichts auszusetzen. Ich bin seit 15 Jahren Software-Ingenieur und muss immer noch fast jeden Tag etwas nachschlagen. Ein Profi nutzt jede verfügbare Ressource, um die Arbeit zu erledigen.

Professionalität und Wissen sind zwei völlig verschiedene Dinge.

Das Nachschlagen von Dingen aus Drittquellen bedeutet, dass es Ihnen an Wissen, nicht an Professionalität mangelt. Mangelndes Wissen ist ein Thema für sich, aber im Großen und Ganzen gibt es keine Person, die alles weiß.

Wenn Sie über Ihren Wissensmangel Bescheid wissen und damit umgehen, indem Sie Dinge aus Quellen Dritter nachschlagen, bedeutet dies, dass Sie eine professionelle Strategie haben, um Ihr spezifisches Problem des mangelnden Wissens zu lösen.

Nicht nachschlagen, ohne zu wissen, dass etwas unprofessionell ist, aber das ist nicht Ihr Fall.

Weiterführende Lektüre über einen Effekt, der Ihrer “Strategie der Nutzung von Dokumentation” entgegensteht: Der Mahnkruger-Effekt

Lässt mich die Verwendung von Dokumentation als Entwickler unprofessionell aussehen?

Nein. Die Erinnerung an winzige willkürliche Details ist eine Verschwendung Ihrer Ressourcen. Sie müssten sich eine Menge davon sowohl in PHP (dem es ein wenig an Konsistenz mangelt) als auch in der Webentwicklung im Allgemeinen merken, wenn Sie sich mit mehreren Sprachen und einem Dutzend Frameworks vertraut machen.

Ich werde verspottet, weil ich SO/Dokumentation so häufig verwende, was Zweifel an meinen Fähigkeiten aufkommen lässt.

Dies ist vielleicht nicht der effizienteste Weg, Ihre Aufgaben zu lösen.

Verwenden Sie irgendeine IDE? Benutzen Ihre Kollegen irgendeine? Denn das Nachschlagen dieser winzigen Details kann der Autovervollständigungsfunktion der IDE überlassen werden. Die Verwendung der Autovervollständigung ist effizienter, als Ihre Aufmerksamkeit auf den Browser zu lenken und dort nach einer Antwort zu suchen.

Wenn Ihre Kollegen die Autovervollständigung ihrer IDE verwenden und Sie stattdessen Google verwenden, könnte das unprofessionell aussehen - nicht, weil Sie Dokumente konsultieren, sondern weil Sie es ineffizient tun.

Wenn sich Ihre Kollegen auf ihr Gedächtnis verlassen und Sie sich auf die Autovervollständigung verlassen, dann können Sie sie bei Aufgaben übertrumpfen, die einen Rahmen verwenden, mit dem keiner von Ihnen vertraut ist, was im Web nicht so selten ist.

Beherrschen Sie Ihre Tools und zeigen Sie Leistung, das ist professionell.

Andere haben solide Antworten gegeben, aber niemand spricht das wirklich frontal an; die Betonung liegt auf fett:

Der Grund für diese Frage ist, dass ich verspottet werde, weil ich Stack Overflow/Dokumentation häufig verwende was andere an meinen Fähigkeiten zweifeln lässt.

Wer sind diese Leute, die Sie “verspotten” und woher wissen Sie, dass “…andere an [Ihren] Fähigkeiten zweifeln lässt?”

Das alles klingt für mich nach Gartensorten (alias: gewöhnlich), die mich schikanieren. Wenn Sie ein Nachwuchsentwickler sind, befinden Sie sich natürlich in einer Hierarchie, in der andere Sie testen und Knöpfe drücken, als Teil ihres eigenen Schikanierverhaltens. Dies geschieht unabhängig davon, ob sie sich dessen bewusst sind oder nicht; es gehört einfach dazu.

Am Ende des Tages benutzt jeder einzelne Mensch auf der Welt Referenzwerkzeuge, um seine Arbeit zu erledigen. Haben Anwälte und Ärzte nicht Unmengen von Nachschlagewerken und Büchern, auf die sie sich ständig beziehen? Programmieren ist nicht anders.

Ihre Aufgabe als Programmierer ist es, die Wünsche eines Projekts mit der Realität des Codes selbst zu verbinden. Ihre Aufgabe ist es nicht, arkanen Unsinn auswendig zu lernen, und wenn Sie zu dem Punkt kommen, an dem Sie sich an diesen Unsinn erinnern und ihn sogar visualisieren können, dann herzlichen Glückwunsch! Aber das passiert nicht von heute auf morgen und manchmal auch gar nicht.

FWIW Ich arbeite seit über 20 Jahren am Computer, und erst in den letzten Jahren kann ich Lösungen buchstäblich in meinem Kopf visualisieren, ohne eine Zeile Code zu schreiben. Das ist eine Fertigkeit, in die man hineinwächst und von der man nicht verlangen kann, dass sie jemand auf Abruf hat.

Auch wenn Sie dadurch nicht unprofessionell aussehen auf einen Profi (in den allermeisten Fällen), sollten Sie vor einem naiven Kunden oder Manager Vorsicht walten lassen. Genauso wie Sie, mit fast einem Jahr Programmiererfahrung, nicht sicher sind, ob Profis die Dinge nachschlagen müssen, so könnten auch Leute mit noch weniger relevanter Erfahrung unsicher sein.

Tatsächlich habe ich bei einigen Gelegenheiten andere Entwickler verteidigt, wenn ein Kunde eines Beratungsauftrags etwas in der Art sagte wie “Warum bezahle ich gutes Geld für jemanden, der nicht einmal Code schreiben kann, ohne ihn im Internet nachzuschlagen”

Das war selten, aber natürlich weiß ich nicht, wie viele Leute einen schlechten Eindruck bekamen, aber still geblieben sind.

Es ist sicherlich nicht unprofessionell, Dinge nachzuschlagen, wenn man nicht vertraut ist.

Wenn Sie dieses Wissen jedoch nicht behalten und ständig die gleichen Dinge nachschlagen**, dann könnte es ein Problem geben. Das ist ineffizient. Es macht Sie langsamer, und das könnte die Ursache für den Spott sein. Sie müssen die Grundlagen Ihres Berufs so weit lernen, dass Sie sie nicht jedes Mal nachschlagen müssen.

Es ist weitaus professioneller, die Dokumentation zu lesen und Ihren Code richtig zu machen, als zu raten und falsch zu machen. Das gilt besonders für eine Sprache wie PHP, wo die Standardbibliothek willkürlich aufgebaut, schwer zu merken und voller Gothas ist.

Nehmen Sie zum Beispiel die Funktion mail() . Wussten Sie, dass

additional_headers keinen Schutz gegen das Einfügen von Mail-Headern hat? Daher müssen Benutzer sicherstellen, dass die angegebenen Header sicher sind und nur Header enthalten, d.h. beginnen Sie den Mail-Body niemals mit mehreren Zeilenumbrüchen.

Wenn Sie sich dieser Warnung nicht bewusst sind, führen Sie am Ende eine Sicherheitslücke ein.

Beim Senden einer Mail muss die Mail einen From-Header enthalten. Dies kann mit dem Parameter additional_headers festgelegt werden, oder es kann eine Voreinstellung in php.ini gesetzt werden.

Das bedeutet, dass das Verhalten Ihrer Anwendung von einer globalen Konfigurationseinstellung abhängen könnte. Das ist nützlich zu wissen, damit Sie vermeiden können, Code zu schreiben, der auf einer Maschine korrekt zu funktionieren scheint, aber nicht auf eine andere portierbar ist.

• Der Parameter $to muss RFC 2822 entsprechen.

Sicher, Sie könnten vielleicht mehr Code herauskurbeln, indem Sie die Dokumentation nicht sorgfältig lesen, aber es wäre wahrscheinlich kein Code professioneller Qualität. Es ist keine Schande, die Dokumentation häufig zu überprüfen, um sicherzustellen, dass Sie die Sprache und die Bibliotheken korrekt verwenden.

Das Nachschlagen von Dingen, bei denen Sie sich nicht sicher sind, spart Zeit und ermöglicht es Ihnen auch, nach besseren Möglichkeiten zu suchen, etwas zu tun. Es ist nicht gut, immer und immer wieder dasselbe ineffizient zu tun, wenn es einen besseren Weg gibt, nur indem man das Netz überprüft.

Es besteht ein Unterschied zwischen “professionell” und “sachkundig”. Wenn es einige Informationen gibt, die ich wissen muss, und ich die Wahl habe, ob ich mich dummerweise auf meinen Stuhl setze und feststecke, oder ob ich die Dokumentation überprüfen möchte, dann überprüfe ich die Dokumentation. Das ist absolut professionell.

Wenn diese Informationen etwas sind, das eine sachkundige Person in meiner Position wissen sollte, dann kann das Nachschlagen zeigen, dass ich nicht so sachkundig bin, wie ich sein sollte, aber es ist trotzdem völlig professionell - denn die Alternative ist, sie nicht zu kennen und nicht zu lernen. Was (der nicht lernende Teil) völlig unprofessionell ist.

Es wäre dumm anzunehmen, dass Sie alles wissen, was Sie wissen sollten, denn jeden Tag wird es etwas Neues geben, das Sie wissen sollten, das gestern noch nicht da war. Selbst wenn Sie etwas wissen, woher wissen Sie, dass Ihr Wissen das bestmögliche ist? Man konsultiert die Dokumentation, um herauszufinden, ob es dort draußen besseres Wissen über dasselbe Thema gibt.

Es kommt selten vor, dass es ein Problem gibt, das ich nicht selbst herausfinden kann. Aber es braucht Zeit. Wenn man die Wahl hat zwischen einer Stunde, um es selbst herauszufinden, und fünf Minuten mit Google, ist es unprofessionell, eine Stunde damit zu verbringen.

Wie andere antworten, gibt es nichts Unprofessionelles bei der Überprüfung der Dokumentation, besonders wenn man bedenkt, dass man noch in der Ausbildung ist, besonders wenn man bedenkt, dass die Programmierung sehr umfangreich ist und es immer ein Detail gibt, das man vergessen kann, und dass man eine Aufgabe hat, damit der Code korrekt ist.

Es gibt jedoch Fälle, die ich als Dokumentationsmissbrauch ansehen würde.

Ich habe einen Kollegen, der manchmal nicht in der Lage ist, eine eigene Lösung für ein bestimmtes Problem zu finden. Deshalb schaut er manchmal im Internet nach, wie er sein Problem lösen kann. Beim letzten Mal hat er zum Beispiel überprüft, wie ein Web-Framework Validatoren und Fehlerzähler für die Architektur entwickelt, weil er ein scheinbar ähnliches Merkmal wie das Design hatte.

Dies ist ein Fall, in dem das, was Sie suchen, viel zu abstrakt ist, als dass das Internet Ihnen helfen könnte. Schlimmer noch, Sie könnten Lösungen finden, die scheinbar passen, es aber in Wirklichkeit nicht tun, weil sie auf einen anderen Anwendungsfall angewendet werden. Durch den Versuch, sich einen vorgefertigten Code/Architektur/Muster zu schnappen, hätte er mehr oder weniger Code in unsere Basis eingespeist, der vielleicht funktioniert hätte, aber schwer zu warten wäre, weil er von jemand anderem für einen anderen Zweck geschrieben wurde.

Ich schaue nicht oft in die Dokumentation, weil ich Code schreibe, der hauptsächlich Kernsprachfunktionen verwendet (kein Framework), und ich bin mit einem zuverlässigen Gedächtnis begabt, wenn es um Code geht, aber ich benutze das Dokument jedes Mal, wenn ich an etwas Trivialem festhänge. Wenn ich jedoch auf einer höheren Ebene feststecke, ist es gut, einen erfahreneren Kollegen um Hilfe zu bitten, dann erhalten Sie eine viel bessere Antwort.

Sie haben bereits ein paar gute Antworten, aber lassen Sie mich eine kleine Wendung hinzufügen…

Ich mag Leute, die Dokumentation benutzen, und es ist ein großartiges Zeichen für Ihre Professionalität.

Dokumentation nicht benutzen

Ich kenne genug Programmierer, die ohne einen wirklichen Plan über lange Zeitspannen stolpern und zufällig dieses und jenes ausprobieren, sich durch alten Quellcode wühlen, wo das, was sie erreichen wollen, bereits gemacht worden zu sein scheint (aber nicht ganz) und so weiter. Ehrlich gesagt, verabscheue ich diese Art der Herangehensweise. Sie kommen nie sehr weit, müssen oft Leute fragen, nehmen selten Ratschläge an und ziehen es vor, scheinbar ewig so weiterzumachen.

Nur Tutorials?

Leute googeln häufig nach Tutorials oder Codeschnipseln einschließlich SO, ohne sich jemals auf Dokumentation zu beziehen, ärgern mich ohne Ende. Dieses Verhalten ist meiner Meinung nach eine riesige Falle. Es führt zu einer Art von Programmierung, die durch halbgares, willkürliches, unsystematisches “Wissen” angeheizt wird. Diese Programmierer neigen dazu, mit einer Menge Vorurteile zu enden. Daher stammen Nuggets wie “verwende nie git rebase”, “verwende nie not in in SQL”, “mache immer XXX”, “mache nie YYY”. Es wird ihnen sehr schwer fallen, über den Tellerrand hinauszudenken, neue Ideen zu entwickeln, eine Intuition dafür zu entwickeln, wie ihre Anwendungen zu strukturieren sind und all das Zeug, das großartige Entwickler ausmacht.

Ich möchte Sie dringend bitten, jedes Problem zuerst zu lösen, indem Sie sich die Dokumentation/Referenz ansehen und dann nach SO oder anderen Schnipseln suchen.

Natürlich gibt es Ausnahmen. Wenn Ihr Problem ganz offensichtlich so etwas wie ein Fehler oder etwas sehr, sehr, sehr besonderes ist, das wahrscheinlich in keiner Art von Dokumentation behandelt wird (z.B, eine spezielle Kombination von Bibliotheken/Modulen usw.), dann gehen Sie auf jeden Fall direkt zu SO.

Wenn es etwas ist, das leicht durch Dokumentation/API herausgefunden werden könnte, dann würde ich vorschlagen, sich hinzusetzen und an diesem speziellen Teil Ihrer Programmiersprache / Bibliotheken usw. zu arbeiten, so dass Ihr Wissen enger wird.

Dokumentation

Die beste Art ist für mich ein Programmierer, der sich, wenn er auf ein neues Thema stößt, die Zeit nimmt, sich wirklich hinzusetzen, sich darin zu vertiefen, einen guten Überblick und ein gutes technisches Verständnis zu bekommen. Dies wird in den meisten Fällen erreicht (wiederum nach meiner Erfahrung mit den vielen Programmiersprachen, mit denen ich Kontakt hatte), indem man die gute alte Dokumentation einschließlich API-Referenzen und so weiter liest. Dies kann meiner Meinung nach niemals durch etwas anderes ersetzt werden.

Ich finde es nicht sonderbar, z.B. die alten C++-Klassiker (gutes altes Papier), die Gang of Four Design Patterns, das (Online-Version des) “Programming Ruby”-Handbuch, die extrem gut gemachten Perl-Manpages, das Git-Buch, bestimmte RFCs, die HTML/XML/etc. Spezifikationen und so weiter von vorne bis hinten zu lesen. Ich würde das auch in meiner Freizeit tun und getan haben und würde es, offen gesagt, von jedem Programmierer erwarten, der sein Salz wert ist (natürlich abhängig davon, womit er arbeitet). Ich bin mir auch durchaus bewusst, dass ich (zumindest in den Firmen, in denen ich in den letzten Jahrzehnten gearbeitet habe) mit dieser Meinung ziemlich allein bin.

(N.B.: Offensichtlich müssen Sie sich keine riesigen Listen von API-Referenzen merken, aber zumindest diese beschönigen, um zu sehen, was verfügbar ist und was der “Geist” der API zu sein scheint. )

Nachdem Sie sich mit dem Thema gründlich vertraut gemacht haben, dann ist es an der Zeit, 3rd-Party-Code zur Inspiration anzuschauen oder sich ältere SO-Fragen anzuschauen (oder selbst neue Fragen zu stellen).

Sie werden vielleicht auch feststellen, dass, wenn Sie ein Feld wie dieses absorbiert haben, es sehr einfach wird, Antworten zu finden, indem Sie direkt in das Fleisch zoomen, woher Sie Ihre Dokumentation auch immer bekommen (Man Pages etc.). An diesem Punkt könnte auch die Autovervollständigung Ihres Editors bereits ausreichen. Und vielleicht wissen Sie auch schon sehr bald, wenn etwas mit dem Werkzeug, mit dem Sie arbeiten, einfach nicht möglich ist, was Ihnen eine Menge vergebliches Suchen erspart.

Bei Ihren Fähigkeiten als Programmierer geht es darum, wie Sie das Gesamtbild erfassen und effektive Lösungen entwerfen können, nicht darum, wie viele APIs Sie sich merken können. Das Ziel ist es, die Arbeit korrekt und effizient zu erledigen. Wenn Sie jede API und jedes Detail nachschlagen müssten, dann würde ich sagen, dass Sie einige Probleme haben. Ich würde erwarten, dass ein guter Entwickler mit allem, was häufig, in letzter Zeit und routinemäßig verwendet wird, gründlich vertraut ist, aber keine Gedanken an Dinge verschwendet, die nur selten verwendet werden, wenn man sie leicht nachschlagen kann. Wenn Sie Stackoverflow mehr oder weniger einmal am Tag besucht haben, ist das kein Problem; wenn Sie die meiste Zeit Ihres typischen Arbeitstages damit beschäftigt sind, wäre das ein Problem.

Ich werde irgendwie verspottet, weil ich Stack Overflow/Dokumentation so häufig benutze

Die Meinung anderer Leute über Sie definiert nicht Sie, sondern nur Sie

Läßt die Verwendung von Dokumentation als Entwickler mich unprofessionell aussehen?

Nein… ein Teil des Professionellen ist die Kompetenz, die Arbeit zu erledigen. Sie werden verspottet, weil Ihre Kollegen Rüpel sind, nicht wegen etwas, das Sie falsch machen.

“Ein Chirurg kann nicht jedes Mal, wenn er einen Patienten operieren muss, seine Bücher lesen.”

Warum nicht? Ich bin skeptisch gegenüber dieser Behauptung, es sei denn, es gibt eine ungewöhnliche Zeitnot. Die Verwendung von Referenzmaterial dauert nur Sekunden.

Wenn ich während eines Vorstellungsgesprächs für eine andere Stelle Code schreiben muss, sollten Sie die Dokumentation wohl nicht verwenden.

Das hängt von den Regeln des Vorstellungsgesprächs ab, manche erlauben es, manche nicht. Insbesondere, wenn es sich um einen Test handelt, kann es erlaubt sein. Es ist eine gute Idee, dies zuerst zu überprüfen!