Maakt het gebruik van documentatie als ontwikkelaar mij onprofessioneel?

Nee, het betekent eigenlijk het tegenovergestelde… want je stoort je senioren niet door vragen te stellen die je gemakkelijk kunt vinden op internet of via documentatie.

De meesten van ons devs kunnen zich geen duizend regels documentatie herinneren… zeker wanneer we schakelen tussen technologieën_

Ik vraag ook naar de toekomst; bijvoorbeeld als ik code moet schrijven tijdens een sollicitatiegesprek voor een andere baan, denk ik dat je de documentatie niet moet gebruiken.

De meeste redelijke bedrijven willen graag de logica/structuur testen die je in een coderingstest naar voren brengt… niet zozeer over de syntaxis.

Iemand heeft me ooit zoiets verteld: “Een chirurg kan niet elke keer zijn boeken lezen als hij een patiënt moet opereren.”

Wie je dat ook verteld heeft, weet niet hoe een operatie werkt. Tenzij het een heel gewone procedure is die de chirurg al honderd keer heeft geoefend, besteden de goeden veel tijd aan het studeren voor elke patiënt die ze zien. Ze brengen ook vele jaren op de medische school door met het bestuderen van een onderwerp dat in enkele duizenden jaren niet veel veranderd is.

Je bent in je eerste jaar in een industrie waar elke week nieuwe manieren van doen worden uitgevonden. Je bent onervaren, dus het is te verwachten dat je regelmatig dingen moet opzoeken. Zolang je de basis hebt om te weten of de oplossingen die je vindt daadwerkelijk je probleem oplossen en dat je leert van de ervaring, is daar niets mis mee. Ik ben al 15 jaar software engineer en moet nog steeds bijna elke dag dingen opzoeken. Een professional gebruikt alle beschikbare middelen om de klus te klaren.

Professionaliteit en kennis zijn twee totaal verschillende dingen.

Dingen opzoeken bij derden betekent wel dat het je aan kennis ontbreekt, niet aan professionaliteit. Gebrek aan kennis is een onderwerp op zich, maar over het algemeen is er geen persoon die alles weet.

Als je je gebrek aan kennis kent en er mee omgaat door dingen op te zoeken uit bronnen van derden, betekent dit dat je een professionele strategie hebt om je specifieke probleem van gebrek aan kennis op te lossen.

Dingen niet opzoeken terwijl je niet weet dat dingen onprofessioneel zijn, maar dit is niet jouw zaak.

Verder lezen over een effect dat je “strategie van het gebruik van documentatie” contrasteert: Het Dunning-Kruger effect

Maakt het gebruik van documentatie als ontwikkelaar mij onprofessioneel?

Nee. Het onthouden van minieme willekeurige details is een verspilling van je middelen. Je zou veel van die dingen moeten onthouden, zowel in PHP (dat een beetje ontbreekt aan consistentie) als in webontwikkeling in het algemeen, als je vertrouwd raakt met verschillende talen en een dozijn frameworks.

Ik word bespot voor het gebruik van SO/Documentatie zo vaak, waardoor het twijfelen aan mijn capaciteiten

Dit is misschien niet de meest efficiënte manier om je taken op te lossen.

Gebruik je een IDE? Gebruiken je collega’s een IDE? Want het opzoeken van die minieme details kan worden gedelegeerd aan IDE’s autocomplete functie. Het gebruik van autoaanvullen is efficiënter dan je aandacht te richten op de browser en daar naar een antwoord te zoeken.

Als je collega’s hun IDE’s autoaanvullen en je gebruikt Google in plaats daarvan, dan kan dat onprofessioneel lijken - niet omdat je dokters raadpleegt, maar omdat je het inefficiënt doet.

Als je collega’s op hun geheugen vertrouwen en je vertrouwt op autoaanvullen, dan kun je hen in staat stellen om taken uit te voeren die geen van jullie kent, wat niet zo zeldzaam is in het web.

Master your tools and show performance, dat is professioneel.

Anderen hebben goede antwoorden gegeven, maar niemand gaat hier echt op in; gewaagde nadruk ligt op mij:

De reden om deze vraag te stellen is dat Ik word bespot voor het regelmatig gebruiken van Stack Overflow/documentatie waardoor anderen aan mijn capaciteiten twijfelen.

Wie zijn deze mensen die jou “bespotten” en hoe weet je dat “…anderen aan [jouw] capaciteiten] twijfelen?”

