Never just present a problem

Ho dato una rapida occhiata al tuo profilo e ho notato che sei stato in giro per la comunità StackExchange per un po’. Avrete sicuramente notato qui che le domande che ricevono le migliori risposte da queste parti sono quelle che presentano il problema e il ragionamento che hanno già preso nel tentativo di rispondere alla domanda.

La vita lavorativa è proprio come questa. Se si pone una domanda, allora si vuole essere sicuri di far sapere anche a loro cosa si è già fatto per cercare di rispondere da soli. Questo vi avvantaggia in diversi modi:

• ** Dimostra che non state chiedendo inutilmente.** Se esponete il vostro ragionamento, allora state facendo sapere alla persona che state facendo un tentativo prima di fare una domanda e non siete solo pigri.
• *Ricevete probabilmente un feedback che andrà a beneficio dei vostri processi di pensiero. * Se un pari viene da me con un problema e mi espone come ha cercato di rispondere a una domanda non solo aiuterà a guidarlo sulla strada giusta, ma lo aiuterò anche a capire come avrebbe potuto pensare alla domanda per arrivarci da solo. Più si espone il proprio processo di pensiero e di ragionamento, più le altre persone possono aiutarvi a costruire su di loro per i problemi futuri.

Ci sono un paio di punti da disimballare.

Pensavo che a tutti gli altri in un'azienda tecnologica piacesse parlare di tecnologia…

Non necessariamente. Molti tecnici parleranno di tecnologia che è rilevante per il compito che stanno svolgendo ora, ma potrebbero non avere alcun interesse in qualcos'altro.

Penso che tu possa essere confuso tra questo e:

Sono stato anche rimproverato per “aver preso la strada sbagliata” quando ho cercato di risolvere un problema che non conoscevo, invece di chiedere a qualcuno che era

Considera il ragazzo che gridava al lupo :) Se passi il tempo di qualcun altro a parlare di cose che non sono rilevanti per quello che sta facendo, allora quando gli fai una domanda rilevante, potresti scoprire che sente di aver già perso abbastanza produttività con te.

Praticamente cerco sempre di risolvere i problemi da solo per almeno un'ora. È troppo breve?

In molti casi, sì, è troppo breve. A meno che il problema che si cerca di risolvere non sia semplice, allora si dovrebbe investire più tempo nella ricerca e nella sperimentazione di diverse permutazioni. Se il problema è semplice, allora una ricerca sul web appropriata dovrebbe dare i risultati corretti.

Mettete tutto insieme, e quello che vedo è un giovane programmatore che ha qualche problema di giudizio, che è quello che vi ha detto il vostro responsabile delle Risorse Umane. Non è insormontabile, ma ci sono alcune cose a cui devi pensare.

• Salvare ipotetiche domande tecniche per la sala da pranzo. Non è appropriato, a meno che tu non conosca bene le persone per sprecare il tuo e quello degli altri per domande irrilevanti. Se ti viene detto che stai facendo troppe domande e che ti prendi troppo tempo per farle, allora chiaramente stai facendo le domande sbagliate.
• Quando fai una domanda, mostra cosa hai provato. Se non avete niente da mostrare come uno sforzo concertato per risolvere un problema, allora non avete provato abbastanza. Infatti, non abbiate paura di utilizzare le risorse come Stack Overflow se c'è qualcosa di tangibile da chiedere che potrebbe essere di pubblico dominio. E infine;
• Salvare le domande per le domande specifiche del business. Non chiedere come guidare il vostro strumento di programmazione, ma fare domande su questioni specifiche di dominio o ambientali che non saranno di pubblico dominio.

Ci sono un sacco di cose che si possono fare per migliorare. Potreste scoprire che il PIP può essere uno strumento molto prezioso per aiutarvi a diventare uno sviluppatore migliore :)

Il problema è che quando si interrompe il lavoro di qualcuno, questo non perde solo i 5-15 minuti necessari per rispondere. Perdono molto più tempo, perché hanno bisogno di ritrovare la concentrazione. E questo può essere piuttosto frustrante.

Mi sono trovato in una situazione simile alla tua. Andavo dalle persone e facevo loro subito delle domande. Anche quando facevano qualcosa che mi bloccava. Questo può anche aver interrotto altre persone nelle vicinanze.

Il mio manager mi ha dato una soluzione: usare la posta elettronica e la messaggistica istantanea, anche quando la persona è seduta accanto a te. In questo modo, penserete più a come formulare la domanda e durante questo processo potrete rispondere a voi stessi. Inoltre, l'altra parte può rispondervi quando ha un po’ di tempo libero.

Un'altra opzione è quella di fissare un incontro, dove tutto viene chiarito.

Cercherò di rispondere dal punto di vista dell'azienda. Io non sono quell'azienda, quindi ci possono essere cose che non vedo, ma l'ho già visto in passato nella mia azienda.

Too Many Questions

La maggior parte della tua confusione sembra derivare dal fatto che non hai capito che fare domande è un gioco pericoloso. Lo è!!!

