¿Qué factores deberían influir en cómo determino cuándo abandonar un pequeño proyecto con un amigo? [cerrado]


30

Últimamente me he encontrado en una situación difícil. He estado trabajando en un juego con un compañero de programación durante casi 8 meses. Ambos comenzamos como recién llegados a la programación alrededor de agosto del año pasado, él es un estudiante de CS de segundo año, soy un técnico de soporte de TI de oficio y soy un programador autodidacta con multitud de libros y suscripciones en línea.

El problema que he estado viendo constantemente es que a medida que escribimos un fragmento de código, a menudo será un poco pirateado, tendrá muchas fallas y, si es un concepto nuevo para uno de nosotros, lleno de soluciones ingenuas. Esto está bien, estamos aprendiendo, espero que ambos códigos sean un poco pirateados juntos en la primera o segunda pasada. El problema se presenta cuando se trata de corregir y refactorizar esos comportamientos pirateados.

Mi compañero se aferrará a su comportamiento recién improvisado, negándose descaradamente a ver cualquier error en el momento en que comience a funcionar. Reclamando casi la perfección de una pieza de estructura que ni siquiera puedo tratar de usar, incluso si tenía comentarios y métodos y campos con el nombre apropiado. No importa cuánto lo intente, simplemente no puedo lograr que vea los defectos evidentemente obvios que evitarán cualquier cambio adicional o expansión del comportamiento sin romperlo por completo y todo lo que está tan estrechamente relacionado podría estar en la misma clase. Las soluciones pirateadas permanecen permanentemente pirateadas, los diseños mal pensados ​​permanecen como estaban cuando se concibieron y probaron por primera vez.

Paso tanto tiempo cuidando niños del nuevo código como lo escribo yo mismo, no sé qué hacer. Mi compañero lo perdió esta noche y dejó en claro que no importa qué, sin importar el punto de referencia, sin importar la práctica común, sin importar la prueba irrefutable, su código se mantendrá de la forma en que lo hizo por primera vez. Incluso si se han escrito libros completos sobre por qué desea evitar hacer algo, él se negará a reconocer su validez alegando que es solo la opinión de alguien.

Tengo un interés personal en nuestro proyecto, sin embargo, no estoy seguro de poder seguir trabajando con mi pareja. Parece que tengo tres opciones abiertas para mí.

  • Deje de preocuparse por el funcionamiento de la base de código más allá del punto de compilación, y solo trate de tratar de mantener y analizar el comportamiento que apenas cojea. Esperando que una vez que las cosas comiencen a romperse seriamente, él lo verá e intentará hacer más que simplemente poner una venda sobre el diseño fundamentalmente defectuoso.
  • Mantenga los argumentos interminables sobre los problemas que han sido resueltos hace una década por otras personas mucho más capaces.
  • Deje de programar en este proyecto, abandonando casi 10,000 líneas de mi código e incontables horas esclavizándose por el diseño e intente encontrar un nuevo proyecto por mi cuenta.

¿Qué enfoque puedo tomar para determinar si vale la pena continuar con este proyecto con esta persona? ¿O qué factores deberían influir en mi decisión? Hemos escrito mucho código y no quiero renunciar a esto a menos que sea necesario.


3
¿Qué pasa con las pautas de estilo de codificación acordadas y un proceso de revisión de código? Evite cualquier problema polémico, solo ponga suficiente en el estándar para que ambos puedan aceptarlo.
Brandin

25
Cuarta opción (si está bajo una licencia permisiva): bifurca el código y continúa trabajando por tu cuenta.
Robert Harvey

44
¿Cómo se licencia el código? ¿Puedes bifurcarlo y continuar con alguien más?
Jaydee

14
Como @enderland menciona en su respuesta, hay una bandera roja absolutamente masiva en lo que escribió: "Mi compañero lo perdió esta noche y dejó en claro que no importa qué, sin importar el punto de referencia, sin importar la práctica común, sin importar el prueba irrefutable, su código se mantendrá como lo hizo por primera vez ". Si usted puede conseguir lejos de esto, hacerlo. Cualquiera con quien valga la pena trabajar tendrá la humildad de aceptar que a veces se equivocarán.
Richard J Foster,

