¿Cómo reaccionarías si alguien te dijera que tu código es un desastre?

Soy un buen programador, o eso pensaba antes. Siempre me encanta programar. Y quiero aprender muchas cosas sobre programación para hacerme un mejor programador. Estudié programación durante 1 año y ahora estoy trabajando como programador durante casi 2 años. En resumen, tengo casi 3 años de experiencia en programación.

Nuestro equipo está compuesto por 5 programadores, y 4 de nosotros somos nuevos, 1 tiene más de 3 años de experiencia. Hemos estado trabajando para un programa durante casi un año y nadie ha revisado mi código y me dieron una página para trabajar. Nunca tuvimos una revisión del código y todos somos nuevos, por lo que no sabemos qué aspecto tiene un código limpio. ¿Creo que los programadores aprenden solos?

Implementamos nuestro programa en el programa sin pruebas exhaustivas. Ahora es estricto y necesitamos una aprobación y revisión del código primero antes de hacer cambios con el código. Por primera vez, alguien revisa mi código y dice que es un desastre.

Me siento muy triste y dolido. Realmente me encanta programar y hacer que digan algo así realmente me duele. Tengo muchas ganas de mejorar a mí mismo. Pero parece que no soy un programador genio como en las películas. ¿Me puede dar consejos sobre cómo ser mejor? ¿Alguna vez has experimentado algo que critica tu código y te sientes realmente herido? ¿Qué haces en esos eventos?

La verdad es que probablemente en 2 años, cuando vea su código actual, estará de acuerdo en que fue un desastre. La programación de aprendizaje es un proceso interminable y siempre habrá alguien que sea mejor que tú.

Entonces, si la persona que dijo que su código es un desastre no solo es malo y no es otro caso de enfermedad "Lo haría mejor" común entre los programadores, debe preguntarle qué es exactamente lo que está mal con su código y cómo puede mejoralo.

No te enorgullezcas de lo bien que codificas. Enorgullecerse de lo bien que aprende. Luego, saber que su código necesita mejoras le brinda la oportunidad de demostrar lo bueno que es en el aprendizaje, en lugar de criticar lo malo que es un programador.

Lea http://www.perlmonks.org/?node_id=270083 si no tiene idea de lo que estoy hablando.

Después de más de 20 años, sé que parte de mi propio código sigue siendo un desastre. Todo se reduce a tomar una decisión entre escribir el mejor código posible o escribir lo que se requiere para hacer el trabajo. Hacer el trabajo dentro de un plazo acordado supera la búsqueda interminable de perfección técnica cualquier día.

El truco es aprender a aceptarlo. Aprende a aceptar que podrías hacerlo mejor. Aprende a vivir con los defectos. Aprenda a aceptar que no lo va a lograr perfecto esta vez, y probablemente la próxima vez también, y que es una elección deliberada porque la alternativa no es la entrega. Y eso es peor.

Descargo de responsabilidad: nada de esto debe leerse como "el código incorrecto está bien".

El código de todos es un desastre y no hay buenos programadores.

Existen:

• programadores que envían rápido,
• programadores que siempre envían código semánticamente correcto,
• programadores que siempre encuentran la solución óptima y el algoritmo más rápido,
• programadores cuyo código es fácil a la vista.

Apenas, si acaso, terminan siendo la misma persona.

Y hay programadores de butthurt que necesitan crecer y:

• pregunta qué pasa
• no tome ningún comentario personal, como una medida de su valor como ser humano;
• darse cuenta de que hay pautas de sintaxis en los equipos, y deben seguirse, y son arbitrarias, por lo que no deben ser discutidas ad nauseam , ya que no hay una solución óptima, ni la última palabra;
• mejorar al comentar su código;
• mejorar al comentar su código; (sic)
• encuentra soluciones más fáciles de depurar, menos inteligentes, para tareas simples y mundanas;
• tomar una clase en SQL
  (enviaría a la mitad de la población de este mundo a tomar una clase en SQL, solo para estar seguro)

