No te preocupes: eres un profesional y estás actuando como tal.

Los profesionales utilizan todos los recursos disponibles para realizar el trabajo, incluida la documentación, el código escrito por otros (bibliotecas), la ayuda de expertos, etc.

No es poco profesional necesitar consultar un recurso externo. De hecho, sería poco profesional no utilizar la documentación si no está seguro de cómo funciona algo.

¿Su nivel de confianza en la documentación muestra inexperiencia? Claro, hasta cierto punto. Pero eres inexperto . Después de solo unos meses en el trabajo, no sabrá tanto como alguien con muchos años de experiencia. Eso es solo un hecho, y es probable que nadie lo tenga en su contra.

Sin embargo, incluso los desarrolladores con 20 años de experiencia revisarán la documentación para algunas cosas. Esto siempre es parte del conjunto de herramientas de un desarrollador.

Las pruebas de programación son algo ligeramente diferente.

Dado que están diseñados para evaluar su propio conocimiento y capacidad, a menudo tendrá que completarlos sin documentación. Esto no se debe a que la documentación sea mala; es solo que, en el entorno artificial de una breve prueba que intenta evaluar su capacidad general, los recursos externos pueden confundir esa imagen.

Sin embargo, las pruebas típicas de programación son de naturaleza conceptual . Por lo general, se refieren a su capacidad para crear un algoritmo, diseñar una solución a un problema y seguir buenas prácticas de codificación. Estas no son cosas que obtendría de la documentación de todos modos. No es probable que un error de sintaxis menor ocasional afecte mucho su evaluación.

¿Usar la documentación como desarrollador me hace parecer poco profesional?

No, en realidad significa lo contrario... ya que no está molestando a sus mayores al hacer preguntas que se pueden encontrar fácilmente en Internet o mediante documentación.

La mayoría de nosotros, los desarrolladores, no podemos recordar miles de líneas de documentación... todo el tiempo, especialmente cuando cambiamos de tecnología.

También estoy preguntando por el futuro; por ejemplo, si tengo que escribir código durante una entrevista para otro trabajo, supongo que no debería usar la documentación.

A la mayoría de las empresas razonables les gustaría probar la lógica/estructura que encuentra en una prueba de codificación... no mucho sobre la sintaxis.

Alguien me dijo una vez algo como: “Un cirujano no puede leer sus libros cada vez que tiene que operar a un paciente”.

Quien te haya dicho eso no sabe cómo funciona la cirugía. A menos que sea un procedimiento muy común que el cirujano haya practicado cien veces, los buenos pasan mucho tiempo estudiando antes de cada paciente que ven. También pasan muchos años en la escuela de medicina estudiando un tema que no ha cambiado mucho en varios miles de años.

Estás en tu primer año en una industria donde cada semana se inventan nuevas formas de hacer las cosas. No tiene experiencia, por lo que se debe esperar que tenga que buscar cosas con frecuencia. Siempre que tenga las bases para saber si las soluciones que encuentra realmente resuelven su problema y que aprende de la experiencia, no hay nada de malo en esto. He sido ingeniero de software durante 15 años y todavía necesito buscar cosas casi todos los días. Un profesional utiliza todos los recursos que tiene disponibles para hacer el trabajo.

Profesionalidad y conocimiento son dos cosas completamente diferentes.

Buscar cosas de fuentes de terceros significa que le falta conocimiento, no falta de profesionalismo. La falta de conocimiento es un tema en sí mismo, pero en general no hay una persona que lo sepa todo.

Si conoce su falta de conocimiento y la maneja buscando cosas en fuentes de terceros, esto significa que tiene una estrategia profesional para resolver su problema específico de falta de conocimiento.

No buscar cosas sin saber que las cosas no son profesionales, pero este no es tu caso.

Lectura adicional sobre un efecto que contrasta con su "estrategia de uso de la documentación": el efecto Dunning-Kruger

¿Usar la documentación como desarrollador me hace parecer poco profesional?

No. Recordar minuciosos detalles arbitrarios es una pérdida de recursos. Tendrías que recordar muchos de ellos tanto en PHP (al que le falta un poco de consistencia) como en el desarrollo web en general, si te familiarizas con varios lenguajes y una docena de marcos.

Se burlan de mí por usar SO/Documentación con tanta frecuencia, lo que me hace dudar de mis habilidades.

Esta puede no ser la forma más eficiente de resolver sus tareas.