Quando fai una domanda, ammetti di non sapere nulla, e che non riesci a capirlo. Come sviluppatore di software, uno dei tuoi compiti è quello di capirlo. Stai insultando l’“attuale” team di sviluppo chiedendoti: “Quindi hai scritto un codice così schifoso che non riesco a capire come leggerlo o cosa stia facendo, quindi ho bisogno che tu me lo spieghi”.

Ora, la parte difficile è che a volte è proprio così e dovresti fare delle domande. È importante ricordare che, in ogni caso, c'è un lato negativo in queste domande.

Un'altra cosa che penso di percepire nel vostro PO è che state facendo domande troppo presto. È assolutamente giusto che un nuovo sviluppatore stia seduto lì a leggere, e a fare ricerche per un giorno intero, per scrivere 2 righe di codice. In realtà, con 14 anni di esperienza, finisco comunque per farlo. Scrivere codice professionale non è questione di “quanto” viene fatto, ma di “quanto bene” viene fatto, e di poter ripetere quel successo. Dubito che qualcuno ti rimprovererà per averci messo 100 volte di più a fare un decimo del lavoro come sviluppatore esperto e affermato. Infatti, quando assumo qualcuno, scrivo il primo mese come se non mi aspettassi alcun lavoro vero e i primi sei mesi come se non mi aspettassi molto.

Non passare abbastanza tempo da solo

Questa è una cosa importante! Quando si chiede aiuto a un membro del team, si riduce anche la produttività di quella persona. Stai influenzando il suo processo e allo stesso tempo lo stai insultando (vedi sopra). Non c'è modo per voi di vincere, se dovete chiedere aiuto. Pensate a ogni richiesta, come a una battaglia persa. Potete ancora vincere la guerra, ma questa battaglia l'avete persa.

Ci sono alcune cose che potete fare per mitigare il problema:

1. 1. Chiedere via e-mail, mai di persona o in chat. La chat potrebbe essere il modo preferito per farlo “ufficialmente”, ma l'email è più bella perché il destinatario può gestirla nel suo tempo libero.
2. Chiedere in chat, mai di persona o in chat. 2. Avvicinatevi da una posizione “bassa”. Sei tu il supplicante qui. 3. Fate un po’ di strisciare. Non c'è problema. Un po’ non vi farà male e mostrerà al destinatario che ci tenete al suo tempo, cioè “So che siete molto occupati, ma non riesco a capire come integrarvi con le vostre API. Quando hai qualche istante puoi mostrarmi cosa mi sto perdendo?”. Dimostra che tu sei nel torto, non loro. È importante.
3. 3. Elenca i passi che hai fatto da solo. “Il documento API dice di passare in una Stringa che rappresenta l'id dell'utente. Ho provato a passare la proprietà user.id e il nome utente, ma non ha funzionato”. Questo dimostra che almeno hai provato a fare qualcosa e che, in generale, stai iniziando a “prendere” il prodotto.

Migliore giudizio Quando fai domande

Questo, a me, suona come se ti fossi “lamentato” con qualcuno, che non aveva un modo carino di dire: “Stai infastidendo tutti con le tue pessime domande. Smettila! In altre parole, credo che questo non sia un problema. Una volta che avrai corretto gli altri tuoi problemi, questo andrà via.

Bad Documentation

Ahem! Questo è un altro insulto personale. Non lo dica mai e poi mai. MAI!!!!! Ancora una volta stai dicendo che la qualità del loro codice è così scarsa che non riesci a capirlo. La loro risposta sarà sempre "Funziona per tutti gli altri, quindi devi essere tu l'idiota, non io!”

Inoltre, questo è un po’ un “benvenuto nel mondo reale”. Nel mondo reale, i clienti pagano per le applicazioni che funzionano e non per il codice o la documentazione (la maggior parte delle volte), quindi è molto comune che la documentazione si degradi nel tempo.

Se pensate che la documentazione sia scadente e che debba essere affrontata, allora tiratelo fuori, in silenzio, con la vostra guida del team. Lasciamo che siano loro a decidere.

Lo dirò comunque. Non importa quanto sia scadente la documentazione, con il codice sorgente proprio davanti a voi non dovreste averne bisogno. È una bella cosa da avere, non fraintendetemi, ma potete lavorare senza.

Essere in ritardo

Ovviamente, non fate tardi. Non è una cosa da poco. Anzi, nella tua situazione attuale, sii 30 minuti in anticipo! Niente scuse. Stai rovinando ogni speranza di trovare il tuo prossimo lavoro con questo. Se chiamassi l'ufficio delle risorse umane e chiedessi loro della tua presenza, e loro dicessero “Era spesso in ritardo” o “Gli è stato fatto rapporto per essere in ritardo”, sarebbe un segnale d'allarme immediato. Ne parlo, perché sia che tu mantenga questo lavoro o ne trovi uno nuovo, questo più di qualsiasi altra cosa ti impedirà di ottenere il prossimo lavoro.

Codice di bassa qualità

Questo è probabilmente vero. Dato il problema della domanda, probabilmente non stai scrivendo un buon codice. Però sei nuovo, e c'è da aspettarselo. Trovo che i college non insegnino un cavolo di niente su la codifica del mondo reale. Non ho mai assunto qualcuno subito dopo il college e non ho mai ottenuto un “buon sviluppatore”. Questo non significa che non siano diventati dei buoni sviluppatori. Semplicemente non iniziano in quel modo. Scrivere del buon codice significa stare al passo con le ultime tendenze e tecniche. Si impara costantemente. Il momento in cui ti fermi è il momento in cui inizi a fare schifo.

