Les défauts de conception et la gestion de l'humiliation [fermé]

Avez-vous toujours été fondamentalement correct dans les conceptions logicielles que vous avez proposées? Lorsque vous distribuez des dessins fondamentalement faux, vous avez tendance à perdre le respect de vos collègues. Peu importe ce que vous faites après cela, vous finissez par être vérifié pour tout ce que vous proposez après cet incident. C’est particulièrement pire lorsque vous débutez dans une équipe et que celle-ci ne connaît pas votre passé, où vous avez eu de bons succès.

Peut-être que la raison pour laquelle vous avez mal agi est dû à un manque d'expérience ou de connaissances, ou aux deux, dans ce domaine. Comment avez-vous affronté une telle situation? Est-ce que c'est comme une chose unique dans votre carrière ou est-ce que cela se produit de temps en temps? Est-ce qu'on met cela derrière ou faut-il, dans une telle situation, chercher un nouveau travail? Quelques commentaires honnêtes s'il vous plaît ...

Je vous remercie.

Une fois, le vice-président d’une fortune 500 a coûté à la société 1 million de dollars avec une mauvaise décision d’entreprise. Lorsqu'il a remis sa démission au PDG, il a reçu la réponse suivante: "Je viens d'investir un million de dollars dans votre éducation et maintenant vous essayez de partir? Je n'accepte pas."

J'en ai assez des gestionnaires et des autres travailleurs qui accusent rapidement une erreur d'être une recrue ou de présumer qu'elle est incompétente. Il n’ya qu’une façon de devenir un bon designer: c’est f @ $% un peu plus. Peu m'importe que mes employés fassent une erreur, je m'inquiète s'ils font le même plusieurs fois. La question est de savoir à quel point vous êtes humble et enseignable. Quand quelqu'un vous présente votre erreur, vous défendez-vous d'abord ou écoutez-vous? Si vous êtes l’un des rares types à pouvoir avaler sa fierté et à en tirer des leçons, alors vous valez le coup. Toute personne à qui vous perdez le respect pour avoir commis une erreur n’est pas quelqu'un qui mérite votre respect.

J'ai personnellement dû réécrire au moins deux fois les deux premiers projets que j'ai conçus, mais vous savez quoi? J'ai appris énormément de choses et, bien que mes employeurs aient été perturbés à l'époque, cela a été rapidement compensé par l'efficacité que j'ai gagnée au fil du temps en étant disposé à apprendre de mes erreurs.

En ce qui concerne l’humiliation et la façon de récupérer, j’ai deux conseils. Tout d'abord, les gens oublient avec le temps. En outre, lorsque quelqu'un d'autre est sous le feu des projecteurs, il se trompe également. Alors tout sera égal à nouveau. Deuxièmement, ne soyez pas un abruti pour les autres quand ils commettent des erreurs, des apprentissages honnêtes. En fait, vous devriez les encourager à moins qu’ils n’aient vraiment besoin d’un coup de pied ferme dans le cul. Au fil du temps, vous pouvez contribuer à changer la culture de votre équipe en vous souvenant de ce que vous avez ressenti lorsque vous avez commis une erreur honnête. Vous finirez par inspirer les gens à devenir de meilleurs programmeurs, concepteurs et êtres humains.

Je fais cela depuis longtemps (15 ans et plus) et je ne comprends toujours pas bien la première fois. Les meilleurs designs proviennent d'un processus itératif et collaboratif. Lorsque vous travaillez sur un design depuis un certain temps, il est facile de penser que c'est la seule façon de le faire. Une nouvelle perspective est utile pour voir les choses qui vous manquent.

Pour que cela fonctionne, l'équipe doit se faire confiance. Vous ne pouvez pas avoir peur de montrer aux gens un dessin qui pourrait être imparfait, et vous devez être capable d’accepter les critiques du dessin. À son tour, le reste de l'équipe doit comprendre que les défauts d'un dessin ne reflètent pas le concepteur. C'est une partie attendue de la conception. C'est également ainsi que les membres de l'équipe apprennent et s'améliorent: à partir de leurs propres erreurs et des erreurs des autres.

