¿Es una buena idea el consejo de un programador sénior sobre usar siempre libros? [cerrado]

Soy un desarrollador junior y solo llevo 5 años en la industria. En mi compañía actual hay un senior, llamémoslo Infestus. De vez en cuando me dan la oportunidad de brillar y hacer algo completamente nuevo desde cero.

Uno de los ejemplos más recientes fue que tuve que hacer un singleton en la aplicación multiproceso. He decidido usar este método. Tan pronto como Infestus lo vio, rápidamente procedió a llamarme estúpido y me dijo que usara este enfoque . Al preguntarle por qué lo rechazó, ya que esto es mejor y así es como este y este libro sobre Java dice que es mejor.

Y es un patrón común: cada vez que tengo la oportunidad de hacer algo nuevo, Infestus me derriba rápidamente y la única razón por la cual su método es mejor es porque esos libros fueron escritos por programadores famosos. Él siempre está tratando de darme libros para leer para que yo pueda "aprender" qué formas de programar.

Solo he estado programando por dinero durante 5 años, pero ¿es siempre una buena idea seguir ciegamente el libro sobre las mejores formas de resolver un problema, o debería intentar experimentar de vez en cuando? El constante aluvión de quejas del Infestus está empezando a hacer que nunca pruebe nada nuevo y siga ejemplos en los libros.

EDITAR : estoy completamente perdido. Sí, sé que seguir algo a ciegas es una mala idea. Pero este programador divino Infestus, que parece saber mucho, me dice que la única forma de programar correctamente es leyendo libros y siguiendo todo hasta una T. Todas las reglas que impone son las que están escritas en los libros, así que me pregunto si los libros son la única forma correcta.

EDIT2 : Infestus no es mi jefe. Él es solo uno de los desarrolladores senior a cargo de revisar el código. Y la mayoría de sus comentarios después de las revisiones consisten en nombres de libros donde tal o cual método está mal.

Te encontrarás con programadores como este toda tu carrera. No hay nada de malo en experimentar y aprender solo. Claro que los libros son geniales. Muchas veces los ejemplos funcionan en un entorno limpio, pero si usted es desarrollador de otra empresa, no existe un entorno limpio (sin interferencia de otros).

Siempre es bueno saber cómo hacer las cosas de la manera "correcta", pero las opiniones cambian año tras año. Entonces aprende lo que puedas. Toma lo que puedas del desarrollador senior, combínalo con tu conocimiento de que aprendes por tu cuenta. Eventualmente, será un desarrollador senior y tomará de estas experiencias y enseñará a los desarrolladores junior.

Simplemente no seas idiota al respecto.

¿Realmente te llamó estúpido, o simplemente menospreció el código? Llamar a cualquier cosa estúpida no tiene tacto, pero eso no invalida la sugerencia. Creo que Infestus ha hecho una sugerencia valiosa, y en el futuro debe considerar seriamente sus sugerencias. Parece leer 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 se garantiza que funcione.

Él siempre está tratando de darme libros para leer para que yo pueda "aprender" qué formas de programar.

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

Y sí, leer te convertirá en un programador mucho mejor. Todos los expertos que he conocido leen extensamente. Si no está leyendo mucho, entonces es mediocre en el mejor de los casos, y en otros cinco años puede descubrir que ya no es comercializable.

Leer un libro no debe ser ciego: el autor debe tratar de convencerte de los méritos de su enfoque cuando lo presente. Es razonable que su superior le señale un libro que explique su enfoque preferido, en lugar de pedirle que 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 lo ha hecho.

Entonces, lea el libro, vea lo que dice el autor del libro, y si le confunde, o si desea confirmar su comprensión, o no está de acuerdo, hable con su superior sobre eso, pero ahora estará capaz de tener una discusión más productiva.

Hay tres elementos clave para cualquier relación saludable. Comunicación, honestidad y confianza. Eso cuenta para todas las relaciones, incluso las relaciones de trabajo. Debería hablar con su supervisor sobre estas inquietudes.

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

Creo que también debes tratar a esta persona con más respeto. En su cabeza, lo llama nombres despectivos y critica su enfoque de lo que considera "aprendizaje". Cuidado con eso. Por otro lado, dijiste que te llamó estúpido. Eso no es genial, y deberías decirle que no es genial llamar a alguien estúpido.

Las ideas pueden ser estúpidas. Todos cometemos errores y extrañamos cosas, incluso los hombres 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? ¿No será mejor el diseño B?"

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é escribiendo nada desde cero, siempre hay espacio para brillar al hacer que su código sea el mejor código que pueda.

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 eso hace que el código sea realmente valioso. Una de las formas en que aprendemos a escribir un código excelente es leer muchos códigos buenos. Muy a menudo encuentras muy buen código en los libros. Por lo tanto, leer uno o dos buenos libros de programación probablemente te hará un mejor programador.

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