3
No importa lo que decida, las 10 mil líneas de código no se pierden: piense en lo que aprendió al escribirlas; piense en el placer que tuvo durante el tiempo de codificación; y aplicar lo aprendido en una tercera / cuarta / n + 1ª iteración (forzada) podría incluso mejorarlo en comparación con la versión actual. Además, si sabe qué escribir 10k líneas de código, puede escribir 10k líneas en un tiempo relativamente corto; a menudo es lo que lleva más tiempo saber qué escribir para que las cosas funcionen.
Kasper van den Berg

Respuestas:


26

El código imperfecto enviado es mejor que el código perfecto en la pizarra que nunca se envía.

Habiendo dicho eso...

Aquellos de ustedes con más experiencia, o que han estado en situaciones similares. ¿Qué hiciste? ¿Qué me recomendarías que haga?

Yo consideraría lo siguiente.

  • ¿Cuál es el propósito de este proyecto? ¿Divertido? ¿Dinero? ¿Aprender?
    • ¿Realmente estás logrando este propósito?
  • ¿Esta persona realmente te permite cumplir mejor tus objetivos?
  • ¿Qué tan cerca estás realmente del envío?
  • ¿Estos problemas te impiden iniciar? ¿O son una cuestión de orgullo personal?
  • ¿Hay beneficios de trabajar con alguien de forma voluntaria cuando es frustrante?

Deje de programar en este proyecto, abandonando casi 10,000 líneas de mi código e incontables horas trabajando en el diseño e intentando encontrar un nuevo proyecto por mi cuenta.

Considere lo anterior, trate de pensar en el trabajo adicional requerido.

Debe determinar sus prioridades y determinar si los problemas relacionados con el trabajo con esta persona valen la pena. No podemos resolver esto por ti.

Mi compañero lo perdió esta noche y dejó en claro que no importa qué, sin importar el punto de referencia, sin importar la práctica común, sin importar la prueba irrefutable, su código se mantendrá de la forma en que lo hizo por primera vez.

Sabes que no quieres trabajar con este tipo de persona.

Probablemente esté haciendo un proyecto como este porque quiere aprender a programar y encontrar elegancia en el oficio mismo.


1
Gracias por su respuesta. Estoy cumpliendo el propósito de divertirme (cuando no estoy luchando) y aprender. El tiempo que se pueda ganar dinero es una historia completamente diferente. Él ayuda a lograr mis objetivos, sin embargo, creo que todavía podría lograrlos por mi cuenta, él ayuda con la motivación. El juego es un gran ejemplo de la característica de arrastre, honestamente no tengo idea de cuándo se puede enviar. Mi compañero ha estado tratando de impulsar un cambio de 2D a 3D durante meses, me niego ya que ya hemos excedido nuestro alcance.
Douglas Gaskell

1
Estaría dispuesto a abandonar el proyecto, si fuera solo mío habría sido eliminado hace meses. Mi factor motivador para continuar es tener a alguien más con quien trabajar, incluso si las luchas internas me hacen cuestionar eso algunos días. Lo único que me impide abandonarlo es una amistad como una conexión con él fuera de la codificación, preferiría evitar tirar eso con el proyecto. Por supuesto, esta no es una explicación muy lógica, ya que sus sentimientos personales involucrados realmente empañan mis capacidades de toma de decisiones.
Douglas Gaskell

1
¡La forma más rápida de perder a un amigo es trabajar con ellos como iguales!

58

Esto puede ser una cosa cultural. En algunas culturas, admitir que cometiste un error es algo inaudito, y pedirle a alguien que admita que cometió un error es lo más grosero que puedes hacer. Si es esa situación, huye.

En mi experiencia con personas muy inteligentes, si les dice que algo que están haciendo es menos que perfecto, (1) le darán una razón correcta y fácil de entender por qué lo que están haciendo es realmente correcto, (2) diga usted que saben que está mal, pero no tienen tiempo para arreglarlo debido a prioridades, o (3) gracias por señalarlo y solucionarlo.

Negarse a aprender es el peor atributo que podría tener un desarrollador de software. Déjalo a él. La vida es demasiado corta y preciosa para perder el tiempo con él.


Gracias Gnasher, veo el número 2 periódicamente, aunque no tenemos un calendario real, por lo que no estoy seguro de qué tan válida sea esa respuesta. Voy a dormir sobre esto y ver lo que estoy pensando en la mañana, esto necesita mucha deliberación antes de tomar una decisión.
Douglas Gaskell

1
"Si es esa situación, huye". - y solo en general, si no puede llegar a un consenso cercano sobre cuáles son sus objetivos, entonces no puede cooperar con alguien. Parece que no consentirá que usted cambie "su" código, sin importar la razón.
Steve Jessop