No es arte, es una artesanía.
Damos por sentado que eres inteligente: estás programando computadoras, maldita sea.
Aún así AMD64y x86no se ven obligados por el poder de su prosa. Mantén las cosas simples.

Bueno, una persona que dice que su código es un desastre no es constructivo, incluso si tiene razón. ¿Te dieron razones por las que es un desastre? Como, los métodos son demasiado largos, las responsabilidades se mezclan entre sí, demasiadas ramificaciones, etc. Honestamente, cualquier código que escribí hace un año, diría que es una mierda porque he aprendido muchísimo desde entonces. Así que no te sientas mal por eso. Estaría más preocupado si todavía te gustara leer el código que escribiste hace mucho tiempo.

Cuanto más limpio sea su código base, menos tiempo pasará luchando contra el código base para resolver un problema dado. Un año es un gran punto para estar porque puede sentir el dolor de cualquier decisión de diseño que haya tomado anteriormente en el proyecto.

En mi proyecto actual, hemos refactorizado varias veces a medida que nos sentimos más cómodos con nuestra pila de tecnología. Esto debe fomentarse y debe tomar nota de las tareas que tardan más de lo debido debido a la base de código actual.

¿Has revisado algunas de las partes más antiguas del código que escribiste? Probablemente pueda ver cosas que desearía hacer de manera diferente ahora o refactorizar.

Además, cuando mencionas la falta de pruebas, esto siempre es algo a tener en cuenta. En nuestro proyecto no teníamos pruebas automatizadas y, como resultado, mucho código altamente acoplado. Incluso si no escribe pruebas de unidad / integración / lo que sea con regularidad, hacerlo por un tiempo le hará tener el hábito de hacer que su código sea más modular (y, en consecuencia, menos desorden).

Me siento muy triste y dolido. Realmente me encanta programar y hacer que digan algo así realmente me duele. Tengo muchas ganas de mejorar a mí mismo.

Eso es bueno. Eso es mucho mejor que tener una reacción como "mi crítico no tiene idea de lo que está hablando", "mi crítico es demasiado exigente" o simplemente "mi crítico no me quiere" e ignorarlos. Esta actitud es buena.

Pero parece que no soy un programador genio como en las películas.

No estoy seguro de qué tipo de películas ves, pero el 90% de los programadores en las películas son tan falsas que tengo lágrimas al final de la secuencia.

¿Me puede dar consejos sobre cómo ser mejor?

Lee y practica. Mira libros como Code Complete o The Pragmatic Programmer . Busque en Amazon libros similares.

¿Alguna vez has experimentado algo que critica tu código y te sientes realmente herido? ¿Qué haces en esos eventos?

¿Por qué te sientes herido? Me siento decepcionado de mí mismo por ser tan imbécil en primer lugar. Utilizo esa motivación para limpiar mi código y asegurarme de no volver a cometer el mismo error . La última cosa que quiero hacer no aprender de ella. Te han humillado una vez, no dejes que vuelva a ocurrir por la misma razón.

Ningún programador nace perfecto, ni siquiera cercano. Cuanto más código escriba, más críticas obtendrá y las revisiones que proporcione , lo convertirán en un mejor programador.

Una de las mejores cosas para mí sobre ser desarrollador es que cada día es un proceso de aprendizaje. Siempre habrá alguien por ahí que no sabe algo que tú sabes, y siempre habrá alguien que sepa algo que tú no. Ciertamente, no me consideraría estar en otro lugar que no sea un nivel de entrada / junior, pero agradezco cualquier crítica que pueda recibir siempre que esté justificada y sea respetada.

