L'uso della documentazione come sviluppatore mi fa sembrare poco professionale?

No, in realtà significa il contrario… poiché non disturbate i vostri anziani facendo domande che si possono facilmente trovare su internet o attraverso la documentazione.

La maggior parte di noi devs non riesce a ricordare migliaia di righe di documentazione… sempre, specialmente quando passiamo da una tecnologia all'altra

Chiedo anche il futuro; ad esempio, se devo scrivere del codice durante un colloquio per un altro lavoro, immagino che non dovreste usare la documentazione.

La maggior parte delle aziende più ragionevoli vorrebbe testare la logica/struttura che trovate in un test di codifica… non tanto per la sintassi.

Qualcuno una volta mi ha detto qualcosa del tipo: “Un chirurgo non può leggere i suoi libri ogni volta che deve operare un paziente”.

Chiunque te l'abbia detto non sa come funziona la chirurgia. A meno che non si tratti di una procedura molto comune che il chirurgo ha praticato centinaia di volte, quelli bravi passano molto tempo a studiare prima di ogni paziente che vedono. Passano anche molti anni alla scuola di medicina studiando una materia che non è cambiata molto in diverse migliaia di anni.

Sei al tuo primo anno in un settore in cui ogni settimana si inventano nuovi modi di fare. Siete inesperti, quindi ci si deve aspettare che dobbiate cercare spesso le cose. Finché avete le basi per sapere se le soluzioni che trovate risolvono effettivamente il vostro problema e che imparate dall'esperienza, non c'è niente di sbagliato in questo. Sono un ingegnere del software da 15 anni e devo ancora cercare le cose quasi ogni giorno. Un professionista usa ogni risorsa a sua disposizione per portare a termine il lavoro.

Professionalità e conoscenza sono due cose completamente diverse.

Cercare le cose da fonti terze significa mancanza di conoscenza, non mancanza di professionalità. La mancanza di conoscenza è un argomento a sé stante, ma nel complesso non c'è una persona che sappia tutto.

Se conosci la tua mancanza di conoscenza e la gestisci cercando le cose da fonti terze, questo significa che hai una strategia professionale per risolvere il tuo problema specifico di mancanza di conoscenza.

Non cercare le cose senza sapere che le cose non sono professionali, ma questo non è il tuo caso.

Ulteriori letture su un effetto che contrasta con la tua “strategia di usare la documentazione”: L'effetto Dunning-Kruger

L'uso della documentazione come sviluppatore mi fa sembrare poco professionale?

No. Ricordare piccoli dettagli arbitrari è uno spreco di risorse. Dovresti ricordarne molti sia in PHP (che manca un po’ di coerenza) che nello sviluppo web in generale, se hai familiarità con diversi linguaggi e una dozzina di framework.

Vengo deriso per aver usato SO/Documentazione così frequentemente che mi fa dubitare delle mie capacità

Questo potrebbe non essere il modo più efficiente per risolvere i tuoi compiti.

Usi qualche IDE? I tuoi colleghi ne usano qualcuno? Perché la ricerca di questi minuscoli dettagli può essere delegata alla funzione di autocompletamento dell'IDE. L'uso dell'autocompletamento è più efficiente rispetto al passaggio al browser e alla ricerca di una risposta.

Se i tuoi colleghi usano l'autocompletamento del loro IDE e tu usi Google al suo posto, allora questo potrebbe sembrare poco professionale - non perché consulti i documenti, ma perché lo fai in modo inefficiente.

Se i vostri colleghi si affidano alla loro memoria e voi vi affidate all'autocompletamento sarete in grado di oupterformarli in compiti che utilizzano un framework con cui nessuno di voi ha familiarità, il che non è così raro nel web.

Padroneggiate i vostri strumenti e mostrate le prestazioni, questo è professionale.

Altri hanno fornito risposte solide, ma nessuno si occupa veramente di questa questione a testa alta; l'enfasi è mia:

La ragione per porre questa domanda è che ** vengo deriso** per aver usato Stack Overflow/documentazione frequentemente ** che fa dubitare gli altri delle mie capacità.**

Chi sono queste persone che ti “deridono” e come fai a saperlo “…fa dubitare gli altri delle [tue] capacità?”

