Come posso diventare un programmatore più autonomo e autosufficiente? [chiuso]

Il singolo principale fattore che mi impedisce di essere uno sviluppatore stellare è la mia dipendenza dagli altri. Sento di fare troppe domande perché temo le conseguenze di rompere tutto e trattenere tutti. Quindi sono eccessivamente cauto ponendo così tante domande che praticamente ottengo le risposte dopo aver fatto abbastanza domande. Ho riconosciuto che è male, ma voglio fermarlo. In parte arriva il momento in cui semplicemente non conosco il codice (o è un ramo con cui non ho mai lavorato o è un prodotto nuovo di zecca), ma voglio fare affidamento su altri meno. Per prefazione, questo tipo di domande non sono quelle relative a modelli o linguaggi generici: di solito le mie domande ruotano attorno a come facciamo codice nella nostra azienda e come facciamo in modo che le cose funzionino nel nostro ecosistema. Voglio essere in grado di prendere le specifiche e di seguirle senza dovermi sentire come se avessi bisogno di aiuto in ogni fase del processo. È normale? Hai passato questo e, in tal caso, come l'hai superato?

Vedo che alcuni nuovi sviluppatori entrano in un lavoro e si sentono immediatamente inadeguati. Ho fatto lo stesso all'inizio della mia carriera. Penso che ci siano almeno due problemi principali che la maggior parte dei ragazzi intelligenti deve superare: la percezione del tempo e la loro capacità naturale.

Percezione del tempo
I ragazzi intelligenti sono abituati a risolvere i problemi in modo relativamente rapido. Ricordo di essere rimasto sbalordito quando ho dovuto passare un'ora su un singolo problema di calcolo. Trascorrere 60 minuti in un problema non è più niente. Quei giorni sono finiti ... seppelliscili e salutali. La complessità e le dimensioni della maggior parte dei software oggi sono scandalose. Le persone non capiscono tutti gli strumenti che devono usare per fare le cose più a lungo. Uno degli uomini chiave del linguaggio JavaScript, Douglas Crockford ha detto,

"Misapplication of standard tools...is the new standard."

Non c'è abbastanza tempo al mondo per imparare tutti gli strumenti di sviluppo.

Abilità naturale La
tua intelligenza, capacità di problem solving e abilità naturali ti hanno portato a tutto il concerto degli sviluppatori in primo luogo. Non c'è proprio spazio per niente di meno in questo campo. Quindi cosa fai con 100.000 righe di codice, linguaggi e framework che conosci a malapena, modelli di design e paradigmi che le persone ti stanno spingendo, ragazzi che ne conoscono la maggior parte come il palmo della loro mano, i clienti che lo vogliono ieri e un capo chi si aspetta il mondo da te? Sfogati quando la tua abilità naturale fallisce.

Sì, è normale. Continuo a dare di matto con alcune delle cose che mi vengono buttate da parte.

Cosa si può fare?

È tempo di migliorare quelle abilità naturali con un buon lavoro vecchio stile. Lavora per scomporre i problemi in parti più piccole. E renditi conto che, a differenza di molte cose che potresti aver fatto in passato, questi problemi richiedono molto tempo per essere risolti. Quindi non arrenderti dopo soli 15 minuti di esame di un problema complesso. Invece, abbatti i problemi e smetti di guardare l'orologio. Dopo un po ', 30 minuti di lavoro su un problema non sono più quelli di una volta.

La fiducia in se stessi gioca un ruolo importante nella capacità di autogoverno. Lo stesso vale per il team, in particolare per gli anziani più esperti. È bene stare attenti a non rompere le cose, ma ciò non significa che è necessario porre un flusso costante di domande.

Utilizzare invece il controllo del codice sorgente. Finché non si verifica una modifica, non è possibile interrompere il prodotto principale e far arrabbiare gli altri sviluppatori. Inoltre, apporta le modifiche che puoi comprendere e testare e assicurati di testarle bene prima del check-in.

Ho anche un piccolo progetto di test che utilizzo per scrivere programmi semplici e una tantum, quindi non devo preoccuparmi di tutto ciò che accade nell'applicazione principale.

Infine, ricorda che ogni decisione arriva con un certo livello di dare e avere. Non si può andare avanti senza fare una sorta di sacrificio ad un certo livello. Non cercare la perfezione, lottare per la bellezza ed essere consapevole delle tue azioni. Perché devi sempre essere pronto a prendere le critiche e spiegare le tue idee e perché le hai fatte. Sii orgoglioso delle decisioni che prendi. Anche quando si sbagliano c'è molto da imparare.

La prima cosa è non aver paura di fare domande. Ho visto anche architetti senior fare domande sul codice. Non sono tenuti a sapere tutto; ci si aspetta che sappiano abbastanza per portare a termine il lavoro e per riuscire a capire il resto.

Probabilmente la migliore tattica sarebbe:

• Scopri come effettuare ricerche su Google. Puoi trovare risposte a quasi tutto con un po 'di lavoro investigativo. Stack Overflow fa miracoli per quei problemi difficili da risolvere.
• Scopri come eseguire il debug. Ho passato ore ad entrare nel codice eccentrico e profondo dell'azienda, solo per trovare la variabile X è 3 invece di 7. Essere in grado di leggere il codice e il debug è probabilmente il modo migliore per diventare autonomo.

Non abbiate paura di porre domande "quadro generale"

Cercavo di trovare la domanda più piccola che potevo porre e di poter continuare il mio lavoro, per paura di essere considerato incompetente se facessi domande generali a cui tutti gli altri sembrano conoscere la risposta. Non capivo la differenza tra ignoranza e incompetenza. L'ignoranza significa solo che non hai ancora imparato qualcosa ed è perfettamente accettabile finché non persiste. Far finta di non essere ignoranti è molto peggio.

