Come non degenerare in un solo programmatore che unisce le API? [chiuso]

Tendo a vedere utilizzando le API e i Framework come parte ingegneristica del software di costruzione, al contrario del lato informatico. Prendo l'analogia della differenza tra pura scienza teorica o di ricerca e applicando quella scienza in una disciplina ingegneristica (fisica diversa in Ingegneria meccanica, civile o elettrica, o Chimica in ingegneria chimica).

Considerata questa analogia, hai una scelta: stagnare nella tua carriera, solo facendo quello che è abbastanza per cavartela, o ottenere una migliore comprensione di come la scienza si applica davvero alla tua disciplina, ottenere un apprezzamento per essa, e sarà Migliora sicuramente il tuo set di abilità, indipendentemente dal fatto che ti avvicini maggiormente all'aspetto ingegneristico o scientifico.

Controlla questa matrice sulle competenze . Se ti inclini verso il lato 2 ^ n o n ^ 2, puoi certamente diventare bravo a diventare uno sviluppatore della strada e puoi creare software. Se inizi a dirigersi verso il lato log (n), inizierai a vedere più rapidamente quanto sono buoni i framework o, ancora meglio, iniziare a scrivere i tuoi che compensano quelli che mancano.

Anche se ho modificato questa risposta per tenere conto delle modifiche all'OP. Mi trovo ancora perplesso sulla scelta della parola degenerazione . Riunire i vari aspetti di API diverse (e talvolta incompatibili) costituisce una parte importante di ciò che fanno gli sviluppatori di software. Se d'altra parte la tua domanda è chiedersi come evitare di farsi incastrare da scarpe in un ruolo che ritieni sia limitante per le tue opzioni per trovare altro lavoro, allora forse i parametri che hai definito sono troppo stretti, o la tua visione anche il ruolo è troppo stretto. Io stesso ho lavorato su progetti in cui ero responsabile di specifici compiti specialistici senza mai dover lavorare oltre quei "limiti", e non ho mai pensato che questi lavori fossero limitanti in alcun modo, dato che potevo usarli come esempi per salire - Rivolgi le mie competenze al prossimo datore di lavoro, con aneddoti appropriati sulle lezioni apprese e le competenze acquisite.

Avendo intervistato molte persone nel corso degli anni, non vedo segni che la gente degeneri in certi aspetti di un ruolo. Vedo che a volte le persone specializzano e che a volte la specializzazione viene presentata come una limitazione. Questo per me è un segnale di avvertimento che il candidato non è molto aperto, e probabilmente non comprende veramente il processo di sviluppo nel suo complesso, o non ha la capacità di spingersi oltre i ruoli in cui il candidato si sente sicuro e a suo agio.

Troverò che qualsiasi datore di lavoro che abbia visto il tipo di lavoro che ho svolto come una degenerazione avrebbe probabilmente una visione molto ristretta delle capacità di un buon sviluppatore di software. Lo sviluppo del software non è solo la possibilità di codificare per nuove GUI o API, e un buon sviluppatore di software sa che non ci sono molte opportunità per lavorare su nuovi progetti, e che è raro che si possa entrare in un nuovo lavoro e iniziare a lavorare su cose eccitanti, perché generalmente sei assunto perché ci sono un sacco di compiti che il personale stabilito non ha il tempo di completare. Indipendentemente da ciò, troverete spesso che "le API di stiching" insieme richiedono l'implementazione di nuovi livelli API per fornire maggiore flessibilità e compatibilità tra i livelli esistenti messi insieme. Le vere domande che dovrebbero essere poste agli sviluppatori sono sapere come gestire e stabilire le priorità dei loro compiti, o come scegliere una metodologia appropriata per i test e l'implementazione, e se capiscono quali strumenti / tecnologie applicare per ottenere risultati che fornire valore al cliente. In sostanza chiedendo loro se sanno COME scrivere software, e anche come gestire attività che potrebbero non essere necessariamente così glamour come avrebbero potuto sperare.