In conclusione

Questo post è stato approssimativo, ma volevo mostrare, chiaramente, quale può essere la posizione di un'azienda. Spesso le aziende (le aziende) avvolgono i loro commenti in così tanti “discorsi da manager” che può essere difficile da capire. Ho cercato di ridurre il più possibile il “discorso del manager” in questo post, ma questo significa che è un po’ grezzo.

I passi più importanti per correggere la tua carriera fallimentare:

1. 1. PRESENTARSI AL LAVORO PRESTO! (non potrò mai sottolinearlo abbastanza)
2. 2. Fai domande con la mente che stai già insultando la persona a cui stai chiedendo.
3. Fai domande con la mente che stai già insultando la persona a cui stai chiedendo. 3. Mostra il tuo lavoro. Quando fate una domanda, dite chiaramente ciò che avete già fatto.
4. Mostrate il vostro lavoro. 4. Trascorrete più tempo ad imparare da soli. È importante dedicare molto più tempo alla ricerca delle cose che alla domanda. Onestamente, 3-4 giorni per cercare qualcosa da soli saranno più rispettati di una domanda di 30 secondi.

Volevo fare un tentativo da un punto di vista gestionale.

Un PIP è una cosa completa

È molto probabile che il miglioramento delle prestazioni sia una raccolta delle cose che il vostro management ha evidenziato, tutte fatte insieme. Sospetto che se tu fossi la persona che ha fatto tante e tante domande, ma che è arrivata presto, è rimasta fino a tardi e ha fatto un ottimo lavoro nella scrittura del codice, il team considererebbe la domanda come una mania personale, o che sei eccezionalmente scrupoloso.

Ma quando il team deve aiutare a trovare e risolvere più bug nel tuo codice, dopo aver risposto più del solito numero di domande, e ti vede lavorare meno ore o presentarti in ritardo senza preavviso, il team e il manager si accorgeranno che non stai contribuendo al livello necessario e che non stai mettendo del tempo in più per aggiornarti. La domanda è stata probabilmente sollevata alla luce degli altri problemi, perché se si cerca di correggere la qualità del codice facendo PIÙ domande, sarà insostenibile per il team.

Ogni ora conta

Ogni ora conta

Un nuovo laureato è un investimento in tempo di squadra. Qualsiasi manager che vi dica il contrario non ha mai assunto un nuovo laureato, o sta mentendo, o ha dei dirigenti davvero eccezionali che lavorano per lui/lei. Ogni nuova assunzione è un qualche investimento, ma i laureati sono PIÙ tempo. Di solito il compromesso ne vale la pena, però - ma sappiate che i laureati fanno più domande che gli sviluppatori più esperti.

Tuttavia - ogni ora conta. Un team di sviluppatori farà di più in una determinata settimana, quando tutti sono al passo con i tempi, conoscono il codice e non fanno molte domande. Inoltre, un team in questo stato gelatinoso sarà in grado di fare e rispondere alle domande molto rapidamente - il che accelera anche la produttività.

Rispondere alle domande fa richiede tempo. E c'è un cambio di contesto ogni volta che uno sviluppatore smette di scrivere codice e inizia a rispondere alle domande. Quindi rispondere alle domande ad alta interruzione è molto più di un killer della produttività che stare seduti per un'ora a rispondere a una serie di domande.

Sarei sicuro nel sostenere che QUALSIASI cambio di contesto costa 1 ora, quindi anche se si ha una domanda di 5 minuti, è costato al team un'ora quando qualcuno si ferma a rispondere alla tua domanda. Ciò significa che prendere 1 ora e non ottenerla, poi chiedere aiuto costa in realtà più tempo che prendere 2-4 ore.

Non esiste una cosa come “ci vorranno solo 5 minuti per farmi risparmiare un'ora”. Data la metrica di almeno un'ora per ogni interruzione, è meglio che l'altro tizio ti faccia risparmiare 2-4 ore.

Consigli per fare domande Bene:

• Capire e fare domande in base all'urgenza - se devi assolutamente avere un problema risolto in un'ora, allora interrompere quasi tutti quelli che possono aiutarti è una buona idea. Se vi è stata data una scadenza di 3 settimane, allora interrompere di meno e risolvere i vostri problemi di più è un'idea migliore. Questo significa che in caso di emergenza, le persone spesso fanno molte domande che altrimenti farebbero da sole. Perché è assolutamente essenziale avere la risposta il più rapidamente possibile.
• Utilizzare i forum di domande per il loro scopo definito, o intuire lo scopo dalle domande/risposte esistenti. Gli Stack Exchanges, per esempio, hanno un insieme abbastanza esteso di regole di base che sono abbastanza ben documentate, e un'aspettativa particolare che gli utenti cerchino le risposte precedenti prima di chiedere. Un altro forum può aspettarsi domande ripetute, ma solo su un'area molto ristretta.
• Cerca la tua domanda. Aspettatevi che scrivere una buona domanda possa richiedere tanto tempo quanto dare la risposta - in molti casi, state descrivendo (tersamente!) i passi che vi hanno portato al punto di non essere in grado di rispondere al problema. Inoltre, è probabile che stiate documentando tutti i sintomi del problema.
• Prendete di mira le vostre domande - cercate di capire chi può effettivamente rispondere alle domande, quando possibile, piuttosto che chiedere a tutti. Non tutte le domande valgono la pena di essere discusse.
• Aggregate una grande pila di domande - soprattutto quando siete nuovi, prendetevi un giorno per rivedere il problema e il codice. Aggregate le vostre domande in un elenco puntato con argomenti aggregati insieme. Poi chiedete a un mentore o a un amico dove andare a chiedere aiuto. È molto probabile che la maggior parte delle domande in un'ora e mezza risponderà entro un'ora e mezza. Le domande che sono arrivate nell'ora #1-2 e a cui non è stato possibile rispondere entro l'ora #8 sono probabilmente in cima alla vostra lista, dato che sapete che in 8 ore non riuscirete a capirlo.
• Il codice non è “auto-documentazione”, ma si possono imparare un sacco di informazioni leggendolo. Ho imparato molti sistemi non documentati stando seduto con un quaderno e disegnando la mia versione del disegno mentre andavo. Se non hai letto diversi livelli sopra e diversi livelli sotto l'area in cui stai lavorando e non hai letto i documenti delle API esterne che stai usando, non hai fatto ricerche abbastanza approfondite.
• Quando si cerca di trovare una risposta, si va molto lontano se si può suggeriscono possibilità, piuttosto che chiedere la risposta. “Sarebbe questo il modo giusto di farlo?” è meglio di “Come faccio? - anche se la risposta è "lo stai facendo in modo completamente sbagliato” - si può comunque chiedere “perché il mio modo è sbagliato?” e più meta “come imparerei a farlo bene ripetutamente”? Questo è l'approccio “insegna ad un uomo a pescare” - impara a pescare, non fare domande che ti danno solo 1 pesce.
• Evita le domande che sono solo un modo educato di dissentire. C'è una linea di demarcazione tra “il mio modo di fare è fattibile?” e “non capisco (cioè sono d'accordo) perché l'hai fatto a modo tuo? Queste sono belle conversazioni, ma si svolgono meglio in modo informale dopo aver conosciuto le persone.
• Modera le tue domande a grandi linee - queste sono di solito le domande sul "perché”. Le nuove persone hanno il diritto di fare un sacco di domande “dove” e “chi” (dove sono i documenti, dov'è il processo per questo, dov'è il posto nel codice che potrei voler guardare? chi può rispondere a questo? chi invito alla revisione?) e un certo numero di domande “come” - è questo il modo in cui dovrei affrontare la cosa? come posso ottenere il vostro accordo? Ma “perché” come “perché l'abbiamo costruito in questo modo?”, “perché non documentiamo più il codice?”, “perché non è una priorità? - sono legittime, ma finché non si ha più esperienza con il lavoro e l'attività, non sono le domande più necessarie. Possono essere GRANDI per un 1 a 1 con il tuo capo dove non hai altre questioni urgenti, ma se il "perché” si affolla il dove, chi e come allora non ti stai concentrando sul tuo lavoro.

Mi sono trovato esattamente nella stessa situazione.

Problema

Quello che lei descrive è il problema che si trova ad affrontare la maggior parte dei neolaureati. La maggior parte delle università ti insegna solo le basi o i concetti, mentre nel lavoro pratico hai bisogno di molto di più.

La maggior parte delle aziende che assumono i neolaureati hanno piani di formazione in atto, che se li seguirai dovresti diventare sicuro di fare il tuo lavoro entro un anno o giù di lì. Ma alcune persone diventano curiose, se si dà loro un semplice compito per riparare un piccolo componente di un sistema, non lo ottengono fino a quando non padroneggiano l'intero sistema e credo che tu sia uno di questi…

Penso che tu faccia domande perché,

• Senti che stai prendendo più di un tempo ragionevole per completare un compito, in quanto non capisci alcune parti del sistema.

• Sei solo curioso di capire completamente il sistema

• La tua azienda non ti ha fornito una formazione adeguata

Soluzione

Se i miei presupposti sono giusti, allora smettila di fare domande a meno che tu non debba farlo (punto fermo - subito)

• Iniziate a dedicare più tempo alla comprensione del sistema (non solo 8 ore)

• Utilizzate invece SO o altri siti correlati (dopo aver fatto la vostra parte di ricerca)

• Chiedete alla vostra azienda di formarvi adeguatamente @aree per le quali avete bisogno di aiuto.

Ho seguito quanto sopra e ora lavoro nella stessa azienda dopo 5 anni e posso affermare di saperne più di chiunque altro qui.

Ci sono già molte risposte qui, ma voglio affrontare alcune parti specifiche della sua domanda.