Tutto questo mi sembra una varietà da giardino (aka: comune) di nonnismo. Se sei uno sviluppatore junior ti trovi naturalmente in una gerarchia in cui gli altri ti mettono alla prova e premono i pulsanti come parte del loro comportamento di nonnismo. Questo accade sia che ne siano consapevoli o meno; è proprio quello che fa parte del corso.

Alla fine della giornata, ogni singola persona al mondo usa strumenti di riferimento per svolgere il proprio lavoro. Diamine, gli avvocati e i medici non hanno tonnellate di referenze e libri a cui fanno costantemente riferimento? La programmazione non è diversa.

Il vostro lavoro di programmatore è quello di collegare i desideri di un progetto con la realtà del codice stesso. Il vostro lavoro non è quello di memorizzare sciocchezze arcane. e se arrivate al punto di ricordare - e anche di visualizzare - sciocchezze arcane, allora congratulazioni! Ma questo non succede da un giorno all'altro e a volte non succede affatto per alcuni.

FWIW Ho lavorato al computer per più di 20 anni ed è solo negli ultimi anni che posso letteralmente visualizzare le soluzioni nella mia testa senza scrivere una riga di codice. È un'abilità in cui si cresce e che non si può pretendere che qualcuno abbia su richiesta.

Anche se questo non vi farà sembrare poco professionali (la maggior parte del tempo), potreste voler usare cautela davanti a un cliente o a un manager ingenuo. Proprio come voi, con quasi un anno di esperienza di programmazione, non siete sicuri se i professionisti hanno bisogno di cercare le cose, così anche le persone con un'esperienza ancora meno rilevante potrebbero non essere sicure.

In realtà, ho difeso altri sviluppatori in alcune occasioni quando un cliente di un incarico di consulenza ha detto qualcosa del tipo “perché pago bene per qualcuno che non può nemmeno scrivere codice senza cercarlo su internet?”

Questo è stato raro, ma naturalmente non so quante persone hanno avuto una cattiva impressione ma sono rimaste in silenzio.

Non è certo poco professionale cercare le cose quando non si ha familiarità.

Tuttavia, se non si conservano queste conoscenze e si cercano continuamente le stesse cose , allora potrebbe esserci un problema. Questo è inefficiente. Ti rende più lento e questo potrebbe essere la causa del beffardo. Devi imparare le basi della tua professione al punto da non doverle cercare ogni volta.

È molto più professionale leggere la documentazione e ottenere il codice corretto piuttosto che indovinare e sbagliare. Questo è particolarmente vero per un linguaggio come PHP, dove la libreria standard è progettata in modo disordinato, difficile da memorizzare e piena di gotchas.

Prendiamo, per esempio, la funzione mail() . Lo sapevate che…

additional_headers non ha la protezione dell'intestazione della posta. Pertanto, gli utenti devono assicurarsi che le intestazioni specificate siano sicure e che contengano solo le intestazioni. Quindi, non iniziare mai il corpo della posta inserendo più righe.

Se non si è a conoscenza di questo avvertimento, allora si finisce per introdurre una vulnerabilità di sicurezza .

Quando si invia la posta, la posta deve contenere un'intestazione From. Questo può essere impostato con il parametro additional_headers, o un default può essere impostato in php.ini.

Ciò significa che il comportamento della vostra applicazione potrebbe dipendere da un'impostazione di configurazione globale. Questo è utile saperlo, in modo da evitare di scrivere codice che sembra funzionare correttamente su una macchina, ma che non è portatile su un'altra.

• Il parametro $to deve essere conforme a RFC 2822 .

Certo, si potrebbe essere in grado di produrre più codice non leggendo la documentazione con attenzione, ma probabilmente non sarebbe codice di qualità professionale. Non c'è da vergognarsi se si controlla spesso la documentazione per assicurarsi di usare correttamente il linguaggio e le librerie.

Cercare cose di cui non si è sicuri fa risparmiare tempo e permette anche di verificare se ci sono modi migliori per fare qualcosa. Rimanere bloccati a fare la stessa cosa più e più volte in modo inefficiente quando c'è un modo migliore solo controllando la rete non va bene.

C'è una differenza tra “professionale” e “competente”. Se c'è qualche informazione che devo sapere, e ho la scelta tra sedermi stupidamente sulla mia sedia e rimanere bloccato, o controllare la documentazione, allora controllo la documentazione. Questo è assolutamente professionale.

