Come porre una domanda a un programmatore senza ottenere "Why" come risposta

Abbiamo tutti avuto questa esperienza. Vai a qualcuno che conosci ha la risposta a una domanda, fai a quella persona la domanda e loro rispondono con la tipica risposta: "perché?" Spieghi perché devi sapere e loro tentano di risolvere il tuo problema.

Ci vuole tempo, torsione del braccio e pazienza per riportare la conversazione alla domanda originale e ottenere quella maledetta risposta.

Perché i programmatori lo fanno costantemente e perché il comportamento peggiora tanto più diventa senior il programmatore?

Come si può porre una domanda a un programmatore nel modo più efficace per estrarre la risposta alla domanda originale?

Perché gli sviluppatori chiedono "perché" quando qualcuno chiede loro come implementare una soluzione?

Perché richiede più conoscenze per valutare se una soluzione è appropriata di quanto non sia effettivamente per implementare la soluzione.

È molto difficile credere a qualcuno quando dicono: "Non so come farlo, ma so per certo che è quello che devo fare". I programmatori insistono costantemente per approfondire perché le persone insistono costantemente nel porre le domande sbagliate. Sì, a volte alla fine ritorna alla tua domanda originale, ma non sempre.

Per analogia, immagina se qualcuno si è avvicinato a un meccanico e gli ha chiesto come sostituire una batteria per auto. Di solito, se si è qualificati per diagnosticare una batteria difettosa, si è qualificati per sostituirne una, quindi il meccanico chiederà come si sa che deve essere sostituito.

Sa se non lo fa, e si scopre che non hai bisogno di una batteria, quindi tornerai a fare sempre più domande fino a quando alla fine capirai che devi spegnere le luci quando il motore è non correndo. Chiedendoti in anticipo, sembra che stia sprecando il tuo tempo, ma in realtà sa per esperienza che potenzialmente ti farà risparmiare molto più tempo.

Quindi, se vuoi evitare la linea di interrogatorio, devi convincerlo in anticipo che sai di cosa stai parlando.

"La domanda è nello specifico come interagire con un altro programmatore per porre una domanda, dove l'altro ha la risposta e saltare il dibattito sul perché la domanda viene posta."

Non puoi, almeno non deterministicamente. L'altro programmatore è una persona, non un computer e non il tuo servitore. Se fai loro una domanda, possono scegliere quella che pensano sia la risposta migliore. Se pensano di aver bisogno di più contesto, possono chiederlo.

Potresti provare a anteporre la tua domanda con un'affermazione che stai solo cercando una risposta breve e di fondo, ma sono ancora liberi di rispondere come pensano meglio.

La domanda è in particolare come si interagisce con un altro programmatore per porre una domanda, dove l'altro ha la risposta e saltare il dibattito sul perché la domanda viene posta.

Non puoi. I programmatori, specialmente quelli buoni, sono cablati per risolvere i problemi e per essere efficienti . Quando un cliente o un collega programmatore viene a cercare una risposta, si assicureranno di conoscere il problema che stanno risolvendo, prima di presentare una soluzione. In questo modo sono efficienti (non stanno sprecando il tuo e il loro tempo dando una risposta che non risolverà il tuo problema) e stanno risolvendo problemi reali (dandoti soluzioni / risposte alle domande che dovresti porre).

Esempio: quando un cliente viene da te e dice che vuole implementare una funzione X. A volte il client ha davvero bisogno di una funzione X e talvolta devi davvero scavare e interrogare il cliente solo per scoprire che non vogliono X ma qualcosa di completamente diverso. Più i programmatori sono più anziani ed esperti, più è probabile che siano stati bruciati in passato non riuscendo a capire il problema prima di presentare una soluzione.

Quindi, per riassumere: se vuoi che le tue domande ricevano una risposta precisa, devi essere sicuro di essere:

• porre le domande giuste (quindi è necessario ricercare in anticipo il problema)
• fornendo il contesto per il problema
• condividendo alcune delle tue ricerche per indirizzarle più rapidamente al problema

La maggior parte degli umani che conosco sono solo umani e non computer. Se vuoi solo risposte, prova a cercarlo su Google.

Perché i programmatori lo fanno costantemente e perché il comportamento peggiora tanto più diventa senior il programmatore?

Purtroppo è tutt'altro che verità generale.

Tale comportamento è limitato alla minoranza di quelli veramente bravi. E meglio che tu lo impari anche tu.

Basta rispondere alla dannata domanda saltando sui perché è un buon modo per guidare in un abisso, veloce e sicuro.

Se vuoi davvero saltare la parte istruita, puoi aggiungere il prefisso alla tua domanda con alcune frasi sulle limitazioni e il tuo desiderio di saltare le domande: potresti avere qualche risposta o essere semplicemente espulso. Presentare un riepilogo della tua ricerca è un'idea migliore.

Ogni risposta qui è una buona risposta alla domanda "perché", ma nessuno ha veramente risposto alla domanda dei PO.

Come si può porre una domanda a un programmatore nel modo più efficace per estrarre la risposta alla domanda originale?

La risposta è sorprendentemente semplice: dì loro perché questo deve essere fatto prima di chiedere loro come.

