¿En qué punto la crítica "constructiva" de su código deja de ser útil?


39

Recientemente comencé como desarrollador junior. Además de ser una de las personas con menos experiencia en el equipo, también soy una mujer, que viene con todo tipo de desafíos trabajando en un entorno dominado por hombres. Últimamente he tenido problemas porque siento que recibo demasiadas críticas pedantes injustificadas sobre mi trabajo. Déjame darte un ejemplo de lo que sucedió recientemente.

El líder del equipo estaba demasiado ocupado para presionar algunas ramas que hice, por lo que no llegó hasta el fin de semana. Revisé mi correo, sin querer hacer ningún trabajo, y descubrí que mis dos ramas habían sido rechazadas en base a nombres de variables, haciendo que los mensajes de error fueran más descriptivos y moviendo algunos valores al archivo de configuración.

No creo que rechazar mi sucursal sobre esta base sea útil. Mucha gente estuvo trabajando durante el fin de semana, y nunca dije que estaría trabajando. Efectivamente, algunas personas probablemente fueron bloqueadas porque no tuve tiempo para hacer los cambios y volver a enviarlos. Estamos trabajando en un proyecto que es muy sensible al tiempo y me parece que no es útil rechazar directamente el código basado en cosas que son transparentes para el cliente. Puedo estar equivocado, pero parece que este tipo de cosas deberían manejarse en confirmaciones de tipo parche cuando tengo tiempo.

Ahora, puedo ver que en algunos entornos, esta sería la norma. Sin embargo, la crítica no parece distribuida equitativamente, que es lo que conduce a mi próximo problema. La base de la mayoría de estos problemas se debió al hecho de que estaba en una base de código que alguien más había escrito e intentaba ser mínimamente invasiva. Estaba imitando los nombres de variables utilizados en otras partes del archivo. Cuando dije esto, me dijeron sin rodeos: "No imiten a los demás, solo hagan lo correcto". Esta es quizás la cosa menos útil que me podrían haber dicho. Si el código que ya está registrado es inaceptable, ¿cómo se supone que debo decir qué está bien y qué está mal? Si la base de la confusión provenía del código subyacente, no lo creo '

Me siento realmente singular y frustrado en esta situación. He mejorado mucho al seguir los estándares que se esperan, y me siento frustrado de que, por ejemplo, cuando refactorice un código para AGREGAR la comprobación de errores que faltaba anteriormente, solo me dijeron que no lo hice comete los errores lo suficientemente detallado (y la rama fue rechazada sobre esta base). ¿Qué pasaría si nunca lo hubiera agregado para empezar? ¿Cómo entró en el código para empezar si estaba tan mal? Por eso me siento tan singular: constantemente me encuentro con este código problemático existente, que imito o refactorizo. Cuando lo imito, está "mal", y si lo refactorizo, me regañan por no hacer lo suficiente (y si voy hasta el final, introduciendo errores, etc.). Nuevamente, si esto es un problema, no entiendo cómo un código ingresa a la base de código,

De todos modos, ¿cómo trato con esto? Recuerda que dije desde arriba que soy una mujer, y estoy seguro de que estos tipos generalmente no tienen que preocuparse por el decoro cuando revisan el código de otros tipos, pero sinceramente, eso no funciona para mí. , y me está haciendo ser menos productivo. Me preocupa que si hablo con mi gerente al respecto, él pensará que no puedo manejar el medio ambiente, etc.


18
Soy un chico, junior (en esta empresa), y he sentido un doble estándar similar. La base de código a menudo parece basura, y sin embargo, se espera que siga un estándar mucho más alto. Bueno, resultó que esa basura entró allí debido a las "marchas de la muerte" que se hicieron en el pasado. Además, aparentemente me veo 5 años más joven que yo. Cuando mis colegas descubrieron mi edad real, me volví mucho más inteligente de la noche a la mañana. Los humanos son monos imperfectos. Ayuda compartir el almuerzo con ellos y reírse de sus bromas, pero no exagere. Los chicos interpretan TODO como un coqueteo.
Trabajo

44
@ Job: Bueno, si la base del código es una mierda, debería ser mejor, por lo tanto, sus commits deben tener un estándar más alto. De lo contrario, se volvería aún más horrible, ¿verdad? :)
Macke

