Crie falhas e lide com a humilhação [fechada]

Você sempre foi fundamentalmente correto nos projetos de software que propôs? Quando você distribui um projeto que estava fundamentalmente errado, você tende a perder o respeito dos colegas de equipe. Não importa o que você faça depois disso, você acaba sendo checado por tudo o que propõe após esse incidente. Isso é especialmente pior quando você é novo em uma equipe e eles não conhecem seu passado, onde você teve boas histórias de sucesso.

Talvez o motivo pelo qual você deu um mau design tenha sido devido à falta de experiência ou conhecimento ou de ambos nessa área. Como você que enfrentou essa situação lidou com isso? Isso é algo único em sua carreira ou acontece dentro e fora? Alguém coloca isso para trás ou, em tal situação, precisa procurar uma nova linha de trabalho? Algum feedback honesto, por favor ...

Obrigado.

Uma vez, o vice-presidente da Fortune 500 custou à empresa 1 milhão de dólares com uma má decisão comercial. Quando ele renunciou ao CEO, a resposta que recebeu foi: "Acabei de investir um milhão de dólares em sua educação e agora você está tentando sair? Não aceito".

Eu me canso de gerentes e outros trabalhadores que rapidamente culpam um erro de alguém ser um novato ou assumir que eles são incompetentes. Existe apenas uma maneira de se tornar um bom designer e isso é f @ $% um pouco acima. Não me importo se meus funcionários cometem um erro, me importo se eles cometem o mesmo várias vezes. A questão é: quão humilde e quão educável você é? Quando alguém lhe apresenta seu erro, você se defende primeiro ou os ouve? Se você é um dos caras raros que pode engolir seu orgulho e aprender com ele, vale a pena se apegar a ele. Quem você perde o respeito por cometer um erro uma vez, não é alguém que merece o seu respeito.

Eu, pessoalmente, tive que reescrever os dois primeiros projetos que desenhei pelo menos duas vezes, mas você sabe o que? Eu aprendi muito e, embora meus empregadores estivessem perturbados na época, isso foi rapidamente compensado pela eficiência que ganhei ao longo do tempo por estar disposto a aprender com meus erros.

Quanto ao aspecto da humilhação e como me recuperar, tenho dois conselhos. Primeiro, as pessoas esquecem com o tempo. Além disso, quando alguém mais estiver focado neles, eles também estragarão. Então tudo será igual novamente. Segundo, não seja idiota para os outros quando eles cometem erros honestos, aprendendo,. Na verdade, você deve incentivá-los, a menos que eles realmente precisem de um chute firme na bunda. Com o tempo, você pode ajudar a mudar a cultura de sua equipe lembrando como se sentiu quando cometeu um erro honesto. Você acabará inspirando as pessoas a serem melhores programadores, designers e seres humanos.

Faço isso há muito tempo (mais de 15 anos) e ainda não entendi direito da primeira vez. Os melhores designs surgem de um processo iterativo e colaborativo. Quando você trabalha em um design há um tempo, é fácil ficar preso ao pensar que é a única maneira de fazê-lo. Uma nova perspectiva é útil para ver o que você sente falta.

Para que isso funcione, a equipe precisa confiar um no outro. Você não pode ter medo de mostrar às pessoas um design que pode ter falhas e precisa ser capaz de aceitar críticas ao design. Por sua vez, o restante da equipe precisa entender que as falhas em um design não refletem o designer. É uma parte esperada do design. É também como os membros da equipe aprendem e melhoram: com seus próprios erros e com os erros dos outros.

Se você estiver em uma equipe disfuncional que não funciona assim, você tem duas opções:

1. tente consertar a equipe
2. encontre uma nova equipe (internamente ou em um novo funcionário).

Até onde eu sei, sempre fui fundamentalmente defensável . Isso não é exatamente a mesma coisa que estar fundamentalmente correto . Muitas vezes, as circunstâncias mudam entre o momento em que você toma a decisão 'x' e o tempo em que fica claro que 'x' foi a decisão errada em retrospectiva .

É como preparar seus impostos de renda nos EUA. Muitas pessoas pensam que deveria haver uma resposta. Não existe. Você tem sua opinião; seu contador tem a opinião dela; o IRS tem sua opinião.

Quando cometo erros, não perco o respeito de ninguém. (Até onde eu sei.) Acho que é porque, em parte, sempre admito meus próprios erros. (Na verdade, muitas vezes encontro meus próprios erros.) Além disso, quase todas as decisões de design significativas têm mais de uma pessoa assinando. Quaisquer erros nessas decisões são de propriedade do grupo, não inteiramente de uma única pessoa.