Anche se sono stato anche rimproverato di non passare abbastanza tempo a cercare di capire le cose da solo prima di chiedere aiuto agli altri. Questo non è vero, però, e il mio manager non avrebbe modo di sapere quanto tempo passa dal momento in cui incontro un problema fino al momento in cui chiedo aiuto a qualcuno. Praticamente cerco sempre di risolvere i problemi da solo per almeno un'ora.

È troppo breve? Qual è una quantità ragionevole di tempo da dedicare a un problema prima di chiedere a un collega che conosce la risposta?

L'enfasi è mia.

Tanto per cominciare, sì, un'ora è probabilmente troppo poco tempo. Dico probabilmente però… dipende davvero dal problema. E avere un limite di tempo è un bene, ma si dovrebbe fare affidamento più sugli indicatori che si è a un muro che non solo su un limite di tempo. Ma, cosa importante, quando si è pronti a fare domande, il destinatario delle vostre domande dovrebbe essere in grado di vedere la ricerca che avete messo nel vostro problema proprio dal tipo di domanda che state facendo.

Ed è allora che si arriva alla parte più audace della citazione. Lei ha tecnicamente ragione. Nessuno, a parte te, può sapere esattamente quanto tempo hai investito in un problema prima di chiedere aiuto.

Ma in base alla domanda che fai, alle informazioni che fornisci con la domanda, al contesto della domanda e alla facilità con cui riesco a trovare la risposta con una semplice ricerca su Google, posso fare una stima piuttosto buona di quanto ti sforzi di risolvere il problema da solo.

Se fai una domanda, e la prima ricerca su Google che provo a fare, la tua soluzione è il risultato numero uno, in pratica sono due colpi per te. Non importa se avete impiegato 10 minuti o 10 mesi per risolvere il problema. Avresti già dovuto studiare quella pagina e o ha risolto il tuo problema, oppure mi stai parlando di questa pagina e del perché non ha risolto il tuo problema.

Ma inoltre, che tipo di domande fai? Stai chiedendo delle soluzioni definitive? Oppure chiedete una piccola spinta nella giusta direzione? A volte, il muro che ti trovi di fronte è che sei completamente all'oscuro di qualche libreria o di qualche parte esistente del codice base che renderà semplice la soluzione del tuo problema.

Direi che avete imparato a conoscere ciò che questa azienda si aspetta attraverso la scuola dei duri colpi. Le domande in questo posto sono un no-no.

Penso che il vostro problema principale sia visibilità. Fare domande a vuoto è una cosa che molte persone possono vedere; anche se non si sentono obbligate a rispondere, questo potrebbe comunque influenzare il loro giudizio su di lei. Nel frattempo, se passi un giorno a cercare di capire una singola caratteristica alla tua scrivania, nessuno vede che la ruota gira. Sembra che tu compaia fare qualcosa di sbagliato, piuttosto che battere i tasti alla scrivania, che sembra un lavoro. Certo, forse nelle revisioni settimanali, mensili o annuali, la vostra produttività si rifletterà male. Ma le vostre domande a vuoto si vedono più volte al giorno, mentre la vostra produttività effettiva si misura molto meno frequentemente.

Ero in una posizione come la vostra. Sono stato assunto per risolvere i bug in un CMS di proprietà, mentre lo sviluppatore di piombo (read:only) ha strapazzato come un matto per aggiungere funzionalità per i clienti. Eravamo in arretrato. Il codice non era in controllo di versione, e ogni lato aveva la sua versione personalizzata. Era un casino completo.

Ingenuamente, ho pensato che fosse meglio occupare 10, 20 o 30 minuti del mio tempo e quello del lead a chiacchierare in modo che potesse spiegarmi le cose, piuttosto che passare mezza giornata, un'intera giornata, o anche diversi giorni per reingegnerizzare una funzionalità per scoprire 1. 2. come avrebbe dovuto funzionare, e 3. come risolvere il bug.

A quanto pare, quando il mio capo (uno dei due partner) l'ha scoperto, ha pensato che mi avesse fatto capire che non ero in grado di risolvere il codice da solo, e che stavo prendendo il tempo del nostro prezioso lead developer. (Il lead developer sembrava divertirsi a parlare di come funzionava il suo codice - in ogni caso, non se ne lamentava con il mio capo, come mi aveva detto). Così, ho smesso di fare domande, e la mia produttività è scesa probabilmente al 10% di quella che era. Sono stato licenziato circa un mese dopo.

Ad ogni modo, questa azienda vi sta dicendo, in modo negativo, che non apprezzano questo effetto collaterale dell'efficienza del tempo e della documentazione. Quindi non fatelo.

Trascorrete una giornata a cercare di capire qualcosa. Trascorrete un paio di giorni… Passate una settimana! Chi se ne frega? Non questa azienda. Qualunque cosa facciate, non fate domande, perché è una cosa che a loro interessa. Che sia la direzione, o i tuoi colleghi che si lamentano, non importa. L'azienda vi ha detto che tipo di cultura sta coltivando.

Quindi, se pensate alla vostra situazione, con i ritardi e la scarsa qualità del codice, il calo della produttività potrebbe essere eccessivo. Invece di aspettare che l'ascia cada, potreste cercare un posto che si adatti meglio a voi e al vostro stile. Un posto che magari abbia dei commenti sul codice e della documentazione, tanto per cominciare.

