Come evitare di essere solo un programmatore API? [duplicare]

Innanzitutto, non c'è nulla di sbagliato nell'essere un eccellente programmatore API. Ci sono un sacco di sfide non banali che possono essere affrontate interamente entro i confini delle API framework - dopo tutto, questo è il motivo per cui questi framework sono stati creati in primo luogo.

Se il livello di sfida nella tua posizione attuale non ti dà abbastanza soddisfazioni, prova a spostare la barra che hai impostato tu stesso. Spesso spetta a te, almeno in misura significativa, decidere cosa ti viene assegnato da un progetto. Vedi se puoi

• Completa il tuo compito molto più velocemente o
• Completa il tuo compito con un numero significativamente minore di codice o
• Completa il tuo incarico a uno standard di qualità significativamente più elevato, o
• Riduci notevolmente la quantità di debug che devi completare il tuo compito

Fare questo in modo coerente dovrebbe alla fine portare a termine compiti più grandi e più complessi, aumentando il livello di sfida. Di solito, la nuova sfida proviene dall'aspetto commerciale del sistema che stai creando, non dalla codifica di esso.

Sì, è assolutamente normale e non c'è motivo di sentirsi male. Ti senti anche male per non aver codificato un sistema operativo e un firmware del dispositivo personalizzati per ogni singolo progetto?

Ogni programmatore è solo un programmatore API

È ciò che fai con le API che definisce il valore e la complessità del tuo lavoro.

Qualunque cosa tu faccia, non iniziare a reinventare le ruote nei progetti di lavoro solo per aumentare la tua soddisfazione personale. Fallo nel tuo tempo libero, o quando c'è un motivo concreto per cui per le esigenze di questo particolare progetto, nessuna delle ruote esistenti è adeguata.

Sono d'accordo con te perché mi sono trovato in una situazione simile 1-2 anni fa: ho avuto qualcosa come 4-5 anni di esperienza lavorativa, e il 90% utilizzava framework pesanti e implementava lo stesso tipo di CRUD ( a volte web). Ecco il mio 2c su questo:

1. Vedo che alcune persone dicono che non c'è niente di sbagliato lavorando solo in questo modo. Non sono d'accordo. Una cosa è usare il batch di Spring e scrivere un po 'di logica di business, ed è del tutto diverso fare il proprio motore di batching multi-threading, adattato al tipo di trattamento per il quale lo si utilizzerà. È più complesso, la categoria di sfide e problemi è completamente diversa. Lo stesso vale per il passaggio dalla sola applicazione di accesso ai dati di Hibernate all'utilizzo di un driver di basso livello e alla creazione del proprio codice per gestire i dati. Solo i problemi di ottimizzazione cambiano completamente, e quelli sono solo la metà delle principali differenze nel paradigma. Quindi sì, penso che ti manchi A LOT solo essendo un programmatore API, almeno così mi sentivo.

2. Fortunatamente ora ho progetti di lavoro che evitano molto l'uso di framework "famosi" come Spring, Hibernate, persino Servlets in favore di custom made, da zero, codice. Questo perché i progetti che avevo al lavoro non erano molto comuni, e questi framework generici sono fatti davvero con un certo tipo di progetto (s) in mente, ma non funzionano bene per gli altri. C'è stato anche il problema delle prestazioni: mettendo da parte tutte le altre insidie nel creare il codice da zero o utilizzando una libreria / framework (velocità di sviluppo, meno bug, codice più testato ecc.), Dal punto di vista strettamente prestazionale è quasi sempre meglio evitare una libreria / framework e fare il tuo codice personalizzato su misura per il problema in questione.

3. Non dimenticare mai che uno dei maggiori vantaggi dello sviluppo open-source è che hai tutto ciò di cui hai bisogno gratuitamente per accedere ovunque e & ogni volta. Se sei curioso di come implementare questo e quello senza usare un framework, prova a farlo da solo. Non devi realizzare un progetto simile per dimensioni e obiettivo a quelli che hai a lavoro, sarebbe ingombrante, perdi molto tempo, ma prova a prototipare certe cose solo per vedere come va. Ad esempio, ho provato a codificare a mano diversi tipi di loop di gioco (che in seguito ho usato per creare giochi semplici), ho provato a implementare vari algoritmi (come AStar), ho giocato con il driver MongoDB per vedere come può gestire Operazioni CRUD senza ulteriore aiuto da altri framework, ecc.

