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

Uma vez, a vp de uma fortuna 500 custou à empresa 1 milhão de dólares com uma má decisão comercial. Quando ele entregou a sua demissão para a C.E.O, a resposta que ele recebeu foi: "Eu acabei de investir um milhão de dólares em sua educação e agora você está tentando ir embora? Eu não aceito".

Eu me canso dos gerentes e outros trabalhadores que são rápidos em culpar um erro em alguém ser um novato ou assumir que ele é incompetente. Há apenas uma maneira de se tornar um bom designer e isso é para f @ $% alguns para cima. Eu não me importo se meus funcionários cometem um erro, eu me importo se eles fazem o mesmo várias vezes. A questão é: quão humilde e educável você é? Quando alguém apresenta seu erro para você, você se defende primeiro ou os ouve? Se você é um dos caras raros que pode engolir seu orgulho e aprender com isso, então vale a pena esperar. Qualquer pessoa de quem você perder 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 eu projetei pelo menos duas vezes, mas sabe de uma coisa? Aprendi uma tonelada e, embora meus patrões 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 de humilhação e como recuperar, tenho dois conselhos. Primeiro, as pessoas esquecem com o tempo. Além disso, quando alguém tem os holofotes sobre eles, eles vão estragar também. Então tudo será igual novamente. Segundo, não seja um babaca para os outros quando eles cometem erros honestos e de aprendizado. Na verdade, você deve incentivá-los a menos que eles realmente precisem de um pontapé firme no rabo. Com o tempo, você pode ajudar a mudar a cultura de sua equipe, lembrando como se sentiu quando cometeu um erro honesto. Você acabará por inspirar as pessoas a serem melhores programadores, designers e seres humanos.

Estou fazendo isso há muito tempo (15 anos ou mais), e ainda não entendi direito na primeira vez. Os melhores designs surgem de um processo iterativo e colaborativo. Quando você está trabalhando em um projeto há algum tempo, é fácil ficar preso em pensar que é a única maneira que pode ser feito. Uma nova perspectiva é útil para ver as coisas que você sente falta.

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

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

1. tente consertar a equipe
2. encontre uma nova equipe (seja internamente ou em um novo empregador).

Tanto quanto sei, sempre fui fundamentalmente defensável . Isso não é exatamente a mesma coisa que ser fundamentalmente correto . Frequentemente, as circunstâncias mudam entre o momento em que você tem que tomar a decisão 'x' e o momento em que fica claro que 'x' foi a decisão errada em retrospectiva .

É como preparar seus impostos de renda nos EUA. Muitas pessoas acham que deveria haver uma resposta. Não há. Você tem sua opinião; seu contador tem sua opinião; 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, eu sempre admito meus próprios erros. (Na verdade, eu freqüentemente encontro meus próprios erros.) Além disso, quase todas as decisões significativas de design têm mais de uma pessoa assinando-as. Quaisquer erros nessas decisões são de propriedade do grupo, não inteiramente por uma única pessoa.

Acontece de vez em quando, e isso 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 uma 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 diria: "Isso é apenas ser pessoas".

Todo mundo faz as coisas erradas às vezes. Erros são inevitáveis. Admita livremente quando estiver errado, aprenda com seus erros e demonstre humildade, especialmente se inicialmente não estivesse convencido de que estava realmente errado.

"Humilhação" nunca deveria 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 adotar decisões difíceis, mas podem admitir estar erradas e ajustar seu comportamento quando necessário.

Have you always been fundamentally correct in the software designs you proposed?

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

When you give out some design that was fundamentally wrong, you tend to lose the respect of your fellow team members.

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

Todo mundo comete erros. Algumas soluções acabam sendo boas, outras ruins, mais alguma coisa no meio. Tanto sucessos como fracassos devem ser tomados como uma lição, por você e pelo resto da equipe.

Os primeiros erros podem parecer ruins, mas depois de fazer centenas deles, é como parte do trabalho.

Isso acontece com todos. 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 da sua parte. Por exemplo, uma vez cometi o erro de usar uma camada de acesso a dados inferior (SubSonic3). No momento em que tomei a decisão, eu estava apenas querendo ficar longe de consultas SQL feitas à mão. Então eu escolhi o que na época parecia ser um dos mais fáceis de começar. Eu não estava muito experiente com os DALs também. Bem, depois de resolver alguns problemas, fiquei me perguntando por que algumas consultas demoravam 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 corrigi-lo. Meu chefe, claro, não estava entusiasmado com a ideia de cometer um grande erro, exigindo alguns dias de pura migração. Mas ele também fez questão de não cometer 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 ele não derrubou tabelas inteiras. No geral, foi uma boa experiência de aprendizado para mim e agora me certificarei de que uma parte essencial do projeto atenda aos requisitos e não tenha grandes problemas.

Então basicamente o que você faz é isso:

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

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

Uma última coisa, relaxe! Todo mundo comete erros. Muito poucas pessoas acertam na primeira vez

Isto é coisa de concurso de mijar nerd, e não é uma boa situação para estar dentro Ninguém está sempre certo, e não há nada para se envergonhar de se alguém vem com uma maneira melhor de fazê-lo, ou se encontrar um problema com a maneira como você fez isso.

Você precisa despir-se emocionalmente da sua solução e gastar seu tempo tentando encontrar a melhor solução, e então ficará satisfeito quando o problema for resolvido, mesmo se for resolvido por outra pessoa.

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

Se o primeiro, então não há razão para se sentir mal e não há razão para seus colegas suspeitarem de você no futuro.

Se você estiver aguardando até a entrega final para discutir seu design com outra pessoa, não os culpo por suspeitar de seu outro trabalho.