Allora, come è finita la mia storia? Dopo un periodo di disoccupazione, ho trovato un nuovo lavoro. A parte il fatto che la base del codice è molto migliore (stiamo usando un CMS standard del settore, siamo sul controllo di versione, abbiamo ambienti dev, staging, e prod, ecc), i miei colleghi sono eccezionali e la mia azienda incoraggia l'apprendimento. Abbiamo un wiki, dove condividiamo le nostre informazioni ed evitiamo di reinventare le ruote. Chiacchieriamo tutto il giorno a vuoto, parliamo di lavoro, facciamo domande, brainstorming, condividiamo notizie, informazioni e scoperte. Iniziamo progetti per migliorare i nostri processi, come l'agile, vagabondo e l'implementazione di un'integrazione continua. Ci insegniamo a vicenda e impariamo l'uno dall'altro. Ci comportiamo come colleghi e collaboratori, non come concorrenti. Abbiamo un'organizzazione e un orientamento per le nuove assunzioni e gli appaltatori, che non saremmo in grado di avere senza questa cultura. È una buona cosa, perché nel tempo in cui sono stato qui, siamo passati da due (me compreso) a otto, e anche appaltatori durante i periodi di lavoro.

La nostra azienda ci manda in formazione, conferenze, e ci incoraggia a prendere tempo per lezioni e casting su web. Ho imparato più in questo tempo qui che in qualsiasi altro periodo della mia carriera, soprattutto in materie in cui non lavoro. È meraviglioso; sono qui da 4 anni e mezzo, e non vedo molte ragioni per andarmene, se non quella di imparare una nuova tecnologia. La cultura del mio nuovo posto è davvero orientata all'apprendimento, alla comprensione e all'implementazione delle migliori pratiche, il che porta alla produttività. È una vittoria per tutti.

Seriamente, ci sono posti migliori per lavorare. Questo non è il posto per te, e tu non sei la persona giusta per loro.

Se fate domande non legate al lavoro, allora potrebbero essere considerate chiacchiere inutili, il che è una brutta cosa agli occhi dei vostri capi, quindi smettetela di farlo.

Tuttavia, fare domande legate al lavoro è una buona cosa perché dimostra che siete interessati al vostro lavoro e volete migliorare voi stessi.

Se siete stati accusati di sprecare il tempo degli altri, suggerirei che hanno bisogno di gestire meglio il loro tempo e di dirvi che sono occupati piuttosto che rispondere alle domande quando dovrebbero fare altre cose. Tuttavia, una risposta più utile sarebbe quella di chiedere se hanno il tempo di rispondere a una domanda prima che voi facciate quella domanda.

Mi sembra che il vostro capo sia un po’ stupido, o che voglia semplicemente sbarazzarsi di voi per qualsiasi motivo. Falliranno perché non documentano le cose, il che è una ricetta per il disastro quando il loro principale sviluppatore (o i loro principali sviluppatori) se ne vanno, ci sono stati, l'hanno fatto.

Tipi di domande di lavoro:

1. Come faccio a fare qualcosa di cui ho bisogno per imparare a fare il lavoro.

2. 1. Come faccio a fare qualcosa che devo imparare a fare il lavoro, ma che mi è già stato detto? 3. Come faccio a fare qualcosa che dovrei già sapere.

3. Come faccio a fare qualcosa che è fuori obiettivo per il lavoro, e so che è fuori obiettivo.

4. Come faccio a fare qualcosa che è fuori obiettivo per il lavoro, e non so che è fuori obiettivo.

5. Come faccio a fare qualcosa che è fuori obiettivo per il lavoro, e non so che è fuori obiettivo. 6. Domande divertenti e chiacchiere.

Quindi…

Potete chiedere tutti i numeri uno che volete. Potrebbero pensare che tu sia fastidioso, ma è un fastidio buono e intelligente. Non ti farebbero rapporto per questo.

Se chiedi il numero 2, allora pensano che tu abbia un problema di comprensione. Oppure ti piace solo fare domande ma non ascoltare. Questo è sopportato fino a un certo punto e invecchia in fretta.

A seconda della tua posizione e delle cose strane che porti al team #3s potrebbe andare bene - conosci bene un'area specifica, sei economico, qualunque sia. Tuttavia, è meglio non chiedere #2s dopo aver chiesto un #3.

Non c'è dubbio che i #4s non sono buoni. Puoi evitare di chiederne alcuni, ma non come nuovo dipendente. I colleghi si aspettano che tu chieda i #1 (e alcuni #2) molto prima di pensare ai #4. Se chiedete molto ai #4, pensano che siate in tutto e per tutto.

Questo è il peggiore. Il solo fatto di chiedere un paio di #5 può scoraggiare qualsiasi membro del team. Significa che non lo capisci e probabilmente non hai l'attitudine per capirlo.

Hmmm… I #6s dipendono dalla persona. Molte persone possono chiedere tonnellate di 6s se sono divertenti o divertenti. D'altra parte, se non lo sei, i 6 possono essere davvero cattivi, specialmente se chiedi i 2-5.