Se stai scoprendo che le risposte delle persone ti stanno portando così lontano, devi chiedere loro di insegnarti a pescare invece di consegnarti un altro pesce. Chiedi come la tua parte si adatta al tutto. Se la tua domanda sembra fondamentale come "cos'è SQL in ogni caso", chiedilo prima o poi. Potresti sembrare un po 'sciocco ora, ma sembrerà molto più sciocco in seguito.

Concediti un periodo di attesa

Non fare domande non appena le hai. A seconda della complessità, concediti ovunque da mezz'ora a un giorno per cercare di capirlo da solo. Molte volte lo risolverai tu stesso. Altrimenti, sarai in grado di dire al tuo collega cosa non ha funzionato, il che può aiutarlo a darti una risposta migliore.

Inoltre, se il tuo collega non conosce una risposta in testa, presta attenzione a come ci arriva. Molte volte non hai bisogno di tanto aiuto quanto pensi. Se non ho tempo per una domanda, spesso indicherò qualcuno in una vaga direzione e dirò che verro 'a seguire quando avrò un minuto, e di solito lo hanno risolto quando arrivo.

Butta via alcune bozze

Siediti e metti giù tutto ciò che ti passa per la testa e poi sei uno scrittore. Ma un autore è colui che può giudicare il valore delle sue cose, senza pietà, e distruggere la maggior parte.
—Sidonie Gabrielle Colette

Non abbiate paura di scrivere codice che non lo trasformerà mai in una versione. Più esperienza ottieni, prima sarai in grado di dire che stai seguendo la strada sbagliata, ma continuando a seguire la strada sbagliata succede comunque. Molte volte il valore di una soluzione non è evidente fino a quando non l'hai vista fare prima nel modo sbagliato.

L'autosufficienza verrebbe con

• Maggiore esperienza ed esposizione nel dominio.
• Maggiori capacità di osservazione e capacità analitiche per comprendere i sistemi esistenti e il loro comportamento, dipendenze.

Fare domande frequentemente rischierebbe di farti mancare entrambi.

Se cambi dominio, tecnologia, piattaforma, lingua, torni al punto di partenza (Quasi, senza contare la tua maggiore capacità di affrontare problemi simili e conoscenze trasferibili)

Non porre domande quando veramente necessario perderebbe molto tempo prezioso per la produzione.

Potrebbe funzionare a tuo favore nel lasciare una parola sul tuo presupposto sull'entità del possibile danno se lo fai in modo sbagliato. o ciò che pensi potrebbe rompersi per ottenere una valutazione effettiva dei tuoi presupposti. Molte volte potrebbe farti scoprire punti e angoli che hai perso.

Essere cauti è buono, ma è meglio che inizi a determinare la natura delle tue domande. È meglio se lo scrivi su carta ed esamini la sua difficoltà / dignità.

1. È qualcosa che puoi capire con google / forum o lavorando su di esso per un tempo più lungo
2. È qualcosa che puoi cavartela o risolvere senza troppi costi se sbagli?

Direi di guardare le cose su cui stai lavorando e iniziare a prendere decisioni da solo (mantenendo ovviamente le specifiche dell'applicazione). Ormai, dovresti avere una buona sensazione per ciò che è un cambiamento di vasta portata e ciò che è un semplice cambiamento. Inizia con quelli semplici. Se pensi che ciò che stai facendo sia giusto, fallo.

È WILL commettono errori e quelli hanno un valore inestimabile. Impara tutto quello che puoi da loro quando accadono perché sono ciò che ti farà fare un lavoro migliore la prossima volta.

Una volta che ti senti a tuo agio con le decisioni più piccole, inizia a prendere quelle più grandi. Dovrai decidere fino a che punto andare con questo in base al tuo progetto / ambiente / team.

Questa è la parte decisionale. L'altra cosa che devi fare è continuare a nutrire il tuo cervello in modo che possa aiutarti a guidare le tue decisioni. Segui i siti che coprono la tua tecnologia. Esistono tutorial online su quasi tutto ciò che riguarda tutto, dal semplice al bizzarro complesso. Non abbiate paura di chiedere alle persone perché prendono determinate decisioni - come un cercatore di informazioni, per non essere conflittuali. Molte persone sono più che felici di spiegare le cose e puoi imparare un po 'da loro.

Una volta che hai le conoscenze tecniche, il resto è saggezza e fiducia e quelli arrivano con esperienza.

Quando ero un principiante, ponevo domande e cercavo sempre di ottenere una risposta parziale alla cosa, usando gli strumenti disponibili; e quando potessi arrivare il più lontano possibile, avrei capito esattamente come formulare la mia domanda in modo da essere il più chiaro e conciso possibile, supponendo che la persona a cui stavo andando in cerca di aiuto fosse occupata. Con questo po 'di preparazione, non credo che nessuno abbia mai avuto problemi a farmi delle domande, e in effetti ho avuto l'impressione che gli piacesse. Successivamente, quando sono diventato l'esperto del dominio, mi è piaciuto anche aiutare le persone che hanno chiarito che rispettavano il mio tempo.

L'altra cosa che ho fatto è stata, ogni giorno, scegliere l'architettura del sistema. Altri manifesti hanno commentato cosa sia una grande impresa dei sistemi moderni, con quale difficoltà a fare i conti. Quindi andrei in tour del codice: iniziare da un punto di ingresso ragionevole, quindi rintracciarlo, annotare appunti su come ha funzionato, fare domande a cui talvolta risponderei per me stesso, a volte chiedere ad altre persone. Questo tipo di familiarità generale e competenza di dominio richiede tempo, ma puoi accelerarlo; e più lo fai, prima sarai autosufficiente nei modi che desideri.