Una analogía que podría ser apropiada se relaciona con un período de tiempo en el que fui tutor de escritura en una universidad, así como cuando participé en cursos de escritura creativa. Escribir código, para todos los efectos, es muy parecido a escribir un poema, ensayo, cuento o novela. Cada individuo tiene su propia manera de hacerlo, pero al mismo tiempo, incluso los mejores escritores (o, en este caso, los desarrolladores) cometen errores o dejan que las cosas se escapen. A menudo podemos dejar de notar estas cosas porque nos acostumbramos tanto a nuestra propia voz (o de nuevo, en este caso, al estilo de código).

Al igual que en cualquier campo, hay quienes se consideran expertos. Si esas personas no existieran, no tendríamos a nadie de quien aprender. Asumiendo que este individuo en cuestión es verdaderamente un experto, escucharía lo que dice y le preguntaría qué sugeriría que haga para mejorar su código. Sin embargo, nunca olvide que él no es el único que puede brindar su ayuda; Tenemos la suerte de que exista una gran cantidad de recursos como SE / SO.

El desorden es bastante subjetivo. Lo mejor que puede hacer es preguntarle a esa persona (o al informe de revisión): ¿por qué es desordenado? (desde su punto de vista, eso es)

Seguramente te responderán y podrás:

• Argumento en contra (si tiene una buena razón para hacerlo, por supuesto)
• Siéntete muy feliz, porque acabas de aprender algo nuevo y tu futuro código será más impresionante, ya que ahora sabes cómo hacerlo menos complicado gracias a sus consejos.

El hecho de que estés preocupado es una buena señal. Comencemos con eso. Menciona que le encanta programar, pero ¿le encanta ser programador profesional? Hay una gran diferencia entre un entusiasta y un profesional. Como profesional, estará bajo constante escrutinio por su producto de trabajo.

Our team is composed of 5 programmers, and 4 of us are new

El hecho de que haya trabajado dos años sin confrontación me dice que está trabajando en un trabajo muy relajado, lo que no es tan bueno si realmente quiere avanzar como profesional. Eso sí, algunos de los mejores programadores del mundo trabajan para la fundación Linux y pueden estar seguros de que no recibirán un trato amable cuando cometan errores marginales ... mucho menos 'código desordenado'.

Para una revisión rápida de algunas pautas de codificación bastante estándar, los Estándares de Colaboradores de la Comunidad Linux deberían darle una idea del nivel de responsabilidad al que aspirar para su producto. Consulte CÓMO OBTENER EL CÓDIGO A LA DERECHA.

Para promover esa afirmación, debe aprender a aceptar la revisión, ya que la mayoría del buen software se revisa a fondo. Esto es compatible con la Ley de Linus que establece ...

"Si hay suficientes revisores, todos los problemas son fáciles de resolver".

Personalmente, he visto a desarrolladores altamente calificados, responsables y confiables obtener el hacha para algo tan simple como olvidar dejar comentarios ... así que si alguien te dice que tus códigos son un desastre, entonces probablemente sea ... Supéralo ... Refactorización Es parte del concierto.

I feel so sad and hurt. 

Vaya a hacer una solicitud de tristeza para evaluar qué tan molesto se pone cuando no se aplica.

Respondiste tu problema ... ¡No pruebas!

Después de ver un comentario que hiciste diciendo que eres un desarrollador de Java, casi me enojo. Entonces, si entiendo correctamente, usted dice que usted y su equipo de desarrollo están trabajando en una tienda Java y no tienen un marco de prueba para sus aplicaciones ...

Ahí radica el roce

"Implementamos nuestro programa en el programa sin pruebas exhaustivas".

Cribbing UML Creator Grady Booch ...

El ingeniero de software aficionado siempre está buscando magia, algún método o herramienta sensacional cuya aplicación promete hacer que el desarrollo de software sea trivial. Es la marca del ingeniero de software profesional saber que no existe tal panacea.

Alistair Cockburn proporciona una gran cantidad de información en su sitio sobre el uso de metodologías ágiles para aumentar el rendimiento y la calidad para usted y su equipo.

