¿Cómo puedo mejorar mis habilidades mientras trabajo en proyectos reales, en ausencia de desarrolladores más experimentados? [cerrado]

Soy el desarrollador principal de una pequeña empresa, trabajando con C # y ASP.Net. Nuestro equipo es pequeño, de 2 a 3 personas, sin mucha experiencia en desarrollo y diseño. No tengo la oportunidad de aprender de más desarrolladores senior, no hay nadie en mi equipo que me guíe y me ayude a elegir los mejores enfoques, ya que yo mismo me encargo de la mayoría de los proyectos.

¿Cómo puedo mejorar mis habilidades de desarrollo de software mientras trabajo en proyectos reales, en ausencia de desarrolladores más experimentados?

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.

Estoy en una situación similar: somos un equipo pequeño y nuestro trabajo principal de productos de desarrollo consiste principalmente en cambios incrementales en una base de código que tiene unos pocos años.

Algunas técnicas que estoy usando para mantenerme actualizado y mejorar mis habilidades.

En el trabajo:

• Leer: libros, blogs, materiales de relaciones públicas. Sigo una serie de canales RSS. Cuando el acuerdo del día de O'Reilly es sobre una tecnología de la que no he oído hablar, leo la descripción del libro. Si la tecnología tiene mucha relación con algo en lo que estoy trabajando, paso cinco o diez minutos investigando un poco más de profundidad, similar a la respuesta de MainMa. Repito esto con algunas fuentes RSS diferentes.
• Cree un plan de capacitación con su gerencia que pueda ser respaldado con recursos de la compañía (tiempo y / o dinero)
• Contrariamente a las tendencias de la mayoría de los programadores, intente adoptar cambios y nuevas opciones de diseño. Cambiar por cambiar no es bueno , pero creo que con demasiada frecuencia los desarrolladores evitan usar un nuevo diseño o marco debido al cambio. Esta es una línea muy fina para caminar, y no se apresure a tomar decisiones vinculantes, pero esté atento a las nuevas formas de hacer las cosas. Algunos cambios pueden tener beneficios inesperados: pasar a DVCS me permite experimentar con nuestra base de código más fácilmente y probar nuevas tecnologías allí.
• A algunas personas les gustan las conferencias; Descubrí que la recompensa es pequeña por el tiempo invertido.

Fuera del trabajo:

Descubrí que trabajar en mis habilidades fuera del día a día es fundamental. La libertad de experimentar, cometer errores y perseguir intereses me mantiene involucrado en TI. Si solo tuviera mis proyectos en el trabajo y necesitara limitar mi aprendizaje a lo que era inmediatamente útil, me agotaría rápidamente.

• Participe en un proyecto que no sea de trabajo. Para mí, esto es desarrollar un sitio web funcional relacionado con un interés personal. Refactorizo ​​libremente e intento experimentar activamente con diferentes tecnologías. Contribuir a Open Source también lo expondrá al código de otras personas. Esto también le dará un buen material para compartir para entrevistas con la compañía que tendrá desarrolladores más experimentados.
• Code Camp: si hay un campo de código en su área, asista. Debido a que estos no son durante las horas de trabajo y son gratuitos, usted siente la libertad de asistir a cualquier sesión sobre temas que le interesen personalmente. En comparación con las conferencias típicas, estas suelen ser locales y abarcan grandes extensiones de tecnología, por lo que creo que hay un valor más concentrado.

Y no olvide visitar SO o Programmers.SE con frecuencia.

Las respuestas aquí probablemente serán de gran ayuda, pero me gustaría enfatizar algo: nada puede reemplazar trabajar con alguien mejor que usted (para definiciones arbitrarias y personales de mejor) durante 8 horas al día, 5 días a la semana. Eso es seguro.

Si eres el tipo de desarrollador que siempre quiere mejorar, siempre quiere aprender, eventualmente tendrás que ir a una compañía diferente. Eso es inevitable y debe planificarse.

Cuando encuentre la compañía adecuada para usted, descubrirá que puede continuar creciendo dentro de ella, en lugar de crecer fuera de ella.