@ Marcus, tienes razón, pero lo que sería realmente útil es si las reglas se establecieran claramente y las mismas reglas se aplicaran a todos. Además, hay algo que decir sobre la mezcla en los mismos estándares de código, como mencionó el autor de la pregunta. He visto a un chico junior ser despedido como chivo expiatorio. La gerencia se quejó de que los ingenieros produjeron demasiados errores. Los ingenieros no pudieron hacer un trabajo decente porque la gerencia les da plazos fijos. Entonces, cuando algo sale mal, siempre hay un chico junior con la mayoría de los errores que culpar y dejar ir. en.wikipedia.org/wiki/Dedovshchina
Job

3
Una cosa que me llamó la atención es "Están acostumbrados a los chicos para que no usen decoro". Yo diría que necesitas aguantar eso a menos que sea claramente un problema de discriminación. ¿Irías a un sitio de construcción y esperarías ser tratado de manera diferente al resto de los redactores? Endurecer. Si trabaja en un entorno dominado por hombres, debe ser capaz de hacer frente y adaptarse a las diferentes normas sociales de la misma manera que lo hacen. No seas tan "sensible".
Plataforma

1
Sé que esto es varios años demasiado tarde, pero creo que este es un tema importante para los futuros lectores. No excluya la posibilidad de que su líder de equipo simplemente sepa mejor; él es probablemente más veterano y ha desarrollado una intuición para problemas de estilo problemáticos: desafío a cualquiera en esta situación a tratar esto como una oportunidad para aprender y crecer. Respetuosamente, solicite una aclaración sobre los problemas que no comprende y tenga cuidado de no malinterpretar la personalidad seca de un colega como maliciosa.
weberc2

Respuestas:


41

Existe la posibilidad de que te destaquen como mujer, pero también es posible que solo seas un desarrollador junior y nuevo en el trabajo.

La verificación de errores y los mensajes expresivos son importantes. Si va a agregar algo al código, asegúrese de que sea correcto y que cumpla con los estándares del equipo. Del mismo modo, si está modificando el código de otra persona, intente mejorarlo siempre que sea posible; no vaya a reescribirlo todo, pero trate de dejarlo un poco más limpio de lo que lo encontró.

¿Existe una versión escrita de los estándares de codificación que sigue su equipo? De lo contrario, podría ser una buena idea escribirlo todo. Puede encabezar el esfuerzo escribiendo los errores que comete y formándolos en una lista de verificación a la que puede hacer referencia antes de enviar sus cambios para su revisión. Como efecto secundario, puede usar ese estándar escrito para apelar futuros rechazos si lo contradicen.

Parece que puede haber cierta falta de comprensión entre usted y el líder del equipo. Puede ser útil para usted solicitar una reunión individual con él y discutir qué puede hacer para mejorar. Puede comenzar con algo como "Siento que todavía me faltan muchos matices de lo que debería estar haciendo. Como desarrollador junior, quiero crecer y mejorar. ¿Me pueden ayudar a llegar allí?" y mira lo que pasa.


Las respuestas de Anna son generalmente muy razonables. +1. Creo que trabajar donde trabajas me volvería loco. ¿No le importa a su gerencia cumplir con los plazos? Si el código funciona, envíelo. Límpialo más tarde. Demonios, incluso podrías limpiarlo el lunes e impulsarlo en el próximo lanzamiento. Este comportamiento de su gerente nunca volaría en mi lugar de trabajo, y me alegra poder concentrarme en cumplir con los plazos en lugar de la política. Espero que su situación mejore y que encuentre una solución. :)
jmort253

11
@ jmort253 Gracias. :) Dicho esto, "si el código funciona, envíalo" puede ser una actitud peligrosa. El código de trabajo no siempre es un buen código (aunque ciertamente es mejor que el código roto) y la calidad del código es importante a largo plazo. Limpiarlo más tarde casi nunca ocurre, ya que aparecen otros plazos y surgen cosas más urgentes. Hay un término para esto: "deuda técnica".
Adam Lear

@ Anna, acuerda la importancia del código conforme. He leído que el código no conforme es suficiente para que Linus Thorvalds rechace un parche enviado para Linux en el acto (pero no puedo localizarlo en este momento).

@ Anna / Thorbjorn: aunque a veces solo tienes que hacer lo que el cliente quiere si hay una fecha límite. Su cliente no será muy comprensivo si perdió $ 15,000 en ingresos comerciales porque simplemente quería limpiar los errores de capitalización. Desafortunadamente, tratar de eliminar el 100% de la deuda técnica no siempre es posible. Sería similar a esperar 40 años para ahorrar suficiente efectivo para comprar la casa de sus sueños en lugar de solicitar una hipoteca. Claro, serías libre y claro, pero habrías pasado toda tu vida tratando con terratenientes sombríos.
jmort253