Uno de los aspectos más importantes de la programación {y la vida} ​​es conocer sus fortalezas y debilidades. Si no trabajas en tus debilidades, no tendrás un conjunto de habilidades completo.

Outro ... Lo estás haciendo bien. Solo no te quejes. Avanza en el desarrollo de tu oficio y deja que tu pasión por la programación te mantenga en marcha. Buena suerte :-)

No permita que sus emociones se interpongan en el camino de mejorar su código. El objetivo de una revisión de código es encontrar problemas, por lo que no debería sorprenderse demasiado si hay algunos. Dicho esto, tampoco se supone que sean una sesión de ataque de codificadores.

Tampoco deberían decir simplemente 'Ewwww' y dejarlo así. Siempre hay una razón por la cual algo está mal en la programación. Por ejemplo, está mal dejar un montón de código comentado por todas partes, pero está mal porque satura el código y hace que sea más difícil de leer, no porque alguien lo haya dicho en un libro.

Tu código no eres tú. Recuerda eso.

Voy a ser el idiota aquí y asesorar sobre la base de ... bueno, lo obvio. Obviamente, su código ES un desastre o la pregunta que haría es "¿POR QUÉ alguien dice que mi código es un desastre?" Pero no estás desafiando la suposición. Simplemente estás actuando herido y, francamente, es posible que estés llorando, pero no hay sensación cuando se trata de justificar la programación.

Pero realmente, ¿por qué preguntas? Sabes que tu código apesta o harías una pregunta diferente. Si alguien me dijera que mi código web de fondo apestaba, me reiría y diría "está bien, ¿qué tiene de malo?" Si me dijeran que mi JavaScript apestaba, les daría el equivalente del programador social de un labio gordo y nunca pediría consejos sobre cómo reaccionar porque las pequeñas perras están claramente equivocadas.

Poseer en lo que eres bueno. Y realmente me refiero a asumir la responsabilidad por ello. porque solo hace falta una tontería para que algún imbécil te adivine. No pidas permiso para ser bueno. Solo conoce tus cosas. El fin.

Recuerda esto: ¡el peor código que verás es el tuyo!

Jeff Atwood de codinghorror.com escribió mucho sobre el tema, es posible que desee comenzar aquí: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Si desea mejorar, comience a leer cosas sobre estilo de codificación, patrones, flujos de trabajo, básicamente todo lo que pueda tener en cuenta. También aprenda más lenguajes de programación, vea cómo hacen las cosas. Si está haciendo POO, lea esto: http://en.wikipedia.org/wiki/Design_Patterns

También hable con otros programadores y empareje la programación o vea el código de otros.

Cometer errores es inevitable, repetirlos sí.

La mayoría de las veces debe decir "Gracias" a la persona que le dijo esto.

Lo más probable es que se preocupen por su profesión, se preocupen por su trabajo, se preocupen por su equipo y se preocupen por usted.

Puede ser difícil aceptar las críticas. No te enojes por eso. Piensa en lo que intentan decirte y no dejes que tus emociones te dominen.

He estado programando durante mucho tiempo (30 años) y mi estilo y código están mejorando todo el tiempo (espero). La única forma en que sé que está mejorando es cuando otras personas me lo dicen o si regreso y reviso mi código.

Intenta mirar el código que escribiste al comienzo de tu carrera. ¿Cómo te parece ahora? ¿Se ve tan bien como pensabas cuando lo escribiste?)

En primer lugar, debe comprender que la programación es un proceso iterativo, al igual que escribir un artículo o un libro. Primero escribes un "borrador" de tu programa, solo para que funcione. En esta etapa, su código será un desastre. Entonces refactorizas para limpiar el código. Luego perfile y vea lo que necesita optimizar para hacerlo más rápido. El truco es refactorizar continuamente, de lo contrario el desorden crecerá. Tienes que limpiar tu código regularmente, al igual que tienes que limpiar tu casa.