Se non trovi costantemente modi per spingerti al di fuori della tua zona di comfort, allora sì, ci sono buone probabilità che ti sentirai così. Conosco un sacco di persone che hanno perso (o non hanno mai avuto) la loro passione per l'apprendimento e sono semplicemente felici di affrontare le loro mosse quotidiane. Niente di male, ma è lontano da me. Sembra che non sia quello che ti piace.

Fai qualcosa di diverso. Lavora in un reparto diverso. Trova un altro lavoro con un'azienda che non sta facendo la stessa cosa che fa la tua azienda, o almeno ha più diversità in aree che non conosci.

Ovviamente, se per il momento sei legato al tuo lavoro perché è una buona busta paga e hai delle responsabilità di vita reale (cioè non sei ancora un giovane laureato che vive ancora nel seminterrato di tuo padre), poi prendine un po ' Progetti OS che ti mettono fuori dalla tua zona di comfort e ti per imparare qualcosa di nuovo. Chissà? Se trovi qualcosa di cui ti appassioni, potresti acquisire una sufficiente esperienza per entrare nel campo professionalmente (se è qualcosa che al momento non hai abbastanza esperienza).

Questo può essere normale, in particolare quando le risorse sono limitate o le persone che impostano la direzione sono prive di fantasia (non una critica, potrebbero essere solo non tecniche). La grande domanda è dove vuoi andare?

Se vuoi essere uno sviluppatore migliore, scopri i problemi di business che stai cercando di risolvere. Leggi riviste o blog commerciali. Partecipa alle conferenze. Fai un corso di formazione. Parla con gli utenti. Più conosci il modo in cui il prodotto viene utilizzato, più puoi contribuire alla sua direzione e più prezioso sarà il tuo dipendente. Puoi quindi proporre cose che sono un po 'più avventurose di CRUD.

Espandi anche i tuoi orizzonti. Inizia un progetto parallelo a casa per spingere quello che sai. Esplora una lingua o una biblioteca diversa. Trova un progetto open source su github, scrivi della documentazione o dei test e chiedi loro se possono essere aggiunti al progetto.

Parla con altri sviluppatori all'interno della tua organizzazione. Fai un pranzo settimanale insieme dove parli di problemi, discuti soluzioni o fai solo una riflessione sul settore IT in generale.

In alternativa, se c'è qualcuno nella tua organizzazione o industria che ammiri, parla con loro e chiedi loro un consiglio. Se sei rispettoso e riconoscente, rimarrai stupito di quanto siano utili gli altri. Potresti anche trovare qualcun altro che ha bisogno di tutoraggio e si offre di aiutarti.

Molti degli strumenti che menzioni sono open source. Magari tira giù il loro codice sorgente, imparale e invia aggiornamenti. Scrivi alcuni materiali di formazione o brevi tutorial e ospitalo su un blog.

Se vuoi entrare nella gestione, inizia a fare volontariato per situazioni in cui puoi assumerti maggiori responsabilità. Guarda le cose anche al di fuori dello sviluppo, come essere un vigile del fuoco, unirti al club sociale o lavorare al comitato 401K. Inizia a conoscere budget, contabilità di base e gestione dei progetti.

A seconda del tuo rapporto con il tuo manager e della sua competenza tecnica, potrebbe valere la pena parlarne con lui o lei. Potrebbero essere distratti da altri problemi e non essere consapevoli di come ti senti. In effetti, se vuoi una promozione, non aspettare che il tuo capo te lo suggerisca. Guidare tu stesso è una delle cose che la gestione cerca.

Circa 15 anni fa, quando ho iniziato a programmare per un lavoro, erano disponibili meno API, solo perché non erano disponibili così tante librerie pronte all'uso.

Al giorno d'oggi con IDE moderni e ampie librerie incorporate nella libreria o nello strumento di sviluppo o nelle terze librerie di terze parti, le API sono sempre più importanti.

Tuttavia, ci sono ancora molte sfide, anche con il solo utilizzo delle API: - le decisioni architettoniche, vale a dire l'usabilità, la manutenzione, i requisiti non funzionali. - desicisioni progettuali, cioè utilizzo di schemi di progettazione, oggetti, classi ecc. Anche la modellazione è diventata sempre più importante - implementazione: questa parte è stata semplificata nel corso degli anni e quindi richiede meno tempo. - test, anche se il test è sempre stato necessario (o dovrebbe essere necessario), il testing è sempre più importante per l'aumento della complessità del software in generale.

Come evitare: - prova ad alzarti in direzione di prendere più decisioni di progettazione o decisioni architettoniche. Inoltre, poiché UI / GUI è sempre più importante, concentrati su questa direzione, specialmente se hai competenze creative.