Come sviluppatore solitario, come posso essere sicuro di imparare e fare un lavoro decente? [duplicare]

32

Background: lavoro in una piccola (meno di 75) persona di ingegneria / produzione. Sono stato assunto come sviluppatore per lavorare con un singolo compagno di squadra, con lo scopo di migrare l'azienda alla moderna era digitale. Il mio compagno di squadra tuttavia non è uno sviluppatore, ma un ingegnere industriale, che lavora principalmente su idee generali, pianificazione e altre aree non correlate al codice. Faccio tutto lo sviluppo.

Problema: mi piace il mio lavoro, ed è (scioccante) a basso stress, probabilmente a causa del fatto che praticamente nessuno capisce cosa faccio. Questo include il mio capo, mi ha assunto solo sapendo che aveva bisogno di qualcuno che potesse "programmare". Il problema con questo è che sono costretto a risolvere ogni compito da solo, senza alcun input da parte di colleghi / anziani. Sono molto bravo in quello che faccio, ma anche abbastanza giovane (non ho ancora iniziato il college), e quindi avrei seriamente beneficiato dall'avere degli anziani da insegnare e correggere. Purtroppo questo non è possibile al momento attuale, quindi sono bloccato a fare tutto a modo mio e sperando che funzioni.

Questo funziona, suppongo, tranne che non ho modo di sapere se sto facendo le cose in modo terribile che alla fine mi costerà mesi di tempo di rilavorazione. Sto facendo le cose in modo efficiente? E anche se non mi sono ancora imbattuto in questo, e se davvero non riuscissi a capire un problema che blocca il nostro progetto? Non posso consegnarlo! E quando me ne vado? Cosa succederebbe se il prossimo sviluppatore crescesse per maledire il mio stesso essere a causa di ciò che si trova davanti ai suoi occhi? :)

Queste domande mi preoccupano abbastanza spesso e mi portano alla domanda :

Come sviluppatore solitario, cosa posso / dovrei fare per assicurarmi che stia imparando e producendo codice efficiente, manutenibile e corretto (quasi privo di bug). Come posso fare cose come:

  • controlla il mio codice
  • esamina i miei disegni
  • ecc.

Modifica

La mia domanda è simile ma non un duplicato di Un programmatore solitario può diventare un programmatore di livello medio o alto senza un mentore? , quella domanda riguarda la "classifica" come programmatore individuale, mi sto chiedendo come posso essere sicuro di imparare e fare le cose correttamente senza altri controlli tecnici.

    
posta Josiah 27.03.2015 - 00:07
fonte

7 risposte

19

As a lone developer, what can/should I do to make sure I am learning,

Ci sono libri che puoi leggere.
Ci sono gruppi di utenti / meetup in cui puoi parlare con altri sviluppatori.
C'è un sito di revisione del codice qui dove puoi inserire il codice (che non è vitale / identificabile per la tua azienda) per ottenere un feedback.

Sono tutti buoni, ma non sostituiscono le buone pratiche. Per scrivere un buon codice, invariabilmente dovrai scrivere prima il codice errato. La cosa migliore che puoi fare è essere introspettivi su come è il codice.

È doloroso da usare? È fragile estendere? Ti sembra di fare sempre le stesse cose?

Quella sorta di miglioramento iterativo è la chiave per crescere - programmazione o no.

    
risposta data 27.03.2015 - 03:47
fonte
11

Oltre alle altre risposte:

Partecipare a forum di programmazione come StackOverflow , Programmers.SE e CodeReview.se ti possono aiutare. Potresti decidere di trascorrere una percentuale del tuo tempo lì. Studiare è parte del lavoro di diventare uno sviluppatore.

Inoltre, probabilmente ci sono video sulle nuove funzionalità nel tuo linguaggio di programmazione: quelli con persone che scrivono effettivamente esempi di codice. Anche se non hai intenzione di aggiornare il tuo ambiente di sviluppo, vedi sempre persone che fanno cose diverse da quelle a cui sei abituato.

Questi sono modi per rimanere in contatto con altri sviluppatori senza incontrarli effettivamente.

    
risposta data 27.03.2015 - 11:38
fonte
6

Vuoi davvero ottenere un input da altri sviluppatori. Aggiungendo ciò che Telastyn e Kent hanno già suggerito, contribuire ad alcuni progetti open source attivi è un buon modo per ottenere feedback sul tuo stile / efficienza di codifica.

Un'altra cosa a cui pensare è cosa non ti piace (in particolare) del tuo attuale linguaggio / strumenti. Le probabilità sono che alcune aree problematiche non sono realmente e sono invece luoghi eccellenti per migliorare te stesso.

    
risposta data 27.03.2015 - 08:47
fonte
2