Las revisiones de código son absolutamente esenciales. Debe hacer que su código sea visto por al menos otro par de ojos. Cuando pasas innumerables horas mirando tu código, te acostumbras y puedes perder fácilmente un error o un olor a código que tu compañero de trabajo puede notar al instante.

Además, el acto de explicar su código a otra persona es una excelente manera de ver si se ha perdido algo. Esto es como leer un periódico que estás escribiendo en voz alta. Su cerebro procesa información de audio y visual de diferentes maneras, y puede encontrar fallas en su razonamiento cambiando de modalidad. Además, si le explica su código a un compañero de trabajo, y algo no tiene sentido para ella, es una buena indicación de que debe refactorizar su código.

Al hacer una revisión del código, es muy importante que tanto el autor como el revisor verifiquen sus egos en la puerta. El objetivo es mejorar el código. Por lo tanto, el revisor debe ser respetuoso y el autor debe mantener una mente abierta. Recuerde, sus compañeros de trabajo son los que tendrán que mantener su código, por lo que debe ser claro para ellos. Si el revisor no comprende lo que hace una variable, cámbiele el nombre. Si el revisor no puede entender lo que hace un bloque de código, refactorícelo en una función con un nombre descriptivo. Independientemente de lo que pueda pensar, si sus compañeros de trabajo no pueden entender su código, no es bueno.

Hablando de refactorización, absolutamente debe tener un marco de prueba de unidad, porque sin él, no puede refactorizar.

Finalmente, recomiendo leer "Clean Code" de Robert C. Martin. Le dirá por qué su código es un desastre y qué puede hacer para limpiarlo.

¿Me puede dar consejos sobre cómo ser mejor?

La respuesta de Jay que recomienda libros es buena, sin embargo, parece que ya estás en un punto de inflexión en el trabajo.

Pasado:

Nuestro equipo está compuesto por 5 programadores, y 4 de nosotros somos nuevos, 1 tiene más de 3 años de experiencia. Hemos estado trabajando para un programa durante casi un año y nadie ha revisado mi código y me dieron una página para trabajar.

Presente:

Ahora es estricto y necesitamos una aprobación y revisión del código primero antes de hacer cambios con el código.

Parece que su empresa / equipo / departamento está aprendiendo en su conjunto, en términos de gestión de proyectos y equipos, así como de programación. Comenzar a revisar el código es una excelente oportunidad para mejorar en casi todas las áreas si se le presta la atención adecuada.

Use esto como una oportunidad; suponiendo que esté haciendo revisiones por pares (con los otros desarrolladores de su equipo), sugiérales que este proceso es importante y que todos pueden aprender de él.

En la línea de base será una revisión rápida con el resultado "sí, se ve bien". Con un poco más de esfuerzo enfocado, pueden intercambiar ideas entre sí, "sí, eso funciona, pero podrían haberlo abordado de esta manera, lo que habría aclarado su objetivo ...". Tome notas para el futuro, incluso si el código se considera correcto para implementar.

Si esto va a tener éxito, debe contar con su equipo y su gerente, lo que a menudo significa explicarles los beneficios. Para los otros desarrolladores, esta es una oportunidad para aprender. Para su gerente, esta es la oportunidad de mejorar las habilidades del equipo a un bajo costo, por lo tanto, crear salidas a) con más valor ob) más rápido c) con menos costo de mantenimiento (¡generalmente un gran problema!).

Este es un cambio de cultura, que no puedes forzar por ti mismo, ¡pero puedes ayudar a empujar las cosas en la dirección correcta!

No olvide que este tipo de cambio cultural puede ser muy beneficioso para las organizaciones; Los buenos gerentes reconocerán que estás trabajando para mejorar a todo el equipo, algo que vale la pena recompensar.

¿Me puede dar consejos sobre cómo ser mejor? ¿Alguna vez has experimentado algo que critica tu código y te sientes realmente herido? ¿Qué haces en esos eventos?