La cosa migliore da fare è includere gli sviluppatori in alcune riunioni di livello superiore intorno a un prodotto: fornire loro un quadro più ampio in modo che possano vedere perché è necessario eseguire questa particolare cosa. Potrebbero anche sorprenderti quando ti viene in mente come.

I bravi programmatori non vogliono solo implementare qualsiasi soluzione; vogliono implementare la migliore soluzione per il problema specifico. Questo richiede informazioni. Le domande sono il modo per raccogliere informazioni. Senza tutte le informazioni, il programmatore sa di essere a rischio nell'implementazione di una soluzione che non si adatta a tutti i requisiti e sarà bloccata a farlo di nuovo. Non nascondere informazioni ai programmatori. Nascondere le informazioni fa perdere tempo, distrugge il morale e porta a soluzioni inferiori.

I programmatori sono "cablati" per risolvere i problemi.

I bravi programmatori cercheranno di risolvere i problemi "giusti".

Fornire semplicemente ciò che qualcuno sta chiedendo è [spesso] il problema sbagliato da risolvere.

Nei giorni in cui l'automazione di MS Office era di gran moda, si ricevevano una serie di domande, di solito nel corso di alcune settimane, che chiedevano come fare "questo" in un prodotto Office, quindi "quello" in qualche altro prodotto , poi qualcos'altro di nuovo in un altro. Ognuno di questi viene risolto rapidamente, ma il "problema" - non ancora pienamente dichiarato - non è risolto. Continuano a tornare per il prossimo "collegamento" nella loro catena.

Se li fermi e chiedi loro "Perché?" quindi devono tornare indietro e spiegare in modo più ampio ciò che vogliono ottenere e non solo descrivere il problema immediatamente di fronte a loro. (A proposito, i programmatori ne soffrono tanto quanto (se non più di chiunque altro), a cui forum come questi portano testamento).
La catena dell'utente di "Ottenere i dati dal grande database in Access, quindi in Excel per massaggiare un po ', poi attraverso Word in modo che possano unire i risultati e inviarli via e-mail alle persone ogni settimana" viene rapidamente sostituito da un processo batch che fa tutto ciò, con i risultati che si trovano nelle caselle di posta delle persone per la prima volta un lunedì mattina, senza alcun coinvolgimento manuale dell'utente.

Agli utenti piace quello.

Dobbiamo sapere dove stai cercando di arrivare, prima di poterti offrire il modo migliore per arrivarci.

In alternativa, (per parafrasare Monty Python): "Vuoi la risposta di 5 minuti o l'intera mezz'ora"?

Non ha senso che il programmatore riesca a scuotere tutte le minuzie di una particolare funzione quando vuoi solo sapere se riuscirà a farcela se gli dai un numero con tre tre cifre decimali.

Conoscere la propria prospettiva può spesso ridefinire radicalmente la risposta che si ottiene.

La tua ultima domanda è "Come puoi fare una domanda a un programmatore nel modo più efficace per estrarre la risposta alla domanda originale?"

Prima confondi "efficiente" ed "efficace". Per essere più efficiente , basta scrivere "Qual è la risposta?" su un pezzo di carta e mostralo al programmatore. Questo è un modo molto efficiente per porre una domanda. È anche molto inefficace nel trovare una risposta.

E in secondo luogo, stai assumendo che gli sviluppatori di software rispondano alle domande. Non sono. Sono risolutori di problemi. Il tuo atteggiamento mostra chiaramente che non capisci la risoluzione dei problemi. Il modo più efficace per risolvere un problema è comprendere il problema al punto in cui è possibile descriverlo a un risolutore di problemi e quindi presentarlo a un risolutore di problemi. L'altro metodo è comprendere il problema parzialmente, per quanto è possibile, quindi presentare la tua comprensione incompleta a un risolutore di problemi, che prima ti farà le domande che temi per trasformare questo in un problema completamente compreso, e poi risolverlo.

Un metodo molto inefficiente è il metodo che stai provando: ottieni una comprensione incompleta del problema, fai un'ipotesi su come risolvere questo problema e chiedi a un risolutore come è possibile ottenere questa soluzione. Il problem solver ha già visto questo comportamento. 10 volte se non ha esperienza, mille volte se è esperto. Quindi il risolutore di problemi sa che stai andando in una direzione completamente sbagliata. E il risolutore di problemi fa ciò che deve fare per andare nella giusta direzione, che è porre domande per capire il problema reale. Prime domande per comprendere la tua comprensione incompleta del problema e seconda domande per capire il vero problema.

Inizia la domanda spiegando cosa vuoi ottenere e qual è il contesto in cui stai lavorando. Se dai un contesto sufficiente non otterrai un "perché?" , otterrai un "è davvero necessario?"

Perché, statisticamente , la maggior parte delle funzionalità proposte fa schifo e non vale la pena implementarle.

Una confutazione tipica sarebbe "ma quello è il suo lavoro". Il suo lavoro è scrivere un buon codice e l'aggiunta di funzionalità di solito va contro questo, perché la maggior parte delle funzionalità richiede una riprogettazione della base di codice funzionante e questa "cosa riprogettazione:"

1. impiega un'eternità
2. aggiunge nuovi bug
3. rompe le cose che un tempo funzionavano
4. rende impermeabile la manutenzione

Questo non è un buon codice, un buon codice è minimo.