Dit klinkt allemaal als tuinvariëteit (aka: gewone) ontgroening voor mij. Als je een junior ontwikkelaar bent, zit je van nature in een hiërarchie waar anderen je zullen testen en op knoppen zullen drukken als onderdeel van hun eigen ontgroening. Dit gebeurt of ze zich er nu bewust van zijn of niet; het is gewoon par voor de cursus.

Aan het eind van de dag gebruikt elke persoon in de wereld referentie-instrumenten om het werk gedaan te krijgen. Heck, hebben advocaten en artsen geen tonnen referenties en boeken waar ze constant naar verwijzen? Programmeren is niet anders.

Het is jouw taak als programmeur om de wensen van een project te overbruggen met de realiteit van de code zelf. Jouw taak is niet om geheimzinnige onzin uit het hoofd te leren. en als je dan toch op het punt komt dat je je kunt herinneren en zelfs visualiseren-arcane onzin, dan gefeliciteerd! Maar dat gebeurt niet van de ene op de andere dag en soms ook helemaal niet voor sommigen.

FWIW Ik doe al 20+ computerwerk en het is pas in de afgelopen jaren dat ik letterlijk oplossingen in mijn hoofd kan visualiseren zonder een regel code te schrijven. Het is een vaardigheid waar men in groeit en die men niet kan eisen dat iemand op afroep heeft.

Hoewel dit u niet onprofessioneel maakt naar een professional (het overgrote deel van de tijd) zou u voorzichtigheid moeten betrachten in het bijzijn van een naïeve klant of manager. Net zoals je, met bijna een jaar programmeerervaring, niet zeker weet of professionals dingen moeten opzoeken, zo kunnen ook mensen met nog minder relevante ervaring onzeker zijn.

In feite heb ik andere ontwikkelaars een paar keer verdedigd toen een klant van een consulting engagement iets zei in de trant van “waarom betaal ik goed geld voor iemand die niet eens code kan schrijven zonder het op te zoeken op het internet?”

Dit is zeldzaam geweest, maar ik weet natuurlijk niet hoeveel mensen een slechte indruk kregen, maar bleven zwijgen.

Het is zeker niet onprofessioneel om dingen op te zoeken als je onbekend bent.

Echter, als je die kennis niet vasthoudt en steeds dezelfde dingen opzoekt , dan kan er een probleem zijn. Dat is inefficiënt. Het maakt je langzamer en dat zou de oorzaak van de spot kunnen zijn. Je moet de basis van je vak leren tot het punt waarop je het niet steeds hoeft op te zoeken.

Het is veel professioneler om de documentatie te lezen en je code goed te krijgen dan om te gissen en het fout te hebben. Dit geldt vooral voor een taal als PHP, waar de standaardbibliotheek lukraak is ontworpen, moeilijk te onthouden is en vol gotchas zit.

Neem bijvoorbeeld de mail() functie. Wist u dat…

additional_headers geen mail header injectie bescherming heeft. Daarom moeten gebruikers ervoor zorgen dat gespecificeerde headers veilig zijn en alleen headers bevatten. d.w.z. Begin nooit met het plaatsen van meerdere newlines.

Als u zich niet bewust bent van dat voorbehoud, dan introduceert u uiteindelijk een veiligheidslek .

Bij het verzenden van mail moet de mail een Van-header bevatten. Dit kan worden ingesteld met de parameter additional_headers, of een standaardinstelling in php.ini.

Dat betekent dat het gedrag van uw applicatie kan afhangen van een globale configuratie-instelling. Dat is handig om te weten, zodat u kunt voorkomen dat u code schrijft die op de ene machine correct lijkt te werken, maar niet overdraagbaar is naar een andere.

• De $to parameter moet voldoen aan RFC 2822 .

Zeker, u zou meer code kunnen uitrollen door de documentatie niet zorgvuldig te lezen, maar het zou waarschijnlijk geen professionele-kwaliteitscode zijn. Het is geen schande om de documentatie regelmatig te controleren om er zeker van te zijn dat u de taal en de bibliotheken correct gebruikt.

Door dingen op te zoeken waar je niet zeker van bent, bespaar je tijd en kun je ook controleren of er betere manieren zijn om iets te doen. Het is niet goed om telkens opnieuw inefficiënt hetzelfde te doen als er een betere manier is door alleen maar het net te controleren.

Er is een verschil tussen “professioneel” en “kennis”. Als er informatie is die ik moet weten, en ik heb de keuze tussen stompzinnig op mijn stoel zitten en vastzitten, of de documentatie controleren, dan controleer ik de documentatie. Dat is absoluut professioneel.