Se pensi a te stesso, perché non possono essere gentili con me e aiutarmi se ho problemi e chiedere sempre i 2-5? Perché possono assumere qualcun altro che sappia di più e non faccia domande stupide. Se fossi in te comincerei a prestare più attenzione, magari portando sempre con te un blocchetto per appunti, e quando qualcuno risponde a qualcosa ti assicuri al 100% di averlo ricevuto o chiedi chiarimenti sul posto.

Questa risposta riguarda come prendere un feedback (le altre risposte coprono già molto bene come fare domande).

Anche se sono stato anche rimproverato per “aver preso la strada sbagliata” quando ho cercato di risolvere un problema che non conoscevo, invece di chiedere a qualcuno che lo era. Quando ho chiesto della contraddizione, il mio manager e le Risorse Umane mi hanno detto che dovevo solo usare un giudizio migliore su quando porre domande. Non mi ero mai reso conto che fare domande potesse essere così pericoloso.

È stata una brutta reazione da parte sua. Immaginate di essere al loro posto per un momento. Sapete che alcuni dipendenti non stanno dando buoni risultati e state dicendo loro ciò di cui hanno bisogno per migliorare. Senza preoccuparsi di pensare a quello che gli stai dicendo, senza mostrare alcun interesse per il tuo feedback, figuriamoci scusarsi per non aver soddisfatto le aspettative, quel dipendente sostiene erroneamente che ti stai contraddicendo.

Quando ricevi un feedback, in particolare se è negativo, dovresti prima ascoltare, poi cercare di capire (facendo domande chiarificatrici, se necessario), e solo quando rispondi.

Questo perché, a meno che tu non abbia fatto un casino intenzionalmente, tu e il tuo capo non siete d'accordo sul fatto che tu abbia fatto un casino. O il vostro capo si sbaglia, o lo siete voi (o entrambi). Dovreste considerare la possibilità che siate voi, perché è molto improbabile che il vostro capo abbia completamente torto, e voi avete completamente ragione - e anche se lo siete, potete convincere il vostro capo che ha torto solo mostrandogli dove ha torto, e questo richiede anche di ascoltarlo.

Potreste anche chiedere consigli su come potreste fare meglio.

Per esempio, dopo aver sentito che state facendo troppe e troppo poche domande, potreste aver chiesto:

Quindi ho fatto entrambe le domande inutili e non ho fatto le domande necessarie. Come devo determinare quali domande sono necessarie? Cioè, che tipo di domande dovrei fare di più e che tipo di domande dovrei fare di meno?

La seguente discussione fattuale avrebbe probabilmente rivelato ciò che è necessario fare per migliorare.

È normale? La nuova persona in un'azienda non dovrebbe essere curiosa o fare domande che non sono immediatamente legate al suo lavoro?

In che misura le domande che si aspettano o che si desiderano sono diverse da un luogo di lavoro all'altro. Potresti desiderare di adattarti alla cultura del tuo posto di lavoro, che puoi scoprire osservando i tuoi colleghi, prendendo nota di come le persone reagiscono alle tue azioni (sono infastidite dalle tue domande, o si rallegrano di loro?), o chiedono il loro feedback (“Era giusto che lo chiedessi?”).

Penso che se sei giovane come me la tua mentalità sia quella di risparmiare tempo e trovare la risposta e poi passare al problema successivo. Tuttavia trovo che con le generazioni più anziane questo non sia una preoccupazione né una priorità per loro. Quindi sì, prendere un'ora per risolvere un problema è troppo breve per una persona più anziana, ma può sembrarvi troppo lungo. Suggerisco di osservare il gap generazionale e di seguirne l'esempio anche se non siete d'accordo. Alla fine diventerete più veloci a risolvere i problemi con più esperienza.

Per quanto riguarda il mettersi nei guai per fare domande, cerco di usare la spiegazione di I want to see how it should be done, or go by company standards. Anche in questo caso ho notato che nelle generazioni più anziane questo è irritante per qualche motivo. Penso che le persone anziane tendano a pensare che io abbia risolto il problema da solo e non ho ricevuto alcun aiuto, quindi sono meno disposti ad aiutare. Si sentono anche loro interrotti. Come qualcuno di cui sopra cerca di trovare il momento giusto per chiedere aiuto, mentre accarezza l'ego, IE “Ho sentito che eri l'uomo da cui andare per questo….”. “Qualcuno ha detto che sei tu l'esperto di….”, si spera che questo li faccia sorvolare su un'interruzione e che siano più disposti ad aiutare, dato che tu hai dato loro qualcosa da dimostrare. Fate attenzione a quest'ultimo consiglio, perché sono sicuro che in alcuni casi potrebbe ritorcersi contro di voi.

Trovo difficile definirlo con precisione, ma ho lavorato con diversi giovani sviluppatori, e alcuni di loro hanno fatto domande molto soddisfacenti a cui rispondere, altri no. Rispondere alle tue domande distrae i tuoi colleghi dal loro lavoro, e questo va bene, se ne viene fuori qualcosa di buono e l'azienda ne trae vantaggio a lungo termine. Ciò significa che dovete chiedere alla persona giusta, porre la domanda giusta e arrivare a un punto in cui avete acquisito una comprensione che vi permetta di fare progressi significativi. Se avete un talento per questo, le persone si sentiranno come se il tempo trascorso ad aiutarvi fosse tempo ben speso, e voi siete un collaboratore prezioso. Se non è così, rischiano di trovarti fastidioso.

