¿Es una buena idea el asesoramiento de un programador senior sobre el uso de libros siempre? [cerrado]

Te vas a encontrar con programadores como este en toda tu carrera. No hay nada de malo en experimentar y aprender por tu cuenta. Claro que los libros son geniales. Muchas veces los ejemplos funcionan en un entorno limpio, pero si eres desarrollador de otra empresa, no existe un entorno limpio (sin interferencias de otros).

Siempre es bueno saber cómo hacer las cosas de la manera "correcta", pero las opiniones cambian año tras año. Así que aprende lo que puedas. Tome lo que pueda del desarrollador senior, combínelo con su conocimiento que aprende por su cuenta. Eventualmente, serás un desarrollador senior y sacarás de estas experiencias y enseñarás a los desarrolladores junior.

Simplemente no seas un idiota al respecto.

¿Realmente te llamó tú estúpido, o simplemente desacreditó el código? Llamar a cualquier estupidez no tiene tacto, pero eso no invalida la sugerencia. Creo que Infestus ha hecho una sugerencia valiosa, y en el futuro deberías considerar sus sugerencias seriamente. Parece que lee mucho, y al menos en este caso su opinión está bien informada. La sincronización es costosa y complicada. Su implementación recomendada es más eficiente y más simple que la suya, y está garantizado que funciona.

  

Siempre está tratando de darme libros para leer para que pueda "aprender" qué formas de programar.

Eso es algo de él. Él está tratando activamente de ayudarte, pero parece que estás dejando que tu ego se interponga en el camino. No tome las críticas de su código personalmente. El código es barato de producir y fácil de cambiar. Si alguien te muestra una forma más sencilla de hacer algo, agradéceles.

Y sí, la lectura te hará un programador mucho mejor. Todos los expertos que he conocido leen mucho. Si no estás leyendo mucho, entonces, en el mejor de los casos, eres mediocre, y en otros cinco años puedes encontrar que ya no eres comercializable.

La lectura de un libro no debe ser ciega: el autor debe tratar de convencerlo de los méritos de su enfoque cuando lo presenta. Es razonable que su superior le indique un libro que explique su enfoque preferido, en lugar de pedirle que se lo explique él mismo: aunque debería poder explicar los beneficios de sus preferencias sin depender del libro, también es una duplicación de esfuerzos. El autor del libro ya ha hecho.

Entonces, lea el libro, vea lo que dice el autor del libro, y si le confunde, o le gustaría confirmar su comprensión, o si no está de acuerdo, entonces hable con su superior, pero ahora Podré tener una discusión más productiva.

Hay tres elementos clave para cualquier relación sana. Comunicación, honestidad y confianza. Eso cuenta para todas las relaciones, incluso para las relaciones laborales. Debe hablar con su supervisor sobre estas inquietudes.

Si no comprende sus razones para abogar por un diseño determinado, dígale eso . Dígale que no ha leído el libro y que le gustaría comprender por qué su forma de hacerlo es mejor. La clave es que deberías estar tratando de entender su manera de hacer las cosas.

Creo que también debes tratar a esta persona con más respeto. En tu cabeza, le estás llamando nombres despectivos y criticando su enfoque de lo que consideras "aprendizaje". Cuidado con eso. Por otro lado, dijiste que te llamó tú estúpido. Eso no es bueno, y debes decirle que no es bueno llamar a alguien estupido.

Las ideas pueden ser estúpidas. Todos cometemos errores y extrañamos cosas, incluso los mayores. Cuando hay un defecto en un diseño, la mejor pregunta es: "¿Por qué lo haces de esta manera? ¿No se romperá en la situación X, Y, Z? ¿El diseño B no será mejor?"

Tenga en cuenta que está trabajando en este software con otras personas. Esa es una habilidad difícil de aprender. No importa que no estés escribiendo nada desde cero, siempre hay espacio para brillar al hacer que tu código sea el mejor que puedas.

Y "mejor" muy a menudo significa legible y comprensible . Los programadores pasamos mucho tiempo leyendo el código de otras personas. Si ese código es claro y legible, entonces el código es realmente valioso. Una de las formas en que aprendemos a escribir un buen código es leyendo muchos buenos códigos. Muy a menudo encuentras muy buen código en los libros. Por lo tanto, leer uno o dos buenos libros de programación probablemente lo convertirá en un mejor programador.

En la empresa donde trabajas, probablemente lo sea. Esto es lo que requieren que hagas.

Este ingeniero Infestus hace un trabajo muy pobre educando a los desarrolladores junior al decirles "esto está escrito en el libro, y es por eso". No es un predicador, es un ingeniero, y debería poder descomponerlo y presentar los conceptos para que los jóvenes puedan aprender de su experiencia.