Si vous êtes dans une équipe dysfonctionnelle qui ne fonctionne pas comme cela, vous avez deux options:

1. essayer de réparer l'équipe
2. trouver une nouvelle équipe (en interne ou chez un nouvel employeur).

Autant que je sache, j'ai toujours été fondamentalement défendable . Ce n'est pas tout à fait la même chose que d'être fondamentalement correct . Les circonstances changent souvent entre le moment où vous devez prendre la décision «x» et le moment où il devient clair que «x» était la mauvaise décision prise a posteriori .

C'est un peu comme préparer votre impôt sur le revenu américain. Beaucoup de gens pensent qu'il est censé y avoir une réponse. Il n'y a pas. Vous avez votre opinion votre comptable fiscaliste a son opinion; l'IRS a leur avis.

Quand je fais des erreurs, je ne perds le respect de personne. (Autant que je sache.) Je pense que c'est parce que, en partie, j'admets toujours mes propres erreurs. (En fait, je trouve souvent mes propres erreurs.) De plus, presque toutes les décisions de conception importantes ont plus d'une personne qui les approuve. Toutes les erreurs dans ces décisions appartiennent au groupe et non à une seule personne.

En ce qui concerne les erreurs, je pense que cela devient plus facile à mesure que vous gagnez en compétence et en expérience. D'après mon expérience, plus vous êtes novice dans la conception et le développement, moins vous risquez d'admettre une erreur.

Cela se produit par intermittence et cela ne devrait pas faire dérailler votre carrière. Personne dans une position de responsabilité significative ne prend invariablement les bonnes décisions. En fait, personne dans une position de responsabilité significative ne prend invariablement des décisions défendables.

Mais la plupart du temps, vous devriez être capable de prendre des décisions défendables sur la base d'informations incomplètes. Comme ma fille le dirait: "C'est juste être des gens."

Tout le monde se trompe parfois. Les erreurs sont inévitables. Admettez librement quand vous vous trompez, tirez les leçons de vos erreurs et montrez votre humilité, surtout si au départ vous n'étiez pas convaincu que vous aviez réellement tort.

"Humiliation" ne devrait jamais, jamais arriver. Il n’est pas susceptible d’améliorer la performance d’une personne.

Ici, au sein de mon entreprise, nous avons développé une culture de respect pour les personnes qui sont toujours disposées à prendre le risque de prendre des décisions difficiles, mais peuvent admettre avoir tort et ajuster leur comportement en cas de besoin.

Avez-vous toujours été fondamentalement correct dans les conceptions logicielles que vous avez proposées?

Oui, je suis un surhumain! Bien sûr que non.

Lorsque vous distribuez des dessins fondamentalement faux, vous avez tendance à perdre le respect de vos collègues.

Non! Si cela se produit, alors il y a quelque chose qui cloche dans l'esprit d'équipe.

Tout le monde fait des erreurs. Certaines solutions s'avèrent bonnes, d'autres mauvaises, la plupart des solutions intermédiaires. Les succès et les échecs doivent être pris comme une leçon par vous et par le reste de l'équipe.

Les premières erreurs peuvent sembler déplorables, mais une fois que vous en avez commis des centaines, cela fait partie du travail.

Ça arrive à tout le monde. L'essentiel est d' apprendre de vos erreurs et d'essayer de ne pas le laisser se reproduire. Assurez-vous également que c'est une erreur de votre part. Par exemple, une fois, j’ai commis l’erreur d’utiliser une couche d’accès aux données inférieure (SubSonic3). Au moment où j'ai pris la décision, je voulais simplement m'éloigner des requêtes SQL conçues à la main. J'ai donc choisi ce qui, à l'époque, semblait être l'un des plus faciles à démarrer. Je n'avais pas trop d'expérience avec les DALs non plus. Eh bien, après avoir résolu quelques problèmes, je me demandais pourquoi certaines requêtes prenaient un peu trop longtemps et trouvais que SubSonic abolissait des tables entières sans raison valable.

