Diseñar fallas y lidiar con la humillación de él [cerrado]

¿Siempre has sido fundamentalmente correcto en los diseños de software que propusiste? Cuando entrega un diseño que era fundamentalmente incorrecto, tiende a perder el respeto de los demás miembros del equipo. No importa lo que haga después de eso, terminará siendo verificado por todo lo que propone después de ese incidente. Esto es especialmente peor cuando eres nuevo en un equipo y no conocen tu pasado en el que has tenido algunas buenas historias de éxito.

Tal vez la razón por la que diste un mal diseño fue por falta de experiencia o conocimiento o ambos en esa área. ¿Cómo lo ha enfrentado usted que se ha enfrentado a tal situación? ¿Es esto algo único en tu carrera o sucede de vez en cuando? ¿Se olvida esto o se necesita buscar una nueva línea de trabajo en una situación así? Algunos comentarios honestos por favor ...

Gracias.

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 presentó su renuncia al CEO, la respuesta que recibió fue: "Acabo de invertir un millón de dólares en su educación y ahora está tratando de 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 son incompetentes. Solo hay una forma de convertirse en un buen diseñador y es f @ $% unos pocos más. No me importa si mis empleados cometen un error, me importa si cometen el mismo varias veces. La pregunta es, ¿cuán humilde y enseñable eres? Cuando alguien te presenta tu error, ¿te defiendes primero o lo escuchas? Si eres uno de los tipos raros que pueden tragarse su orgullo y aprender de él, entonces vale la pena aferrarte a él. Quien pierde el respeto por cometer un error una vez, no es alguien que merece su 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 rápidamente compensado 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 recuperarse, tengo dos consejos. Primero, la gente olvida con el tiempo. Además, cuando alguien más tiene el centro de atención sobre ellos, también se equivocarán. Entonces todo volverá a ser igual. Segundo, no seas un imbécil con los demás cuando cometen errores honestos, de aprendizaje. De hecho, debes alentarlos a menos que realmente necesiten una patada firme en el trasero. Con el tiempo, puede ayudar a cambiar la cultura de su equipo al recordar 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 durante un tiempo, es fácil quedar atrapado pensando que es la única forma de hacerlo. Una nueva perspectiva es útil para ver las cosas que echas de menos.

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

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

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

Hasta donde sé, siempre he sido fundamentalmente defendible . Eso no es 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 como preparar sus impuestos sobre la renta en los Estados Unidos. Mucha gente piensa que se supone que debe haber una respuesta. No hay Tienes tu opinion; su contable 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 es porque, en parte, siempre admito mis propios errores. (De hecho, a menudo encuentro mis propios errores). Además, en casi todas las decisiones de diseño importantes, más de una persona las aprueba. Cualquier error en esas decisiones es propiedad del grupo, no del todo de una sola persona.

En cuanto a admitir errores, creo que eso se vuelve más fácil a medida que adquieres competencia y experiencia. En mi experiencia, cuanto más nuevo sea para diseñar y desarrollar, menos probable es que admita un error.

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

Pero la mayoría de las veces, debe poder tomar decisiones defendibles basadas en información incompleta. Como diría mi hija, "Eso es solo ser personas".

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.

La "humillación" nunca debería suceder. 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 esforzarse por tomar decisiones difíciles, pero pueden admitir que están equivocadas y ajustar su comportamiento cuando sea necesario.

¿Siempre has sido fundamentalmente correcto en los diseños de software que propusiste?

¡Sí, soy sobrehumano! Bueno, claro que no.

Cuando entrega un diseño que era fundamentalmente incorrecto, tiende a perder el respeto de los demás miembros del equipo.

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

Todos cometen errores. Algunas soluciones resultan ser buenas, otras malas, la mayoría algo intermedio. Tanto los éxitos como los fracasos deben ser tomados como una lección, por usted y por el resto del equipo.

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

Le pasa a todo el mundo. Lo principal es aprender de sus errores y tratar de no dejar que 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 SQL hechas a mano. Así que elegí lo que en ese momento parecía uno de los más fáciles de comenzar. Tampoco tenía mucha experiencia con los DAL. Bueno, después de resolver algunos problemas, me preguntaba por qué algunas consultas demoraban demasiado y descubrí que SubSonic estaba retirando tablas enteras sin una buena razón.

Entonces, le dije a mi jefe, le expliqué que había cometido un error y le di mi plan para arreglarlo. Mi jefe, por supuesto, no estaba entusiasmado con el hecho de que cometiera un error bastante grande que requería unos días de pura migración. 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 propuse migrar y nos aseguramos de que funcionara con nuestros requisitos y que no desplegara 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.

Entonces, 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 de nuevo.
5. ¡Arreglalo!

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

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

Esto es un asunto de concurso de meadas geek, y no es una buena situación para estar. Nadie siempre tiene la razón, y no hay nada de qué avergonzarse si alguien encuentra una mejor manera de hacerlo, o si encuentran un problema con el como lo hiciste.

Debe deshacerse emocionalmente de su solución y dedicar su tiempo a tratar de encontrar la mejor solución, entonces puede estar satisfecho cuando se resuelve el problema, incluso si alguien más lo resuelve.

Hay muchas cosas que no estás diciendo en tu pregunta. No puedo decir cuál es su configuración para "dar un diseño". ¿Es 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 sus compañeros sospechen de usted 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 alguien más. Dependiendo de la complejidad o la importancia crítica, es posible que deba analizarlo 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 esté repitiendo los mismos errores una y otra vez. Las revisiones por pares hacen que sea más fácil detectar errores temprano.

