Como fazer uma pergunta ao programador sem obter o "Por que" como resposta

Todos nós já tivemos essa experiência. Você vai a alguém que conhece que tem a resposta para uma pergunta, pergunta a essa pessoa e ela responde com a resposta típica: "por quê?" Você explica por que precisa saber e eles tentam resolver seu problema.

Leva tempo, torcer o braço e paciência para direcionar a conversa de volta à pergunta original e obter essa resposta danada.

Por que os programadores fazem isso constantemente e por que o comportamento piora quanto mais velho o programador se torna?

Como você pode fazer uma pergunta ao programador da maneira mais eficiente para extrair a resposta da pergunta original?

Por que os desenvolvedores perguntam "por que" quando alguém pergunta como implementar uma solução?

Porque requer mais conhecimento para avaliar se uma solução é apropriada do que para realmente implementá-la.

É muito difícil acreditar em alguém quando dizem: "Não sei como fazer isso, mas sei com certeza que é o que preciso fazer". Os programadores insistem constantemente em investigar mais profundamente, porque as pessoas insistem constantemente em fazer as perguntas erradas. Sim, às vezes, eventualmente, volta à sua pergunta original, mas nem sempre.

Como analogia, imagine se alguém fosse até um mecânico e perguntasse como substituir uma bateria de carro. Geralmente, se você está qualificado para diagnosticar uma bateria com defeito, está qualificado para trocar uma, para que o mecânico pergunte como você sabe que ela precisa ser substituída.

Ele sabe que se não fizer isso, e acontece que você não precisa de bateria, você continuará voltando a fazer mais e mais perguntas até que, eventualmente, descubra que precisa desligar as luzes quando o motor estiver ligado. não está funcionando. Ao perguntar a você com antecedência, parece que ele está desperdiçando seu tempo, mas na verdade ele sabe por experiência própria que está potencialmente economizando muito mais tempo para vocês dois.

Então, se você quiser evitar a linha de questionamento, precisa convencê-lo de antemão de que sabe do que está falando.

"A questão é especificamente como alguém se envolve com outro programador para fazer uma pergunta, onde o outro tem a resposta e pula o debate sobre o motivo pelo qual a pergunta está sendo feita".

Você não pode, pelo menos não deterministicamente. O outro programador é uma pessoa, não um computador e não seu servo. Se você fizer uma pergunta, eles poderão escolher o que acham que é a melhor resposta. Se eles acham que precisam de mais contexto, pedem.

Você pode tentar anteceder sua pergunta com uma afirmação de que está procurando apenas uma resposta curta e final, mas eles ainda podem responder da maneira que acharem melhor.

A questão é especificamente como alguém se envolve com outro programador para fazer uma pergunta, onde o outro tem a resposta e pula o debate sobre o motivo pelo qual a pergunta está sendo feita.

Você não pode. Programadores, especialmente os bons, são conectados para resolver problemas e serem eficientes . Quando um cliente ou um colega programador chega em busca de uma resposta - ele saberá o problema que está resolvendo antes de apresentar uma solução. Dessa forma, eles são eficientes (eles não estão desperdiçando seu tempo e dando uma resposta que não resolverá o seu problema) e estão resolvendo problemas reais (dando soluções / respostas às perguntas que você deveria estar fazendo).

Exemplo - quando um cliente chega até você e diz que quer um recurso X implementado. Às vezes, o cliente realmente precisa de um recurso X e, às vezes, você realmente precisa se aprofundar e interrogar o cliente apenas para descobrir que ele não quer o X, mas algo completamente diferente. Quanto mais velhos e experientes forem os programadores, maior a probabilidade de eles terem sido queimados no passado por não chegarem ao cerne do problema antes de apresentar uma solução.

Então, para resumir - se você deseja que suas perguntas sejam respondidas com precisão, você precisa ter certeza de que está:

• fazendo as perguntas certas (portanto, você precisa pesquisar o problema de antemão)
• fornecendo o contexto para o problema
• compartilhando algumas de suas pesquisas para direcioná-las mais rapidamente ao problema

A maioria dos humanos que conheço são apenas humanos e não computadores. Se você só quer respostas, tente pesquisar no Google.

Por que os programadores fazem isso constantemente e por que o comportamento piora quanto mais velho o programador se torna?

Infelizmente, está o mais longe possível da verdade geral.

Esse comportamento é restrito à minoria dos realmente bons. E é melhor você aprender também.

Apenas responder à maldita pergunta que pula sobre os porquês é uma boa maneira de entrar em um abismo, rápido e seguro.

Se você realmente deseja pular a parte instruída, pode prefixar sua pergunta com algumas frases sobre limitações e seu desejo de pular perguntas - você pode obter alguma resposta ou apenas ser expulso. Apresentar um resumo de sua própria pesquisa é uma ideia melhor.

Todas as respostas aqui são uma boa resposta para a pergunta "por que", mas ninguém realmente respondeu à pergunta dos OPs.

Como você pode fazer uma pergunta ao programador da maneira mais eficiente para extrair a resposta da pergunta original?