Als die informatie iets is wat een kenner in mijn positie zou moeten weten, dan kan het opzoeken ervan aantonen dat ik niet zo kenbaar ben als ik zou moeten zijn, maar het is nog steeds volledig professioneel - want het alternatief is het niet kennen, en het niet leren. Wat (het niet leren deel) volledig onprofessioneel is.

Het zou dom zijn om aan te nemen dat je alles weet wat je zou moeten weten, want elke dag zal er iets nieuws zijn dat je zou moeten weten, dat er gisteren niet was. Zelfs als je weet iets, hoe weet je dan dat je kennis de best mogelijke is? Je raadpleegt documentatie om te weten te komen of er een betere kennis is over hetzelfde onderwerp.

Het komt zelden voor dat er een probleem is waar ik zelf niet achter kan komen. Maar het kost tijd. Gezien de keuze tussen een uurtje om het zelf uit te zoeken en vijf minuten met Google, is het doorbrengen van het uur onprofessioneel.

Zoals anderen antwoorden, is er niet zoiets als onprofessioneel zijn voor het controleren van de documentatie, vooral gezien het feit dat je junior bent, vooral gezien het feit dat het programmeren enorm is en er altijd een detail is dat je kunt vergeten en dat je een missie hebt om je code correct te laten zijn.

Er zijn echter gevallen waarin ik zou overwegen om misbruik van documentatie te maken.

Ik heb een collega die soms niet in staat is om met zijn eigen oplossing voor een bepaald probleem te komen. Daarom gaat hij soms verder met het controleren van het web over hoe zijn probleem op te lossen. De laatste keer heeft hij bijvoorbeeld gecontroleerd hoe een webframework validators en fouttellers architectuurt omdat hij een schijnbaar gelijkaardige functie had om te ontwerpen.

Dit is een geval waarin wat je zoekt veel te abstract is voor het internet om je te helpen. Erger nog, je zou oplossingen kunnen vinden die schijnbaar passen, maar in feite niet, omdat ze worden toegepast op een andere use case. Door te proberen wat kant-en-klare code/architectuur/patroon te pakken te krijgen zou hij min of meer geïnjecteerde code in onze basis hebben die misschien werkte, maar moeilijk te onderhouden zou zijn omdat hij door iemand anders is geschreven voor een ander doel.

Ik kijk niet vaak in de documentatie omdat ik code schrijf die voornamelijk gebruik maakt van kerntaalfuncties (geen framework) en ik ben begaafd met een betrouwbaar geheugen als het gaat om code, maar ik gebruik de doc wel elke keer als ik vastzit aan iets triviaals. Echter, als ik vastzit op iets hogers, is het goed om hulp te zoeken bij een meer ervaren collega, dan krijg je een veel beter antwoord.

Je hebt al een paar goede antwoorden, maar laat me er een kleine draai aan geven…

Ik hou van mensen die documentatie gebruiken en het is een goed teken voor je professionaliteit.

Het niet gebruiken van documentatie

Ik ken genoeg programmeurs die zonder een echt plan voor lange tijdspannes meelopen, dit en dat toevallig uitproberen, door oude broncode heen plukken waar wat ze willen bereiken al gedaan lijkt te zijn (maar nog niet helemaal) en zo verder. Eerlijk gezegd verafschuw ik dit soort benaderingen. Ze komen nooit ver, moeten vaak mensen vragen, nemen zelden advies aan en gaan schijnbaar voor altijd zo door.

Alleen tutorials?

Mensen googlen vaak naar tutorials of code snippets inclusief SO, zonder ooit te refereren aan documentatie, irriteert me tot niets. Dit gedrag is naar mijn mening een enorme valkuil. Het leidt tot een soort programmering die gevoed wordt door halfbakken, willekeurige, onsystematische “kennis”. Die programmeurs hebben de neiging om met veel vooroordelen te eindigen. Dit is waar nuggets als “gebruik nooit git rebase”, “gebruik nooit not in in SQL”, “doe altijd XXX”, “doe nooit YYY” vandaan komen. Ze zullen het erg moeilijk vinden om out of the box te denken, met nieuwe ideeën te komen, intuïtie te vormen over hoe ze hun applicaties moeten structureren en al die dingen die geweldige ontwikkelaars maken.

Ik wil er bij u op aandringen om elk probleem eerst op te lossen door te kijken naar de documentatie/referentie, en daar te zoeken naar SO of andere snippets.

Natuurlijk, er zijn uitzonderingen. Als uw probleem duidelijk zoiets is als een bug, of iets heel, heel, heel bijzonders dat waarschijnlijk niet in enige vorm van documentatie behandeld zal worden (bijv, een speciale combinatie van bibliotheken/modules etc.), ga dan direct naar SO.

