Ya tienes algunas buenas respuestas, pero déjame añadir un pequeño giro…
Me gusta la gente que usa documentación y es una gran señal de tu profesionalidad.
No uso documentación
Conozco suficientes programadores que se tropiezan sin un plan real durante largos períodos de tiempo, intentando esto y aquello por casualidad, revisando código fuente antiguo donde lo que quieren conseguir parece que ya se ha hecho (pero no se ha hecho del todo) y así sucesivamente. Francamente, detesto este tipo de enfoque. Nunca llegan muy lejos, a menudo tienen que preguntar a la gente, rara vez aceptan consejos y prefieren continuar así para siempre, aparentemente.
¿Sólo tutoriales?
La gente busca frecuentemente en Google tutoriales o fragmentos de código incluyendo SO, sin referirse nunca a la documentación, me irrita hasta el final. Este comportamiento es una gran trampa, en mi opinión. Conduce a un tipo de programación alimentada por un “conocimiento” a medias, arbitrario y poco sistemático. Esos programadores tienden a terminar con muchos prejuicios. De aquí vienen nuggets como “nunca use git rebase”, “nunca use not in en SQL”, “siempre haga XXX”, “nunca haga YYY”. Les resultará muy difícil pensar fuera de la caja, proponer nuevas ideas, formar intuición sobre cómo estructurar sus aplicaciones y todas esas cosas que hacen a los grandes desarrolladores.
Les insto a resolver cualquier problema primero mirando la documentación/referencia, y luego buscar SO u otros recortes.
Por supuesto, hay excepciones. Si su problema es obviamente algo como un error, o algo muy, muy, muy especial que es improbable que se maneje en cualquier tipo de documentación (por ejemplo, una combinación especial de librerías/módulos etc.), entonces por todos los medios ve directamente al SO.
Si es algo que podría ser fácilmente resuelto por la documentación/API, entonces sugeriría sentarse y trabajar en esa parte particular de tu lenguaje de programación / librerías etc. para que tu conocimiento sea más ajustado.
Documentación
El mejor tipo, para mí, es un programador que, cuando se encuentra con un nuevo tema, se toma el tiempo para sentarse realmente, indagar en él, obtener una buena visión general y una buena comprensión técnica. Esto se consigue la mayoría de las veces (de nuevo, en mi experiencia, con los muchos lenguajes de programación con los que he tenido contacto) leyendo la buena y vieja documentación, incluyendo las referencias de la API y demás. Esto, en mi opinión, nunca puede ser reemplazado por nada más.
No me parece descabellado leer, por ejemplo, los viejos clásicos de C++ (buen papel), la Pandilla de Cuatro Patrones de Diseño, el (versión online del) manual de “Programación Ruby”, las extremadamente bien hechas páginas de Perl, el libro de Git, ciertas RFCs, las especificaciones HTML/XML/etc. 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 valga la pena (dependiendo de con qué estén trabajando, obviamente). También soy plenamente consciente de que estoy (al menos en las empresas en las que he trabajado, en los últimos decenios) bastante solo con esta opinión.
(N.B.: Obviamente no es necesario memorizar enormes listas de referencias de API, pero al menos hay que pasarlas por alto para ver lo que está disponible y cuál es 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 para inspirarse, o de mirar preguntas SO más antiguas (o hacer nuevas preguntas usted mismo).
También podría encontrar que cuando ha absorbido un campo como este, es muy fácil encontrar respuestas haciendo un zoom directo a la carne de donde sea que obtenga su documentación (páginas de manual, etc.). En este punto, la autocompletación de tu editor también podría ser suficiente. Y es posible que pronto sepas cuando algo no es posible con la herramienta con la que trabajas, ahorrando así muchas búsquedas inútiles.