La respuesta a esto se puede encontrar en las empresas de nueva generación. He estado en compañías como Google y FaceBook y veo que si sigues el proceso Agile / Scrum religiosamente, entonces puedes escribir un mejor código y mejorarlo cada sprint.

How to be better? 

La respuesta es la refactorización continua. Las herramientas de desarrollo modernas como Visual Studio tienen muchas herramientas que lo ayudan en este proceso. Si sigue el proceso de desarrollo del software Scrum, luego, por ejemplo, escribió un código incorrecto en el ciclo 1 de sprint y alguien señaló durante la revisión que es malo, luego, en el sprint 2, tiene la oportunidad de refactorizar el código.

Estos problemas están ocurriendo en primer lugar debido a la falta de un buen proceso. Entonces, la solución es crear un buen proceso de desarrollo de software para su equipo y practicar la refactorización continua.

Les agradecería los comentarios y luego les pediría que explicaran qué lo hace malo y cómo debería mejorarse.

Si está de acuerdo con que la persona que da los comentarios tiene sentido, considere hacer cambios en el futuro. Pero recuerde, solo porque alguien dice que no significa que sea verdad.

¿Puedes dar ejemplos específicos de lo que se ha llamado "un desastre"?

En primer lugar, alguien que dice que su código es un desastre es muy vago y subjetivo. Puede significar cosas diferentes para diferentes personas. Este es el por qué; Hay dos cosas diferentes que deben considerarse.

Estructura

La estructura de su código se rige por el idioma, los estándares de la industria y los estándares de la compañía, por nombrar algunos. Obviamente también hay otros factores.

Estos son los tipos de errores que la pelusa, las herramientas de prueba y productos similares están diseñados para identificar. Están bien definidos y usted o sus herramientas pueden tomar decisiones objetivas en cuanto a su validez / corrección.

Estilo

A pesar de la estructura / reglas estandarizadas para el código, cada desarrollador tiene un cierto estilo en la forma en que escribe y aborda un problema o tarea. Realice el mantenimiento del código en cualquier entorno de equipo y, con el tiempo, podrá adivinar quién escribió el código según el estilo. También desarrollará su propio estilo y cambiará a medida que adquiera experiencia y aprenda su oficio.

Entonces, cada vez que alguien dice que su código es un desastre , debe comprender si está hablando de la estructura o el estilo . Son dos cosas muy diferentes; la estructura es objetiva mientras que el estilo es absolutamente subjetivo.

Dicho esto, cualquier comentario constructivo de otros programadores puede ser muy valioso para usted. Todo depende de ti y de cómo tomas las críticas. Con el tiempo, aprenderá quién es la opinión que debe tomar en serio versus quién tomar con un grano de sal.

A medida que avance en su carrera, verá su propio código y verá cosas que podría hacer de manera diferente, mejor, más limpia y más rápida. Todo es parte del proceso de aprendizaje y ver tus propios errores pasados ​​es una verdadera indicación de que estás perfeccionando y mejorando tu oficio.

No dejes que un poco de crítica te desanime. Tome lo que pueda de él y, si es significativo y valioso, agréguelo a su reserva de conocimiento.

Si bien es importante reconocer cuándo su propio código es un desastre (sentimiento muy típico entre los programadores, especialmente a medida que adquieren más experiencia y su código anterior envejece), es aún más importante escuchar cuando otras personas se lo dicen.

Solo hay muchos problemas que puede reconocer en su propio código, ya que se produjo con limitaciones de su conocimiento actual de programación.

La revisión del código es una oportunidad de aprendizaje esencial porque probablemente lo expone a nuevos conocimientos que no tenía mientras trabajaba en el código (de lo contrario, lo usaría y no habría problemas).

Creo que hay dos partes para procesar comentarios negativos.

1. Determine la naturaleza de los problemas planteados y qué debe aprender de ellos

Cuando reviso o reviso mi código, clasifico la información sobre los problemas de código en aproximadamente estos grupos:

