La programmazione come professione in una corsa verso il basso? [chiuso]

Penso che tu abbia fatto una domanda molto toccante.

La creazione di strumenti di codifica GUI mette i programmatori fuori dal lavoro tanto quanto i robot mettono fuori dal lavoro i tecnici della catena di montaggio. Secondo me, mentre c'è una perdita di posti di lavoro, c'è anche un cambiamento in dove sono i prossimi posti di lavoro.

La tecnologia necessaria per eseguire un'attività cambia, ma l'attività deve ancora essere completata: le macchine devono ancora essere assemblate / assemblate prima di poter essere guidate; il codice / business logic deve ancora essere messo insieme affinché l'applicazione funzioni.

Cambiamenti nelle scelte attuali della tecnologia per i programmatori: scopri la programmazione basata sulla GUI o gli strumenti della GUI del programma ... o ... qualcos'altro interamente.

Può esserci un disallineamento tra le competenze dei dipendenti e gli interessi del datore di lavoro, ma non per molto tempo, soprattutto se il datore di lavoro è esperto. È quindi nel migliore interesse del datore di lavoro e del dipendente che perseguano ciò che è a loro reciproco vantaggio. Ma uno sarà inevitabilmente davanti all'altro. Spero che tu sia (-:

Un caro saluto,

KM

Alle tendenze che hai citato ne aggiungerei un'altra, che IMHO le spiega:

Vi sono molti più programmatori (necessari) che mai.

La quantità di attività che richiedono o includono la programmazione è in costante aumento e in una percentuale ancora maggiore rispetto al numero di programmatori. Oggigiorno ci sono diversi microchip in una macchina media. In 5 anni potrebbe esserci un chip nel tuo frigorifero e nel tuo tostapane. In 10 anni, la tua biancheria intima? ... E qualcuno ha bisogno di produrre tutto quel software per far funzionare queste cose. Quindi c'è tutto il possibile sforzo fatto per automatizzare tutto ciò che è automatizzabile e per migliorare la "produttività" (comunque è definita). E sempre più cervelli freschi vengono reclutati.

Ciò implica che la maggior parte dei programmatori attivi di oggi sono inesperti e / o mal preparati per il loro lavoro. Ci vogliono diversi anni per raggiungere un livello adeguato di esperienza e ci vuole costante apprendimento per mantenersi lì. La linea di fondo è, sempre più lavori di programmazione stanno diventando sempre meno impegnativi. Ma ci sono ancora abbastanza sfide per chiunque le stia cercando .

Lasciami fare l'avvocato del diavolo contro i tuoi punti sopra:

Not taking time to implement best practices

Molte persone no, molte persone lo fanno. Tenish anni fa, quando ho scoperto per la prima volta i test unitari e l'approccio agile, nessuno dei miei colleghi aveva la minima idea di cosa fosse. Oggigiorno è un materiale quasi standardizzato nelle università, così tanti neolaureati lo capiscono già.

Using other's people code as much as possible (custom code as a liability)

Contrariamente a cosa? Reinventare la ruota? O usare il codice di altre persone per evitarlo?

Penso che sia importante notare che siamo pagati (principalmente) per risolvere i problemi, e scrivere codice non è la fine, ma solo i mezzi per farlo . Se un problema può essere risolto senza scrivere una sola riga di codice, rende ancora felice il cliente. Soprattutto se in questo modo riusciremo a produrre una soluzione più affidabile più veloce ed economica. Non vedo alcun problema con questo.

Using increasingly higher level languages to improve productivity

Al contrario di codificare tutto in assemblea? ; -)

GUI based development "tools" that greatly simplify "programming" and do not require people to understand the plumbing behind the code

IMHO qualsiasi strumento può essere utilizzato in modo improprio. Il che non vuol dire che i costruttori di GUI fossero necessariamente perfetti o addirittura buoni - la maggior parte (o almeno alcuni) di essi sono utilizzabili nei loro limiti. Ma se qualcuno non conosce questi limiti, è un problema dello strumento o del suo utente?

In generale, credo (anche se non ho prove per dimostrarlo) che nei giorni della scheda perforata e del codice macchina, approssimativamente la stessa proporzione del codice esistente era orribile come ora, solo entrambi

• la quantità totale di codice e
• le possibilità che gli estranei abbiano mai visto tale codice

era molto meno.

Ora, con Internet e Daily WTF, siamo esposti ai peggiori esempi giorno dopo giorno. È un po 'come guardare tutte le notizie sul terrorismo, i terremoti e le celebrità divorziate, e gridare quanto sia pericoloso e immorale questo mondo.

Riassumi correttamente la situazione, ma interpreti completamente il significato.

Man mano che il software diventa più potente, i compiti assumono proporzioni tali. Così sicuro, potrebbe non essere necessario oggigiorno essere un programmatore di database per creare un database di contatti telefonici quando è possibile utilizzare Access. E potrebbe non essere necessario essere un programmatore web per creare un blog quando puoi semplicemente andare su wordpress. Ma, mentre 15 anni fa sarebbe necessario essere un programmatore per fare quelle cose, quello che i programmatori fanno ora è di ordini di grandezza maggiore di quello che si potrebbe fare 15 anni fa.