Alors, j’ai dit à mon patron, j’ai fait une erreur et lui ai dit que j’avais un plan pour la réparer. Bien sûr, mon patron n’était pas enthousiasmé par le fait que j’ai commis une grave erreur nécessitant quelques jours de pure migration. Mais il s'est également assuré que je ne commettais plus la même erreur. Il m'a fait créer un projet de validation de concept pour la prochaine couche d'accès aux données que je proposais de migrer et nous nous sommes assurés que cela fonctionnerait avec nos exigences et que cela ne réduirait pas l'intégralité des tables. Dans l’ensemble, c’est une bonne expérience d’apprentissage pour moi et je vais maintenant veiller à ce qu’un élément clé du projet réponde aux exigences et ne pose pas de gros problèmes.

Donc, fondamentalement, ce que vous faites est le suivant:

1. Admettez que vous avez commis une erreur
2. Faites un plan pour y remédier
3. Assurez-vous que votre plan fonctionnera réellement
4. Assurez-vous encore.
5. Répare le!

Si vous ne savez pas comment le résoudre, n’ayez pas peur de faire participer les autres membres de l’équipe.

Une dernière chose, détendez-vous! Tout le monde fait des erreurs. Très peu de gens l'obtiennent parfaitement la première fois

C’est un concours geek de pisse, et ce n’est pas une bonne situation. Personne n’a toujours raison, et il n’ya pas de quoi avoir honte si quelqu'un trouve un meilleur moyen de le faire, ou s’il trouve un problème avec le comme vous l'avez fait.

Vous devez vous dépouiller émotionnellement de votre solution et passer votre temps à essayer de trouver la meilleure solution. Vous pourrez alors être ravi lorsque le problème sera résolu, même s'il est résolu par quelqu'un d'autre.

Il y a beaucoup de choses que vous ne dites pas dans votre question. Je ne peux pas dire quel est votre réglage pour "donner un dessin". S'agit-il d'une discussion initiale avec un pair sur votre approche planifiée ou s'agit-il de la fourniture de ce que vous espérez être le code final?

Si c'est le cas, il n'y a aucune raison de vous sentir mal et aucune raison pour que vos pairs vous soupçonnent à l'avenir.

Si vous attendez la livraison finale pour discuter de votre projet avec quelqu'un d'autre, je ne le reproche pas à moi de se méfier de votre autre travail.

Tout le monde doit discuter de leur conception avec quelqu'un d'autre. En fonction de la complexité ou de la criticité, vous devrez peut-être en discuter avec plusieurs personnes à plusieurs reprises. Tout le monde peut faire une erreur, mal comprendre une exigence ou rater un cas particulier.

Les erreurs identifiées tôt sont plus faciles et moins coûteuses à corriger. Ils devraient être très faciles à pardonner à moins que vous ne répétiez les mêmes erreurs, encore et encore. Les examens par les pairs facilitent la détection précoce des erreurs.

Si vous essayez d'être un seul codeur dans un environnement d'équipe, vous commettez le péché (presque impardonnable) de penser que vous êtes suffisamment parfait pour que vous n'ayez besoin de l'aide de personne. Le fait qu'il s'agisse d'un environnement d'équipe prouve que le problème est suffisamment important pour que personne ne puisse tout comprendre. Les gens doivent se parler ou des erreurs se dresseraient trop près de la libération (ou après la libération).

J'ai toujours fait la distinction entre, d'une part, les bonnes et les mauvaises décisions; et sur les autres décisions correctes et incorrectes. Une bonne décision est celle qui, dans les mêmes circonstances, avec les mêmes informations, vous prendriez de la même manière; une mauvaise décision est une décision que vous prendriez différemment. Une décision correcte est une décision qui, avec le recul et des informations supplémentaires, s'avère être correcte; et inversement avec des décisions incorrectes.

On a souvent dit que la personne qui ne prend pas de décisions erronées ne fait jamais rien. Les décisions incorrectes sont la façon dont on apprend. Les mauvaises décisions sont souvent exacerbées par le fait que le décideur s'investit dans la décision et tente de justifier la décision rétrospectivement ou de prouver qu'il s'agissait d'une bonne décision (le camouflage est toujours plus dommageable que la décision initiale).