Los proyectos de código abierto son diferentes a los proyectos con fines de lucro. Muchos proyectos de código abierto pueden permitirse tener estándares más estrictos porque no siempre hay ganancias que perder / perder. Los proyectos propietarios tienen objetivos diferentes y, a veces, esos objetivos comerciales tienen prioridad. No estoy diciendo que el código no debería ajustarse, solo que a veces solo tienes que hacer lo que tienes que hacer y tener la disciplina para volver y solucionar el problema después de la implementación.
jmort253

25

Parece que te estás tomando estas cosas demasiado personalmente. No lo hagas; Este tipo de cosas sucede todo el tiempo.

Las razones para rechazar su registro (nombres variables, calidad de comentarios, ubicación de configuración) me parecen bastante estándar.

El momento fue la decisión del líder de su equipo, y no me preocuparía si fuera usted. Si alguien está bloqueado durante el fin de semana, el líder del equipo podría optar por permitir el check-in y pedirle que lo arregle después. Si sentía que era apropiado devolverlo a pesar de que podría bloquear a otros desarrolladores, es su responsabilidad.

En cuanto al líder del equipo que le dice que no imite a los demás, sino que haga lo correcto, parece que está tratando de darle alguna iniciativa para mejorar la base del código. Esa es una buena señal. Él confía en ti para que uses tu juicio, así que adelante y haz lo que sabes que es correcto. Eso no significa que deba cambiar el código de todos los demás, pero sí significa que debe asumir la responsabilidad de la calidad del código que escribe.


2
+1 Te estás enfocando en las relaciones y las emociones. Los programadores con los que está trabajando suenan muy secos, pero solo se están concentrando en los problemas del código. Esto es bastante común en entornos de programación en los que he trabajado. Por cierto, he visto esto independientemente del género.
Michael Durrant

14

Una adición a las otras respuestas:

Como desarrollador principal, generalmente soy más exigente con los desarrolladores junior porque son mucho más maleables que las personas que han estado trabajando durante algunos años. (Mis habilidades de ppl no son tan buenas ... todavía).

Es muy difícil cambiar a alguien que ha estado trabajando (y ganando un salario decente) por un tiempo y está satisfecho con su nivel de código (aunque la calidad podría mejorarse). A esos tipos no les importa si tratas de guiarlos para que se conviertan en mejores / mejores programadores. Son felices trabajando en la fábrica de códigos.

Los chicos nuevos, como usted, OTOH, suelen anhelar orientación y saber qué es lo correcto y qué no. Además, son capaces de absorber los comentarios y cambiar sus formas para mejor. No están configurados de otra manera.

Si toma en serio estos consejos y los convierte en parte de su vida cotidiana, descubrirá que en poco tiempo estará escribiendo código que es superior a gran parte de la base de código existente.

Asi que ...

.. podría ser que está recibiendo más comentarios solo porque tiene el potencial de hacer algo al respecto. :)


Esto plantea muchos puntos buenos.
sevenseacat

13

Es completamente posible que te estén señalando porque ... eres un desarrollador junior.

Según su descripción, parece que no siguió el estándar tal como lo percibe el líder del equipo .

La solución es simple:

  • Si ese es el estándar, sígalo.
  • Si no comprende el estándar, solicite una aclaración.
  • Si su interpretación del estándar o las instrucciones difiere de la del líder del equipo, solicite una aclaración

No pelees con eso; Si intenta hacer que el equipo lidere "mal", incluso si gana, pierde. Aprenda la lección apropiada y continúe creciendo.


1
Intentar seguir algún "estándar" a la "T" cuando se trata de idiotas como ella describe no servirá de mucho. Será una discusión interminable sobre definiciones y semántica.
MrDatabase

44
@MrDatabase No me parecen mucho idiotas. Un poco exigente, tal vez, pero el diablo a menudo está en los detalles y una vez que comienzas a bajar tus estándares, toda tu aplicación puede ir cuesta abajo rápidamente.
Adam Lear

3
Es cierto que los estándares deben ser respetados. Sin embargo, ella demuestra claramente que no es realmente un estándar (los desarrolladores anteriores no se adhirieron a él). Por lo tanto, sus compañeros de trabajo que le imponen el "estándar" (sin decir algo como "hey mira ... sabemos que parece inconsistente, pero realmente estamos tratando de mejorar nuestra base de código") es hipócrita e inútil. Cuando los compañeros de trabajo actúan así, debe adoptar un enfoque diferente e inteligente.
MrDatabase

