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

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 le proprie capacità naturali.

Percezione temporale
I ragazzi intelligenti sono abituati a risolvere i problemi in tempi relativamente brevi. Ricordo di essere stato sbalordito quando ho dovuto passare un'ora su un singolo problema di calcolo. Trascorrere 60 minuti su un problema non è più nulla. Quei giorni sono finiti ... seppellirli e dire addio. La complessità e le dimensioni della maggior parte del software oggi sono oltraggiose. Le persone non capiscono tutti gli strumenti che devono usare per portare a termine le cose. Uno degli uomini chiave del linguaggio JavaScript, Douglas Crockford ha detto,

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

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

Abilità naturale La tua intelligenza, capacità di problem solving e abilità naturali ti hanno portato all'intero spettacolo per sviluppatori. Non c'è spazio per qualcosa di meno in questo campo. Quindi cosa fai con 100.000 linee di codice, lingue e strutture che conosci a malapena, modelli di progettazione e paradigmi che le persone ti stanno spingendo, ragazzi che ne conoscono la maggior parte come il palmo della mano, i clienti che lo vogliono ieri e un capo chi si aspetta il mondo da te? Sparisci quando la tua abilità naturale fallisce.

Si, è normale. Sono ancora fuori di testa con alcune delle cose che mi vengono lanciate a modo mio.

Che cosa si può fare?

È ora di migliorare quelle capacità naturali con un buon lavoro vecchio stile. Lavora per rompere 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 risolverlo. Quindi non rinunciare dopo soli 15 minuti di esame di un problema complesso. Invece, rompi i problemi e smetti di guardare l'orologio. Dopo un po ', 30 minuti di lavoro con un problema in realtà non sono più quello di una volta.

L'autostima gioca un ruolo importante nella capacità di autogoverno. Così fa la squadra, specialmente gli anziani più esperti. È bene fare attenzione a non rompere le cose, ma questo non significa che devi chiedere un flusso costante di domande.

Utilizza invece il controllo del codice sorgente. Finché non si effettua il check-in di un cambiamento, non è possibile rompere il prodotto principale e rendere arrabbiati altri sviluppatori. Inoltre, apporta modifiche che puoi comprendere e testare e assicurati di testarle bene prima di effettuare il check-in.

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

Infine, ricorda che ogni decisione arriva con un certo livello di dare e avere. Non si può andare avanti senza fare alcun tipo di sacrificio ad un certo livello. Non lottare per la perfezione, sforzarti per la meraviglia e essere consapevole delle tue azioni. Perché devi sempre essere preparato a criticare e spiegare le tue idee e perché le hai create. Sii orgoglioso delle decisioni che prendi. Anche quando hanno torto c'è molto da imparare.

La prima cosa è non aver paura di porre domande. Ho visto persino architetti senior che fanno domande sul codice. Non ci si aspetta che sappiano tutto; ci si aspetta che sappiano abbastanza per portare a termine il lavoro e per essere in grado di capire il resto.

Probabilmente le migliori tattiche sarebbero:

• Scopri come eseguire ricerche su Google. Puoi trovare risposte a quasi qualsiasi cosa con un piccolo lavoro investigativo. Stack Overflow fa miracoli per quei problemi difficili da risolvere.
• Scopri come eseguire il debug. Ho trascorso ore a calpestare il codice aziendale eccentrico e profondo, solo per trovare la variabile X è 3 anziché 7. Essere in grado di leggere il codice e il debug è probabilmente il modo migliore per diventare autonomo.

Non abbiate paura di porre domande sulla "grande immagine"

Cercavo sempre di trovare la più piccola domanda che potessi porre ed ero ancora in grado di procedere con il mio lavoro, per paura che sarei considerato incompetente se facessi domande ampie a cui tutti sembrano conoscere la risposta. Non ho capito la differenza tra ignoranza e incompetenza. L'ignoranza significa semplicemente che non hai ancora imparato qualcosa, ed è perfettamente accettabile finché non persiste. Fingere di non essere ignoranti è molto peggio.

Se stai scoprendo che le risposte delle persone ti stanno portando solo lontano, devi chiedere loro di insegnarti a pescare invece di darti un altro pesce. Chiedi come si integra la tua parte con il tutto. Se la tua domanda sembra di base come "cosa è SQL in ogni caso", chiedilo prima piuttosto che dopo. Potresti sembrare un po 'sciocco ora, ma in seguito sembrerà molto più sciocco.