¿Usas algún IDE? ¿Tus compañeros usan alguno? Porque la búsqueda de esos detalles minuciosos se puede delegar en la función de autocompletar de IDE. Usar autocompletar es más eficiente que cambiar su atención al navegador y buscar una respuesta allí.

Si sus colegas usan el autocompletado de su IDE y usted usa Google en su lugar, eso podría parecer poco profesional, no porque consulte documentos sino porque lo está haciendo de manera ineficiente.

Si sus colegas confían en su memoria y usted confía en el autocompletado, podrá superarlos en tareas que usan algún marco con el que ninguno de ustedes está familiarizado, lo cual no es tan raro en la web.

Domina tus herramientas y muestra el rendimiento, eso es profesional.

Otros han brindado respuestas sólidas, pero nadie realmente aborda esto de frente; el énfasis en negrita es mío:

La razón para hacer esta pregunta es que se burlan de mí por usar Stack Overflow/documentación con frecuencia , lo que hace que otros duden de mis habilidades.

¿Quiénes son estas personas que se “burlan” de ti y cómo sabes que “…hace que otros duden de [tus] habilidades?”

Todo esto suena como una variedad de jardín (también conocido como común) para mí. Si usted es un desarrollador junior, naturalmente se encuentra en una jerarquía en la que otros lo pondrán a prueba y presionarán botones como parte de su propio comportamiento de novatadas. Esto sucede tanto si son conscientes de ello como si no; es sólo parte del curso.

Al final del día, todas las personas del mundo utilizan herramientas de referencia para realizar su trabajo. Diablos, ¿los abogados y los médicos no tienen toneladas de referencias y libros a los que se refieren constantemente? La programación no es diferente.

Tu trabajo como programador es unir los deseos de un proyecto con la realidad del código mismo. Tu trabajo no es memorizar tonterías arcanas. y si llega al punto en que puede recordar, e incluso visualizar, tonterías arcanas, ¡entonces felicidades! Pero eso no sucede de la noche a la mañana y, a veces, no sucede en absoluto para algunos.

FWIW, he estado trabajando en la computadora durante más de 20 años y solo en los últimos años puedo, literalmente, visualizar soluciones en mi cabeza sin escribir una línea de código. Es una habilidad en la que uno crece y no se puede exigir que alguien tenga a pedido.

Si bien esto no lo hará parecer poco profesional para un profesional (la gran mayoría de las veces), es posible que desee tener cuidado frente a un cliente o gerente ingenuo. Así como usted, con casi un año de experiencia en programación, no está seguro de si los profesionales necesitan buscar cosas, las personas con una experiencia aún menos relevante también pueden no estar seguras.

De hecho, he defendido a otros desarrolladores en algunas ocasiones cuando un cliente de un compromiso de consultoría dijo algo como "¿por qué estoy pagando un buen dinero por alguien que ni siquiera puede escribir código sin buscarlo en Internet?"

Esto ha sido raro, pero por supuesto no sé cuántas personas tuvieron una mala impresión pero permanecieron en silencio.

Ciertamente, no es poco profesional buscar cosas cuando no está familiarizado.

Sin embargo, si no retiene ese conocimiento y busca continuamente las mismas cosas , entonces podría haber un problema. Eso es ineficiente. Te hace más lento y esa podría ser la causa de las burlas. Debe aprender los conceptos básicos de su profesión hasta el punto en que no necesite buscarlos cada vez.

Es mucho más profesional leer la documentación y obtener el código correcto que adivinar y equivocarse. Esto es especialmente cierto en un lenguaje como PHP, donde la biblioteca estándar está diseñada al azar, es difícil de memorizar y está llena de trampas.

Tomemos, por ejemplo, la mail()función. Sabías…

• additional_headersno tiene protección de inyección de encabezado de correo. Por lo tanto, los usuarios deben asegurarse de que los encabezados especificados sean seguros y solo contengan encabezados. es decir, nunca inicie el cuerpo del correo poniendo varias líneas nuevas.

  Si no está al tanto de esa advertencia, terminará introduciendo una vulnerabilidad de seguridad .

• Al enviar correo, el correo debe contener un encabezado De. Esto se puede establecer con el additional_headersparámetro, o se puede establecer un valor predeterminado en php.ini.

  Eso significa que el comportamiento de su aplicación podría depender de una configuración global. Es útil saberlo, para que pueda evitar escribir código que parece funcionar correctamente en una máquina, pero que no es portátil para otra.