Se questa informazione è qualcosa che una persona competente nella mia posizione dovrebbe sapere, allora cercarla può dimostrare che non sono così competente come dovrei essere, ma è comunque del tutto professionale - poiché l'alternativa è non conoscerla, e non impararla. Il che (la parte del non imparare) è del tutto non professionale.

Sarebbe sciocco dare per scontato che tu sappia tutto quello che dovresti sapere, perché ogni giorno ci sarà qualcosa di fresco che dovresti sapere, che ieri non c'era. Anche se sai qualcosa, come fai a sapere che la tua conoscenza è la migliore possibile? Si consulta la documentazione per scoprire se c'è una conoscenza migliore sullo stesso argomento.

È raro che ci sia un problema che non riesco a capire da solo. Ma ci vuole tempo. Data la scelta tra un'ora per capirlo da solo e cinque minuti con Google, passare l'ora non è professionale.

Come altri rispondono, non c'è nulla di poco professionale nel controllare la documentazione, soprattutto se si considera che si è junior, soprattutto se si considera che la programmazione è vasta e c'è sempre un dettaglio che si può dimenticare e si ha la missione di correggere il proprio codice.

Ci sono comunque casi che considererei come abusi della documentazione.

Ho un collega che a volte non è in grado di trovare una soluzione propria su un determinato problema. Per questo motivo, a volte, procede a controllare sul web come risolvere il suo problema. L'ultima volta, per esempio, ha controllato come un framework web stesse architettando validatori e contatori di errori perché aveva una caratteristica apparentemente simile al design.

Questo è un caso in cui quello che stai cercando è troppo astratto perché Internet ti possa aiutare. Peggio ancora, si potrebbero trovare soluzioni che apparentemente si adattano, ma in realtà non lo fanno, perché sono applicate a un caso d'uso diverso. Cercando di prendere qualche codice/architettura/pattern pre-fatto avrebbe più o meno iniettato del codice nella nostra base che potrebbe aver funzionato, ma sarebbe difficile da mantenere perché scritto da qualcun altro per uno scopo diverso.

Non guardo spesso la documentazione perché scrivo codice che usa per lo più caratteristiche del linguaggio di base (nessun framework) e sono dotato di una memoria affidabile quando si tratta di codice, ma uso il doc ogni volta che sono bloccato su qualcosa di banale. Tuttavia, se sono bloccato su qualcosa di più alto livello, la cosa buona da fare è cercare aiuto da un collega più esperto, si otterrà una risposta molto migliore.

Avete già qualche buona risposta, ma lasciatemi aggiungere un piccolo tocco…

Mi piace la gente che usa la documentazione ed è un grande segno della vostra professionalità.

Non usando la documentazione

Conosco abbastanza programmatori che inciampano senza un vero piano per lunghi periodi di tempo, provando questo e quello per caso, scegliendo attraverso il vecchio codice sorgente dove qualsiasi cosa vogliano ottenere sembra essere già stata fatta (ma non del tutto) e così via. Francamente, detesto questo tipo di approccio. Non vanno mai molto lontano, spesso devono chiedere alla gente, raramente accettano consigli e preferiscono continuare così per sempre, apparentemente.

Solo tutorial?

La gente spesso cerca su Google tutorial o frammenti di codice, tra cui SO, senza mai fare riferimento alla documentazione, mi irrita a morte. Questo comportamento è una trappola enorme, secondo me. Porta a una sorta di programmazione alimentata da una “conoscenza” non sistematica, arbitraria e non sistematica. Questi programmatori tendono a finire con un sacco di pregiudizi. Da qui nascono pepite come “non usare mai git rebase”, “non usare mai not in in SQL”, “fai sempre XXX”, “non fare mai YYY”. Troveranno molto difficile pensare fuori dagli schemi, inventarsi nuove idee, formarsi un'intuizione su come strutturare le loro applicazioni e tutte quelle cose che fanno grandi sviluppatori.

Vi esorto a risolvere prima qualsiasi problema guardando la documentazione/riferimento, e allora cercare SO o altri frammenti.