@ user15859: si te refieres a mi respuesta, esa no era mi intención en absoluto. Creo que dije exactamente lo mismo que Anna dijo en su respuesta. No se pretendía ofender. Las violaciones de los estándares que mencionó son importantes para el mantenimiento a largo plazo, y cualquier ambigüedad en el alcance de la aplicación de los estándares debe resolverse con el líder de su equipo. Si fueras perezoso no hubieras publicado aquí. Si fueras incompetente, no te importaría tanto. No creo que seas ninguno de esos.
Steven A. Lowe

1
Creo que se está refiriendo a lo que dijo Woot4Moot cuando usó "pereza e incompetencia" como una frase en su comentario. Creo que su respuesta está bien, ya que le da al OP algún recurso y espacio para tomar medidas basadas en su interpretación de lo que realmente está sucediendo.
jmort253

10

Nota del autor

Unos años despues; He editado esto para reflejar con mayor precisión cómo me siento acerca de la situación. Estoy poniendo más matices en mi respuesta porque estoy aprendiendo más sobre los matices en estas situaciones. Es fácil reclamar una respuesta 'negra o blanca', pero todos sabemos que no es tan simple. Mi respuesta ahora refleja eso.

Por lo que has descrito; el comportamiento que estás experimentando no parece tener nada que ver con tu género. Eso no quiere decir que no esté experimentando ningún tratamiento relacionado con el género (espero que no lo esté), solo que lo que describe no parece estar relacionado con el género.

Cuando era líder de equipo, trataba a todos por igual. No hay espacio en tecnología para tratar mal a alguien debido a su género. No sé cómo lidiar con eso si te está sucediendo.

Es importante que confíe en que el líder de su equipo trata a hombres y mujeres por igual. Si hay evidencia de que no lo es, entonces se aplica el viejo dicho: Cambie su entorno o cambie su entorno.

Por igual quiero decir que trata a todos por igual sin deferencia al género. Si está haciendo su trabajo correctamente, no debería verlo criticar a nadie más; y no deberían verlo criticarte. Frente a otros, es muy importante que el líder del equipo muestre confianza, incluso si solo pasó los últimos cinco minutos antes de corregir el comportamiento en privado.

Ahora a los problemas que ha planteado:

Usted registró un código que no cumplió con el estándar que estableció, por lo que rechazó su sucursal. Si estuviera en su lugar, no habría hecho lo mismo de la misma manera, pero me aseguraría de que mis subordinados (palabra extraña; porque no pienso en un líder como "superior" a la gente que liderar; pero con precisión (no de manera adecuada) describe la situación) saber qué es lo que hay que hacer. Si no saben cuáles son los estándares, es mi culpa como líder. Depende de mí corregirlo. En este caso, es posible que haya cometido un error, pero el simple hecho de que sucedió significa que o bien 1) no se le dijo qué era lo que debía hacer o 2) no recibió la orientación adecuada. Tampoco es tu culpa.

Una de las partes más importantes de ser un programador es darse cuenta de que la base de código en la que trabaja debe ser mantenida por muchas personas diferentes. Cualquier desorden variable u otras cosas que disminuyan la capacidad de leer el código no son transparentes para el cliente , ya que lleva más tiempo solucionar los problemas en el código que es más difícil de leer.

Si su equipo ha escrito pautas de codificación, sígalas. Si no lo hacen, entonces debería haber algún tipo de convención comunitaria para su lenguaje (para .NET y C #, Microsoft tiene un estándar que muchas compañías siguen).

Pregúntele a su jefe de equipo dónde están las pautas de codificación para asegurarse de seguirlas. Lleve dos registros a sus reuniones donde otros dos desarrolladores no siguieron las pautas de manera consistente, de modo que cuando él dice que no hay ninguno, puede señalar que otros también parecen tener problemas, y todos se beneficiarían de tener Esas pautas.

Si te está tratando de manera justa, entonces verá esto y esto debería estar en la parte superior de su lista de cosas que hacer. Si él no te trata de manera justa, entonces tienes municiones si sigue sucediendo.

Decir "Ya lo haré más tarde" es malo. Más tarde nunca sucede. Tómese el tiempo para hacerlo bien. No hay más tarde en la programación.

Es difícil cuando eres un desarrollador junior. Te sientes presionado para actuar y hay muchas personas mirándote, y cada error que cometes está vinculado a tu nombre en el control de la fuente para siempre.


1
Secundaré el comentario sobre "Lo veré más tarde". Si tuviera un centavo por cada vez que he escuchado eso, bueno, no estaría aquí escribiendo este comentario. :-)
Eric King

