Fallas en el diseño y cómo lidiar con la humillación [cerrado]

Una vez, el VP de una fortuna 500 le costó a la compañía 1 millón de dólares con una mala decisión comercial. Cuando entregó su renuncia a la C.E.O, la respuesta que le dieron fue: "Acabo de invertir un millón de dólares en su educación y ahora está intentando irse. No acepto".

Me canso de los gerentes y otros trabajadores que rápidamente culpan de un error a alguien que es un novato o que asume que es incompetente. Solo hay una forma de convertirse en un buen diseñador y es f @ $% unos pocos. No me importa si mis empleados cometen un error, me importa si cometen el mismo error varias veces. La pregunta es, ¿qué tan humilde y cuán educable eres? Cuando alguien te presenta tu error, ¿te defiendes primero o lo escuchas? Si eres uno de los pocos tipos que pueden tragarse su orgullo y aprender de él, entonces vale la pena aferrarte. Cualquiera de quien pierdas el respeto por cometer un error una vez, no es alguien que merezca tu respeto.

Personalmente tuve que reescribir los dos primeros proyectos que diseñé al menos dos veces, ¿pero sabes qué? Aprendí un montón, y aunque mis empleadores estaban perturbados en ese momento, eso fue compensado rápidamente por la eficiencia que gané con el tiempo al estar dispuesto a aprender de mis errores.

En cuanto al aspecto de la humillación y cómo recuperarme, tengo dos consejos. Primero, la gente olvida con el tiempo. Además, cuando alguien más tiene el foco en ellos, también se equivocarán. Entonces todos serán iguales de nuevo. Segundo, no seas un imbécil con los demás cuando cometen errores honestos, de aprendizaje. De hecho, deberías animarlos a menos que realmente necesiten una patada firme en el culo. Con el tiempo, puede ayudar a cambiar la cultura de su equipo recordando cómo se sintió cuando cometió un error honesto. Eventualmente, inspirará a las personas a ser mejores programadores, diseñadores y seres humanos.

He estado haciendo esto durante mucho tiempo (más de 15 años), y todavía no lo hago bien la primera vez. Los mejores diseños surgen de un proceso iterativo y colaborativo. Cuando ha estado trabajando en un diseño por un tiempo, es fácil quedar atrapado en pensar que es la única manera de hacerlo. Una nueva perspectiva es útil para ver las cosas que extrañas.

Para que esto funcione, el equipo debe confiar el uno en el otro. No puedes tener miedo de mostrarle a la gente un diseño que podría ser defectuoso, y necesitas poder aceptar las críticas del diseño. A su vez, el resto del equipo debe comprender que las fallas en un diseño no son una reflexión sobre el diseñador. Es una parte esperada del diseño. También es así como los miembros del equipo aprenden y mejoran: de sus propios errores y los errores de los demás.

Si estás en un equipo disfuncional que no funciona así, tienes dos opciones:

1. intenta arreglar el equipo
2. encuentre un nuevo equipo (ya sea internamente o en un nuevo empleador).

Hasta donde sé, siempre he sido fundamentalmente defendible . No es exactamente lo mismo que ser fundamentalmente correcto . A menudo, las circunstancias cambian entre el momento en que tiene que tomar la decisión 'x' y el momento en que queda claro que 'x' fue la decisión incorrecta en retrospectiva .

Es algo así como preparar tus impuestos a la renta en los Estados Unidos. Mucha gente piensa que se supone que hay una respuesta. No hay Tienes tu opinión; su asesor fiscal tiene su opinión; El IRS tiene su opinión.

Cuando cometo errores, no pierdo el respeto de nadie. (Hasta donde sé.) Creo que eso se debe a que, en parte, siempre admito mis propios errores. (De hecho, a menudo encuentro mis propios errores.) Además, casi todas las decisiones de diseño importantes tienen más de una persona que las aprueba. Cualquier error en esas decisiones es propiedad del grupo, no del todo por una sola persona.

En cuanto a admitir errores, creo que se vuelve más fácil a medida que adquiere competencia y experiencia. En mi experiencia, cuanto más nuevo eres en diseño y desarrollo, menos probabilidades tienes de admitir un error.

Ocurre de vez en cuando, y no debería descarrilar tu carrera. Nadie en una posición de responsabilidad significativa invariablemente toma las decisiones correctas. De hecho, nadie en una posición de responsabilidad significativa invariablemente toma decisiones defendibles.