È positivo che tu riconosca la tua situazione e voglia fare le cose per bene. Alcune cattive abitudini sono difficili da calciare se le tieni per troppo tempo.

Se ci sono sviluppatori in altri team della compagnia, vedi se puoi unirti a loro per far rimbalzare idee e farli guardare da dietro le spalle una volta ogni tanto.

Libri, blog, podcast, gruppi di utenti locali e incontri (come ha affermato @Telastyn) sono anche buone fonti di nuove idee.

    
risposta data 27.03.2015 - 04:01
fonte
0

How do I know if I'm doing things right?

non è mai stato fatto, perfetto, incapace di essere migliorato. ma è comunque opportuno misurare il tuo lavoro (che è il codice) in base a qualche metrica o metrica delle prestazioni. ti ho inviato un powerpoint di qualcosa che ho presentato nel 2008.

ci sono alcune metriche ovvie che ho pensato siano salienti:

È questa roba che vuoi fare?

  1. Crea un prodotto interessante
  2. Utilizza la tua proprietà intellettuale
  3. Mercato di nicchia (ad es. audio)
  4. Guadagna
  5. Aspettatevi un futuro:

a) Interessi a lungo termine contro a breve termine

b) Leva vecchio in nuovo

Il tuo codice:

  1. Esegue una funzione interessante (questa è l'idea principale)

  2. Costo:

hardware richiesto

tempo di esecuzione (velocità)

spazio (loop stretti)

non ricorrente (NRE)

  1. Valore futuro:

manutenibilità,

riusabilità,

portabilità

Decidi cosa è importante, vedi quanto il tuo codice segna con gli obiettivi che hai per esso.

    
risposta data 31.03.2015 - 04:41
fonte
0

L'unico suggerimento che posso dare è leggere il codice open source.

Scopri come sono strutturati i codebase principali e quali sono gli stili e i framework di codifica utilizzati. In questo modo non imparerai "nella direzione sbagliata" e rimarrai aggiornato sul settore quando cambi.

    
risposta data 31.03.2015 - 13:04
fonte
0

Nella mia esperienza personale:

  1. Read open source code suona alla grande, ma la maggior parte di noi raramente ha la larghezza di banda per immergersi nei progetti. Soprattutto con il tipo di tempo che merita un progetto. Senza quel tipo di tempo non si può sempre apprezzare il perché dietro il modo in cui il codice è stato scritto.

Quello che faccio ora è che raccolgo solo i moduli di progetti open source come riferimento rispetto all'inizio. Coding python e vuoi vedere come i professionisti registrano o configano? Raccogli un progetto che hai usato . Quella familiarità respinge l'esaurimento. Per me era il demone carbonico di Graphite.

  1. Mentre i buoni mentori sono buoni, quelli cattivi sono davvero cattivi.

In realtà è uno sviluppatore solitario piuttosto liberatorio, dato che puoi scegliere le tue influenze. Possono essere i migliori al mondo. Se sei l'unico dev, il lavoro probabilmente non è così stressante come quello in cui la scimmia codificante più veloce ottiene la banana. Pick up Code complete 2, L'ambiente di programmazione unix, 97 cose che ogni programmatore dovrebbe conoscere. Tu sei il tuo limite. Questo può essere sia liberatorio che intimidatorio.

  1. Una "best practice xyz" sullo stackoverflow combinata con i primi cinque di una ricerca su google è per la maggior parte dei casi pratici, meglio di qualsiasi mentore che ti circonda.

È più comune trovare cattivi mentori che buoni. E anche i bravi non saranno i migliori in tutto e per tutto. Avranno i loro limiti, pregiudizi. Le risposte più votate non lo farebbero. Rendere un punto per iscriversi alla newsletter di code-review e programmers.se. E se puoi permetterti di leggere i commenti sui thread rilevanti su HackerNews, non penso che nessun team di mentori possa battere questo.

  1. Barriere a bassa energia per strumenti più recenti.

Non devi convincere una squadra a passare da svn a git. Rimanere in contatto con HN e puoi essere bravo quanto bello.

Tutto detto, il tuo più grande ostacolo è la dimensione del tuo progetto. Come giustamente menzionato nelle risposte precedenti, devi dover scrivere codice errato. arrivi alle buone pratiche di codifica.

Cose che non potrei mai inventare:

Nei team che ruotano frequentemente a causa di mgt, il codice stesso è rivelatore nel senso che è possibile alla fine vedere cosa c'è che non va . Quando devi piegare il codice per diversi casi d'uso, puoi vedere "quali interruzioni. Nella programmazione generale con requisiti fissi, questa flessibilità è richiesta raramente che consente spazio per hardcoding, cattiva progettazione, un approccio procedurale miope.

    
risposta data 01.04.2015 - 02:47
fonte

Leggi altre domande sui tag