Bueno, parece que la presión del tiempo no es la razón para rechazar los cambios.
gnasher729

1
Esta es una respuesta genial. ¡No puedes obligar a alguien a cambiar sus formas! Sin embargo, parece que hay mucho tiempo y esfuerzo en el proyecto tanto para él como para el tuyo. Creo que puede que él no quiera cambiar su código porque no entiende la forma en que crees que debería hacerse. Es eso o es terco, pero si ES que no lo entiende, trate de tener en cuenta que puede sentirse frustrado y pensar que le está "hablando mal", a pesar de que tiene buenas intenciones. Mi consejo es tratar de hablar con él cuando ambos estén a la altura.
zfrisch

^ + Es fácil ofenderse por alguien cuando comienzas al mismo nivel y te superan en habilidad. No estoy diciendo que sea seguro el caso, pero ciertamente parece que puede tener algo que ver con eso.
zfrisch

12

Posiblemente, la forma más fácil es traer a alguien más al proyecto: o estás equivocado y su base de código es demasiado inteligente para ti, o tienes razón y es demasiado inteligente para todos. Pronto lo descubrirá y obtendrá una copia de seguridad si resulta ser basura, enrevesada, código de nivel de programador junior.

Por otro lado, un producto que funcione vale cualquier número de años de código claro, elegante y finamente ajustado. Haz el juego, envíalo, aléjate y deja que lo mantenga y no trabajes en v2.


2
Gracias por la respuesta. Es curioso que menciones tu primer punto. Él está tratando de encontrar y traer un programador novato que pueda enseñar para ayudar con el proyecto. Solo podría esperar que esto resulte horriblemente si hay dos personas que siguen el mismo estilo de pirateo y olvido. Me gusta la segunda opción, hacerla, enviarla y luego dejarla. El problema con el que me puedo encontrar es que estamos a medio camino a pesar de hacer una LLC para tener un nombre para enviar nuestro juego. Ambos usos tendrán una cuota del 50%, por supuesto. Sin embargo, podría terminarlo y luego seguir adelante. El proyecto es grande, eso podría llevar un tiempo.
Douglas Gaskell

20
Usted no bajo ninguna circunstancia quiere entrar en una relación comercial legalmente vinculante con una persona así.
gnasher729

3
@ douglasg14b trae a un joven para enseñar ... pobre niño. Le sugiero que traiga a un tipo experimentado "ya que se aceleraría mucho más rápido y ayudaría a terminar el producto". Fije su vista en una línea de meta, ¿o ambos tienen la intención de trabajar en este pasatiempo para siempre y para siempre? (visto que sucede, hasta que se cancela)
gbjbaanb

Planeo terminarlo, definitivamente. Aunque sí creo que fue un proyecto demasiado grande para abordarlo como el primero. Comenzó como un diseño simple, no se suponía que estuviera cerca de la escala que es ahora. El límite de nuestro alcance está siendo constantemente empujado por el arrastre de características por parte de mi socio, soy parcialmente culpable de eso porque permito que suceda e incluso estoy de acuerdo con algunas características. El alcance es hasta el punto de que, si se deja solo, probablemente estemos finalizando dentro de un año. Afortunadamente con la forma en que lo programé, las partes se pueden sacar fácilmente y poner en otros proyectos más adelante.
Douglas Gaskell

44
Piense en el código como perteneciente al proyecto, no a usted. Si tiene una propiedad conjunta del producto, puede reutilizar todo el código para su próximo proyecto. Si no tiene idea de a quién pertenece qué, entonces tenga esa discusión ahora. Buena suerte.
gbjbaanb

9