Concediti un periodo di attesa

Non fare domande non appena le hai. A seconda della complessità, concediti da mezz'ora a un giorno per provare a capirlo da solo. Molte volte lo risolverai da solo. 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 dalla sua testa, fai attenzione a come arriva. Molte volte non ti serve tanto aiuto come pensi. Se non ho tempo per una domanda, spesso punterò qualcuno in una direzione vaga e dirò loro che verrò a seguire quando avrò un minuto, e di solito l'hanno risolto nel momento in cui arrivo.

Elimina alcune bozze

Sit down and put down everything that comes into your head and then you're a writer. But an author is one who can judge his own stuff's worth, without pity, and destroy most of it.
—Sidonie Gabrielle Colette

Non abbiate paura di scrivere codice che non sarà mai rilasciato. Più esperienza riesci a ottenere, prima riuscirai a dire che stai seguendo la strada sbagliata, ma che succede ancora nel percorso sbagliato. Un sacco di volte il valore di una soluzione non è evidente fino a quando non l'hai visto farlo nel modo sbagliato.

L'autosufficienza sarebbe arrivata con

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

Fare domande frequentemente rischierebbe di mostrarti la mancanza di entrambi.

Se cambi il tuo dominio, la tecnologia, la piattaforma, la lingua sei di nuovo al punto di partenza (quasi, non contando per la tua maggiore capacità di affrontare problemi simili e conoscenze trasferibili)

Non fare domande quando veramente necessario sprecherebbe un sacco di tempo prezioso per la produzione.

Potrebbe funzionare a tuo favore lasciando cadere una parola sulla tua ipotesi sulla portata del possibile danno se lo fai male. o ciò che pensi potrebbe rompere per ottenere una valutazione effettiva delle tue ipotesi. Molte volte potrebbe permetterti di scoprire i punti e l'angolo che hai perso.

Essere cauti è buono.Ma è meglio che tu determini la natura delle tue domande. È meglio se lo scrivi sulla carta e ne esamina la difficoltà / dignità.

1. È qualcosa che puoi capire con google / forum o lavorando su di esso per un tempo più lungo
2. È qualcosa che puoi farla franca o riparare senza molti costi se ti incasini?

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 un buon feeling per quello che è un cambiamento di vasta portata e che cos'è un semplice cambiamento. Inizia con quelli semplici. Se pensi che quello che stai facendo è giusto, fallo.

Tu WILL fai errori e quelli sono inestimabili. Impara tutto ciò che puoi da loro quando accadono in quanto sono ciò che ti farà fare un lavoro migliore la prossima volta.

Quando ti senti a tuo agio con le decisioni più piccole, inizia a creare quelle più grandi. Dovrai decidere fino a dove andare con questo basato sul tuo progetto / ambiente / squadra.

Questo è il lato decisivo. L'altra cosa che devi fare è continuare a nutrire il tuo cervello in modo che possa aiutare a guidare le tue decisioni. Segui i siti che riguardano la tua tecnologia. Ci sono tutorial online di quasi tutto là fuori che coprono tutto, dal semplice al bizzarro complesso. Non aver paura di chiedere alle persone perché prendono certe decisioni - come cercatore di informazioni, per non essere conflittuali. La maggior parte delle persone è più che felice di spiegare le cose e si può imparare un po 'da loro.

Una volta che hai le conoscenze tecniche, il resto è saggezza e sicurezza e quelle vengono con esperienza.

Quando ero un principiante facevo domande, cercavo sempre di ottenere una risposta parziale a me stesso, usando gli strumenti disponibili; e quando ho ottenuto il massimo che potevo, avrei capito esattamente come esprimere la mia domanda in modo da essere il più chiaro e conciso possibile, partendo dal presupposto che la persona a cui stavo andando aiuto era occupata. Con questo po 'di preparazione, non penso che nessuno abbia mai pensato che io facessi loro delle domande, e in effetti ho avuto l'impressione che gli piacesse. Più tardi, 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 su cosa siano imponenti i sistemi moderni, quanto sia difficile venire a patti con. Quindi andavo a visitare il codice: iniziare da un punto di ingresso ragionevole, quindi tracciarlo, prendere appunti su me stesso su come funzionava, fare domande a cui avrei talvolta risposto per me stesso, a volte chiedere ad altre persone. Questo tipo di familiarità e competenza di dominio complessive richiede tempo, ma è possibile accelerarlo; e più fai, prima sarai autosufficiente nel modo desiderato.