Quanto a admitir erros, acho que fica mais fácil à medida que você ganha competência e experiência. Na minha experiência, quanto mais novo você for projetar e desenvolver, menor a probabilidade de admitir um erro.

Isso acontece de vez em quando, e não deve atrapalhar sua carreira. Ninguém em uma posição de responsabilidade significativa invariavelmente toma decisões corretas. De fato, ninguém em posição de responsabilidade significativa invariavelmente toma decisões defensáveis.

Mas na maioria das vezes, você deve ser capaz de tomar decisões defensáveis ​​com base em informações incompletas. Como minha filha dizia: "Isso é ser pessoas".

Todo mundo às vezes erra as coisas. Erros são inevitáveis. Admita livremente quando estiver errado, aprenda com seus erros e mostre humildade, especialmente se você não estava convencido de que estava realmente errado.

"Humilhação" nunca deve acontecer. Não é provável que melhore o desempenho de uma pessoa.

Aqui na minha empresa, desenvolvemos uma cultura de respeito pelas pessoas que ainda estão dispostas a tomar decisões difíceis, mas que admitem estar erradas e ajustam seu comportamento quando necessário.

Você sempre foi fundamentalmente correto nos projetos de software que propôs?

Sim, sou um super-humano! Bem, claro que não.

Quando você distribui um projeto que estava fundamentalmente errado, você tende a perder o respeito dos colegas de equipe.

Não! Se isso acontecer, então há algo errado com o espírito de equipe.

Todos cometem erros. Algumas soluções acabam sendo boas, outras ruins, quase sempre algo entre elas. Tanto sucessos quanto fracassos devem ser tomados como lição, por você e pelo restante da equipe.

Os primeiros erros podem parecer ruins, mas depois que você cometeu centenas deles, é como parte do trabalho.

Isso acontece com todo mundo. O principal é aprender com seus erros e tentar não deixar isso acontecer novamente. Além disso, não deixe de admitir que foi um erro de sua parte. Por exemplo, uma vez cometi o erro de usar uma camada inferior de acesso a dados (SubSonic3). No momento em que tomei a decisão, estava apenas querendo me afastar das consultas SQL criadas manualmente. Por isso, escolhi o que na época parecia ser um dos mais fáceis de começar. Também não tinha muita experiência com DALs. Bem, depois de resolver alguns problemas, fiquei pensando por que algumas consultas estavam demorando um pouco demais e descobri que a SubSonic estava derrubando tabelas inteiras sem um bom motivo.

Então, eu disse ao meu chefe, expliquei que cometi um erro e dei a ele meu plano para consertá-lo. É claro que meu chefe não estava entusiasmado por eu cometer um erro bastante grande, exigindo alguns dias de pura migração. Mas ele também garantiu que eu não cometesse o mesmo erro novamente. Ele me fez criar um projeto de prova de conceito para a próxima camada de acesso a dados para a qual propus migrar e nos certificamos de que funcionaria com nossos requisitos e que não derrubasse tabelas inteiras. Em suma, foi uma boa experiência de aprendizado para mim e agora assegurarei que uma parte essencial do projeto atenda aos requisitos e não tenha grandes problemas.

Então, basicamente, o que você faz é o seguinte:

1. Admita que cometeu um erro
2. Faça um plano para corrigi-lo
3. Verifique se o seu plano realmente funcionará
4. Certifique-se novamente.
5. Consertá-lo!

Se você não tiver certeza de como consertá-lo, não tenha medo de incluir outros membros da equipe.

Uma última coisa, relaxe! Todo mundo comete erros. Pouquíssimas pessoas o aperfeiçoam da primeira vez

É uma coisa nerd de concurso de mijar, e não é uma boa situação. Ninguém está sempre certo e não há o que se envergonhar se alguém encontrar uma maneira melhor de fazê-lo ou se encontrar um problema com o do jeito que você fez.

Você precisa se desfazer emocionalmente de sua solução e gastar seu tempo tentando encontrar a melhor solução, para ficar satisfeito quando o problema for resolvido, mesmo que seja resolvido por outra pessoa.

Há muita coisa que você não está dizendo na sua pergunta. Não sei dizer qual é a sua configuração para "distribuir um design". É uma discussão inicial com um colega sobre sua abordagem planejada ou é a entrega do que você espera que seja o código final?

Se for o primeiro, não há razão para se sentir mal e nenhum motivo para suspeitar de você no futuro.

Se você está esperando até a entrega final para discutir seu projeto com outra pessoa, não os culpo por suspeitar de seu outro trabalho.

