Lässt mich die Verwendung von Dokumentation als Entwickler unprofessionell erscheinen?
Ich bin Junior-Entwickler und arbeite im Rahmen meines dualen Studiums alle zwei Monate in einem Softwareentwicklungsunternehmen.
Obwohl ich seit fast 1 Jahr programmiere (3 x 3 Monate Berufserfahrung + Nebenprojekte), muss ich während meines Arbeitstages ziemlich oft die Dokumentation und/oder den Stack Overflow überprüfen. Ich fürchte, das lässt mich unprofessionell oder unerfahrener aussehen, als ich tatsächlich bin (ich bin ziemlich vertraut mit dem Entwerfen und Erstellen von Software, muss aber oft nach Begriffen wie „PHP/JavaScript-Funktion, die XYZ macht“) suchen. In den meisten Fällen sollte ich dies bereits wissen, da ich dies bereits zuvor verwendet habe, es aber noch einmal überprüfen möchte, bevor ich Fehler mache.
Der Grund für diese Frage ist, dass ich irgendwie verspottet werde, weil ich Stack Overflow/Dokumentation so häufig verwende, was andere und mich selbst an meinen Fähigkeiten zweifeln lässt. Für mich ist es selbstverständlich, effizienter zu arbeiten und der Sprache bewusster zu werden. Jemand hat mir mal so etwas gesagt wie: „Ein Chirurg kann nicht jedes Mal seine Bücher lesen, wenn er einen Patienten operieren muss.“ Was meiner Meinung nach Unsinn ist.
Ich frage auch nach der Zukunft; zB wenn ich während eines Vorstellungsgesprächs für einen anderen Job Code schreiben muss, denke ich, dass Sie die Dokumentation nicht verwenden sollten.
Keine Sorge: Sie sind ein Profi und handeln auch so.
Fachleute nutzen alle verfügbaren Ressourcen, um ihre Arbeit zu erledigen, einschließlich Dokumentation, Code, der von anderen geschrieben wurde (Bibliotheken), Hilfe von Experten usw.
Es ist nicht unprofessionell, eine externe Ressource konsultieren zu müssen. Tatsächlich wäre es unprofessionell, keine Dokumentation zu verwenden, wenn Sie sich nicht sicher sind, wie etwas funktioniert.
Zeigt Ihr Vertrauen in die Dokumentation Unerfahrenheit? Sicher, bis zu einem gewissen Grad. Aber du bist unerfahren . Nach nur wenigen Monaten im Job wissen Sie nicht so viel wie jemand mit langjähriger Erfahrung. Das ist nur eine Tatsache, und niemand wird es Ihnen wahrscheinlich vorhalten.
Aber auch Entwickler mit 20 Jahren Erfahrung werden die Dokumentation auf einige Dinge überprüfen. Dies ist immer Teil des Toolkits eines Entwicklers.
Programmiertests sind eine etwas andere Sache.
Da sie dazu dienen, die eigenen Kenntnisse und Fähigkeiten zu beurteilen, müssen Sie sie oft ohne Nachweise absolvieren. Das liegt nicht daran, dass die Dokumentation schlecht ist; Es ist nur so, dass in der künstlichen Umgebung eines kurzen Tests, der versucht, Ihre Gesamtfähigkeit zu bewerten, externe Ressourcen dieses Bild verwirren können.
Typische Programmiertests sind jedoch konzeptioneller Natur. In der Regel geht es dabei um Ihre Fähigkeit, einen Algorithmus zu erstellen, eine Lösung für ein Problem zu entwerfen und gute Codierungspraktiken zu befolgen. Das sind Dinge, die Sie sowieso nicht aus der Dokumentation bekommen würden. Wenn Sie gelegentlich ein kleines Syntaxdetail falsch machen, wirkt sich dies wahrscheinlich nicht sehr auf Ihre Bewertung aus.
Does your level of reliance on documentation show inexperience? Sure, to a certain extent.
- Nein, tut es nicht.Lässt mich die Verwendung von Dokumentation als Entwickler unprofessionell erscheinen?
Nein, es bedeutet eigentlich das Gegenteil ... da Sie Ihre Senioren nicht stören, indem Sie Fragen stellen, die man leicht im Internet oder in Dokumentationen finden kann.
Die meisten von uns Entwicklern können sich nicht an Tausende von Dokumentationszeilen erinnern... ständig, besonders wenn wir zwischen Technologien wechseln
Ich frage auch nach der Zukunft; zB wenn ich während eines Vorstellungsgesprächs für einen anderen Job Code schreiben muss, denke ich, dass Sie die Dokumentation nicht verwenden sollten.
Die meisten vernünftigen Unternehmen möchten die Logik/Struktur testen, die Sie in einem Codierungstest finden. Nicht so viel über die Syntax.
Jemand hat mir mal so etwas gesagt wie: „Ein Chirurg kann nicht jedes Mal seine Bücher lesen, wenn er einen Patienten operieren muss.“
Wer auch immer Ihnen das gesagt hat, weiß nicht, wie eine Operation funktioniert. Wenn es sich nicht um ein sehr häufiges Verfahren handelt, das der Chirurg hundertmal geübt hat, verbringen die Guten viel Zeit damit, vor jedem Patienten, den sie sehen, zu studieren. Sie verbringen auch viele Jahre an der medizinischen Fakultät und studieren ein Fach, das sich seit mehreren tausend Jahren nicht wesentlich verändert hat.
Sie befinden sich in Ihrem ersten Jahr in einer Branche, in der jede Woche neue Vorgehensweisen erfunden werden. Sie sind unerfahren, daher ist mit häufigem Nachschlagen zu rechnen. Solange Sie die Grundlagen haben, um zu wissen, ob die Lösungen, die Sie finden, Ihr Problem tatsächlich lösen, und dass Sie aus der Erfahrung lernen, ist daran nichts auszusetzen. Ich bin seit 15 Jahren Softwareentwickler und muss immer noch fast täglich nachschlagen. Ein Profi nutzt alle Ressourcen, die ihm zur Verfügung stehen, 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 mangelt, nicht an Professionalität. Mangelndes Wissen ist ein Thema für sich, aber insgesamt gibt es niemanden, der alles weiß.
Wenn Sie Ihren Mangel an Wissen kennen und damit umgehen, indem Sie bei Drittanbietern nachschlagen, haben Sie eine professionelle Strategie, um Ihr spezifisches Problem des Mangels an Wissen zu lösen.
Dinge nicht nachzuschlagen, ohne diese Dinge zu wissen, ist unprofessionell, aber das ist nicht Ihr Fall.
Weiterführende Literatur zu einem Effekt, der Ihrer „Dokumentationsstrategie“ entgegensteht: Der Dunning-Kruger-Effekt
Lässt mich die Verwendung von Dokumentation als Entwickler unprofessionell erscheinen?
Nein. Das Erinnern an kleinste willkürliche Details ist eine Verschwendung Ihrer Ressourcen. Sie müssten sich viele davon merken, sowohl in PHP (dem es ein wenig an Konsistenz mangelt) als auch in der Webentwicklung im Allgemeinen, wenn Sie sich mit mehreren Sprachen und einem Dutzend Frameworks vertraut machen.
Ich werde verspottet, weil ich SO/Documentation so häufig benutze, was dazu führt, dass ich an meinen Fähigkeiten zweifele
Dies ist möglicherweise nicht der effizienteste Weg, um Ihre Aufgaben zu lösen.
Benutzt du irgendeine IDE? Verwenden Ihre Kollegen welche? Weil das Nachschlagen dieser winzigen Details an die Autovervollständigungsfunktion von IDE delegiert werden kann. Die Verwendung der automatischen Vervollständigung ist effizienter, als Ihre Aufmerksamkeit auf den Browser zu lenken und dort nach einer Antwort zu suchen.
Wenn Ihre Kollegen die automatische Vervollstä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 automatische Vervollständigung verlassen, können Sie sie bei Aufgaben übertreffen, die ein Framework verwenden, mit dem keiner von Ihnen vertraut ist, was im Web nicht so selten ist.
Beherrschen Sie Ihre Werkzeuge und zeigen Sie Leistung, das ist professionell.
upper
(in PHP-Datei) ein und IDEA bietet 3 Optionen: ctype_upper
, mb_strtoupper
und strtoupper
. Beide beginnen nicht mit „upper“, aber sie sind alle relevant. Sind Sie sicher, dass Autocomplete für C++ so viel schlimmer ist?htmlentities
codieren und html_entity_decode
decodieren sollte.Andere haben solide Antworten gegeben, aber niemand spricht dies wirklich frontal an; fette Hervorhebung von mir:
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“?
Das alles klingt für mich nach Gartenvielfalt (auch bekannt als: gewöhnlich). Wenn Sie ein Junior-Entwickler sind, befinden Sie sich natürlich in einer Hierarchie, in der andere Sie testen und Knöpfe drücken, als Teil ihres eigenen Hazing-Verhaltens. Dies geschieht, ob sie sich dessen bewusst sind oder nicht; es ist einfach selbstverständlich.
Letztendlich verwendet jeder einzelne Mensch auf der Welt Referenztools, um seine Arbeit zu erledigen. Verdammt, haben Anwälte und Ärzte nicht Unmengen von Referenzen und Büchern, auf die sie sich ständig beziehen? Programmieren ist nicht anders.
Ihre Aufgabe als Programmierer besteht darin, 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 an den Punkt kommen, an den Sie sich an arkanen Unsinn erinnern – und sogar visualisieren – können, dann herzlichen Glückwunsch! Aber das geht nicht von heute auf morgen und bei manchen 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. Es ist eine Fähigkeit, in die man hineinwächst und die nicht verlangt werden kann, die jemand auf Anfrage hat.
Obwohl Sie dadurch für einen Fachmann nicht unprofessionell aussehen (in den allermeisten Fällen), sollten Sie vor einem naiven Kunden oder Manager Vorsicht walten lassen. So wie Sie sich mit fast einem Jahr Programmiererfahrung nicht sicher sind, ob Profis nachschlagen müssen, können auch Menschen mit noch weniger relevanter Erfahrung unsicher sein.
Tatsächlich habe ich einige Male andere Entwickler verteidigt, als ein Kunde eines Beratungsauftrags etwas in der Art sagte: "Warum bezahle ich gutes Geld für jemanden, der nicht einmal Code schreiben kann, ohne im Internet nachzuschlagen?"
Das war selten, aber ich weiß natürlich nicht, wie viele Leute einen schlechten Eindruck bekommen haben, aber geschwiegen haben.
Es ist sicherlich nicht unprofessionell, Dinge nachzuschlagen, wenn man sich nicht auskennt.
Wenn Sie dieses Wissen jedoch nicht behalten und ständig dieselben Dinge nachschlagen , dann könnte es ein Problem geben. Das ist ineffizient. Es macht dich langsamer und das könnte der Grund für das Spotten sein. Sie müssen die Grundlagen Ihres Berufes so weit lernen, dass Sie sie nicht jedes Mal nachschlagen müssen.
Es ist viel professioneller, die Dokumentation zu lesen und Ihren Code richtig zu machen, als zu raten und es falsch zu machen. Dies gilt insbesondere für eine Sprache wie PHP, bei der die Standardbibliothek willkürlich gestaltet, schwer zu merken und voller Fallstricke ist.
Nehmen Sie zum Beispiel die mail()
Funktion. Hast Du gewusst…
additional_headers
hat keinen Mail-Header-Injection-Schutz. Daher müssen Benutzer sicherstellen, dass die angegebenen Header sicher sind und nur Header enthalten. dh beginnen Sie den Mail-Body niemals mit mehreren Zeilenumbrüchen.
Wenn Sie sich dieser Einschränkung nicht bewusst sind, führen Sie am Ende eine Sicherheitslücke ein .
Beim Senden von E-Mails muss die E-Mail einen From-Header enthalten. Dies kann mit dem
additional_headers
Parameter eingestellt werden, oder es kann eine Voreinstellung in eingestellt werdenphp.ini
.
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 einem Computer korrekt zu funktionieren scheint, aber nicht auf einen anderen portierbar ist.
Der $to
Parameter muss RFC 2822 entsprechen .
Sie haben Tausende von E-Mails gesehen, also glauben Sie zu wissen, wie eine akzeptable E-Mail-Adresse aussieht, richtig? Lesen Sie die Spezifikation – Sie wären wahrscheinlich überrascht.
Sicher, Sie könnten möglicherweise mehr Code herauskitzeln, indem Sie die Dokumentation nicht sorgfältig lesen, aber es wäre wahrscheinlich kein Code in professioneller Qualität. Es ist keine Schande, die Dokumentation regelmäßig 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 wieder ineffizient das Gleiche zu tun, wenn es einen besseren Weg gibt, indem man einfach das Netz überprüft.
Wie andere antworten, ist es nicht unprofessionell, die Dokumentation zu überprüfen, insbesondere wenn man bedenkt, dass man ein Junior ist, insbesondere wenn man bedenkt, dass die Programmierung umfangreich ist und es immer ein Detail gibt, das man vergessen kann, und man eine Mission hat, dass der Code korrekt ist.
Es gibt jedoch Fälle, die ich als Dokumentationsmissbrauch betrachten würde.
Ich habe einen Kollegen, der manchmal keine eigene Lösung für ein bestimmtes Problem finden kann. Daher fährt er manchmal damit fort, das Internet zu durchsuchen, um zu erfahren, wie er sein Problem lösen kann. Letztes Mal hat er zum Beispiel überprüft, wie ein Web-Framework Validatoren und Fehlerzähler aufbaut, weil er ein scheinbar ähnliches Feature zum Design hatte.
Dies ist ein Fall, in dem das, wonach 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, aber tatsächlich nicht passen, weil sie auf einen anderen Anwendungsfall angewendet werden. Durch den Versuch, vorgefertigten Code/Architektur/Muster zu greifen, hätte er mehr oder weniger Code in unsere Basis eingefügt, der vielleicht funktioniert hat, 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 zentrale Sprachfunktionen verwendet (kein Framework), und ich bin mit einem zuverlässigen Gedächtnis ausgestattet, wenn es um Code geht, aber ich verwende die Dokumentation jedes Mal, wenn ich bei etwas Trivialem feststecke . Wenn ich jedoch auf einer höheren Ebene feststecke, ist es gut, einen erfahreneren Kollegen um Hilfe zu bitten. Sie erhalten eine viel bessere Antwort.
Es gibt einen Unterschied zwischen „professionell“ und „sachkundig“. Wenn es eine Information gibt, die ich wissen muss, und ich die Wahl habe, dumm auf meinem Stuhl zu sitzen und festzusitzen, oder die Dokumentation zu überprüfen, dann prü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 immer noch absolut professionell – da die Alternative ist, es nicht zu wissen, und nicht es 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? Sie konsultieren die Dokumentation, um herauszufinden, ob es da draußen besseres Wissen über dasselbe Thema gibt.
Es kommt selten vor, dass es ein Problem gibt, das ich nicht selbst lösen kann. Aber es braucht Zeit. Angesichts der Wahl zwischen einer Stunde, um es selbst herauszufinden, und fünf Minuten mit Google, ist es unprofessionell, die Stunde zu verbringen.
Sie haben bereits ein paar gute Antworten, aber lassen Sie mich eine kleine Wendung hinzufügen ...
Ich mag Menschen, die Dokumentation verwenden, und das ist ein großartiges Zeichen für Ihre Professionalität.
Ich kenne genug Programmierer, die lange Zeit ohne wirklichen Plan herumstolpern, zufällig dies und das ausprobieren, alten Quellcode durchsuchen, wo das, was sie erreichen wollen, bereits getan zu sein scheint (aber noch nicht ganz ist) und so an. Ehrlich gesagt verabscheue ich diese Art von Herangehensweise. Sie kommen nie sehr weit, müssen oft Leute fragen, nehmen selten Ratschläge an und ziehen es vor, scheinbar ewig so weiterzumachen.
Leute, die häufig nach Tutorials oder Codeschnipseln einschließlich SO googeln, ohne sich jemals auf die Dokumentation zu beziehen, ärgern mich ohne Ende. Dieses Verhalten ist meiner Meinung nach eine riesige Falle. Es führt zu einer Art Programmierung, die von halbgarem, willkürlichem, unsystematischem "Wissen" angetrieben wird. Diese Programmierer neigen dazu, viele Vorurteile zu haben. Hier kommen Nuggets wie „nie verwenden git rebase
“, „nie not in
in SQL verwenden“, „immer XXX“, „nie YYY“ her. Sie werden es sehr schwer finden, über den Tellerrand zu schauen, neue Ideen zu entwickeln, eine Intuition zu entwickeln, wie sie ihre Anwendungen strukturieren und all das Zeug, das großartige Entwickler ausmacht.
Ich würde 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 ist oder etwas sehr, sehr, sehr spezielles, das wahrscheinlich nicht in irgendeiner Art von Dokumentation behandelt wird (zB eine spezielle Kombination von Bibliotheken/Modulen usw.), dann gehen Sie auf jeden Fall geradeaus zu SO.
Wenn es etwas ist, das leicht durch Dokumentation/API herausgefunden werden könnte, würde ich vorschlagen, sich hinzusetzen und an diesem bestimmten Teil Ihrer Programmiersprache/Bibliotheken usw. zu arbeiten, damit Ihr Wissen enger wird.
Die beste Sorte ist für mich ein Programmierer, der sich bei einem neuen Thema die Zeit nimmt, sich richtig hinzusetzen, zu vertiefen, sich einen guten Überblick und ein gutes technisches Verständnis zu verschaffen. Dies wird meistens erreicht (meiner Erfahrung nach mit den vielen Programmiersprachen, mit denen ich Kontakt hatte), indem man die gute alte Dokumentation einschließlich API-Referenzen und so weiter liest. Das ist meiner Meinung nach nie durch etwas anderes zu ersetzen.
Ich finde es nicht abwegig, zum Beispiel die alten C++-Klassiker (gutes altes Papier), die Gang of Four Design Patterns, die (Online-Version des) "Programming Ruby"-Handbuchs, die äußerst gut gemachten Perl-Manpages, die Git-Buch, bestimmte RFCs, das HTML/XML/etc. Spezifikationen und so weiter von vorne nach hinten. Ich würde und habe das sogar in meiner Freizeit getan und würde es ehrlich gesagt von jedem Programmierer erwarten, der sein Geld wert ist (natürlich abhängig davon, womit er arbeitet). Mir ist auch durchaus bewusst, dass ich (zumindest in den Unternehmen, in denen ich in den vergangenen Jahrzehnten gearbeitet habe) mit dieser Meinung ziemlich allein stehe.
(NB: Natürlich müssen Sie sich keine riesigen Listen von API-Referenzen merken, aber sie zumindest 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, ist es an der Zeit, sich den Code von Drittanbietern zur Inspiration anzusehen oder sich ältere SO-Fragen anzusehen (oder selbst neue Fragen zu stellen).
Sie werden vielleicht auch feststellen, dass es sehr einfach wird, Antworten zu finden, wenn Sie sich mit einem Feld wie diesem befasst haben, indem Sie direkt in das Fleisch hineinzoomen, woher Sie Ihre Dokumentation beziehen (Manpages usw.). An dieser Stelle reicht vielleicht auch schon die Autovervollständigung deines Editors. Und Sie können ziemlich schnell wissen, wenn etwas mit dem Tool, mit dem Sie arbeiten, einfach nicht möglich ist, und sich viel vergebliches Suchen ersparen.
Only tutorials?
Ich gehöre zu diesem und ich bin in keinem Teil der Bande This is where nuggets like "never use git rebase", "never use not in in SQL", "always do XXX", "never do YYY" come from
. Aber ich stimme zu, dass es ziemlich viele Entwickler gibt, die einfach nach "How to do X" suchen und den Code erhalten, ohne zu verstehen, was sie tun. Das sind nicht extra ein "Nur Tutorial" sondern eher einIt works on my computer and I don't give a shit about the rest
Ihre Fähigkeit als Programmierer besteht darin, wie Sie das Gesamtbild erfassen und effektive Lösungen entwerfen können, nicht wie viele APIs Sie sich merken können. Ziel ist es, die Arbeit richtig 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 Gehirnleistung für Dinge verschwendet, die selten verwendet werden, wenn sie leicht nachgeschlagen werden können. Wenn Sie Stackoverflow mehr oder weniger einmal am Tag besucht haben, kein Problem; Wenn Sie den größten Teil Ihres typischen Arbeitstages damit verbringen, wäre dies ein Problem.
Ich werde irgendwie verspottet, weil ich Stack Overflow/Dokumentation so häufig verwende
Die Meinung anderer Leute über dich definiert dich nicht , sie definiert nur sie
Lässt mich die Verwendung von Dokumentation als Entwickler unprofessionell erscheinen?
Nein ... Teil der Professionalität ist die Kompetenz, die Arbeit zu erledigen. Sie werden verspottet, weil Ihre Kollegen gemobbt werden, nicht wegen irgendetwas, das Sie falsch machen.
„Ein Chirurg kann nicht jedes Mal seine Bücher lesen, wenn er einen Patienten operieren muss.“
Warum nicht? Ich bin skeptisch gegenüber dieser Behauptung, es sei denn, es gibt einen ungewöhnlichen Zeitdruck. Die Verwendung von Referenzmaterial dauert nur Sekunden.
Wenn ich während eines Vorstellungsgesprächs für einen anderen Job Code schreiben muss, sollten Sie die Dokumentation nicht verwenden
Hängt von den Regeln des Interviews ab, einige erlauben es, andere nicht. Insbesondere wenn es sich um einen Test handelt, kann dieser zugelassen werden. Es ist eine gute Idee, zuerst zu überprüfen!
Erik
Paul D. Waite
Jane S
Walfrat
The reason for asking this question is that I get mocked for using Stack Overflow/documentation so frequently which makes others doubt my abilities
, blöde Frage, wer sind die, die dich verspotten, weil du SO und so weiter benutzt? Manager, IT der alten Generation, die Frameworks immer noch selbst umschreiben, anstatt vorhandene robuste zu verwenden, jemand anderes?Benutzer428517
Benutzer207421
NZKschatrija
3.1415926535897932384626433...
:-)
AI Breveleri
Erik
FreeMan
James Jungmann
Benutzer428517
Par