Aquí hay algunas ideas, incluso si algunas de ellas son mutuamente excluyentes.

  • Responsabilidades de fuente separadas. Si trabajas en el Módulo A y él en el Módulo B, puedes competir con tus diferentes estilos. ¿Está lanzando funciones de trabajo a menudo? ¿Llega a un punto en el que necesita reescribir su código desde cero? Refactorice el código de sus módulos y no lo toque,

  • Déjelo hacer el mantenimiento de su peor código. Si lo hace con éxito, has evitado una tarea horrible. Si no puede, sentirá el dolor.

  • Considérelo desde el punto de vista de un usuario o negocio. En algunos casos, solo necesita un producto viable que Google o Microsoft puedan comprar. En otro caso, lanzará un producto al mercado y respaldar a miles de clientes con código defectuoso o pirateado será un infierno. No es lo mismo si su código controla aviones no tripulados con misiles nucleares o hace videos felices para adolescentes.

  • Él hace las clases, tú haces las pruebas. Refactorizar el código con pruebas es más fácil y seguro. De esta manera, no necesitará mirar dentro del código solo en la barra Junit. Esto supone que A) está programando pruebas, B) su código de colega es comprobable. Si le resulta difícil construir las pruebas durante la fase de codificación, esta última será peor.

  • Ir juntos a entrenamientos o eventos. Cuando no sepa que la forma correcta es bastante natural, use la única forma que sepa. Ver el código de otros podría no resolverlo todo, pero no está de más intentarlo.

  • Encuentra tus fortalezas complementarias. Refactorizar a veces puede ser divertido. Si él escribe cosas que al menos funcionan, entonces podrías hacer la refactorización. Puede hacer picos para explorar soluciones que no terminan en código de producción.

  • Es posible que no quiera volver a escribir el código, pero podría aceptar escribir mejor el nuevo código. Entiendo que reescribir es difícil, aburrido y puede romper cosas. Cultiva algunas islas de calidad. De esta manera tendrá buenos ejemplos de cómo hacer las cosas.

  • Usa la regla del boy scout . Deje las cosas intactas a menos que necesite trabajar en ello. Si un módulo está mal escrito pero funciona y no necesita cambiar, déjelo así. Si necesita corregir un error o completar una función, mejórela un poco. Después de algún tiempo, el 20% de las clases que cambias el 80% del tiempo mejorarán. Más islas de calidad.

No podemos sugerir cuál es la mejor solución sin conocerlos a ambos. Buena suerte.


4

Ok, aquí hay una respuesta que probablemente no te gustará.

No 'corrija' el código a menos que no implemente la función.

Aquí está mi razonamiento. Probablemente estés tratando de ganar dinero. Para ganar dinero, debe enviar rápidamente las funciones completas. Nadie te va a pagar más por un juego de computadora 'bien codificado'.

La mayoría de las empresas tienen el mismo problema. Refactorice el código existente para hacerlo 'mejor', a veces incluso objetivamente mejor en términos de velocidad o confiabilidad O escriba nuevas características.

El 99% de las veces eligen escribir las nuevas características porque son el resultado de un simple análisis de costo-beneficio.


15
Sin embargo, esto cae dentro del argumento de la "deuda técnica", ¿verdad? Cuando escribe esa nueva característica (o modifica una existente), ¿se tarda tres veces más y produce diez veces más errores que si hubiera continuado con su refactorización? Si es así, entonces omitir la refactorización fue una economía falsa.
Ben Aaronson

1
Se podría pensar que sí, pero he trabajado en muchas compañías exitosas y (casi) nunca veo la refactorización con alta prioridad. Mi conclusión es que simplemente no vale la pena.
Ewan

Eso es lo suficientemente justo y estoy seguro de que hay una variedad de opiniones sobre esto, solo parece que no abordar eso de una forma u otra es una omisión significativa de la respuesta. También puedo estar equivocado, pero leyendo entre líneas en la pregunta, creo que el código incorrecto del que está preocupado el OP puede ser mucho peor que el tipo de código en el que está pensando.
Ben Aaronson

je, si! pero también parece que el costo de hacer los cambios es muy alto. En mi respuesta trato de dar el objetivo '¿estás en esto por el dinero?' respuesta, más mi punto de vista subjetivo de dónde se encuentra el equilibrio de probabilidad
Ewan

1
Esto es razonable en algunos casos, pero si el "código de trabajo" de alguien está causando que otra persona pase el doble de tiempo en su código o en la integración de sistemas o trabajo futuro, ya no es una simple decisión de "enviar contra no enviar". Muchos proyectos a gran escala mueren porque no toman decisiones para hacerlo bien en lugar de rápido.
enderland

3

Me gustan todas las respuestas hasta ahora. Tomando uno de los puntos de la respuesta de Enderland :

¿Hay beneficios de trabajar con alguien de forma voluntaria cuando es frustrante?

Me gustaría aprovechar este tiempo para conectar el intercambio de pila de revisión de código . Es un lugar maravilloso donde los profesionales pueden criticar tu código. Y, sinceramente, muchas de las revisiones de códigos son de gran ayuda para los involucrados: los que preguntan, los que responden y los que se topan y las leen. Raramente obtienes reseñas tan útiles en un entorno profesional (que puede ser el caso en los lugares donde he trabajado por cualquier motivo).