Pero la mayoría de las veces, debería poder tomar decisiones defendibles basadas en información incompleta. Como diría mi hija, "eso es ser gente".

Todo el mundo se equivoca a veces. Los errores son inevitables. Admita libremente cuando esté equivocado, aprenda de sus errores y muestre humildad, especialmente si inicialmente no estaba convencido de que realmente estaba equivocado.

"Humillación" nunca debería suceder, nunca. No es probable que mejore el rendimiento de una persona en absoluto.

Aquí, en mi empresa, hemos desarrollado una cultura de respeto por aquellas personas que todavía están dispuestas a tomar decisiones difíciles pero que pueden admitir que están equivocadas y ajustar su comportamiento cuando sea necesario.

  

¿Siempre ha sido fundamentalmente correcto en los diseños de software que propuso?

¡Sí, soy un sobrehumano! Bueno, por supuesto que no.

  

Cuando das un diseño que era fundamentalmente incorrecto, tiendes a perder el respeto de los demás miembros de tu equipo.

¡No! Si eso sucede, entonces hay algo mal con el espíritu del equipo.

Todo el mundo comete errores. Algunas soluciones resultan ser buenas, otras malas, la mayoría es algo intermedio. Tanto usted como el resto del equipo deben tomar tanto los éxitos como los fracasos.

Los primeros errores pueden sentirse mal, pero después de que hayas cometido cientos de ellos, es como parte del trabajo.

Les pasa a todos. Lo principal es aprender de sus errores e intentar que no vuelva a suceder. Además, asegúrese de admitir que fue un error de su parte. Por ejemplo, una vez cometí el error de usar una capa de acceso a datos inferior (SubSonic3). Cuando tomé la decisión, solo quería alejarme de las consultas de SQL hechas a mano. Así que elegí lo que en ese momento parecía ser uno de los más fáciles para comenzar. Yo tampoco tenía mucha experiencia con los DAL. Bueno, después de resolver algunos problemas, me preguntaba por qué algunas consultas demoraban un poco y descubrí que SubSonic estaba derribando tablas enteras sin una buena razón.

Entonces, le dije a mi jefe, le expliqué que cometí un error y le di mi plan para solucionarlo. Por supuesto, mi jefe no estaba entusiasmado con que cometiera un error bastante grande que requería unos días de migración pura. Pero, también se aseguró de que no volviera a cometer el mismo error. Me hizo crear un proyecto de prueba de concepto para la siguiente capa de acceso a datos a la que me propuse migrar y nos aseguramos de que funcionara con nuestros requisitos, y que no eliminara tablas completas. En general, fue una buena experiencia de aprendizaje para mí y ahora me aseguraré de que una parte clave del proyecto cumpla con los requisitos y no tenga grandes problemas.

Básicamente, lo que haces es esto:

1. Admite que cometiste un error
2. Haz un plan para arreglarlo
3. Asegúrese de que su plan realmente funcione
4. Asegúrate otra vez.
5. ¡Arreglalo!

Si no estás seguro de cómo solucionarlo, no tengas miedo de involucrar a otros miembros del equipo.

Una última cosa, ¡relájate! Todos cometemos errores. Muy pocas personas lo consiguen perfecto la primera vez

Esto es un tema de concurso geeky pissing, y no es una buena situación. Nadie siempre tiene razón, y no hay nada de qué avergonzarse si a alguien se le ocurre una mejor manera de hacerlo, o si encuentra una problema con la forma en que lo hiciste.

Necesita deshacerse emocionalmente de su solución, y dedicar su tiempo a buscar la mejor mejor , entonces puede sentirse satisfecho cuando se resuelva el problema, incluso si es resuelto por otra persona.

Hay mucho que no está diciendo en su pregunta. No puedo decir cuál es su configuración para "dar un diseño". ¿Se trata de una discusión inicial con un compañero sobre su enfoque planificado o es la entrega de lo que espera que sea el código final?

Si es lo primero, entonces no hay razón para sentirse mal y no hay razón para que tus compañeros te sospechen en el futuro.

Si está esperando hasta la entrega final para discutir su diseño con otra persona, entonces no los culpo por sospechar de su otro trabajo.

Todos necesitan discutir su diseño con otra persona. Dependiendo de la complejidad o criticidad, es posible que deba discutirlo con varias personas varias veces. Todos pueden cometer un error, malinterpretar un requisito o perder un caso especial.

Los errores identificados temprano son más fáciles y más baratos de solucionar. Deben ser muy perdonables a menos que repita los mismos errores una y otra vez. Las revisiones por pares facilitan la detección temprana de errores.