La plupart des décisions de conception que j’ai prises s’avèrent correctes, mais j’ai beaucoup appris et avancé plus avec des décisions incorrectes. J'espère que très peu de mes décisions ont été de mauvaises décisions, mais le problème des mauvaises décisions consiste en partie à reconnaître qu'une décision était mauvaise et à accepter les leçons souvent déplaisantes qui en découlent.

Tant qu'ils ne sont pas les " lundi matin Quarterback ". Je n'ai aucune utilité pour quelqu'un qui assiste à toutes les discussions sur la conception sans rien dire, mais simplement pour prétendre qu'il savait que cela ne fonctionnerait pas après le fait. Vous devez pouvoir accepter les critiques même si elles ne sont pas placées dans un contexte constructif.

L’une des meilleures caractéristiques du site SO est probablement de pouvoir prendre un risque et de proposer une solution incertaine. C'est comme ça que tu apprends. Passer à travers la vie avec un tas de merde dans la tête qui ne va pas, mais on ne vous a jamais dit que le scandale, c'est de la vraie ignorance.

Ils peuvent savoir quelque chose que vous ne connaissez pas, mais ils ne sauront pas tout. Passez à autre chose, mettez-vous au travail et faites quelque chose. Laissez-les perdre du temps en pensant qu'ils sont si intelligents.

Ai-je toujours fourni un bon design? Non! Je m'efforce de le faire, je m'efforce de m'améliorer, mais avec chaque projet successif, ce que je peux apparemment toujours faire est de regarder en arrière à ce que j'ai déjà fait et de grincer des dents.

En ce qui concerne quelqu'un qui a proposé un design moins que stellaire, je ne le blâmerais pas si cette personne démontrait qu'elle était disposée à tirer les leçons de l'erreur et était ouverte aux critiques. Si je vois des preuves que la personne s'efforce de la même manière de s'améliorer et a l'aptitude à le faire, alors une mauvaise proposition de conception ne constitue qu'une opportunité d'apprentissage.

Cela arrive à tout le monde de temps en temps, alors la meilleure chose à faire est de comprendre pourquoi la conception était fausse et d'en tirer des leçons. S'il s'agit d'un manque de connaissances, l'échec de la conception vous apportera de nouvelles connaissances que vous pourrez utiliser la prochaine fois. Ne laissez pas cela vous décourager, tout le monde passe à travers cela à un moment donné. C'est le meilleur moyen d'acquérir de l'expérience et de rattraper une nouvelle équipe / un nouvel environnement.

Cela arrivera souvent. Notre industrie évolue si rapidement que les chances de ne jamais se tromper sont nulles.

Cependant, avez-vous repoussé le mauvais dessin au détriment de leurs objections? Cela pourrait être la raison pour laquelle ils réagissent de manière excessive.

Si l'erreur était massive, il faudra évidemment du temps pour regagner le respect. Si l'un de vos collègues vous prenait dans une mauvaise direction et créait des problèmes pour toute l'équipe, n'avez-vous pas besoin de lui pour faire ses preuves à court terme?

Tout ce que vous pouvez faire, c'est admettre que vous avez eu tort, rendre hommage à celui qui a eu raison et vous efforcer d'écouter mieux et de mieux rechercher les options à l'avenir.

Qu'est-ce que vous n'avez pas considéré comme une erreur dans la conception? (Exemple non aléatoire - concevez un processus d'importation pour utiliser le service Web existant qui s'exécute ligne par ligne (réutilisation du code et nécessitant uniquement de modifier les règles de gestion à un seul endroit) sans se rendre compte que certaines importations comporteront des millions terminer.) Apprendre et considérer ces choses à l’avenir.

Il y aura toujours des erreurs. Se tromper, c'est être programmeur. Continuez à apprendre des autres sur Internet et en particulier de vos collègues. La seule honte ici serait d'abandonner ou de vous enterrer la tête dans le sable quand il s'agit de problèmes de ce genre à partir de maintenant.

Mets-le derrière toi, baisse la tête et fais de ton mieux. Si vous êtes un bon programmeur, vous ferez ressortir vos erreurs.