Todo mundo precisa discutir seu design com outra pessoa. Dependendo da complexidade ou criticidade, pode ser necessário discuti-lo com várias pessoas várias vezes. Todos podem cometer um erro, interpretar mal um requisito ou perder um caso especial.

Erros identificados cedo são mais fáceis e baratos de corrigir. Eles devem ser muito perdoáveis, a menos que você esteja repetindo os mesmos erros repetidamente. As revisões por pares facilitam a detecção de erros mais cedo.

Se você está tentando ser um codificador solitário em um ambiente de equipe, está cometendo o pecado (quase imperdoável) de pensar que é perfeito o suficiente para não precisar da ajuda de mais ninguém. O fato de ser um ambiente de equipe prova que o problema é grande o suficiente para que ninguém entenda tudo. As pessoas têm que conversar umas com as outras ou os erros elevarão suas cabeças muito perto do lançamento (ou após o lançamento).

Sempre fiz uma distinção entre, por um lado, boas ou más decisões; e por outras decisões corretas e incorretas. Uma boa decisão é aquela que, nas mesmas circunstâncias, com a mesma informação, você tomaria da mesma maneira; uma decisão ruim é aquela que você tomaria de maneira diferente. Uma decisão correta é aquela que, com o benefício da retrospectiva e informações adicionais, prova estar correta; e, inversamente, com decisões incorretas.

Tem sido dito frequentemente que a pessoa que não toma decisões incorretas nunca faz nada. Decisões incorretas são a maneira como se aprende. As decisões ruins são muitas vezes exacerbadas porque o tomador de decisões investe na decisão e tenta justificar retrospectivamente a decisão ou provar que foi uma boa decisão, afinal (o encobrimento é sempre mais prejudicial do que a decisão original).

A maioria das decisões de design que tomei se mostrou correta, mas aprendi mais e avancei mais com as decisões incorretas. Espero que muito poucas de minhas decisões tenham sido más, mas parte do problema com as más decisões é reconhecer que uma decisão foi ruim e aceitar as lições frequentemente desagradáveis ​​decorrentes delas.

Contanto que eles não sejam o " Monday Morning Quarterback ". Não tenho utilidade para alguém que passa por todas as discussões de design sem dizer nada, apenas para afirmar que sabia que não funcionaria depois do fato. Você deve ser capaz de receber críticas, mesmo que não sejam colocadas em um contexto construtivo.

Provavelmente, um dos melhores recursos do site SO é ser capaz de assumir riscos e propor uma solução incerta. É assim que você aprende. Passar a vida com um monte de porcaria na cabeça que está errado, mas você nunca foi informado sobre o conflito, é uma verdadeira ignorância.

Eles podem saber algo que você não sabe, mas não sabem tudo. Supere isso, comece a trabalhar e faça algo. Deixe-os perder tempo pensando que são tão malditamente inteligentes.

Eu sempre forneci um bom design? Não! Eu me esforço para fazê-lo, me esforço para melhorar, mas a cada projeto sucessivo, o que aparentemente posso sempre fazer é olhar para o que já fiz antes e me arrepender de como errei a marca de alguma maneira.

Quanto a alguém que propôs um projeto menos do que estelar, eu não a oporia se essa pessoa demonstrasse que estava disposta a aprender com o erro e estava aberta às críticas. Se vejo evidências de que a pessoa está se esforçando para se tornar melhor e tem a capacidade de fazê-lo, uma proposta de design ruim é apenas uma oportunidade de aprendizado.

Isso acontece com todo mundo de vez em quando, então a melhor coisa a fazer é descobrir por que o design estava errado e aprender com isso. Se houver falta de conhecimento, esperamos que a falha no design traga novos conhecimentos que você poderá usar na próxima vez. Não deixe que isso desencoraje você, todo mundo passa por isso em algum momento. É a melhor maneira de ganhar experiência e se conectar com uma nova equipe / ambiente.

Isso acontecerá frequentemente. Nossa indústria está mudando tão rapidamente que as chances de nunca estar errado são efetivamente zero.

No entanto, você pressionou o mau design por suas objeções? Pode ser por isso que eles estão exagerando.

Se o erro foi enorme, é claro que levará tempo para recuperar o respeito. Se um de seus colegas de trabalho o levou em uma direção ruim e criou problemas para toda a equipe, você não precisaria que ele se provasse mais no curto prazo?

Tudo o que você pode fazer é admitir que estava errado, dar crédito a quem estava certo e se esforçar para ouvir melhor e pesquisar opções melhor no futuro.