Lo alentaría a hablar con desarrolladores con conocimientos en su empresa, hacerles preguntas sobre los pros y los contras de las diferentes técnicas de programación, etc. Esto, junto con la lectura de libros y blogs (recomendaría Joel en Software; solo busque en Google, es un deber) debe darle una mejor comprensión.

En mi humilde opinión, hay dos aspectos aquí, que debe tratar por separado:

• El hecho de que el chico esté siendo un imbécil, llamándote nombres y demás simplemente porque puede (él es mayor, no lo eres, si alguno de los dos se queja del otro, obtendrá el beneficio de la duda ) es simplemente un comportamiento abusivo, y simplemente malo.

Intenta no agacharte a su nivel con esto. No intentes intimidarle de nuevo o "decirle" al jefe o algo así. Haga todo lo posible por ignorar este aspecto de su comportamiento, teniendo en cuenta que se vuelve demasiado extremo (es decir, si afecta su productividad y demás), debería hacer algo al respecto.

• El hecho de que te está diciendo que tu código es malo (y cómo hacerlo correctamente). Honestamente de lo que describe, ignorando el tono del chico, este aspecto de su comportamiento no es tan malo. Aprendes mucho más rápido y puedes verlos en el contexto adecuado cuando tienes a alguien más experimentado que te corrige y te dice no solo lo que hiciste mal, sino también cómo hacerlo bien (en comparación con solo aprenderlo todo por ti mismo. de experimentos de prueba / error personales y similares).

Muchas veces he tenido a alguien que corrigió lo que inicialmente pensé que era "mi código perfecto" y me molesté porque el tipo me estaba diciendo qué hacer solo para luego darme cuenta de que tenía razón todo el tiempo, mi versión era mala , el suyo era bueno, y gracias a Dios vio eso! :) Así que aprendí a atenuar mis impulsos iniciales de "hey, u no me digas qué hacer, mista!" y en vez de eso, cada vez que alguien me corrige yo primero, objetivamente, reviso mi código, luego reviso el suyo, y me aseguro de que no está realmente bien y que soy yo quien está cometiendo el error. Si fue mi culpa, le agradezco la ayuda y me aseguro de que realmente entiendo cómo funciona su solución (en lugar de simplemente copiarla / pegarla).

Y oye, a veces me parece que la corrección ofrecida fue, de hecho, peor que la que hice inicialmente, momento en el que trato de hablar todo esto con el otro tipo. Honestamente, me he dado cuenta de que nada gana el respeto de los demás por ti más rápido que cuando ven que puedes aceptar que te corrijan cuando cometes un error, pero al mismo tiempo, no temes decir que tú eres el indicado. Quién tiene razón cuando crees que es así, dado que puedes probar de inmediato que basas tu afirmación en una investigación real, y no solo en el ego.

En este punto, creo que realmente deberías intentar hablar con el tipo sobre lo que propone, lo que propones, etc. Muéstrale lo que piensas, cómo llegaste a una solución en particular y por qué crees que es mejor que la suya (cuando crees que es honesta y objetivamente). O, si descubre que su propuesta es mejor que la suya, dígale, exprese su agradecimiento por la ayuda. Esto puede reconstruir algunos puentes quemados.

Experimenta por tu cuenta y aprende todo lo que puedas. Después de leer suficientes libros, descubrirá que hay varios libros sobre temas particulares y que pueden contradecirse entre sí. Pruebe el que crea que es mejor y pruebe ambos si tiene tiempo o desea comparar / contrastar.

Tratar con tu jefe es un tema y enfoque completamente diferente. Si quisiera que alguien hiciera algo exactamente como estaba en un libro, se lo diría. Eso es solo yo porque no me asocio con los lectores de la mente. Su jefe lo convierte en un hábito, solo pregúntele si recomienda algún libro o referencia cuando obtenga un nuevo proyecto.

Hagas lo que hagas, no dejes de trabajar en nuevos proyectos. Sé que es fácil para todos nosotros dar consejos sobre cómo lidiar con esta situación y pueden funcionar o no, pero usted es el que tiene que vivir con ella y sufrir la negatividad. Vas a mejorar, pero eso generalmente viene de escribir más código en cosas nuevas, aprender de los éxitos y los fracasos.

Seguir libros a ciegas es una mala idea, pero hay una diferencia entre seguir un libro exactamente y seguirlo a ciegas .