Si vous n'êtes pas certain que votre idée repose sur des bases solides, vous devez en discuter avec quelques collègues de confiance avant de la proposer à l'ensemble de l'entreprise ou du service. En fait, même si vous êtes certain, vous devriez quand même en discuter avec les personnes avec qui vous travaillez et qui sont le plus susceptibles de vous connaître le mieux. Ils vous aideront à détecter les problèmes dès le début.

Cela nous arrive tous parfois. Utilisez le premier dessin comme prototype. Découvrez exactement ce qui a fonctionné et ce qui n'a pas fonctionné et pourquoi. Ensuite, vous pouvez écrire un produit final bien meilleur.

N'essayez pas de vous justifier ou de vous mettre sur la défensive. Admettez l'erreur et avancez.

Le problème fondamental ne semble pas être expliqué: c'est un problème social . Vous pouvez voir un tel comportement dans presque toutes les professions: si vous faites une erreur et qu'ils aiment vous "catégoriser" dans certaines choses, c'est pour toujours. C'est un comportement social. Même les personnes intelligentes auront tendance à suivre tout le monde.

Permettez-moi de vous donner un exemple qui n'a rien à voir avec la programmation: dans mon travail précédent, j'avais oublié de laver ma vaisselle une ou deux fois. Depuis lors, tous les travailleurs ont pensé que j'étais le genre d'homme qui ne fait jamais la vaisselle. Et maintenant, dès qu'il y a quelque chose de sale dans l'évier, c'est moi (qui d'autre pourrait-il être).

C'est la même chose partout: c'est un comportement social , quel que soit le type de problème que cela puisse être.

Vous me dites que vous voulez des commentaires honnêtes? La seule solution est de quitter pour un autre emploi. Si tous les membres de l'équipe pensent que vous n'êtes pas bon dans votre travail, cela ne changera pas de sitôt, désolé de le dire ainsi. Alors cherchez un autre emploi, car vous ne changerez jamais ce genre de comportement social (stupide, je dois l'avouer) .

La clé est de savoir comment énoncer votre cas et quels types de changements apportez-vous. Si vous prétendez être un gourou de la programmation qui ne se trompe pas et qui est plus génial que Jon Skeet, il est fort probable que vous serez éliminé à un moment donné pour cela. La clé est de savoir comment présentez-vous vos solutions afin de pouvoir démontrer qu'il s'agit d'une solution raisonnable au problème plutôt que de la solution parfaite qui ne devrait même pas être vérifiée.

Mon meilleur exemple serait de découvrir les effets secondaires d'un cours staticdans une application Web sur laquelle j'ai déjà travaillé. Je ne savais pas à quel point il serait désagréable qu'une instance persiste et soit partagée par tous les utilisateurs de l'application, mais j'en ai tiré des enseignements et récupéré à temps. Parfois, il se peut que quelque chose soit trouvé et que des corrections majeures soient nécessaires. J'ai également été dans ce camp où j'ai dû passer au crible une série de VBScript afin de réduire les concaténations de chaînes qui posaient des problèmes de mémoire sur lesquels j'avais déjà travaillé. Je me souviens même d’avoir écrit du code vulnérable aux injections SQL en 1998, alors que j’écrivais un morceau de code client qui devait générer dynamiquement le code SQL car j’avais environ 20 champs facultatifs dans cette partie de l’application.

Le perfectionnisme peut être un peu comme une épée à deux tranchants ici. C’est ainsi que je vois ce 3ème commentaire et en même temps un comportement que je suis parfois. Le mal est de voir qu'il y a toutes ces erreurs et que rien n'est jamais juste. L’avantage, c’est qu’en obtenant le meilleur que vous pouvez, vous pourriez bien rencontrer, voire dépasser les attentes des autres. L’amélioration continue pourrait bien être la façon pour le PC de percevoir le perfectionnisme et, si elle est conservée avec modération, je considère cela comme une bonne chose. Pour toutes les erreurs commises, votre code entre-t-il en production? Fait-il le travail? Ce sont des points à considérer aussi bien que si quelqu'un est toujours en train de réparer quelque chose ou est-ce bien que vous souhaitiez être si bon que vous préfériez ne rien faire d'autre jusqu'à ce que ce soit parfait? La pratique peut être utile pour aider à trouver les schémas permettant de mieux faire le travail. cependant,