Naturalmente, ci sono delle eccezioni. Se il vostro problema è ovviamente qualcosa di simile a un bug, o qualcosa di molto, molto, molto, molto, molto speciale, che è improbabile che venga gestito in qualsiasi tipo di documentazione (ad es, una speciale combinazione di librerie/moduli ecc.), allora andate direttamente a SO.

Se è qualcosa che può essere facilmente capito da documentazione/API, allora vi suggerirei di sedervi e lavorare su quella particolare parte del vostro linguaggio di programmazione / librerie ecc. in modo che la vostra conoscenza diventi più stretta.

Documentazione

Il tipo migliore, per me, è un programmatore che, quando incontra un nuovo argomento, si prende il tempo per sedersi davvero, scavare in esso, ottenere una buona visione d'insieme e una buona comprensione tecnica. Questo si ottiene il più delle volte (sempre secondo la mia esperienza, con i molti linguaggi di programmazione con cui ho avuto contatti) leggendo la buona vecchia documentazione, compresi i riferimenti alle API e così via. Questo, secondo me, non può mai essere sostituito da altro.

Non trovo stravagante leggere, per esempio, i vecchi classici del C++ (buon vecchio cartaceo), la Gang of Four Design Patterns, il manuale “Programming Ruby” (versione online del) manuale “Programming Ruby”, le manpages di Perl estremamente ben fatte, il libro di Git, alcuni RFC, le specifiche HTML/XML/etc. e così via da davanti a dietro. Lo farei e l'avrei fatto anche nel mio tempo libero e, francamente, me lo sarei aspettato da qualsiasi programmatore degno di fiducia (a seconda di ciò con cui sta lavorando, ovviamente). Sono anche perfettamente consapevole di essere (almeno nelle aziende in cui ho lavorato, negli ultimi decenni) abbastanza solo con questa opinione.

(N.B.: Ovviamente non è necessario memorizzare enormi liste di riferimenti alle API, ma almeno sorvolare su di esse per vedere cosa è disponibile e quale sembra essere lo “spirito” dell'API. )

Dopo esservi abituati all'argomento, allora è il momento di guardare al codice di terze parti per trovare ispirazione, o di guardare le vecchie domande di SO (o di fare nuove domande da soli).

Potreste anche scoprire che quando avete assorbito un campo come questo, diventa molto facile trovare le risposte zoomando direttamente nella carne di ogni luogo da cui si ottiene la vostra documentazione (pagine man ecc.). A questo punto, anche l'autocompletamento del vostro editor potrebbe essere già sufficiente. E potreste anche sapere molto presto quando qualcosa non è possibile con lo strumento con cui state lavorando, risparmiando un sacco di ricerche inutili.

La tua abilità come programmatore riguarda il modo in cui puoi prendere in mano il quadro completo e progettare soluzioni efficaci, non quante API puoi memorizzare. L'obiettivo è quello di svolgere il lavoro in modo corretto ed efficiente. Se dovessi cercare ogni API e ogni dettaglio, direi che hai qualche problema. Mi aspetterei che un buon sviluppatore abbia una buona conoscenza di tutto ciò che viene usato di frequente, di recente, e di routine, ma non sprechi il cervello per cose usate di rado quando possono essere facilmente cercate. Se avete visitato lo stackoverflow più o meno una volta al giorno, non è un problema; se vi trovate su di esso per la maggior parte della vostra tipica giornata di lavoro, questo sarebbe un problema.

Mi prendo un po’ in giro per aver usato Stack Overflow/documentazione così frequentemente

L'opinione di altre persone su di te non definisce te, definiscono solo loro

Usare la documentazione come sviluppatore mi fa sembrare poco professionale?

No… parte dell'essere professionale è la competenza nel portare a termine il lavoro. Ti prendono in giro perché i tuoi colleghi sono prepotenti, non per qualcosa che stai facendo di sbagliato.

“Un chirurgo non può leggere i suoi libri ogni volta che deve operare un paziente”.

Perché no? Sono scettico su questa affermazione, a meno che non ci sia un insolito scricchiolio del tempo. Usare materiale di riferimento richiede solo pochi secondi.

se devo scrivere del codice durante un colloquio per un altro lavoro immagino che non dovresti usare la documentazione

Dipende dalle regole del colloquio, alcuni lo permettono, altri no. In particolare, se si tratta di un test, può essere consentito. È una buona idea controllare prima!