Este ingeniero Infestus hace un trabajo muy pobre al educar 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 desglosarlo y presentar los conceptos para que los jóvenes puedan aprender de su experiencia.

Le animo a que hable con desarrolladores expertos en su empresa, les haga 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 Google, es imprescindible) debería darte una mejor comprensión.

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

• El hecho de que el tipo sea un imbécil, llamándote y simplemente porque puede (es mayor, no lo eres, si alguno de ustedes se queja del otro, obtendrá el beneficio de la duda) es simplemente comportamiento de matón, y simplemente malo.

Intenta no rebajarte a su nivel con esto. No trates de intimidarlo o "decirle" al jefe ni nada. 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 tal), debe hacer algo al respecto.

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

Muchas veces he tenido a alguien que corrigió lo que inicialmente pensé que era "mi código perfecto" y me molestó que el tipo me dijera qué hacer para luego darme cuenta de que tenía razón todo el tiempo, mi versión era mala, la suya era bien, y gracias a Dios que vio eso! :) Así que he aprendido a atenuar mis impulsos iniciales de "¡oye, no me digas qué hacer, error!" y, en cambio, cada vez que alguien me corrige, primero reviso mi código de manera objetiva, luego compruebo el suyo y me aseguro de que no esté realmente en lo cierto y que soy yo quien comete el error. Si fue mi culpa, le agradezco la ayuda y me aseguro de entender realmente cómo funciona su solución (en lugar de simplemente copiarla / pegarla).

Y oye, a veces encuentro que la corrección ofrecida fue, de hecho, peor de lo que hice inicialmente, en ese momento trato de hablar todo esto con el otro tipo. Honestamente, he notado 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 cometiste un error, pero al mismo tiempo, no temes decir que eres el indicado. quién tiene razón cuando cree que es así, dado que puede probar de inmediato que basa su 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 chico sobre lo que propone, y lo que tú 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 descubres que su propuesta es mejor que la tuya, díselo, expresa tu agradecimiento por la ayuda. Esto puede reconstruir algunos puentes quemados.

Experimente por su cuenta y aprenda todo lo que pueda. Después de leer suficientes libros, descubrirá que hay varios libros sobre temas particulares y que pueden contradecirse entre sí. Pruebe el que le parezca mejor y pruebe ambos si tiene tiempo o desea comparar / contrastar.

Tratar con su jefe es un tema y enfoque completamente diferente. Si quisiera que alguien hiciera algo de la manera exacta en un libro, se lo diría. Solo soy yo porque no me asocio con los lectores mentales. Su jefe lo convierte en un hábito, solo pregunte 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 o no funcionar, pero tú eres quien tiene que vivir con eso y sufrir la negatividad. Vas a mejorar, pero eso generalmente viene de escribir más código sobre cosas nuevas, aprender de los éxitos y fracasos.

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

Cuando intentas comprender las cosas en un libro, generalmente es apropiado 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 pasar las cosas como esta, pero seguir el libro exactamente al principio te dará algo con lo que experimentar, mientras tratas de entender tus preguntas. Las probabilidades son nuevamente buenas de que encontrará formas en las que no está de acuerdo con lo que está en el libro, pero comprenderá los problemas que el libro estaba tratando de abordar, de modo que cuando llegue el momento de escribir su propio código, pueda abordarlos a su manera (o tal vez a su manera, al menos en parte) en lugar de dejar esos problemas para morderlo más tarde.

Otra cosa que no es inherentemente específica de Java, pero que es especialmente común en esa comunidad. Creo que puedo adivinar de qué libros estás hablando, y forman una parte importante del léxico de la comunidad 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 blog es muy útil en la programación. Hay algunos libros que todos los desarrolladores deberían 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 otras cosas que también debemos hacer. Puedes encontrar más detalles aquí .

Debes preguntarle qué está mal en particular con tu método. Si no puede responder con claridad, puede estar bastante seguro de que es solo un tipo común al que le gusta sentirse superior.

Lo que pasa con los libros es que, en su mayoría, pasan por revisiones, que tienen una mejor oportunidad de detectar malas prácticas y conceptos erróneos. Además, los "grandes nombres" son personas experimentadas 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 manera de crecer como profesional, por supuesto, cuando lo confirma la práctica. Entonces, es bueno que leas esos libros (incluso los recomendados por Infestus). Sin embargo, los libros deben principalmente ampliar su comprensión sobre el tema, ya que casi siempre habrá otras formas de resolver el mismo problema.