Lasciatemelo dire così, tra 100 anni, sarà banale installare un sistema complesso come Facebook o Google. Non sto parlando delle loro pagine web, intendo i loro data center. Chiunque sarà in grado di farlo. Sarà incorporato nei telefoni, supponendo che li usiamo ancora. MA, ci saranno ancora programmatori, e mentre potrebbero non lavorare su sistemi così "banali" tra 100 anni, lavoreranno su sistemi molto più complessi e sofisticati che nessuno qui può nemmeno cominciare a comprendere la loro portata e scala. E quei sistemi, come quelli ora, saranno di gran lunga fuori dalla portata del lavoratore d'ufficio medio perché alcune persone, chiamate programmatori, sceglieranno di specializzarsi nel portare la tecnologia di quell'era ai suoi estremi.

Ho letto questo genere di cose per quaranta anni e non ero all'inizio delle previsioni. Non è ancora successo.

COBOL era lo strumento di sviluppo originale destinato a rimuovere la necessità di programmatori di business ed era un linguaggio di livello molto più elevato rispetto all'assemblatore. Le librerie di codici (per evitare di dover scrivere il proprio codice) sono di antichità simili.

Ogni tanto succede qualcosa che permette ai non programmatori di fare qualcosa di più come il lavoro di programmazione. C'erano le "lingue di quarta generazione" degli anni '80, fogli di calcolo di fantasia come Excel, generatori di rapporti e simili. Quello che hanno fatto in modo uniforme, in caso di successo, è rimuovere alcune delle scutwork dalla programmazione e consentire ai programmatori di fare altre cose più interessanti.

Questo schema non durerà per sempre, ma avrò bisogno di qualcosa di più degli argomenti teorici e delle previsioni per convincermi che la programmazione sta davvero andando in discesa.

Il problema da COBOL ai moderni strumenti di sviluppo è che non sostituiscono la capacità di prendere una specifica inesatta e trasformarla in qualcosa di preciso e utile. Questa è l'abilità fondamentale dei programmatori e il motivo per cui non andremo via per molto tempo.

I programmatori Assembly e FORTRAN probabilmente hanno detto le stesse cose quando la programmazione strutturata e gli interpreti diffusi stavano entrando in scena.

Alla fine della giornata, il software è una creazione pensata per automatizzare qualcosa che in precedenza era stato fatto a mano. Un dipartimento di contabilità di una società moderata avrebbe in precedenza richiesto dozzine di persone, ora tutto quel lavoro può essere realizzato con il lavoro di uno o due. Di conseguenza, i post degli obiettivi si sono spostati e ora ci aspettiamo uno standard di capacità extra da un contabile.

Ci vuole più tempo per rendere i film Pixar come mai prima d'ora. Nonostante l'enorme aumento della velocità di elaborazione, insieme ad esso, gli animatori hanno richiesto complessità e dettagli sempre crescenti nelle loro scene. L'animazione del calibro Toy Story non è accettabile nel 2010 come nel 1995. Poiché i loro strumenti sono avanzati, anche le loro capacità e quindi le loro aspettative.

Quando il drag and drop o le altre metodologie di programmazione sono di dominio comune, il mondo richiederà soluzioni a problemi ancora più complessi e complessi, e avranno bisogno di programmatori che utilizzino i nuovi e fantasiosi strumenti per risolverli. I post della porta si sposteranno.

Pur condividendo la maggior parte delle risposte che sottolineano che ci sarà ancora molto lavoro da fare, darò una risposta diversa da prendere in considerazione:

Sì, lo è, e DOVREBBE essere

Sono qui per progettare una soluzione ai problemi che altri non possono. Qualsiasi cosa nel set di strumenti che impiega il mio tempo lontano dalla risoluzione dei problemi per gestire tutti i piccoli dettagli su come implementare il mio disegno è uno spreco.

L'unica ragione per cui temo di passare a un linguaggio di livello superiore o uno strumento più semplice e più astratto è che quegli strumenti spesso fanno supposizioni che mi ostacolano e richiedono il mio tempo per aggirare le ipotesi per ottenere l'implementazione desiderata.

Ci sono sempre più problemi da risolvere rispetto a buoni risolutori di problemi. Anche se l'intera catena di sviluppo diventasse così semplice, i bambini in età prescolare potrebbero usarlo, la maggior parte delle soluzioni progettate sarebbe insufficiente o abbastanza inefficiente che la gente pagherebbe per una soluzione migliore perché la maggior parte delle persone è solo cattiva nel vedere la soluzione corretta ai problemi con tutti i casi limite e che cosa è necessario prendere in considerazione per fare una buona soluzione.

