Ma se non sei sicuro, chiedilo!

Questo. Perché, attualmente, il tuo approccio è:

^{1: Dal punto di vista del tuo manager, perché non si adatta al loro requisiti.}

Quindi, segui i consigli del tuo manager. Ma, e ecco il punto, non come fai tu adesso! .

Insegno questioni tecniche e di sicurezza a persone che non ne sanno nulla. Quindi, quando lo faccio, uso il vecchio trucco del gioco in cui qualcuno deve farti capire cosa sta pensando, senza dirlo, cioè. Ho modificato le regole qui, per soddisfare le mie esigenze. È tutto basato su oltre 20 anni di esperienza e miglioramento. E funziona come un incantesimo .

"Ciò che capisci bene, lo enunci chiaramente ", ha detto l'autore e filosofo francese Nicolas Boileau. Quindi, quello che faccio è spiegare qualcosa a qualcuno, poi chiedere a questa persona, con le sue stesse parole, di spiegare lo stesso concetto a qualcun altro, che non ci ha sentito per primo.

Se tu puoi spiegarlo, l'hai capito. In caso contrario, ascolta di nuovo e riprova ...

Il mio consiglio è di applicarlo a te stesso. Ottieni il compito e riformulalo con parole tue. Quindi, torna dal tuo manager:

Ciao capo, mi hai chiesto di fare X. Ho intenzione di andare in questo modo: A / B / C. È corretto e cosa ti aspetti da me? Altrimenti, potrei anche andare con D / E / F. Cosa ne pensi? È meglio o no? Grazie per il feedback.

Da qui, ti farà sapere. E saprai se hai capito bene o no.

Ma se non sei sicuro, chiedi pure!

Vorrei riformularlo in:

Se pensi di sapere come risolverlo, discuti la tua soluzione con un membro del team. Chiedi a un membro del team se pensa che la soluzione proposta sia la strada da percorrere o se ci sono altri modi per farlo.

Sono un ingegnere del software junior e sto ancora imparando molto. Cosa si fa sul posto di lavoro, per impedirmi di fare "la cosa completamente sbagliata / la cosa buona in un modo completamente sbagliato":

• All'inizio di una storia, faccio squadra con una squadra membro.
• Ho letto la storia e non appena ho un'idea di come la implementerò, do un segnale a un collega.
• Discutiamo la soluzione, se è in linea con l'ambito della storia e il codice di base esistente, e ottengo un go / no-go,
• Cosa ancora più importante : Ricevo consigli su come risolverlo correttamente / feedback sul fatto di aver interpretato correttamente il problema.

Questo è, come Erik ha sottolineato nei commenti, molto diverso dalla programmazione in coppia "pura" , ma il principio ne deriva, ne sono sicuro. È un ottimo modo per ottenere / fornire feedback e assicurarsi che ciò che deve essere fatto venga fatto.

Quindi, come posso assicurarmi di aver capito correttamente un compito, se mi manca l'esperienza per sapere quali modi sono disponibili per risolvere il compito e il mio capo pensa che sia abbastanza chiaro nella sua formulazione?