Mi pequeño consejo es publicar parte de su código para su revisión. No sugeriría usarlo como munición para demostrar que este tipo está equivocado, dudo que lo tome en serio, pero puede obtener información muy útil tanto sobre el código que ha escrito como sobre el código que ha escrito. Recomiendo enviar los fragmentos de código por los que más pelean. Con toda probabilidad, ambos están equivocados hasta cierto punto y pueden usar la revisión como una forma de lograr que un tercero objetivo intervenga. Esto logrará algunas cosas:

  • Puedes desconectarte de la tensión emocional de la situación.

  • Obtiene asesoramiento profesional en tiempo real. Un gran impulso a lo que estás aprendiendo.

  • Alguien te dirá que te equivocas. Lo cual es bueno, porque cualquiera que programe por un período de tiempo va a escuchar esto. Puedes manejarlo mal como este chico con el que estás trabajando, o puedes aprender a lidiar con eso.

Creo que si usa las revisiones de código de la manera correcta, tiene mucho que ganar al tratar con esta persona extremadamente frustrante. Y es mucho más interactivo que un libro o sitio web que dice "haz esto, porque es la forma correcta la mayor parte del tiempo".

Del mismo modo, está el intercambio de pila de desarrolladores de juegos . No es tanto un lugar para publicar código para su revisión, sino para preguntar sobre conceptos / ideas con los que está luchando. Una vez más, ese lugar es de gran ayuda para todos los involucrados.

Es posible que haya visto estos dos sitios antes; Solo quería asegurarme de que sean parte de su conjunto de herramientas.


2

Suena bastante inútil. Probablemente me rendiría y seguiría adelante si me sintiera como tú; Definitivamente llega el momento de alejarse y usted puede estar allí.

Si aún no está listo para marcharse, necesita encontrar una manera de llegar a un mejor acuerdo sobre su proceso. Parece que tiene estándares de codificación, pero no estándares acordados. La próxima vez que te encuentres en una encrucijada, la próxima vez que quieras un mono con un poco de código y tu amigo quiera dejarlo solo, toma una conversación en las siguientes líneas:

Douglas: Quiero cambiarlo porque X, que está aquí en nuestras directrices.

amigo: Está bien como es.

Douglas: ¿Entonces estás diciendo que deberíamos cambiar las pautas?

amigo: No, creo que está bien como está.

Douglas: Entonces, ¿para qué sirven las pautas?

amigo: No sé, los escribiste.

Douglas: ¿Qué pautas escribirías?

amigo: no escribiría pautas. Es una pérdida de tiempo.

Douglas: ¿Entonces deberíamos tirar las pautas y escribir cualquier basura que estemos pensando en ese momento?

amigo: Esto no es una mierda.

Douglas: ¿Es perfecto? ¿Es ideal?

amigo: hace el trabajo; pasemos a la siguiente característica.

Douglas: ¿Hay algo en lo que podamos estar de acuerdo, que X es un buen código e Y es un mal código?

amigo: Déjame en paz; ¡Solo quiero codificar!

Bueno, eso no salió bien, ¿verdad? Creo que la sensación que tengo es que tú y Buddy quieren cosas diferentes. Si hay algo en lo que puedas estar de acuerdo, genial; comenzar desde allí y construir sobre él. Pero no puedes hacer que acepte querer lo que quieres, más de lo que podrías hacerte querer lo que parece querer. Si puede encontrar ese deseo común y llegar a un acuerdo común desde allí, tal vez puedan trabajar juntos.

Douglas: ¿Qué quieres?

amigo: solo quiero codificar.

Douglas: Yo también quiero codificar, pero quiero sentirme orgulloso de mi código.

amigo: estoy orgulloso de mi código.

Douglas: Aquí hay una función de la que estoy orgulloso: ¿qué opinas de ella?

amigo: Bueno, está bien, pero no deberías volver a calcular X dentro del bucle; Es ineficiente.

Douglas: ¿Entonces estás diciendo que siempre debemos calcular valores constantes fuera de los bucles?

amigo: Bueno, duh!

Douglas: ¿Crees que eso debería estar en nuestras pautas?

amigo: por supuesto.

douglas: OK, lo agregaré a nuestras pautas y actualizaré mi código ...

Douglas: ¿Cómo es ahora?