A resposta é surpreendentemente simples: diga a eles por que isso precisa ser feito antes de você perguntar como.

A melhor coisa a fazer é incluir os desenvolvedores em algumas reuniões de nível superior em torno de um produto - forneça-lhes uma visão geral para que eles possam ver por que essa coisa específica precisa ser feita. Eles podem até surpreendê-lo com a forma como primeiro.

Bons programadores não querem apenas implementar qualquer solução; eles querem implementar a melhor solução para o problema específico. Isso requer informação. As perguntas são a maneira de coletar informações. Sem todas as informações, o programador sabe que está em risco de implementar uma solução que não atenda a todos os requisitos e ficará impedida de fazê-lo novamente. Não esconda informações de seus programadores. Ocultar informações desperdiça tempo, destrói o moral e leva a soluções inferiores.

Os programadores são "conectados" para resolver problemas.

Bons programadores tentarão resolver os problemas "certos".

Apenas fornecer o que alguém está pedindo é [frequentemente] o problema errado a ser resolvido.

Nos dias em que a automação do MS Office estava em alta, você recebia uma série de perguntas, geralmente ao longo de algumas semanas, perguntando como fazer "isso" em um produto do Office e depois "isso" em outro produto. , então outra coisa novamente em outra. Cada um deles é tratado rapidamente, mas o "problema" - ainda não totalmente declarado - não está resolvido. Eles continuam voltando para o próximo "elo" da cadeia.

Se você os parar e perguntar "Por quê?" então eles precisam voltar atrás e explicar de maneira mais ampla o que desejam alcançar e não apenas descrever o problema imediatamente à sua frente. (BTW, os programadores sofrem com isso tanto quanto (se não mais que) qualquer outra pessoa, para os quais fóruns como esses são testemunhos).
A cadeia de usuários "Obtendo os dados do grande banco de dados no Access, depois no Excel para massagear um pouco e depois no Word para que eles possam mesclar os resultados por email e enviá-los por e-mail para as pessoas todas as semanas" é rapidamente substituída por um trabalho em lote que faz tudo isso, com os resultados nas caixas de entrada das pessoas logo na segunda-feira de manhã, sem o envolvimento manual do usuário.

Usuários assim .

Precisamos saber para onde você está tentando chegar antes que possamos oferecer a melhor maneira de chegar lá.

Como alternativa, (parafraseando Monty Python): "Você quer a resposta de 5 minutos ou a meia hora completa"?

Não há nenhum ponto em que o Programador discute todas as minúcias de uma função específica quando você deseja apenas saber se ela funcionará se você alimentar um número com três três casas decimais.

Conhecer sua perspectiva muitas vezes pode reformular radicalmente a resposta que você recebe.

Sua pergunta final é "Como você pode fazer uma pergunta ao programador da maneira mais eficiente para extrair a resposta da pergunta original?"

Você está confundindo primeiro "eficiente" e "eficaz". Para ser mais eficiente , basta escrever "Qual é a resposta?" em um pedaço de papel e mostre-o ao programador. Essa é uma maneira muito eficiente de fazer uma pergunta. Também é muito ineficaz para obter uma resposta.

E segundo, você está assumindo que os desenvolvedores de software são respondedores de perguntas. Eles não são. Eles são solucionadores de problemas. Sua atitude mostra claramente que você não entende a solução de problemas. A maneira mais eficaz de resolver um problema é compreendê-lo ao ponto em que você pode descrevê-lo para um solucionador de problemas e depois apresentá-lo a um solucionador de problemas. O outro método é entender o problema parcialmente, tanto quanto possível, e apresentar seu entendimento incompleto a um solucionador de problemas, que primeiro fará as perguntas que você teme para transformar isso em um problema totalmente compreendido e depois o solucionará.

Uma maneira muito ineficiente é o método que você está tentando: obtenha uma compreensão incompleta do problema, adivinhe como esse problema poderia ser resolvido e pergunte a um solucionador de problemas como essa solução pode ser alcançada. O solucionador de problemas já viu esse comportamento antes. 10 vezes se ele é inexperiente, mil vezes se ele é experiente. Então, o solucionador de problemas sabe que você está indo para uma direção completamente errada. E o solucionador de problemas faz o que precisa ser feito para chegar à direção certa, que é fazer perguntas para entender o problema real. Primeiras perguntas para entender sua compreensão incompleta do problema, e segunda mais perguntas para entender o problema real.

Comece a pergunta explicando o que você deseja alcançar e qual é o contexto em que está trabalhando. Se você fornecer contexto suficiente , não receberá um "por quê?" , você receberá um "isso é realmente necessário?"

Porque, estatisticamente , a maioria dos recursos propostos é péssima e não vale a pena ser implementada.

Uma refutação típica seria "mas esse é o trabalho dele". Seu trabalho é escrever um bom código , e adicionar recursos geralmente vai contra isso, porque a maioria dos recursos exige um redesenho da base de código em funcionamento e essa "coisa de redesenho:"

1. leva uma eternidade
2. adiciona novos bugs
3. quebra coisas que costumavam trabalhar
4. torna a manutenção impermeável

Esse não é um bom código, é bom.