• El $toparámetro debe cumplir con RFC 2822 .

  Has visto miles de correos electrónicos, así que crees que sabes cómo es una dirección de correo electrónico aceptable, ¿verdad? Lea las especificaciones; probablemente se sorprendería.

Claro, es posible que pueda generar más código si no lee la documentación detenidamente, pero probablemente no sea un código de calidad profesional . No tiene por qué avergonzarse de comprobar la documentación con frecuencia para asegurarse de que está utilizando el idioma y las bibliotecas correctamente.

Buscar cosas de las que no está seguro ahorra tiempo y también le permite buscar mejores formas de hacer algo. Quedarse atascado haciendo lo mismo una y otra vez de manera ineficiente cuando hay una mejor manera simplemente comprobando que la red no es buena.

Como otros respondieron, no existe la falta de profesionalidad para verificar la documentación, especialmente considerando que es junior, especialmente considerando que la programación es amplia y siempre hay un detalle que puede olvidar y tiene la misión de que su código sea correcto.

Sin embargo, hay casos que consideraría abusos de documentación.

Tengo un colega que a veces no puede encontrar su propia solución a un problema determinado. Por lo tanto, a veces procede a consultar la web sobre cómo resolver su problema. La última vez, por ejemplo, comprobó cómo un marco web estaba estructurando validadores y contadores de errores porque tenía una característica aparentemente similar para diseñar.

Este es un caso en el que lo que está buscando es demasiado abstracto para que Internet lo ayude. Peor aún, podría encontrar soluciones que aparentemente encajan, pero de hecho no lo hacen, porque se aplican a un caso de uso diferente. Al tratar de tomar algún código/arquitectura/patrón prefabricado, tendría más o menos código inyectado en nuestra base que podría haber funcionado, pero que sería difícil de mantener porque lo escribió otra persona para un propósito diferente.

No miro la documentación a menudo porque escribo código que usa principalmente funciones de lenguaje central (sin marco) y tengo una memoria confiable cuando se trata de código, pero uso el documento cada vez que estoy atascado en algo trivial. . Sin embargo, si estoy atascado en algo de nivel superior, lo bueno que puedo hacer es buscar ayuda de un colega con más experiencia, obtendrá una respuesta mucho mejor.

Hay una diferencia entre "profesional" y "con conocimientos". Si hay alguna información que necesito saber, y tengo que elegir entre sentarme estúpidamente en mi silla y quedarme atascado, o revisar la documentación, entonces reviso la documentación. Eso es absolutamente profesional.

Si esa información es algo que una persona bien informada en mi posición debería saber, entonces buscarla puede mostrar que no tengo tantos conocimientos como debería, pero aún así es completamente profesional, ya que la alternativa es no saberlo y no aprendiendo Lo cual (la parte de no aprender) es completamente poco profesional.

Sería tonto suponer que sabes todo lo que deberías saber, porque todos los días habrá algo nuevo que deberías saber, que no estaba allí ayer. Incluso si sabes algo, ¿cómo sabes que tu conocimiento es el mejor posible? Consulta la documentación para averiguar si hay algún conocimiento mejor sobre el mismo tema.

Es raro que haya un problema que no pueda resolver por mí mismo. Pero lleva tiempo. Dada la opción entre tomarme una hora para resolverlo yo mismo y cinco minutos usando Google, pasar la hora no es profesional.

Ya tienes algunas buenas respuestas, pero déjame agregar un pequeño giro...

Me gusta que la gente utilice la documentación y es una gran señal de tu profesionalidad.

No usar documentación

Conozco suficientes programadores que se tambalean sin un plan real durante largos períodos de tiempo, probando esto y aquello por casualidad, seleccionando código fuente antiguo donde lo que quieren lograr parece que ya se ha hecho (pero no del todo) y así. en. Francamente, detesto este tipo de enfoque. Nunca llegan muy lejos, a menudo tienen que preguntarle a la gente, rara vez aceptan consejos y prefieren continuar así para siempre, aparentemente.

¿Solo tutoriales?

Las personas que buscan en Google con frecuencia tutoriales o fragmentos de código, incluido SO, sin consultar nunca la documentación, me irritan muchísimo. Este comportamiento es una gran trampa, en mi opinión. Conduce a una especie de programación alimentada por un "conocimiento" arbitrario, asistemático y a medias. Esos programadores tienden a terminar con muchos prejuicios. Aquí es donde vienen las pepitas como "nunca usar git rebase", "nunca usar not inen SQL", "siempre hacer XXX", "nunca hacer YYY". Les resultará muy difícil pensar fuera de la caja, generar nuevas ideas, desarrollar la intuición sobre cómo estructurar sus aplicaciones y todo eso que hace a los grandes desarrolladores.