amigo: bien.

Ahora Buddy está contribuyendo a las pautas (aunque sea indirectamente), por lo que tiene un poco de sentido de propiedad. Tal vez, solo tal vez, comenzará a tomarlos más en serio. Creo que me inclinaría a borrar la pizarra y comenzar de nuevo con las pautas, dejando que la mayoría o todas ellas provengan de Buddy al principio. Siga adelante y escriba código de mierda para que sienta la necesidad de agregar a las pautas; deja que vengan de él. Tal vez entonces él comenzará a entender la razón de ellos.

Pero si prefieres darte por vencido y seguir adelante, esa tampoco sería una mala opción.


2

Suponiendo que decide abandonar el proyecto:

  • Bifurca el código y refactorízalo, utilizándolo como un elemento de cartera 'antes / después'
  • Dado que el objetivo era (principalmente o en parte) aprender programación y aprender algo lleva de 2 a 4 veces más tiempo que hacer algo que ya sabes, ese trabajo no se desperdicia realmente.
  • El 'apego a los costos hundidos' (la inversión que ya ha realizado en una empresa antes de saber que era una mala idea) es uno de los errores humanos más comunes en la toma de decisiones.
  • Para mantener la amistad, enmarca tu decisión como priorizando la amistad sobre la codificación

1

tl; dr deberías abandonar el proyecto.

Sin saber más sobre esto, entonces nos lo ha dicho, especularía que la fricción que está experimentando está relacionada con la experiencia.

A pesar de que no eres un programador de profesión como profesional de TI, probablemente hayas aprendido de la manera difícil hacer las cosas bien la primera vez, tu referencia a tu futuro yo indica que lo has jodido en el pasado y aprendido No a.

Su estudiante de CS de segundo año, incluso si es muy talentoso, probablemente carece de la perspectiva de haberlo hecho (si es como yo, repetidamente :).

Él / ella nunca creerá realmente en el valor de arreglar las cosas a medida que avanza hasta que tenga cicatrices de quemaduras por no hacerlo o sea asesorado en una cultura con una disciplina de ingeniería excepcional, o ambas.

Esta persona puede ser su compañero de programación, pero no es su compañero de proyecto, por lo que hacer este juego como un proyecto de compañero probablemente sea una causa perdida. A menos que esté preparado para comer el costo futuro. Quizás la relación sea lo suficientemente valiosa para ti. En ese caso, déle al dobladillo suficiente cuerda para ahorcarse e intervenga para ayudar a limpiar el desorden cuando esa persona se vea obligada a reconocer el problema.

De lo contrario, rescatar y hacer un proyecto con un compañero, o hacer un proyecto de mentor / aprendiz donde esa es la dinámica desde el principio.


1

Para agregar puntos adicionales a todas las excelentes respuestas:

  • ¿Cuánto más esfuerzo tomará terminar el proyecto? Tenga en cuenta que terminar el "último 10%" lleva mucho más tiempo de lo que la gente espera. Eso incluye pruebas de juego / ajuste, corrección de usabilidad, manejo de una variedad de plataformas de destino, lanzamiento, ... Si es un juego de iOS, entonces hay firma de código y pasar por la revisión de Apple. Honestamente, el acabado puede llevar tanto tiempo como el primer "90%". Y será más difícil si el código es tan malo como sugieres. (¿Puedes comenzar a jugar probándolo ahora?)
  • Siendo realistas, ¿qué tan probable es que la gente disfrute tu juego?
  • Cuidado con el " costo hundido heurístico ". Evalúe esa inversión de 10,000 líneas de código a la luz del panorama general, mirando hacia atrás en un producto terminado y sin un optimismo indebido.
  • ¿Puedes seguir si lleva otros 3 años? Ustedes dos tienen diferentes estilos de desarrollo (no es un buen partido de equipo). Parece que estás cerca del final de tu paciencia y si continúas, podría ser difícil seguir siendo amigos.

3
El "último 10%" lleva mucho más tiempo si el 90% del código es basura :-(
gnasher729

0

Debería seguir haciendo su código de la manera que considere correcta, con comentarios y demás, y hacer una copia de su versión del código (en caso de que cambie su código).

No pelees, no te enojes, solo sonríe cuando veas sus malas decisiones.

Solo se quejan como usuario, si está funcionando no se quejen.

No te rindas tampoco, es importante acostumbrarse a las personas que son diferentes a ti, eso sucederá en un trabajo real.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.