• viola requisitos tecnológicos difíciles
  • simplemente incorrecto (no funciona o cumple con los requisitos)
  • fallará en otras circunstancias (cambio de entorno / configuración)
  • usa una funcionalidad obsoleta y se romperá en un futuro previsible
• viola las mejores prácticas de la industria, falta de cosas como
  • utilizando un enfoque probado para un problema específico
  • actuación
  • compatibilidad al revés
  • facilidad de mantenimiento
  • estilo de codificación
  • documentación
• viola las mejores prácticas en el lugar de trabajo
  • igual que la industria, pero más específico para la empresa / colegas y puede diferir de la industria en detalles
• no está en línea con la experiencia personal
  • se puede mejorar de alguna manera, en opinión de la persona que revisa

Tenga en cuenta que esto va desde cosas muy objetivas ("esto se romperá cuando se implemente en nuestro servidor de producción") hasta cosas muy subjetivas ("No me gusta cómo nombró las variables").

2. Determine qué cambios (si los hay) al código se realizarán como resultado de la revisión

Después de que se procesa la información, se decide si es accionable y si se debe cambiar el código. Esta no es necesariamente su decisión, su opinión puede o no importar dependiendo de las partes involucradas y los detalles de su situación (antigüedad, etc.). Pero los resultados posibles más o menos son:

• abordar el problema en su totalidad
  • arreglar roto
  • formato al estilo de codificación requerido
  • y así
• llegar a un compromiso si el problema debe abordarse total o parcialmente, ya que puede haber
  • sin recursos (como tiempo o presupuesto)
  • no es necesario (solo logrará una mejora insignificante, comprometerá la estabilidad, etc.)
• entender que el problema planteado no es válido
  • la retroalimentación (especialmente de la categoría de opinión subjetiva) puede ser muy dañina y no se debe actuar a ciegas

Has aprendido que es doloroso recibir comentarios negativos y que muy bien puede ser doloroso cada vez en el futuro. Sin embargo, ha aprendido cómo es una importante oportunidad de aprendizaje y cómo el proceso lo ayuda a mejorar profesionalmente y a su lugar de trabajo para lograr una mejor base de código.

Bueno, no te sientas roto. Eventualmente aprenderás de los errores. Una vez que hayas terminado con el problema, puedes hablar con el chico para que sienta que quieres mejorar. Intenta escuchar más y discutir menos.

He pasado por esta situación y puedo entender.

TL; DR

¿Cómo reaccionarías si alguien te dijera que tu código es un desastre?

Mi respuesta directa, "demasiado tiempo no leí (todas las respuestas - disculpas, espero encontrar tiempo para más tarde y editar / modificar esto si es necesario)" respuesta / consejo:

• Buena vieja revisión por pares. Pida a diferentes equipos con diferentes mentalidades colectivas, niveles de experiencia y / o niveles de agresividad que revisen su código.
• Solo para elaborar un poco sobre lo que quiero decir con grupos de pares "diferentes": la diáspora de StackExchange es probablemente el grupo más confiado, profesional y estimado debido a la relativa dificultad para formar parte de él, en comparación con, por ejemplo, Reddit. Reddit tiende a ser muy agresivo en los sub-reddits más populares, pero curiosamente, los subreddits de programación son bastante amigables (por lo que he experimentado).

Un buen, quizás el mejor, ejemplo del tipo agresivo de mentalidad de pandilla gangsta es la multitud de foros XDK, y el peor de los peores trofeos que entrego al CyanogenMod para foros de Android / población del canal IRC.

Eso fue un poco más de lo que pretendía; se suponía que mi punto era: obtener críticas variadas, pero centrarme en obtener críticas honestas de las personas que conocen su oficio y saben qué es la crítica constructiva . Ah, y ser capaz de tomar cualquier forma de crítica sin dejar que te deprima. Regla general: si comienza a escuchar comentarios similares relacionados con algo que puede ser mutuo a los comentarios, haga una introspección más exhaustiva.