O que você não considerou que cometeu um erro no design? (Exemplo não aleatório - projete um processo de importação para usar o serviço da Web existente que é executado linha por linha (reutilização de código e apenas necessidade de alterar as regras de negócios em um único local), sem perceber que algumas importações terão milhões de registros e levariam dias para serem processados. final). Aprenda com ele e considere essas coisas no futuro.

Haverá sempre ser erros. Errar é ser um programador. Continue aprendendo com outras pessoas na internet e principalmente com seus colegas de trabalho. A única vergonha aqui seria desistir ou enterrar a cabeça na areia quando se trata de questões como essa daqui em diante.

Coloque isso para trás, abaixe a cabeça e faça o seu melhor. Se você é um bom programador, irá brilhar com seus erros.

Se você não tem certeza de que sua ideia se baseia em uma base sólida, deve discuti-la com alguns colegas de confiança antes de propor para toda a empresa ou departamento. De fato, mesmo se você tiver certeza, ainda deve discuti-lo com as pessoas com quem trabalha e com maior probabilidade de conhecê-lo melhor. Eles ajudarão você a detectar problemas desde o início.

Isso acontece com todos nós às vezes. Use o primeiro design como um protótipo. Descubra exatamente o que funcionou e o que não funcionou e por quê. Então você pode escrever um produto final muito melhor.

Não tente se justificar ou ficar na defensiva. Admita o erro e siga em frente.

O problema fundamental não parece ser explicado: este é um problema social . Você pode ver esse comportamento em quase todas as profissões: se você cometer um erro, e eles gostarem de "categorizar" você em uma determinada coisa, é para sempre. É um comportamento social. Até pessoas inteligentes e inteligentes tendem a seguir todos.

Deixe-me dar um exemplo que não tem nada a ver com programação: no meu trabalho anterior, eu havia me esquecido de lavar a louça, digamos uma ou duas vezes. Desde então, todos os trabalhadores pensaram que eu sou o tipo de homem que nunca lava a louça. E agora, assim que há uma coisa suja na pia, sou eu (quem mais poderia ser).

É o mesmo em todo lugar: esse é um comportamento social , não importa que tipo de problema possa ser.

Você me disse que quer um feedback honesto? A única solução é sair para outro trabalho. Se todas as pessoas da equipe acharem que você não é bom no seu trabalho, isso não mudará tão cedo, desculpe-o assim. Portanto, procure outro emprego, porque você nunca mudará esse tipo de comportamento social (estúpido, devo confessar) .

A chave é como você declara seu caso e que tipos de alterações você faz. Se você afirma ser um guru da programação que não faz nada errado e é mais impressionante do que Jon Skeet, é bem provável que, em algum momento, você seja dispensado por isso. A chave é como você apresenta suas soluções para poder mostrar que essa é uma solução razoável para o problema, e não a solução perfeita que nem deveria ser verificada.

Meu melhor exemplo seria descobrir os efeitos colaterais de ter uma classe staticem um aplicativo Web em que trabalhei uma vez. Eu não sabia o quanto seria ruim ter essa instância persistente e ser compartilhada com todos os usuários do aplicativo, mas aprendi com ele e me recuperei com o tempo. Às vezes, pode ser que algo seja encontrado e as principais correções precisam ser feitas. Também estive naquele campo em que tive que vasculhar um monte de VBScript para reduzir as concatenações de cadeias que estavam causando problemas de memória em que trabalhei uma vez. Ainda me lembro de escrever um código vulnerável a injeções de SQL em 1998, quando eu escrevia um código de localização de cliente que precisava gerar dinamicamente o SQL, pois eu tinha ~ 20 campos opcionais nessa parte do aplicativo.

O perfeccionismo pode ser um pouco de uma faca de dois gumes aqui, e é assim que vejo o terceiro comentário, além de ser uma maneira que às vezes também sou. O ruim é ver que existem todos esses erros e nada está certo. O bom é que, ao obter o melhor que puder, você pode estar atendendo, se não superando, as expectativas dos outros. A melhoria contínua pode muito bem ser a maneira do PC enxergar o perfeccionismo e, se mantida com moderação, vejo isso como uma coisa boa. Por todos os erros cometidos, seu código entra em produção? Isso faz o trabalho? Esses são pontos a serem ponderados, assim como se alguém está sempre consertando algo nele ou é bom que você queira tanto ser tão bom que prefere não fazer mais nada até que isso seja perfeito? A prática pode ser útil para ajudar a encontrar os padrões para fazer o trabalho melhor. Contudo,