Il nostro lavoro consiste nel risolvere i problemi meglio della maggior parte degli altri, la complessità della toolchain non è terribilmente rilevante nella visione d'insieme, a patto che torni e ti costruisca e costruisca qualcosa di buono.

La programmazione visiva non è meno valida o meritevole di disprezzo della programmazione basata su testo.

Ci sono alcuni deficit e sfide quando si programma visivamente, ma l'impianto idraulico sottostante è potenzialmente pericoloso quando ignorato non è monopolizzato dalle componenti visive e, in modo più rilevante, dai visual designer. L'essere sottotetto che viene ignorato rappresenta un rischio per qualsiasi sviluppo.

Se hai la possibilità di provare Labview, potresti vedere il potenziale (o anche una variante specializzata nell'ambiente Lego NXT). Anche se non senza difetti o carenze, ci sono benefici ereditari. Vedere per credere.

Anche se le tecnologie di programmazione possono cambiare, la complessità di fondo di un prodotto software è ancora lì. Se il software può essere scritto completamente utilizzando diagrammi o diagrammi di flusso (o qualche altro modo "semplice"), tutta la complessità del software deve ancora essere compresa e affrontata. Per questo motivo, è importante che i datori di lavoro abbiano programmatori che conoscono i prodotti dell'azienda al loro interno per aggiornarli o aggiungere nuove funzionalità. E ci vuole un po 'di tempo prima che i dipendenti imparino un prodotto software.

Indipendentemente da ciò che è possibile automatizzare o estrarre dallo scaffale, la maggior parte dei pacchetti software si divide in due categorie:

1. È semplice da utilizzare, ma non corrisponde esattamente a ciò di cui l'azienda ha realmente bisogno
2. È altamente personalizzabile, ma ci vuole uno specialista per capire e sfruttare la personalizzazione

Suppongo di aver dimenticato il terzo È un software standard per la produttività (email, browser, word proc, ecc.) Il software nella categoria uno porta le aziende ad assumere sviluppatori software per personalizzare il software off the shelf (se possibile). software, beh potrebbero anche assumere uno sviluppatore perché la persona che sa che il sistema personalizzabile dentro e fuori è molto ricercato (pensa SAP, PeopleSoft, ecc.) o una razza morente (si pensi a qualsiasi sistema simile a SAP e PeopleSoft che non 't abbastanza hanno la stessa penetrazione del mercato).

Ci sarà sempre bisogno di sviluppatori. Quello che sto vedendo è che più di quello che era un lavoro manuale, noioso e ripetitivo è diventato automatico (pensate di scrivere il codice per l'accesso ai dati a mano contro l'uso di un O / RM). Ciò consente agli sviluppatori di offrire più valore al business con meno sforzo.

Non prendo i tuoi argomenti:

1. Not taking time to implement best practices

tranne quello.

1. Using other's people code as much as possible (custom code as a liability)

Il riutilizzo del codice è una buona pratica. Il codice usato è testato. Ovviamente si dovrebbe usare il codice da buone fonti, che viene mantenuto e utilizzato da molti.

1. Using increasingly higher level languages to improve productivity

La produttività non è male di per sé - vero?

1. GUI based development "tools" that greatly simplify "programming" and do not require people to understand the plumbing behind the code

Se lo strumento fa il lavoro: usalo. Altrimenti: rifiutalo. Se la promessa è valida e le persone non hanno davvero bisogno di capire il codice - ben fatto! Sembra che tu dica che questa è una promessa che non regge?

(I numeri qui sono rerenderizzati automaticamente. :))

Le pratiche di programmazione non solo aumentano la produttività e riducono i costi per determinati tipi di sviluppo (la tua corsa verso il basso), ma aumentano le capacità applicative e le aspettative dei clienti (incoraggiando così una corsa verso l'alto). Testimoniare i bonus che Goole e Facebook stanno pagando per ottenere i migliori tecnologi.

Non c'è altra professione che si occupa di ingegneria dell'esistenza che si sforza di cambiare tanto quanto la programmazione. Non appena si semplifica qualcosa, si apre una lattina a nuovi problemi che generano nuove idee.

Quindi non sporcherei gli sforzi degli altri per condividere codice e soluzioni al fine di aiutarci ad avanzare verso nuove sfide, idee e esperienze utente con le cattive pratiche, le cattive abitudini e le maniere prive di umanità del praticante.

Se prendiamo le pratiche di:

• Non ci vuole tempo per implementare le migliori pratiche
• Utilizzare il codice di altre persone il più possibile (codice personalizzato come responsabilità)

WTF? Intendevi che questa lista fosse incoerente? Le liste dovrebbero provenire dallo stesso lato per ciascun elemento piuttosto che passare avanti e indietro senza preavviso. Quindi la tua lista dovrebbe leggere:

Se prendiamo le pratiche di:

• Non ci vuole tempo per implementare le migliori pratiche
• Non utilizzare il codice di altre persone il più possibile (codice personalizzato come responsabilità)