Si estás tratando de ser un codificador solitario en un entorno de equipo, estás cometiendo el pecado (casi imperdonable) de pensar que eres lo suficientemente perfecto como para no necesitar la ayuda de nadie más. El hecho de que sea un entorno de equipo demuestra que el problema es lo suficientemente grande como para que ninguna persona lo entienda todo. Las personas tienen que hablar entre sí o los errores levantarán sus cabezas demasiado cerca de la liberación (o después de la liberación).

Siempre he hecho una distinción entre, por un lado, buenas o malas decisiones; y en las otras 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 la 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 haber sido correcta; y viceversa con decisiones incorrectas.

A menudo se ha dicho 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 tomador de decisiones invierte en la decisión y trata de justificar retrospectivamente la decisión, o demostrar 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 avancé más con aquellas decisiones que eran incorrectas. Espero que muy pocas de mis decisiones hayan sido malas, pero parte del problema con las malas decisiones de uno es reconocer que una decisión fue mala y aceptar las lecciones a menudo desagradables que surgen de ellas.

Mientras no sean el " quarterback de lunes por la mañana ". No tengo uso para alguien que se sienta a través de todas las discusiones de diseño sin decir nada solo para afirmar que sabía que no funcionaría después del hecho. Debes ser capaz de aceptar las críticas incluso si no se ponen en un contexto constructivo.

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

Puede que sepan algo que tú no, pero no lo sabrán todo. Supéralo, ponte a trabajar y haz algo. Permítales perder el tiempo pensando que son tan listos.

¿ Siempre he proporcionado un buen diseño? ¡No! Me esfuerzo por hacerlo, me esfuerzo por mejorar, pero con cada proyecto sucesivo, lo que parece que siempre puedo hacer es mirar hacia atrás a lo que he hecho antes y encogerme de alguna manera por haber perdido la marca.

En cuanto a alguien que ha propuesto un diseño menos que estelar, no lo consideraría en contra de esa persona si esa persona demostrara que está dispuesto a aprender del error y está abierto a las críticas. Si veo evidencia de que la persona se esfuerza de manera similar por mejorar y tiene la capacidad de hacerlo, entonces una mala propuesta de diseño es solo una oportunidad de aprendizaje.

Le sucede a todos de vez en cuando, así que lo mejor que puedes hacer es descubrir por qué el diseño estaba mal y aprender de eso. Si se trata de una falta de conocimiento, es probable que la falla del diseño le brinde algunos conocimientos nuevos 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 atrapar con un nuevo equipo / entorno.

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

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

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

Todo lo que puede hacer es admitir que estaba equivocado, dar crédito a quien tenía razón y esforzarse por escuchar mejor e investigar mejor las 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 (reutilización de código y solo necesita cambiar las reglas comerciales en un solo lugar) sin darse cuenta de que algunas importaciones tendrán millones de registros y demorarían días en completarse terminar.) Aprenda de eso y considere esas cosas en el futuro.

Habrá siempre haber errores. Errar es ser un programador. Continúe aprendiendo de otros en Internet y especialmente de sus compañeros de trabajo. La única vergüenza aquí sería darse por vencido o enterrar la cabeza en la arena cuando se trata de problemas como este de aquí en adelante.

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

Si no está seguro de que su idea se base en una base sólida, debe discutirla con algunos colegas de confianza antes de proponerla a toda la empresa o departamento. De hecho, incluso si ESTÁS seguro, aún debes discutirlo con las personas con las que trabajas y que tienen más probabilidades de conocerte mejor. Te ayudarán a detectar problemas desde el principio.

Nos pasa a todos a veces. Usa el primer diseño como prototipo. Averigüe exactamente qué funcionó y qué no funcionó 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 . Puedes ver ese comportamiento en casi todas las profesiones: si cometes un error y les gusta "categorizarte" en ciertas cosas, es para siempre. Es un comportamiento social. Incluso las personas inteligentes e inteligentes tenderán a seguir a todos.

Permíteme darte un ejemplo que no tiene nada que ver con la programación: en mi trabajo anterior, me había olvidado de 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, cuando hay algo sucio en el fregadero, soy yo (quién más podría ser).

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

¿Me dices que quieres comentarios honestos? 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 busca otro trabajo, porque nunca cambiarás este tipo de comportamiento social (estúpido, debo confesar) .

La clave es cómo declara su caso y qué tipo de cambios realiza. Si afirma ser un gurú de la programación que no hace nada malo y que es más increíble que Jon Skeet, es muy probable que en algún momento lo desanimen. La clave es cómo presentar sus soluciones para poder 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 staticen una aplicación web donde trabajé una vez. No sabía qué tan malo sería que esa instancia persistiera y se compartiera entre 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 tengan que hacer correcciones importantes. También estuve 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 escribir código vulnerable a las inyecciones de SQL en 1998 cuando estaba escribiendo un código de encontrar 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 una especie de espada de dos filos aquí, así es como veo ese tercer comentario, además de ser una forma en que soy a veces también. Lo malo es ver que hay todos estos errores y que nada es correcto. Lo bueno es que al obtener lo mejor que puede, podría estar cumpliendo si no superando las expectativas de los demás sobre usted. La mejora continua bien podría ser la forma en que la PC ve el perfeccionismo y, si se mantiene con moderación, lo veo 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á arreglando algo o ¿es bueno que quieras ser tan bueno que preferirías no hacer nada más hasta que eso sea perfecto? La práctica puede ser útil para ayudar a encontrar los patrones para hacer mejor el trabajo. Sin embargo,