Antecedentes: soy un recién graduado y desarrollador de software. La empresa en la que trabajo tiene un equipo relativamente pequeño con 8 miembros. Soy el más nuevo en el equipo y he estado aquí 10 meses.
Me llevo bien con uno de los desarrolladores senior cada vez que hablo de algo que no sea el código específico. Necesito acudir a él en busca de soporte con frecuencia ya que conoce bastante bien .NET. Cuando estamos hablando de las diferentes formas de resolver un problema técnico, hay un conflicto y una tensión notables. Esto se debe a que ambos tenemos diferentes formas de hacer las cosas y un proceso de pensamiento fundamental diferente. Solo un ejemplo (de muchos) en el que pensamos de manera diferente es que me capacitaron con más enfoque en el diseño orientado a objetos, usando la herencia, mientras que él ve los datos por la forma en que encajarían en una tabla e incluso pregunta por qué usaría la herencia en lugar de solo un referencia simple a un objeto principal.
Cada vez que trato de decir cortésmente algo como "Entiendo tu punto, pero sigo pensando que este es el mejor enfoque porque xy z", él no ve mi punto de vista e incluso se vuelve un poco más insistente que el método. él está recomendando es mejor y esto provoca un aumento de la tensión. Entiendo de dónde viene y puedo ver los beneficios de hacerlo a su manera, sin embargo, veo más beneficios al resolver el problema a mi manera.
Por lo tanto, mi pregunta es cómo trato con él de manera que mis relaciones con él mejoren o si es el mejor enfoque para simplemente imponer un espacio entre él y yo cuando se trata de conversaciones técnicas y, como resultado, inhibir que se convierta en un mentor valioso?
NOTA: ¿Cómo puedo reducir las brechas de comunicación con un colega que tiene un estilo de trabajo diferente? <-- Una pregunta similar pero más sobre la comunicación, que no es un problema.
EDITAR: Esta persona no es mi superior, simplemente es un colega con más experiencia, el jefe mío (tengo 2...) que está a cargo de mi trabajo, trabaja y piensa igual que yo cuando se trata de resolver problemas. . Esto significa que implementar una solución en la forma en que este otro desarrollador sugiere que tendría que tener la misma discusión con mi jefe, pero yo argumentaría a favor de una implementación en la que realmente no creo. Mi jefe no sabe mucho de .NET. bueno, sin embargo, él no puede ayudar con las preguntas técnicas/de implementación que tengo.
EDIT 2: cambié la pregunta y eliminé muchos de los detalles técnicos según la sugerencia en los comentarios.
Su determinación de utilizar programación orientada a objetos donde puede que no importe, y su determinación de utilizar una base de datos real donde puede que no importe, son las dos caras de la misma moneda. Te llevarás mejor con él si recuerdas que esto es un oficio, no una ciencia, y dos desarrolladores a menudo abordarán el mismo problema desde diferentes direcciones sin que ninguno se equivoque. Elegir la mejor solución depende de cómo se va a usar y de cuánto esfuerzo requerirá de una forma u otra... y esto último varía de un individuo a otro. Y a veces la respuesta correcta no es la mejor técnicamente O la que usted prefiere, sino la que será más fácil de mantener.
En lugar de quedar atrapado en quién tiene razón, concéntrese en aprender por qué se hace una sugerencia y cuáles son las ventajas y desventajas.
Y si es posible, no peleen por cosas que no importan. Quién tiene razón importa menos que hacer el trabajo.
Veo tu punto, pero sigo pensando que este es el mejor enfoque.
"Mejor" en esta oración es una medida puramente ficticia, al menos para él. Ustedes (ambos, como equipo) nunca han establecido los estándares de "bueno", por lo que asumir que algo es "mejor" no tiene una base común.
Le han enseñado que OOP es "mejor". Pero si fue una buena educación, también te han enseñado por qué . Así que haz un caso. ¿Qué ofrecería su solución que la suya no ofrecería? ¿Qué se podría hacer con su software, que no se podría hacer con el suyo?
Si le presenta un caso de negocios probable que su solución manejaría en menos tiempo o por menos dinero, entonces verá que, de hecho, es "mejor". Si no puede encontrar un ejemplo de por qué su enfoque es "mejor", tal vez no lo sea. La programación orientada a objetos y la herencia son herramientas para resolver problemas. ¿Quizás este no es el problema correcto para el conjunto de herramientas que tiene? Bien podría ser que necesite un segundo (y tercero y cuarto...) conjunto de herramientas.
Me gustaría sugerirle que comience la conversación con él con una mentalidad positiva; por ejemplo, podría aprender grandes cosas de este desarrollador senior, etc. ¿Por qué no quiero que sepa por qué su método es mejor que el suyo haciéndole varias preguntas? sobre su método.
Creo que sería bueno recordar aquí algunas "reglas de Dale Carnegie" relevantes:
1) No critiques, condenes o te quejes (sin intentar un enfoque correcto, creo que el anterior que mencioné es uno de ellos);
2) Despierta en la otra persona un deseo ansioso (hazle creer que también está contribuyendo a tu proyecto/solución).
Si su enfoque OOP es mejor, presente un par de casos de uso en su situación donde el enfoque OOP funciona mejor que el enfoque de base de datos/tabla (que parece una delegación). Si los casos de uso son lo suficientemente importantes, puede ayudar a su mentor a llegar a su conclusión.
Dado que él es el mentor, también podría ser conveniente que pruebes su enfoque de principio a fin. Puedes aprender que su forma es mejor, o que tu forma es mejor, o que ambas formas son solo 2 formas diferentes de resolver el mismo problema. Pero su conocimiento estará basado en la experiencia. Y si aprende en ambos sentidos, la próxima vez que le pida ayuda, podrá traducir su enfoque preferido a su enfoque preferido sin dificultad.
Tuve una situación en la que escribí una parte del código utilizando la biblioteca Ruby Enumerable con mapas en cascada/reducir bloques para realizar un trabajo de procesamiento de datos doloroso en un conjunto de datos. Mi jefe no apreció los beneficios de usar cascading map/reduce (un estilo de programación más funcional), y se quejó de que el código era difícil de leer. Le respondí diciendo que si pudiera escribir el código de manera más concisa usando un estilo de codificación más imperativo, entonces cambiaría. (Solo lo dije porque sabía que los intentos anteriores de problemas similares tenían el triple del volumen de código y era frágil). Mi enfoque se ha mantenido hasta ahora porque funciona y porque aún no ha producido código para resolver el mismo problema en el estilo de programación imperativa. En este caso, probé los dos métodos diferentes, por lo que pude articular las diferencias y escribir el código.
Myles
Brandín
Another one of the conflicts was where he was suggesting creating a database to store data on disk for an ad-hoc solution that would only be used by me<-- No entiendo este conflicto. Si la solución solo debe ser utilizada por usted, ¿por qué importa la opinión de su superior? OTOH, si fuera para que otros usaran un producto, entonces la entrada de su superior no se puede ignorar, incluso si es "incorrecta".adrian773
adrian773
Brandín
You: I was thinking of using X for this. What do you think? Him: Hmm... I would definitely use Y for this.. Esto no es un "conflicto" a menos que intente discutir el punto (sin motivo alguno). Son solo dos opiniones diferentes. Si quieres hacer X, simplemente hazlo. Ni siquiera tienes que mencionárselo.adrian773
Me: I was thinking of using X for this. Have you already done X and if so, what library did you use? Him: I haven't done X, what is this for? Me: Its for Y. Him: Oh, Z would be a better solution to Y. Me: Really? That wouldn't have A or B and X has C and D. Wouldn't that make X a much better solution? Him: Nah, A and B are negligible.podría continuar desde aquí, pero sería más o menos lo mismo hasta que esté tenso y me resulte difícil simplemente ignorarlo y alejarme sin ser grosero.Brandín