Ovviamente se ci sono molte cose che non sai, questo ti mette in una situazione delicata, ma l'atteggiamento e l'attitudine fanno una grande differenza. Nessuno si aspetta che tu sappia tutto, ma si preoccupa di come lo affronti. Altri qui hanno già parlato delle cose che si possono fare per ottenere il massimo del successo quando si ha un anziano che ha un'anziana esperienza, quindi non ripeterò i loro consigli; sto solo cercando di fare un po’ di luce sui sentimenti dei tuoi colleghi che hanno portato a questa situazione, in modo che tu possa capirla ed evitarla in futuro.

Questo è quasi più un suggerimento per il vostro datore di lavoro, ma forse potreste farlo funzionare per voi.

Vi hanno assegnato un mentore quando avete iniziato? Dare a un nuovo dipendente un mentore assegnato, qualcuno da cui potersi rivolgere con le loro domande è una buona idea. Questo dà loro qualcuno che ha già esperienza in azienda e impedisce al nuovo assunto di infastidire costantemente tutti gli altri. :-)

Il mentore conoscerà anche le persone giuste a cui chiedere e i posti giusti per cercare cose come la documentazione. Per esempio, alcuni progetti potrebbero avere documenti di Google Doc, un altro li ha su un file server interno e un terzo li ha impegnati all'interno del repository dei sorgenti. Mentre altri progetti non hanno affatto documenti.

Un altro suggerimento è che quando si inizia a lavorare su un nuovo progetto chiedere un tour. Un solido blocco di quattro ore di tempo con voi e una persona esperta può mettervi al corrente senza richiedere quelle quattro ore di tempo come interruzioni distribuite su diversi mesi.

Una cosa da ricordare: il codice è come la grammatica. La gente può sapere che il proprio fa schifo, ma non ama che glielo si dica. Per esempio, se ti facessi notare che hai ripetutamente sbagliato a scrivere “giudizio”, potresti essere infastidito perché non sto aggiungendo nulla di costruttivo. Beh, l'ho appena fatto comunque :)

Ma abbinate questo al fatto che molti programmatori esperti tendono ad adottare un atteggiamento da diva. Quelle che lei intende come domande sincere radicate nella logica possono essere molto minacciose per loro. Ho lavorato con innumerevoli esempi (e potrei esserlo anch'io) che hanno mantenuto lo stesso vecchio codice di merda che non è più rilevante da 15 anni. Sanno che c'è un modo migliore per farlo al giorno d'oggi, ma non hanno interesse o motivazione ad imparare cose nuove, quindi la vostra semplice presenza come generazione successiva è una minaccia per loro. Quando fanno il gesto della primadonna, basta ridere di te stesso e ricordare che sei tu quello con il vero potere - hai molti anni davanti a te per lavorare con la tecnologia del futuro e la direzione definitiva della tua carriera è ancora nelle tue mani. Di solito non è così per gli snob esperti.

Sono d'accordo con altri che hanno detto che questo non sembra un buon incubatore per aspiranti sviluppatori. Tuttavia, questo è comune. Ci vuole tempo ed esperienza per identificare la vostra nicchia, trovare un datore di lavoro che sia adatto a voi, e determinare ciò che conta di più per voi. Quindi, pagate le vostre quote, prendete i vostri debiti, pianificate la vostra carriera e uscite dopo qualche anno di solido lavoro. Per ora basta seguire il consiglio per quello che vale, non preoccupatevi del PIP e continuate a ricordare a voi stessi che la vostra situazione attuale è solo un mezzo per raggiungere un fine. I tuoi supervisori si aspettano che tu timbri l'entrata e l'uscita in orario come se lavorassi da Wendy’s. Non è così che deve essere, anche per i nuovi sviluppatori inesperti, quindi ci può essere un futuro molto più luminoso altrove.

Ho provato a dire loro esattamente quello che ho detto a voi ragazzi qui. Si sono solo arrabbiati con me per aver litigato con loro “con le unghie e con i denti” e per non aver seguito bene i loro consigli. Ho detto che stavo solo cercando di esprimere il mio punto di vista… si sono arrabbiati di più.

Credo di poter spiegare perché si sono arrabbiati: semplicemente non vogliono un feedback. Il tuo manager non ti ha invitato a dare la tua opinione, ha semplicemente detto, con questo piano di “miglioramento necessario”, che hai un cattivo comportamento e che devi rimediare, “per il tuo bene”.

Chi decide cosa è un cattivo comportamento? Solo le persone che ti pagano e che possono licenziarti. Quando critichi le loro decisioni, si irritano, perché ti pagano per seguire i loro ordini, non per metterli in discussione. Non sono “giudici imparziali”, sono loro che ti pagano. E se li critichi nel momento in cui ti danno un serio e formale avvertimento “cambia o vattene” (quello che loro chiamano “consiglio per migliorare”), questo può portarli a pensare che non hai la redenzione.