Non so se è possibile per te (richiede un po 'di energia / interazione sociale) ma se possibile, chiedi al tuo capo se permette a te e ai tuoi colleghi ) (forse anche 1 persona designata), per fare il tipo di programmazione in coppia che ho descritto sopra . Potresti anche farlo insieme al tuo capo, anche se potrebbe non avere tempo da perdere.

Se sia tu che un altro programmatore non capite cosa dovrebbe essere fatto (o avete opinioni molto diverse al riguardo), andate dal vostro capo per chiarimenti prima di implementare la storia. Presentagli entrambe le tue opinioni e fagli prendere una decisione. (Nella mia squadra c'è anche un vantaggio tecnico per questo).

Soprattutto se ti manca esperienza, avrai bisogno di un mentore, un navigatore. Con l'esperienza arriva anche la capacità di capire meglio cosa significa il tuo capo perché conosci i limiti della base di codice. Fino ad allora, avrai bisogno di un interprete / tutore che ti protegga dal fare le cose "nel modo sbagliato".

In risposta al tuo commento su "come implementarlo". Per prima cosa, chiedi al tuo capo manager:

Ehi, come forse saprai, il mio Asperger spesso mi fa fraintendere le cose scritte o prenderle troppo alla lettera. C'è una soluzione alternativa per questo che in pratica significa che una volta che penso di sapere cosa dovrei fare, gestisco questa soluzione da un altro collega e chiedo la loro approvazione. In questo modo, mi impediamo di fare "le cose sbagliate / le cose buone in modo sbagliato". Ci fa risparmiare molto tempo a lungo termine e, man mano che conosco meglio lo stile di comunicazione all'interno di questo ufficio e acquisisco maggiore esperienza con la base di codice, potrebbe anche richiedere sempre meno tempo (fino a quando non si avvicina a una sorta di ' minimo sforzo richiesto ', poiché probabilmente sarà sempre necessario per te).

Fondamentalmente, come implementare questo:

• Chiedi al tuo capo di consentire questo tipo di programmazione in coppia. Menziona molti dei punti positivi (come sopra).
• Se il tuo capo è d'accordo, chiedigli di dire ai colleghi che ci si aspetta che lo facciano con te. (Chiedigli di farlo, non dargli ordini)
• Assicurati di poter spiegare ai tuoi colleghi cosa ti aspetti da loro (quale sarà il loro ruolo): feedback sulle soluzioni proposte / una spinta nella giusta direzione se sei sulla strada sbagliata. Non dovrebbero fare il tuo lavoro per te.
• Se hai un collega preferito (forse qualcuno che capisce te e i tuoi Asperger un po 'meglio degli altri?), chiedigli se è pronto per essere la tua persona "standard".
• Se ciò non è possibile, per ogni storia, chiedi chi è il più informato su quella parte del codice e chiedi loro di discutere l'implementazione di quella storia con te.

Quando il tuo capo ha scritto "Visualizzare il grafico principale in un frame Qt" probabilmente aveva un'idea chiara di come voleva che tu lo facessi, ma non puoi leggere la sua mente. Inoltre, l'affermazione è molto breve e concisa, soggetta a interpretazioni errate. Non incolpare troppo i tuoi Asperger qui, probabilmente tutti si sarebbero grattati la testa su questo.

Quindi avresti potuto chiedere chiarimenti, come "Hai già pensato a un modo per codificare questo? Se quindi per favore dimmi, mi farà risparmiare tempo. " o "Quale sarebbe il tuo modo preferito per implementarlo?"

In questo caso il capo impiegherebbe 5 minuti per scrivere una descrizione più dettagliata del tuo compito, facendoti risparmiare diverse ore nella ricerca, il che è un buon compromesso.

Potresti anche costringerti a trovare due soluzioni. Avere Asperger potrebbe renderlo un po 'imbarazzante, ma per favore aspetta.

Quindi qui hai trovato una soluzione con un frame OpenGL. Scrivine una breve descrizione usando le tue stesse parole finché è fresco, quindi respingilo nel retro della tua mente e cerca un'altra soluzione, approfondisci i documenti, va bene chiedere ai tuoi colleghi (o anche a stackoverflow). In questo caso avresti potuto scavare più a fondo nella documentazione del frame Qt.

Non hai bisogno di scrivere tutto il codice per entrambe le soluzioni complete, hai solo una vaga idea di come lo farai, magari un diagramma su carta con alcune note.

Dopo questo scrivi una breve descrizione dell'altra soluzione e chiedi al tuo capo quale preferisce. Descrivi i vantaggi e gli svantaggi di ciascuna soluzione.

Dandogli la possibilità di scegliere tra due opzioni ti dà una ragione legittima per chiedere il suo aiuto, dovrebbe anche lusingarlo un po 'che apprezzi la sua autorità.

Inoltre, quando trovi una soluzione ... tutti hanno la tendenza a pensare che la loro prima idea sia la migliore e unica soluzione possibile. Quindi, quando hai questa prima soluzione, fai l'avvocato del diavolo e trova tutti i suoi difetti prima di implementarla. Forse troverai abbastanza per farti pensare che il tuo tempo sarà speso meglio a scavare per un'altra soluzione più pratica che inizialmente non era ovvia. Ad ogni modo, avere una sola opzione dovrebbe essere un po 'sospetto, è un indicatore che non hai considerato altre, forse scelte migliori.

... Ma ero sicuro. Non sapevo che il frame Qt avesse altri mezzi per risolvere questo problema. Ho appena trovato un modo per risolvere il mio problema, che rispetta (presumibilmente) i requisiti. Allora perché dovrei continuare a cercare altri mezzi per risolverlo?

Commenterò questa parte perché l'ho vista molto con gli sviluppatori:

1. Prendono la prima opzione che trovano (o la prima idea che gli viene in mente).
2. Ci dedicano molto tempo prima di ricevere feedback.

Scegliere la prima cosa che trovano di solito è male perché significa che non hanno pensato al problema e ai compromessi. Il risultato è molto più lavoro (a breve e lungo termine).

Passare molto tempo è un problema perché non si rendono conto che ci sono problemi fino a quando il tempo è già trascorso.

Quindi, prima di iniziare a scrivere codice, dedica un po 'di tempo a trovare tre opzioni e prova alcuni esempi di base utilizzandole. Quindi presenta queste opzioni con una raccomandazione e lascia che il tuo manager ti guidi da lì.

E se lo facessi in generale, come potrei sapere se ho trovato la soluzione migliore e posso smettere di cercare altri?

Questo richiederà esperienza per svilupparsi. Ma se riesci a trovare tre opzioni, puoi selezionare la "migliore" tra quelle e sapere che è almeno migliore di altre due. L'atto di scegliere ti richiederà di pensare a dei compromessi, che ti aiuteranno a diventare uno sviluppatore migliore. E ti offre un punto di confronto quando ricevi un feedback, in particolare se ti sei perso qualcosa.

• Male: "So che sono passati 30 secondi da quando abbiamo parlato, ma come posso farlo?" (Nessuna iniziativa)
• Meglio: "Ho passato 3 giorni alla prima idea che mi è venuta in mente. Cosa ne pensi?" (Iniziativa, ma nessuna accortezza)
• Migliore: "Ho passato alcune ore (o un giorno) a cercare modi per farlo, e qui ci sono alcune opzioni. Questa mi piace di più perché x, y, e z. Cosa ne pensi? " (Iniziativa e lungimiranza)

Recentemente ho avuto un colloquio presso un'azienda, che è molto sensibile per l'argomento autismo al lavoro.

E non capire correttamente gli incarichi di lavoro se non abbastanza specifico è un problema di cui sono molto consapevoli i loro dipendenti aspie.

Mi ha parlato degli strumenti che ha sviluppato per andare d'accordo, per vedere se potevo usarli.

E uno di loro era semplicemente qualcosa che io letteralmente innamorato di.

Uno degli strumenti che ha menzionato, non era solo creare elenchi di cose da fare per incarichi di lavoro, ma anche creare elenchi di cose da fare.

Ha anche menzionato, che non ha mai avuto un aspie nei suoi team prima, ma ha pensato che questo sistema aiuta anche i suoi sviluppatori a non essere affetti da autismo.

Capisco che questa soluzione sia qualcosa che non è facile da imparare per un superiore chi non è aperto per questo.

Quindi il mio requisito OP di essere in grado di portare quel sistema nella posizione non è soddisfatto da questa risposta poiché richiede uno sforzo da parte della persona che mi supervisiona.

Ma lo trovo comunque abbastanza brillante da valere una risposta da solo.

Suona molto familiare (anch'io ho una diagnosi di Asperger). Anch'io sarei sicuro, nella situazione che hai descritto.

Nell'azienda in cui lavoro, abbiamo una regola generale (non specifica per i lavoratori aspie) per mostrare il risultato all'80% circa del tempo assegnato .

L'ho adottato personalmente per mostrare il mio lavoro quando penso di aver finito il 50% circa, indipendentemente dal fatto che lo ritenga buono / giusto o no. Nella mia esperienza, questo aiuta molto a rimanere / tornare in pista.

Quando ti vengono fornite meno informazioni, sei obbligato a fare supposizioni.

Ti consiglio di risolvere questo problema

Rivisitando e confermando i presupposti

Il modo in cui lo fai è semplicemente ponendo domande di conferma

Semplicemente, pensa a ogni presupposto che hai e confermalo.

Partendo da presupposti che molto probabilmente non sono veri.

Aumenta le tue possibilità di feedback

Attualmente, il problema nel tuo flusso di lavoro sembra essere che tu svolga un'attività e la completi se possibile, lavorando in isolamento fino a raggiungere un blocco. Come dici, ti è stato detto di chiedere se non sei sicuro, ma non perché eri sicuro. Questo non è un buon modo di lavorare.

Per qualsiasi attività di risoluzione dei problemi in cui potrebbero esserci più soluzioni per ottenere il risultato finale, è importante coinvolgere le persone in tanti passaggi quanti possibile.

Comprendi che chiedere feedback non è chiedere aiuto

Chiedere feedback non significa affermare di non capire cosa sei destinato a fare, o fare domande per avere una migliore comprensione. Non è chiedere loro di farti un favore chiedendo consiglio.

Significa invitare qualcun altro a dare la sua opinione su ciò che stai pensando. Questo sta dando loro la possibilità di essere coinvolti nel tuo processo e di offrire la loro opinione. Dovresti vederlo come una cosa positiva per loro: li stai includendo nel processo decisionale e offri loro la possibilità di esprimere qualsiasi preoccupazione.

Con questo in mente, dovrebbe essere più chiaro che fornire maggiori opportunità per il feedback viene generalmente accolto bene dai tuoi colleghi e non è visto come un fastidio per chiedere aiuto.

Pianifica il feedback durante il tuo ciclo di sviluppo

Così come è una buona cosa per i tuoi colleghi tanto quanto te, dovrebbe essere chiaro che chiedere un feedback più regolarmente è una buona cosa. Pertanto, dovresti programmare mentalmente del tempo nella tua pianificazione per quando chiederai feedback.

Alcuni esempi di volte che potrebbe avere senso sono:

• Dopo inizialmente leggere le specifiche

• Dopo aver svolto una ricerca iniziale sul problema e aver trovato potenziali soluzioni

• Dopo aver prototipato le aree del problema e aver trovato fornire nuove informazioni

• Dopo aver stabilito un'implementazione finale, prima di implementarla completamente

• Dopo aver completato l'implementazione minima, prima di firmarla

A seconda della situazione, potresti voler offrire più o meno opportunità di feedback. Ma devi assolutamente offrirlo più spesso di quanto fai attualmente. Ricorda, non stai chiedendo aiuto, stai offrendo ai tuoi colleghi la possibilità di essere coinvolti.

Come chiedere il feedback

Ora che tu ho un piano per ottenere il feedback: è importante concentrarti su ciò che desideri ottenere da esso e su come puoi invitare al meglio le persone a darlo.

Quando chiedi un feedback, suggerisci di includere quanto segue:

• Dai alle persone una panoramica di ciò che hai fatto finora (che potrebbe essere semplicemente "Ho letto le specifiche e le ho comprese come x" )

• Descrivi quale opzione ritieni sia la migliore concorrente ("Stavo cercando di implementarla utilizzando un frame OpenGL, che dovrebbe permetterci di fare x, y ")

• Spiega quali sono le tue preoccupazioni (" Ma immagino che potrebbe essere un sacco di lavoro "o" Anche se sono non sono sicuro che sia la migliore, non ho trovato alternative ")

• Invitali a esprimere i loro pensieri (" Hai qualche idea su questo? "," Ti sembra ragionevole? " , "So che hai esperienza con y, ha senso per te?")

Il processo non deve essere formale / scritto ( anche se può essere se funziona meglio per te), può essere solo un rapido "Hai 5 minuti per controllare alcune cose con te?" conversazione.