Als het iets is wat gemakkelijk uit te zoeken is door documentatie/API, dan stel ik voor om te gaan zitten en te werken aan dat specifieke deel van je programmeertaal/bibliotheken etc. zodat je kennis strakker wordt.

Documentatie

De beste soort, voor mij, is een programmeur die, wanneer hij een nieuw onderwerp tegenkomt, de tijd neemt om er echt in te gaan zitten, er in te graven, een goed overzicht te krijgen en een goed technisch begrip te krijgen. Dit wordt meestal bereikt (opnieuw, in mijn ervaring, met de vele programmeertalen waarmee ik contact had) door het lezen van de goede oude documentatie inclusief API referenties en ga zo maar door. Dit kan naar mijn mening nooit vervangen worden door iets anders.

Ik vind het niet vreemd om bijvoorbeeld de oude C++ klassiekers (goed oud papier), de Gang of Four Design Patterns, de (online versie van de) “Programming Ruby” handleiding, de extreem goed gemaakte Perl manpages, het Git boek, bepaalde RFC’s, de HTML/XML/etc. specificaties te lezen en ga zo maar door van voor naar achter. Ik zou dat zelfs in mijn vrije tijd doen en hebben gedaan en zou het, eerlijk gezegd, verwachten van elke programmeur die zijn/haar zout waard is (afhankelijk van waar ze mee werken, uiteraard). Ik ben me er ook terdege van bewust dat ik (in ieder geval in de bedrijven waar ik in de afgelopen decennia heb gewerkt) helemaal alleen sta met deze mening.

(N.B.: Je hoeft natuurlijk geen enorme lijsten met API-referenties te onthouden, maar je moet ze in ieder geval verdoezelen om te zien wat er beschikbaar is en wat de “geest” van de API lijkt te zijn. )

Nadat je je grondig vertrouwd hebt gemaakt met het onderwerp, _ is het tijd om naar 3rd party code te kijken voor inspiratie, of om naar oudere SO vragen te kijken (of zelf nieuwe vragen te stellen).

Je zou ook kunnen vinden dat wanneer je een veld als dit hebt geabsorbeerd, het heel gemakkelijk wordt om antwoorden te vinden door recht in het vlees te zoomen van waar je je documentatie vandaan haalt (man pagina’s etc.). Op dit punt kan het autoaanvullen van je editor ook al genoeg zijn. En je kan net zo goed al snel weten wanneer iets niet mogelijk is met de tool waarmee je werkt, waardoor je een hoop nutteloos zoeken kunt besparen.

Uw vaardigheid als programmeur gaat over hoe u het volledige plaatje kunt zien en effectieve oplossingen kunt ontwerpen, niet over hoeveel API’s u kunt onthouden. Het doel is om de klus correct en efficiënt te klaren. Als je elke API en elk detail zou moeten opzoeken, dan zou ik zeggen dat je wat problemen hebt. Ik zou verwachten dat een goede ontwikkelaar grondig vertrouwd is met alles wat vaak, recentelijk en routinematig gebruikt wordt, maar geen hersenkracht verspillen aan dingen die zelden gebruikt worden wanneer ze gemakkelijk kunnen worden opgezocht. Als je stackoverflow min of meer een keer per dag bezoekt, is dat geen probleem; als je er het grootste deel van je typische werkdag mee bezig bent, zou dat een probleem zijn.

Ik word zo vaak bespot omdat ik Stack Overflow/documentatie gebruik

De meningen van anderen over u definiëren niet je, ze definiëren alleen je

Maakt het gebruik van documentatie als ontwikkelaar mij onprofessioneel?

Nee… een deel van het professioneel zijn is de competentie om de klus te klaren. Je wordt bespot omdat je collega’s pestkoppen zijn, niet omdat je iets verkeerd doet.

“Een chirurg kan zijn boeken niet elke keer lezen als hij een patiënt moet opereren.”

Waarom niet? Ik ben sceptisch over die bewering, tenzij er sprake is van een ongewone tijdcrisis. Het gebruik van referentiemateriaal neemt slechts enkele seconden in beslag.

als ik code moet schrijven tijdens een sollicitatiegesprek voor een andere baan dan denk ik dat je de documentatie

niet moet gebruiken Afhankelijk van de regels van het sollicitatiegesprek, sommige staan het toe, andere niet. In het bijzonder, als het een test is kan het toegestaan zijn. Het is een goed idee om het eerst te controleren!