El desarrollo de software es un deporte de equipo. Como un deporte, para jugar a un nivel muy alto, debes estar y competir contra otros que hacen lo mismo. Busque oportunidades para moverse.

Recuerde que la práctica hace que sea permanente, por lo que si no está trabajando constantemente hacia una mejor técnica y conocimiento, si trabaja de forma aislada sin crítico o modelo a seguir, puede descubrir que sus habilidades no crecen.

En todo el mundo, las cosas se están volviendo más competitivas, así que espere que su nicho sea temporal y prepárese para el tipo de oportunidad que cumpla con sus criterios de trabajo satisfactorio, mientras que al mismo tiempo lo lleva fuera de su zona de confort para trabajar con un equipo superior.

Antes de llegar a cualquier sugerencia, debo decir que estaba en una posición muy similar hace poco más de un año.

Si está realizando los proyectos, pero siente que hay mucho espacio para mejorar, eso es algo bueno.

En una ocasión no tenía la capacidad técnica y la confianza para completar el proyecto. A menudo compraba un libro, leía un blog bastante técnico y me encontraba "fuera de mi profundidad". Creo que el mayor problema para mí fue el hecho de que no estaba expuesto a ninguna aplicación empresarial de gran tamaño. Muy a menudo haría algo bien, pero no tendría a nadie a mi lado para validar lo que he hecho.

Esto fue desmotivador y desafiante, así que veo de dónde vienes. ¿Cómo solucioné este problema? Dejé una empresa y me uní a una casa de desarrollo de software bien establecida, lo que me ha ayudado a ganar mucha experiencia durante el año pasado.

A menos que quiera dejar la empresa, le sugeriría libros escritos por los pioneros de nuestra industria. Comenzaría con The Pragmatic Programmer por Andrew Hunt. El libro contiene toneladas de analogías útiles que son muy fáciles de recordar. Los primeros capítulos de este libro me han animado a elegir un lenguaje de programación muy diferente al que usamos en el trabajo. Empecé a leer literatura no técnica; ahora creo que leer novelas y ciencia ficción me hará un mejor programador. Escribir ensayos no está muy lejos de escribir código limpio. Algunos escritores son buenos y otros malos. Este libro me hizo preocuparme por lo que escribo. Una de las analogías se llama "Windows roto". Dejas un auto abandonado en la calle durante días y no le pasa nada. Una vez que rompes una sola ventana, el auto probablemente será destruido al día siguiente. El código no es diferente. Si ve código roto o mal escrito, corríjalo de inmediato, no lo deje allí, porque tarde o temprano volverá a "perseguirlo". Una vez que comience a leer este libro, recogerá docenas de analogías similares que lo harán pensar en el código de una manera diferente.

Entonces te sugiero que pases a Clean Code por Robert C. Martin. Este libro es más práctico, ya que te obliga a leer códigos buenos y malos (limpios). El autor utiliza ejemplos de código de uno de los proyectos de código abierto. Dices que no hay nadie que te guíe. Hay una oportunidad perfecta para mirar el código de otra persona, compararlo con el suyo y ver cómo puede mejorarlo. Para mí, leer este libro fue como seguir a alguien trabajando en un proyecto. El libro también hace un fuerte énfasis en lo más fácil: la separación de las preocupaciones. El autor ha preguntado a los pioneros de nuestra industria qué consideran que es un código "limpio". Una vez que lea sus respuestas, podrá compararlas con su propia opinión sobre el código limpio.

Finalmente, ¿ha considerado trabajar en proyectos de código abierto? Estará colaborando con otros desarrolladores, probablemente más experimentados, que podrán revisar su código y orientarlo en la dirección correcta.

Como dije en mi respuesta original, no sucederá durante la noche. He estado haciendo esto durante algunos años y casi todos los días descubro que lo he estado haciendo mal.

¡Buena suerte!

Practica resolviendo problemas. Lea y trabaje para comprender el código de otros (github es un gran recurso para esto) y envíe mejoras al mismo. Hacer trabajo de consultoría realmente puede ayudarlo a ampliar su conjunto de habilidades.