Sobre su enfoque de "ir por mí mismo", el punto es: ¿puede mantener 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 los demás tienen a su favor, al menos, los casos de uso. Luego, sea creativo y reflexivo, pero lo más importante, sea efectivo.

Si lo fuera, leería esos libros. Eso lo ayudará al brindarle más argumentos y, al mismo tiempo, puede descubrir que Infestus, tal vez, está tomando esos libros erróneamente como argumentos, y aún no fue descubierto porque nadie conoce el contenido de esos libros. O puede encontrar que él realmente k

Mi experiencia es que cuando se trata de programar el tema, la calidad y la presentación de la información con explicaciones adecuadas en los libros es mucho mejor que cuando se busca la misma información del 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.

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

Investigaría los méritos de cada enfoque y llegaría a su propio juicio. 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 pedir una segunda opinión o simplemente aceptar el enfoque de Infestus, dependiendo de qué tan fuerte se sienta al respecto.

En el caso de los singletons, un argumento que podría hacer contra el 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, se podría argumentar que, en aras de la coherencia, se debe evitar incluso cuando no se necesita una extendscláusula.

Algunos otros argumentos que podrían hacerse contra el 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 mucho en los libros como fuente de conocimiento: estos son excelentes fundamentos y creo que Infestus tiene razón en que debería consumir cantidades significativas de libros en su tiempo libre, ya que realmente aceleran sus habilidades. Sin embargo, los libros no son la única fuente de información que creo que debería estar consumiendo: asista a su grupo de usuarios local, reciba los boletines de tecnología relevantes en su bandeja de entrada, lea blogs.

Sin embargo, no estoy de acuerdo con la afirmación de que, dado que está escrito de cierta manera en un libro, es la forma en que debe hacerse. Sí, los libros brindan excelentes consejos, y están escritos por expertos y revisados ​​por expertos, pero después de haber estado involucrado en un libro comparativamente simple, puedo decirle que generalmente toma al menos dos años comenzar a terminar, escribir, editar y lanzar un libro. . El ritmo de cambio en la tecnología es rápido y el consejo de hace dos años ya no es el correcto para hoy. Los principios genéricos suelen resistir el paso del tiempo, pero la optimización de una actividad específica puede invalidarse con un nuevo bit de hardware o una nueva versión de software.

La sugerencia de pedirle a Infestus que haga sugerencias contigo es excelente: vete, lee todo y regresa con un montón de preguntas reflexivas que ya has intentado responder / resolver por ti mismo junto con tu evidencia de apoyo para tu método.

Hubo preguntas sobre si después de 5 años por qué aún eras un junior. Para mí, la medida clave de si alguien es un joven no es años de experiencia, sino cuánto requieren alimentación con cuchara. 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 deberían estar en la etapa en la que puedan comenzar a enseñar a los jóvenes porque tienen una comprensión firme de su tema para poder explicar las cosas con claridad. La otra competencia central es la confianza: si ha hecho el trabajo, leído y producido algo decente, no tenga miedo de defenderlo en un tribunal de debate, ya que un junior requiere validación, un desarrollador solicita 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 los libros ...

Los propósitos de una revisión de código en un equipo son 1) validar el código y 2) asegurar 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 "cambiar 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 que discuten esto en el libro GoF".

Si su desarrollador principal no está, al menos simple y sutilmente, brindando una explicación para un cambio e insistiendo en usar la palabrería de "debido a [libro]", está siendo un poco astuto y un imbécil. ¿Cómo lo afrontas? Mencione en una reunión de equipo, verbalmente, 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 útil referencia del libro. Asegúrese de agradecerle por la referencia del libro.

Acéptelo, su objetivo es apreciar la sugerencia de cambio y no desmotivarse por su tarea o su trabajo. Dile eso. "Le agradecería más la sugerencia de cambio si pudiera describir brevemente la ventaja o la necesidad del cambio cuando revisa mi código; ya que creo que solo las referencias de su libro 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 igual o mayor notoriedad en la industria con una opinión diferente y se ajusta a su escenario, podría agregar su propio libro referencia en su comentario de revisión en consideración de retener el código original. Haga esto suficientes veces, podría retroceder. Tenga mucho cuidado de que el contraargumento sea correcto y significativamente más importante; está bien dejar que un desarrollador sénior se equivoque y aún así se salga con la suya, esto es algo que he aprendido y tengo que seguir aprendiendo.

Diría que aprender la programación de los libros solo es imposible, pero los buenos le proporcionarán un gran impulso. Es como el karate: no obtendrás cinturón negro solo leyendo sobre eso;) Creo que en este caso particular, el Sr. Infestus se refería a "Java efectivo" de Joshua Bloch. Es realmente un gran libro sobre el desarrollo de Java y definitivamente deberías leerlo si aún no lo has hecho.