Todos precisam discutir seu design com outra pessoa. Dependendo da complexidade ou da criticidade, talvez seja necessário discuti-lo com várias pessoas várias vezes. Todos podem cometer um erro, entender mal um requisito ou perder um caso especial.

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

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

Eu sempre fiz uma distinção entre, por um lado, decisões boas ou ruins; e nas outras decisões corretas e incorretas. Uma boa decisão é aquela que, nas mesmas circunstâncias, com a mesma informação, você faria da mesma maneira; uma decisão ruim é aquela que você faria de forma diferente. Uma decisão correta é aquela que, com o benefício da retrospectiva e de informações adicionais, prova ter sido correta; e, inversamente, com decisões incorretas.

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

A maioria das decisões de design que fiz se mostrou correta, mas eu aprendi mais e progredi mais com essas decisões que estavam incorretas. Espero que muito poucas das 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 muitas vezes desagradáveis que surgem delas.

Desde que não estejam sendo o " Quarterback de segunda-feira de manhã ." Eu não tenho nenhum uso para alguém que se senta em todas as discussões de design sem dizer nada apenas para afirmar que eles sabiam que não funcionaria depois do fato. Você tem que ser capaz de receber críticas, mesmo que não seja colocado em um contexto construtivo.

Provavelmente, uma das melhores características do site SO é ser capaz de assumir um risco e propor uma solução incerta. É assim que você aprende. Passar pela vida com um monte de porcaria na sua cabeça que está errado, mas você nunca foi informado do contrário, é a verdadeira ignorância.

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

Já sempre forneceu um bom design? Não! Eu me esforço para fazer isso, eu me esforço para melhorar, mas com cada projeto sucessivo, o que eu aparentemente consigo sempre faço é olhar para o que eu fiz antes e me arrepender de como perdi a marca em de alguma maneira.

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

Acontece com todos de vez em quando, então a melhor coisa a fazer é descobrir por que o design estava errado e aprender com isso. Se é falta de conhecimento, então a falha do design lhe dará algum conhecimento novo que você pode usar da próxima vez. Não deixe desencorajar você, todo mundo passa por isso em algum momento. É a melhor maneira de ganhar experiência e aprender com uma nova equipe / ambiente.

Isso acontecerá com frequência. Nossa indústria está mudando tão rapidamente que as chances de nunca errar são efetivamente zero.

No entanto, você empurrou o design ruim para baixo sobre suas objeções? Pode ser por isso que eles estão exagerando.

Se o erro foi grande, é claro que levará tempo para recuperar o respeito. Se um de seus colegas de trabalho o levou a uma má direção e criou problemas para toda a equipe, você não precisaria que ele provasse mais a 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 melhor as opções no futuro.

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

Haverá sempre erros. Errar é ser 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 esta daqui em diante.

Coloque atrás de você, abaixe a cabeça e faça o seu melhor. Se você é um bom programador, vai brilhar com os seus erros.

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

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 tal comportamento em quase todas as profissões: se você cometer um erro, e eles gostam de "categorizar" você em uma certa coisa, é para sempre. É um comportamento social. Até pessoas espertas 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 tinha esquecido de lavar meus pratos dizer uma ou duas vezes. Desde então, todos os trabalhadores pensaram que eu sou o tipo de homem que nunca lava meus pratos. E agora, assim que houver uma coisa suja na pia, sou eu (quem mais poderia ser).

É o mesmo em todos os lugares: esse é um comportamento social , independentemente do tipo de problema que possa ser.

Você me diz que quer um feedback honesto? A única solução é desistir de outro emprego. Se todas as pessoas da equipe acharem que você não é bom em seu trabalho, isso não mudará em breve, desculpe dizer assim. Então, procure outro emprego, porque você nunca vai mudar esse tipo de comportamento (estúpido, devo confessar) social .

A chave é como você declara seu caso e que tipos de mudanças você faz. Se você afirma ser um guru de programação que não faz nada de errado e é mais incrível que Jon Skeet, então é bem provável que em algum momento você será derrubado por isso. A chave é como você apresenta suas soluções para que você seja capaz de 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 em static em um aplicativo da web em que trabalhei uma vez. Eu não sabia o quanto seria que essa instância persistisse e fosse compartilhada entre todos os usuários do aplicativo, mas aprendi com ela e me recuperei a tempo. Às vezes pode ser que algo seja encontrado e correções importantes tenham que ser feitas. Eu estive nesse campo também, onde tive que vasculhar um monte de VBScript para reduzir as concatenações de strings que estavam causando problemas de memória onde trabalhei uma vez. Eu até me lembro de escrever código vulnerável a injeções de SQL em 1998, quando eu estava escrevendo um código de cliente para localizar dinamicamente o SQL desde que eu tinha ~ 20 campos opcionais nessa parte do aplicativo.

O perfeccionismo pode ser um pouco uma faca de dois gumes aqui, que é como eu vejo esse terceiro comentário, além de ser uma maneira que eu sou às vezes também. O ruim é ver que há todos esses erros e que nada está certo. O bom é que, ao obter o melhor que você pode, você pode estar se encontrando, se não superando as expectativas dos outros em relação a você. A melhoria contínua poderia muito bem ser o jeito do PC de ver o perfeccionismo e, se mantido com moderação, eu vejo isso como uma coisa boa. Por todos os erros cometidos, o seu código entra em produção? Isso faz o trabalho? Esses são pontos para refletir, assim como se alguém está sempre consertando algo ou é bom que você quer ser tão grande que você preferiria não fazer mais nada até que seja perfeito? A prática pode ser útil para ajudar a encontrar os padrões para fazer melhor o trabalho. No entanto, há algo a ser dito para entender a análise de custo-benefício em voltar a fazer pequenos ajustes quando há outros incêndios para resolver primeiro.