Para .Net hay estilo de policía. Actívelo para que el código no se cree hasta que StyleCop esté contento. Esto elimina la subjetividad humana es el acoso laboral. Verá, la tecnología puede ayudarlo a decidir si Michael Phelps era el # 1 o el # 2. Sin embargo, en el patinaje artístico ... Figureskating.about.com/od/famousskaters/tp/scandals.htm Ser un líder de equipo no debería ser un truco de poder. No debe haber [dis-] favoritos en un equipo. Hay que tener cuidado para asegurarse de que tal impresión no se forme. Una buena manera de hacerlo es activar las reglas que verificarían el código y le darían una respuesta imparcial.
Trabajo

3

En ninguna parte de tu publicación mencionas cómo se trata a los demás. Sigues repitiendo que "sientes" que estás siendo "señalado" porque eres "una mujer".

Creo que te están tratando como un programador junior, independientemente de tu género y deberías estar agradecido por eso, porque eso es lo que significa igualdad. También siento que estás haciendo un gran alboroto por pequeños cambios estéticos de código de 5 minutos que te piden que hagas ahora en lugar de ponerlos en una lista de tareas pendientes y nunca llegar a ellos.

En ninguna parte de su publicación mencionó que se le ordenó hacer estas cosas el fin de semana. Podría estar perfectamente bien revisar las correcciones el lunes por la mañana.

El liderazgo de su equipo puede ser un poco pedante para mis gustos, pero desde su publicación no veo nada de malo en sus solicitudes.

Por favor, deja de jugar la carta de género para nada . Siento que esto no es digno y socava el concepto de igualdad de género.


1

No creo que rechazar mi sucursal sobre esta base sea útil. Mucha gente estuvo trabajando durante el fin de semana, y nunca dije que estaría trabajando. Efectivamente, algunas personas probablemente fueron bloqueadas porque no tuve tiempo para hacer los cambios y volver a enviarlos. Estamos trabajando en un proyecto que es muy sensible al tiempo y me parece que no es útil rechazar directamente el código basado en cosas que son transparentes para el cliente. Puedo estar equivocado, pero parece que este tipo de cosas deberían manejarse en confirmaciones de tipo parche cuando tengo tiempo.

Es difícil decir algo útil como alguien que no vio su código ni sabe algo sobre el cronograma de sus proyectos. Pero, si su líder se comporta de manera responsable y hace un buen trabajo, él sabe que otros no estaban realmente bloqueados y que el sprint no llegará tarde. Entonces, no te preocupes por eso. Quizás sobrevaloras el impacto en tu compromiso. De lo contrario: si su proyecto es crítico y pasa todas las pruebas, sería demasiado exigente rechazar el código, que podría solucionarse después del lanzamiento en un abrir y cerrar de ojos.

Haz que funcione Hazlo bien Hazlo rápido

Entonces, si su líder tomó la decisión de rechazar su compromiso, como profesional debería saber qué estaba haciendo.

Ahora, puedo ver que en algunos entornos, esta sería la norma. Sin embargo, la crítica no parece distribuida equitativamente, que es lo que conduce a mi próximo problema. La base de la mayoría de estos problemas se debió al hecho de que estaba en una base de código que alguien más había escrito e intentaba ser mínimamente invasiva. Estaba imitando los nombres de variables utilizados en otras partes del archivo. Cuando dije esto, me dijeron sin rodeos: "No imiten a los demás, solo hagan lo correcto".

Como Junior, es difícil encontrar el camino hacia la base de código de una empresa.

Lo mejor: existen estándares de codificación documentados , y con suerte aprenderá a dominarlos.

Por lo general: hay estándares de codificación no documentados , y debe aprender a través de prueba y error, ¿ o debería decir commit y _reject? Esto a menudo es doloroso (como en su caso). Esto a veces es peligroso en términos de calidad de código y podría conducir a la programación de culto de carga , donde uno no solo imita nombres variables, sino que copia y pega estructuras y patrones de la base del código de buena fe, tiene que hacerse así. ¡No hagas eso! Ni siquiera imite los nombres de variables existentes.