Le insto a que resuelva cualquier problema primero mirando la documentación/referencia, y luego busque SO u otros fragmentos.

Por supuesto, hay excepciones. Si su problema es obviamente algo así como un error, o algo muy, muy, muy especial que es poco probable que se maneje en ningún tipo de documentación (por ejemplo, una combinación especial de bibliotecas/módulos, etc.), entonces vaya directamente a SO.

Si es algo que podría resolverse fácilmente mediante documentación/API, entonces sugeriría sentarse y trabajar en esa parte particular de su lenguaje de programación/bibliotecas, etc. para que su conocimiento sea más estricto.

Documentación

El mejor tipo, para mí, es un programador que, cuando se encuentra con un tema nuevo, se toma el tiempo para realmente sentarse, profundizar en él, obtener una buena visión general y una buena comprensión técnica. Esto se logra la mayoría de las veces (nuevamente, en mi experiencia, con los muchos lenguajes de programación con los que tuve contacto) leyendo la buena documentación anterior, incluidas las referencias de API, etc. En mi opinión, esto nunca puede ser reemplazado por nada más.

No me parece descabellado leer, por ejemplo, los viejos clásicos de C++ (buen artículo antiguo), los patrones de diseño de Gang of Four, la (versión en línea del) manual "Programming Ruby", las páginas de manual de Perl extremadamente bien hechas, el Libro Git, ciertos RFC, HTML/XML/etc. especificaciones y así sucesivamente de adelante hacia atrás. Lo haría y lo he hecho incluso en mi tiempo libre y, francamente, lo esperaría de cualquier programador que se precie (dependiendo de con qué esté trabajando, obviamente). También soy plenamente consciente de que estoy (al menos en las empresas en las que trabajé, en las últimas décadas) bastante solo con esta opinión.

(NB: Obviamente, no necesita memorizar grandes listas de referencias de API, pero al menos páselas por alto para ver qué hay disponible y cuál parece ser el "espíritu" de la API).

Después de sentirse completamente cómodo con el tema, entonces es el momento de mirar el código de terceros en busca de inspiración, o de mirar las preguntas anteriores de SO (o hacer nuevas preguntas usted mismo).

También puede encontrar que cuando ha absorbido un campo como este, es muy fácil encontrar respuestas haciendo zoom directamente en el lugar donde obtiene su documentación (páginas de manual, etc.). En este punto, la finalización automática de su editor también podría ser suficiente. Y también podría saber muy pronto cuándo algo no es posible con la herramienta con la que está trabajando, ahorrando una gran cantidad de búsquedas inútiles.

Su habilidad como programador se trata de cómo puede ver la imagen completa y diseñar soluciones efectivas, no cuántas API puede memorizar. El objetivo es hacer el trabajo de manera correcta y eficiente. Si tuviera que buscar cada API y cada detalle, diría que tiene algunos problemas. Esperaría que un buen desarrollador esté completamente familiarizado con todo lo que se usa con frecuencia, recientemente y de forma rutinaria, pero que no desperdicie su capacidad intelectual en cosas que se usan con poca frecuencia cuando se pueden buscar fácilmente. Si visitó stackoverflow más o menos una vez al día, no hay problema; si está en él la mayor parte de su día laboral típico, eso sería un problema.

Me burlan un poco por usar Stack Overflow/documentación con tanta frecuencia

Las opiniones de otras personas sobre ti no te definen a ti , solo las definen a ellas.

¿Usar la documentación como desarrollador me hace parecer poco profesional?

No... parte de ser profesional es la competencia para hacer el trabajo. Se burlan de ti porque tus colegas son acosadores, no por algo que estés haciendo mal.

“Un cirujano no puede leer sus libros cada vez que tiene que operar a un paciente”.

¿Por que no? Soy escéptico de esa afirmación a menos que haya una escasez de tiempo inusual. Usar material de referencia solo lleva unos segundos.

si tengo que escribir código durante una entrevista para otro trabajo, supongo que no debería usar la documentación

Depende de las reglas de la entrevista, algunas lo permiten, otras no. En particular, si se trata de una prueba, puede permitirse. ¡Es una buena idea comprobar primero!