Si está tratando de ser un programador solitario en un entorno de equipo, está cometiendo el pecado (casi imperdonable) de pensar que es lo suficientemente perfecto como para no necesitar la ayuda de nadie. El hecho de que se trate de un entorno de equipo demuestra que el problema es lo suficientemente grande como para que nadie lo entienda todo. Las personas tienen que hablar entre sí o los errores harán que sus cabezas erectas se acerquen demasiado al lanzamiento (o después del lanzamiento).

Siempre he hecho una distinción entre, por un lado, decisiones buenas o malas; y en las demás decisiones correctas e incorrectas. Una buena decisión es aquella que, en las mismas circunstancias, con la misma información, tomaría de la misma manera; Una mala decisión es una que tomarías de manera diferente. Una decisión correcta es aquella que, con el beneficio de la retrospectiva y la información adicional, demuestra ser correcta; ya la inversa con decisiones incorrectas.

Se ha dicho a menudo que la persona que no toma decisiones incorrectas nunca toma nada. Las decisiones incorrectas son la forma en que uno aprende. Las malas decisiones a menudo se exacerban porque el decisor se invierte en la decisión y trata de justificarla retrospectivamente, o prueba que fue una buena decisión después de todo (el encubrimiento siempre es más perjudicial que la decisión original).

La mayoría de las decisiones de diseño que tomé resultaron ser correctas, pero aprendí más y avanzé más con aquellas decisiones que fueron incorrectas. Espero que muy pocas de mis decisiones hayan sido malas, pero parte del problema con las malas decisiones es reconocer que una decisión fue mala y aceptar las lecciones a menudo desagradables que surgen de ellas.

Mientras no estén siendo " Monday Morning Quarterback ". No tengo uso para alguien que se siente en todas las discusiones de diseño sin decir nada solo para decir que sabía que no funcionaría después del hecho. Tienes que ser capaz de recibir críticas incluso si no se pone en un contexto constructivo.

Probablemente una de las mejores características del sitio SO es poder tomar un riesgo y proponer una solución incierta. Así es como aprendes. Pasar por la vida con un montón de mierda en tu cabeza que está mal, pero nunca te han dicho que es una verdadera ignorancia.

Pueden saber algo que tú no sabes, pero no lo sabrán todo. Supéralo, ponte a trabajar y haz algo. Deje que pierdan el tiempo pensando que son tan inteligentes.

¿He siempre brindado un buen diseño? ¡No! Me esfuerzo por hacerlo, me esfuerzo por mejorar, pero con cada proyecto sucesivo, lo que aparentemente puedo siempre hacer es mirar hacia atrás a lo que he hecho antes y encogerme de ver cómo me perdí la marca de alguna manera

En cuanto a alguien que ha propuesto un diseño menos que estelar, no lo mantendría contra esa persona si esa persona demostrara que estaba dispuesta a aprender del error y estaba abierta a las críticas. Si veo evidencia de que la persona se esfuerza por mejorar y tiene la capacidad para hacerlo, entonces una mala propuesta de diseño es solo una oportunidad de aprendizaje.

Le pasa a todos de vez en cuando, por lo que lo mejor es averiguar por qué que el diseño fue incorrecto y aprender de eso. Si se trata de una falta de conocimiento, entonces, la falla en el diseño le proporcionará nuevos conocimientos que puede usar la próxima vez. No dejes que te desanime, todos pasan por esto en algún momento. Es la mejor manera de ganar experiencia y de atrapar a un nuevo equipo / entorno.

Esto sucederá a menudo. Nuestra industria está cambiando tan rápidamente, las posibilidades de nunca equivocarse son efectivamente nulas.

Sin embargo, ¿presionaste el mal diseño sobre sus objeciones sobre sus objeciones? Esa podría ser la razón por la que están exagerando.

Si el error fue masivo, por supuesto, tomará tiempo recuperar el respeto. Si uno de tus compañeros de trabajo te tomó en una mala dirección y creó problemas para todo el equipo, ¿no necesitarías que se demuestre más en el corto plazo?

Todo lo que puede hacer es admitir que estaba equivocado, reconocer a quien tuvo la razón y esforzarse por escuchar mejor y buscar mejores opciones en el futuro.

¿Qué no consideraste que hizo que el diseño fuera un error? (Ejemplo no aleatorio: diseñe un proceso de importación para usar el servicio web existente que se ejecuta fila por fila (la reutilización del código y solo la necesidad de cambiar las reglas comerciales en un solo lugar) sin darse cuenta de que algunas importaciones tendrán millones de registros y llevarán días terminar.) Aprende de ello y considera esas cosas en el futuro.