Quindi, per rispondere a quello in cui credo che la tua domanda dovrebbe riguardare, non vedo che ci sia qualcosa da temere dal trovarti diretto in un aspetto particolare dello sviluppo del software, ma che se senti che non è il percorso di carriera appropriato per te, hai la possibilità di discutere le opzioni con il tuo capo o di partire per un ruolo diverso. Se te ne vai, allora devi evitare di sorvolare sul lavoro che non ti piace e trovare un modo per trarre utili esperienze dal lavoro che hai fatto.

Degenerate è un termine caricato che implica che l'utilizzo dell'API ti rende in qualche modo meno programmatore. La verità è che nel software non puoi scappare usando una qualche forma di interfaccia per accedere agli altri livelli del sistema. Le interfacce sono ovunque, dal set di istruzioni di qualsiasi processore a cui stai lavorando alla raccolta di script di alto livello forniti da alcuni strumenti. I bravi programmatori possono essere efficaci a qualsiasi livello: non c'è nulla di intrinsecamente sbagliato nel lavorare a qualsiasi livello.

È difficile sapere esattamente qual è la situazione del tuo intervistato. Forse a lui o lei è stata promessa una cosa e poi si è bloccato facendo un altro con poche possibilità di avanzamento o di cambiamento. Le politiche di avanzamento variano da un posto di lavoro all'altro, ma in genere una buona strategia per ottenere ciò che vuoi è fare un ottimo lavoro a qualsiasi cosa tu stia facendo .

Il tuo "perché parti?" la domanda nell'intervista non è stata irragionevole, specialmente alla luce del breve curriculum dell'intervistato, ma sembra una di quelle in cui la risposta non ti dice molto. Non hai modo di sapere quale fosse la vera situazione. Una domanda più interessante potrebbe essere "cosa hai fatto nel breve periodo in cui sei stato al tuo attuale lavoro?"

In molte organizzazioni questo si riduce al loro appetito per il lato build di build vs buy e quanto efficacemente integrano le cose che scelgono di acquistare.

Alcune organizzazioni sono pesantemente sul lato delle build, ma la maggior parte ha un bel po 'di buy coinvolti. La differenza in quest'ultimo è la completa e completa integrazione di ciò che scelgono di acquistare.

I segnali di avvertimento per un'organizzazione che finisce per trasformare i loro sviluppatori in operazioni di integrazione del sistema sono svariati, ma un negozio con molti fornitori di consulenza, senza sviluppatori di Sr che sono ragazzi di basso livello, un grande processo per le decisioni di architettura, molti di una gestione non tecnica all'interno dell'IT o di una strong dipendenza da ricerche retribuite come Gartner possono essere tutti segnali di avvertimento che un'organizzazione probabilmente seguirà questo percorso.

Se ti trovi in un'organizzazione che segue questi schemi, c'è poco che puoi fare se non cercare di mantenere la corrente nella tecnologia scelta al di fuori del lavoro, ma discutere di questi problemi con alcuni degli sviluppatori durante l'intervista può darti una sensazione approssimativa se stai camminando in un posto che ritieni possa essere una strada senza uscita di carriera.

Il problema è che non aveva abbastanza pazienza.

Nessuno ti permetterà di lavorare su un framework o una piattaforma di un grande sistema aziendale subito.

Dovrai fare quanto segue:

• Mostra l'impulso di imparare
• Familiarizzarsi con il business lavorando con un sistema finito
• Crea gli amici giusti e chiarisci che alla fine desideri lavorare su una piattaforma, anziché "incollare le API"
• Ottieni la fiducia della gente

Tutto questo non viene dopo un anno, soprattutto per un grande sistema aziendale. Sì, è bello che l'impiegato voglia fare il lavoro da grande, ma ce ne sono molti altri che hanno già passato anni e sono più qualificati.