Hay muchas fuentes para aprender de los colegas más experimentados: libros, blogs de desarrolladores hábiles, Stack Exchange, conferencias / conferencias, etc. Las revisiones de códigos también son cruciales, y CodeReview.SE es un recurso valioso.
Veamos cómo podría funcionar en un ejemplo.
Ejemplo
Estás leyendo una publicación de blog que menciona un término "ETL". No sabes el significado de esto, pero a partir de este artículo, entiendes vagamente que es una especie de proceso o flujo de trabajo que mueve datos de un soporte de datos a otro.
Vas a Wikipedia y otros recursos y obtienes una visión más precisa de la cosa. Todavía no está muy claro cuándo sería útil usar un ETL. Después de todo, parece mucho más fácil escribir una consulta SQL que hará todo el trabajo, en lugar de pasar demasiado tiempo construyendo un ETL real.
Para responder esas preguntas, toma prestado un libro sobre los ETL de su biblioteca local. Explica que algunos procesos de extracción-transformación-carga no son fáciles de realizar con una simple consulta SQL: no solo la fase de extracción puede manejar varios soportes de datos diversos, no solo una base de datos relacional, sino que también el paso de transformación puede ser muy complicado para tanto validar / normalizar los datos como mapearlos.
Ahora tiene una visión clara de qué es un ETL, cómo usarlo y especialmente cuando necesita un ETL y cuando no es una herramienta adecuada. Mientras tanto, ha implementado un pequeño ETL como proyecto personal. Este proyecto le permite descubrir algunos puntos que no son lo suficientemente claros para usted y que no están cubiertos por un libro. Esos puntos son bastante abstractos y no están relacionados con el código fuente, usted publica una pregunta en Programmers.SE .
Cuando tiene la oportunidad de construir uno en su empresa, comienza a crearlo. Tienes algunos problemas. Algunos están relacionados con el código; Usted publica preguntas en Stack Overflow . Otros están relacionados con la base de datos; a hacer las preguntas sobre DBA.SE .
Finalmente, hay una conferencia realizada por un desarrollador altamente hábil sobre cómo optimizar los ETL. Usted asiste a esta conferencia y le da pistas valiosas sobre las mejoras que puede hacer para su proyecto.
También comienza a seguir un blog de un desarrollador que estuvo trabajando en diferentes ETL durante años. Es interesante ver los diferentes enfoques, y a través de este blog, aprenderá sobre ECCD; usted está interesado, por lo que toma prestado el Kit de herramientas ETL de Data Warehouse de Ralph Kimball, el libro que habla en detalle sobre el proceso de "extraer, limpiar, conformar y entregar". El mismo blog también menciona muchas aplicaciones destinadas a crear ETL sin habilidades de programación. Esto es particularmente útil para el ETL que ha hecho para su empresa, ya que su jefe, una persona no techista, le pide constantemente que haga algunos pequeños cambios en lo que ha hecho.
Descubriendo cosas
En mi humilde opinión, la parte difícil, cuando no tienes un mentor o un colega más experimentado, es descubrir cosas, y por descubrir, me refiero a pasar del estado "Nunca he oído hablar de esto" a "He escuché sobre eso pero no sé muy bien qué es ".
Si alguien revisa mi código y dice que realmente debería comenzar a usar algunas convenciones de estilo, con un poco de curiosidad puedo encontrar que en la programación, hay diferentes estilos de escritura de código, que uno debería seguir con un estilo para un lenguaje y una base de código dados, y que muchos lenguajes tienen herramientas para imponer un estilo (como StyleCop para C #).
Si nadie me cuenta sobre el estilo, ¿cómo sabría que existe tal cosa?
Ahí es donde los recursos como blogs o Stack Exchange son útiles. Wikipedia no ayudaría (a menos que pase días visitando páginas aleatorias sobre programación), y los libros rara vez hablan de esas cosas.
Lo mismo se aplica también a patrones y prácticas o cosas que están menos relacionadas con el código. Por ejemplo, apenas imagino a un desarrollador que se despierta por la mañana diciéndose a sí mismo que debe aprender algo sobre ITIL mientras que nunca antes se había preocupado por ITIL.
Una vez que descubrió un nuevo término, es bastante fácil aprenderlo. Si le ha dado un nuevo término "contratos de código" y es un desarrollador de C #, puede encontrar fácilmente suficiente información en MSDN (o, mejor aún, en el libro de Jon Skeet).
La curiosidad ayuda
Cuando trabajo con pasantes, siempre noto que los mejores son aquellos que tenían curiosidad fuera de sus conferencias. Es posible que sepan que existe una cosa llamada programación funcional, incluso si ninguno de sus maestros nunca lo mencionó, y si bien es posible que no conozcan ningún lenguaje funcional, aún pueden explicar en términos generales qué es FP y cómo es diferente de otros paradigmas Pueden saber sobre Agile, o sobre Unicode, o sobre el modelo de confianza parcial / sandbox, simplemente porque estaban leyendo blogs y usando Stack Exchange, en lugar de simplemente asistir a sus conferencias.
Incluso cuando no tienen un mentor, aprenden todas esas cosas que no se cuentan en la universidad.