Siempre habrá errores. Errar es ser programador. Continúe aprendiendo de otros en Internet y especialmente de sus compañeros de trabajo. La única vergüenza aquí sería rendirse o enterrar la cabeza en la arena cuando se trata de temas como este de aquí en adelante.

Ponlo detrás de ti, baja la cabeza y haz lo mejor que puedas. Si eres un buen programador, brillarás a través de tus errores.

Si no está seguro de que su idea se asiente sobre una base sólida, debe analizarla con algunos colegas de confianza antes de proponerla a toda la compañía o departamento. De hecho, incluso si ESTÁ seguro, aún debe discutirlo con las personas con las que trabaja y con quienes es más probable que lo conozcan mejor. Te ayudarán a detectar problemas desde el principio.

Nos pasa a todos a veces. Utiliza el primer diseño como prototipo. Descubra exactamente qué funcionó y qué no y por qué. Entonces puedes escribir un producto final mucho mejor.

No intentes justificarte o ponerte a la defensiva. Admite el error y sigue adelante.

El problema fundamental no parece explicarse: este es un problema social . Puede ver este tipo de comportamiento en casi todas las profesiones: si comete un error y les gusta "categorizarlo" en ciertas cosas, es para siempre. Es un comportamiento social. Incluso las personas inteligentes e inteligentes tenderán a seguir a todos.

Déjame darte un ejemplo que no tiene nada que ver con la programación: en mi trabajo anterior, había olvidado lavar mis platos una o dos veces. Desde entonces, todos los trabajadores pensaron que soy el tipo de hombre que nunca lava mis platos. Y ahora, tan pronto como hay una cosa sucia en el fregadero, soy yo (¿quién más podría ser?)

Es lo mismo en todas partes: este es un comportamiento social , no importa qué tipo de problema pueda ser.

¿Me dices que quieres retroalimentación honesta? La única solución es renunciar a otro trabajo. Si todas las personas del equipo piensan que no eres bueno en tu trabajo, no cambiará pronto, lamento decirlo de esta manera. Así que busque otro trabajo, porque nunca cambiará este tipo de comportamiento (estúpido, debo confesar) social .

La clave es cómo declara su caso y qué tipo de cambios realiza. Si dices ser un gurú de la programación que no se equivoca y es más asombroso que Jon Skeet, entonces es muy probable que en algún momento te desanimen por eso. La clave es cómo presentar sus soluciones para que pueda demostrar que esta es una solución razonable al problema en lugar de la solución perfecta que ni siquiera debería verificarse.

Mi mejor ejemplo sería descubrir los efectos secundarios de tener una clase como static en una aplicación web donde trabajé una vez. No sabía qué tan grave sería que esa instancia persistiera y se compartiera con todos los usuarios de la aplicación, pero aprendí de ella y me recuperé a tiempo. A veces puede ser que se encuentre algo y se deban hacer correcciones importantes. También he estado en ese campamento donde tuve que examinar un montón de VBScript para reducir las concatenaciones de cadenas que causaban problemas de memoria donde trabajé una vez. Incluso puedo recordar que escribí código vulnerable a las inyecciones de SQL en 1998 cuando estaba escribiendo un código de un cliente que tenía que generar dinámicamente el SQL ya que tenía ~ 20 campos opcionales en esa parte de la aplicación.

El perfeccionismo puede ser un poco como un arma de doble filo aquí, que es como veo ese tercer comentario y también como lo soy a veces. Lo malo es ver que hay todos estos errores y que nada está bien. Lo bueno es que, al obtener lo mejor que puedas, podrías estar cumpliendo si no superas las expectativas que otros tienen de ti. La mejora continua bien podría ser la manera en que la PC ve el perfeccionismo y, si se mantiene con moderación, veo esto como algo bueno. Por todos los errores cometidos, ¿su código entra en producción? ¿Se hace el trabajo? Esos son puntos para reflexionar, así como si alguien siempre está reparando algo o ¿es bueno que quieras ser tan bueno que preferirías no hacer nada más hasta que sea perfecto? La práctica puede ser útil para ayudar a encontrar los patrones para hacer mejor el trabajo. Sin embargo, hay algo que decir para comprender el análisis de costo-beneficio al regresar para hacer ajustes menores cuando hay otros incendios que deben manejarse primero.