Cuando estás tratando de entender cosas en un libro, generalmente es apropiado para seguirlo exactamente al principio, mientras te das cuenta de lo que está tratando de enseñarte. Lo más probable es que aún no entiendas todo cuando hayas terminado (así es como suelen ir las cosas así), pero seguir el libro exactamente al principio te dará algo para experimentar, mientras intentas entender tus preguntas. Otra vez es bueno que encuentre formas en las que no está de acuerdo con lo que hay en el libro, pero comprenderá los problemas que el libro estaba tratando de resolver, de modo que, cuando llegue el momento de escribir su propio código, pueda diríjalos a su manera (o tal vez a su manera, al menos en parte) en lugar de simplemente dejar esos problemas para picarle más tarde.

Otra cosa que no es inherentemente específica de Java, pero que sin embargo es especialmente común en esa comunidad. Creo que puedo adivinar de qué libros están hablando, y forman una parte importante del léxico de la comunidad de Java. Comprenderlos, y las formas en que describen las cosas, será de gran ayuda cuando necesite comprender otro código Java que encuentre. Esa es una habilidad valiosa por derecho propio.

Leer libros y publicaciones de blogs es muy útil para la programación. Hay algunos libros, que todos los desarrolladores deben leer.

Sin embargo, los libros no son la única fuente para aprender diferentes conceptos y tecnologías de programación. Hoy en día, la capacitación basada en video a pedido se está volviendo muy popular. Puede consultar Pluralsight , que brinda capacitación de alta calidad a profesionales.

De hecho, si lees solo libros, eso tampoco te ayudará. Además de leer, hay otra cosa que tenemos que hacer también. Puede encontrar más detalles aquí .

Deberías preguntarle qué problema tiene tu método en particular. Si no puede responder con claridad, puede estar bastante seguro de que solo es un tipo común al que le gusta sentirse superior.

Lo que pasa con los libros es que, en su mayoría, pasan las revisiones, que tienen una mejor oportunidad de detectar malas prácticas y conceptos erróneos. Además, los "grandes nombres" son personas con experiencia que confían en ser buenos para ganar dinero extra vendiendo libros, por lo tanto, hay algunas garantías mínimas de calidad sobre lo que dicen.

Dicho esto, leer libros, documentos y otras fuentes es una buena forma de crecer como profesional, por supuesto, cuando se confirma con la práctica. Por lo tanto, es bueno que lea esos libros (incluso los recomendados por Infestus). Sin embargo, los libros deben ampliar principalmente su comprensión sobre el tema, ya que casi siempre habrá otras formas de resolver el mismo problema.

Acerca de su enfoque de "ir solo", el punto es: ¿puede sostener su punto de vista? ¿Cómo demuestras que tu solución es mejor que ninguna otra? Algunas veces puede idear soluciones brillantes por su cuenta, pero, en comparación con otras soluciones conocidas, debe poder argumentar la razón por la cual la suya es mejor, ya que las otras tienen a su favor, al menos, los casos de uso. Entonces, sea creativo y reflexivo, pero lo más importante, sea efectivo.

Si lo fuera, tú leería esos libros. Eso lo ayudará dándole más argumentos y, al mismo tiempo, puede descubrir que Infestus, tal vez, está tomando esos libros como argumentos, y no fue visto todavía porque nadie conoce el contenido de esos libros. O puede encontrar que en realidad k

Mi experiencia es que cuando se trata de temas de programación, la calidad y la presentación de la información con explicaciones adecuadas en los libros es mucho mejor que cuando se busca información sobre el mismo tema en Internet. Internet a menudo carece de una explicación, contexto y calidad adecuados.

La cantidad de dicha información en Internet es mayor.

Por lo tanto, mi estrategia general es aprender de los libros para obtener una comprensión más profunda y, después, aprender de Internet para exponerme a diferentes implementaciones y ampliar mi experiencia (y, a menudo, ver cómo no hacer cosas).

Investigaré los méritos de cada enfoque y llegaré a su propio criterio. Si crees que tu enfoque es mejor, discútelo con Infestus hasta que uno de ustedes convenza al otro. Si no puede llegar a un acuerdo, puede solicitar una segunda opinión o simplemente aceptar el enfoque de Infestus, dependiendo de qué tan fuerte se sienta al respecto.

En el caso de singletons, uno de los argumentos que podría presentar en contra del enfoque de enumeración es que las enumeraciones no pueden extender las clases. A menudo escribo código como este:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Esto no se puede hacer con enumeraciones. Dado que el enfoque de enumeración no funciona en todos los casos, podría argumentar que, por razones de coherencia, debe evitarse incluso cuando no es necesario tener una cláusula extends .

Algunos otros argumentos que podrían presentarse en contra del uso de enumeraciones:

• es un truco, está usando enumeraciones para algo para lo que no estaban destinados
• es confuso para los lectores que no lo han visto antes