Apégate al código limpio . Es una buena práctica y le brinda una posición fácil de defender. Si es un código legible, comprobable y mantenible, la mayoría de las veces ha ganado alguna discusión.

Y esto lleva a otro (el último) consejo: ¡Sigue la regla del boy scout !

Siempre deje la base de código en un mejor estado de lo que estaba. Incluso si el código circundante con el que está trabajando es desagradable, limpie el suyo y, si tiene tiempo, repare los alrededores.


0

Tómese un tiempo para aprender los diversos matices de las personalidades de sus compañeros de trabajo. En mi experiencia, puede evitar críticas irracionales, innecesarias, inconsistentes o simplemente inútiles si evita las peculiaridades de sus compañeros de trabajo.

Por ejemplo, algunos compañeros de trabajo pueden tener resaca los lunes. Pueden estar muy irritables y demasiado ansiosos por rechazar ciertas ramificaciones o confirmaciones de código. Si tiene que trabajar con alguien como este, trate de evitar cometer código los lunes.

Por otro lado, un compañero de trabajo con resaca puede ser demasiado grosero para preocuparse por la verbosidad de los mensajes de error ... por lo que el lunes por la mañana puede ser el momento perfecto para confirmar su código :-p

Las peculiaridades de la personalidad en la oficina o el lugar de trabajo son literalmente infinitas. Esperemos que pueda aprender a quién evitar y cuándo evitarlos. Además, no seas demasiado duro contigo mismo :-) ¡Siempre puedes renunciar y encontrar otro trabajo!


1
Encuentre el trabajo antes de renunciar, muchos gerentes de contratación ni siquiera lo entrevistarán si no está empleado.
Woot4Moo

-2

Nunca he trabajado en un entorno donde el código se rechaza sobre la base de que no se siguen ciertas convenciones. Si estuviera en su lugar, estaría tentado a buscar empleo en un lugar donde esté más capacitado para tomar las decisiones correctas y donde el cliente sea el foco principal, no el código.

No digo que el código limpio y los estándares no sean importantes, pero el cliente y la línea de tiempo del producto no deberían sufrir debido a un error de ortografía en algo que ninguna persona no técnica, cliente o ejecutivo nunca verá.

Dicho esto, parece que podría estar trabajando en un entorno donde las expectativas no son claras, o no comprende completamente los requisitos, por cualquier razón.

Independientemente de la situación, depende de usted tomar el control y hacer preguntas aclaratorias. Sea proactivo, si aún no lo ha hecho. Los miembros de su equipo y el líder del equipo probablemente lo respetarán más por hacer preguntas para aclarar las reglas para registrarse. También puede solicitar una "revisión posterior a la acción" donde usted y el líder de su equipo discutan lo que deberían haber hecho y cómo puede notar la diferencia en cuanto a cuándo tomar ciertas acciones y cuándo no hacerlo.

Te sugiero que le des tiempo, ya que eres nuevo, para ver si puedes superar cualquier obstáculo y resolver estos problemas con experiencia, comunicación y aprendizaje de los estándares. Sin embargo, si después de varios meses la situación no ha cambiado y el ambiente sigue plagado de ambigüedad, puede ser el momento de buscar empleo en otra empresa.

No todas las organizaciones son tan draconianas, y es posible que encuentre otros entornos de trabajo más adecuados para su personalidad, estilo y requisitos de comunicación.


2
Esto no parece "draconiano"; la consistencia es un componente importante en la mantenibilidad, la mantenibilidad es un componente importante en la calidad, y el software de calidad tiene muchas más posibilidades de envío a tiempo y a un costo menor que el "código de compromiso". Puede ser alentador que algo así como el 80% de las compañías de software estén ansiosas por comprometer la calidad y sufrir las consecuencias, por lo que no parece haber escasez de oportunidades de empleo "no draconianas". :)
weberc2

1
No me gustaría trabajar en un entorno donde no se cumplan las convenciones básicas . Si un proyecto abandona la defensa de sus pautas de codificación, está condenado a ser inmanejable a largo plazo. La nomenclatura especialmente variable no es algo insignificante: no importa cuánto código existente se llame cierta matrizA , nunca aceptaría una confirmación que llame a otra matriz Bpor consistencia. Por supuesto, no sé lo que el OP quiso decir con "imitar nombres [...] utilizados en otros lugares" precisamente, sin embargo, dada la calidad de algunos códigos que he visto, podría estar en esta línea.
cmaster
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.