Confío en los libros como una fuente de conocimiento: estos son excelentes cimientos y creo que Infestus tiene razón en que debes consumir cantidades significativas de libros en tu tiempo libre, ya que realmente aceleran tus habilidades. Sin embargo, los libros no son la única fuente de información que creo que debería consumir: atienda a su grupo de usuarios locales, reciba los boletines informativos de tecnología relevantes en su bandeja de entrada, lea los blogs.

Sin embargo, no estoy de acuerdo con la afirmación de que, como está escrito de cierta manera en un libro, es la forma en que debe hacerse. Sí, los libros brindan un gran consejo, y están escritos por expertos y revisados por expertos, pero como he estado involucrado en un libro comparativamente simple, puedo decirles que normalmente se necesitan al menos dos años para escribir, editar y publicar un libro. . El ritmo del cambio en la tecnología es rápido y el consejo de hace dos años puede que ya no sea el correcto para hoy. Los directores genéricos a menudo resisten el paso del tiempo, pero la optimización de una actividad específica se puede invalidar con un nuevo hardware o una nueva versión de software.

La sugerencia de pedirle a Infestus que haga las sugerencias con usted es excelente: váyase, lea todo y regrese con un montón de preguntas que ya ha tratado de responder / resolver por sí mismo junto con su apoyo. evidencia de tu método

Hubo preguntas sobre si, después de 5 años, por qué todavía eras junior. Para mí, la medida clave de si una persona es menor no es la experiencia de muchos años, sino la cantidad de alimentos que requieren. Espero que un desarrollador de nivel medio sea relativamente autosuficiente, un consumidor reflexivo de fuentes de conocimiento que pueda actuar sobre él y extenderlo a su situación. También deben estar en la etapa en la que pueden comenzar a enseñar a los jóvenes porque tienen una comprensión firme de su tema para que puedan explicar las cosas con claridad. La otra competencia básica es la confianza: si has hecho el trabajo, has leído las cosas y has producido algo decente, no tengas miedo de defenderlo en un tribunal de debate, ya que un junior requiere validación, un desarrollador solicita el consenso.

Dejando de lado los modales en el lugar de trabajo, dejando de lado la realidad de un rol de mentor que tienen los desarrolladores senior, dejando de lado su propio deseo de explorar, dejando de lado el comportamiento insultante y dejando de lado los fetiches para libros ...

Los propósitos de una revisión del código en un equipo son 1) validar el código y 2) garantizar que la persona que escribe el código entienda el significado detrás de la mejora del código. No es el lugar para decir "cambia esto porque Martin Fowler lo dijo en el libro de GoF". Sin embargo, es el lugar para decir "cambiar esto porque [breve explicación]; hay más detalles sobre esto en el libro de GoF".

Si su desarrollador senior no está, al menos simple y sutilmente, proporcionando una explicación para un cambio e insistiendo en usar la vergüenza de "debido a [libro]", está siendo un poco inteligente y un imbécil. ¿Cómo lo afrontas? Mencione verbalmente en una reunión del equipo y solicite a sus compañeros de equipo que proporcionen una o dos declaraciones que expliquen brevemente la ventaja o la necesidad del cambio, junto con la referencia útil del libro. Asegúrese de darle las gracias por la referencia del libro.

Enfréntalo, tu objetivo es apreciar la sugerencia de cambio y no ser desmotivado para tu tarea o tu trabajo. Dile eso. "Apreciaría más la sugerencia de cambio si pudiera describir brevemente la ventaja o la necesidad del cambio cuando revise mi código; tal y como lo veo, las referencias de sus libros solo son un poco desmotivadoras".

Si continúa negándose a proporcionar una explicación simple con las referencias de su libro, si puede proporcionar otro libro o recurso de notoriedad igual o mayor en la industria con una opinión diferente y que coincida con su escenario, es posible que pueda agregar su propia referencia de libro en su comentario de revisión en consideración de conservar el código original. Haga esto suficientes veces, él podría retroceder. Tenga mucho cuidado de que el argumento contrario sea correcto y significativamente más importante; está bien dejar que un desarrollador senior se equivoque y aún así seguir su camino, esto es algo que aprendí y tengo que seguir aprendiendo.

Yo diría que aprender programación de libros solo es imposible, pero los buenos te proporcionarán un gran impulso. Es como el karate: no obtendrás el cinturón negro solo leyendo sobre él;) Creo que en este caso particular, el Sr. Infesto se refería a "Java efectiva" por Joshua Bloch. Es realmente un gran libro sobre el desarrollo de Java y definitivamente debería leerlo si aún no lo ha hecho.