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

Mi sembra che l'industria della programmazione sia in corsa verso il basso. Se prendiamo le pratiche di:

1. Non prendere tempo per attuare le migliori pratiche
2. Utilizzare il codice di altre persone il più possibile (codice personalizzato come responsabilità)
3. Utilizzo di linguaggi di livello sempre più elevato per migliorare la produttività
4. "Strumenti" di sviluppo basati sulla GUI che semplificano notevolmente la "programmazione" e non richiedono alle persone di comprendere le tubature alla base del codice

Queste cose implicano per me che siamo in corsa per diventare come qualsiasi altro impiegato. È nell'interesse del datore di lavoro che le cose non richiedano abilità (più facili da sostituire), che le cose siano precompilate (meno tempo del progetto).

Il mio punto qui è che a) esiste un disallineamento tra competenza e interessi economici del datore di lavoro? e b) se esiste, come lo mitiga per far rispettare gli standard professionali?

Penso che tu abbia posto una domanda molto toccante.

La creazione di strumenti di codifica della GUI mette i programmatori fuori dal lavoro tanto quanto i robot mettono fuori servizio i lavoratori della catena di montaggio. A mio avviso, mentre vi è una perdita di posti di lavoro, c'è anche un cambiamento nel luogo in cui si trovano i lavori successivi.

La tecnologia per eseguire un'attività cambia, ma l'attività deve ancora essere completata: le auto devono ancora essere realizzate / assemblate prima di poter essere guidate; la logica di codice / business deve ancora essere messa insieme affinché l'applicazione funzioni.

I cambiamenti nella tecnologia presentano scelte per i programmatori: apprendi la programmazione basata sulla GUI o programma gli strumenti della GUI ... o ... qualcos'altro.

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

Auguri,

KM

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

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

La quantità di compiti che richiedono o includono la programmazione è in costante aumento e ad un ritmo persino superiore rispetto al numero di programmatori. Oggi ci sono diversi microchip in un'auto media. Tra 5 anni potrebbe esserci un chip nel tuo frigorifero e nel tuo tostapane. Tra 10 anni, la tua biancheria intima? ... E qualcuno deve produrre tutto quel software per farlo funzionare. Quindi c'è ogni sforzo possibile per automatizzare tutto ciò che è automatizzabile e per migliorare la "produttività" (comunque sia definita). E vengono reclutati sempre più cervelli freschi.

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 arrivare a un livello adeguato di esperienza e ci vuole un apprendimento costante per rimanere lì. La linea di fondo è che sempre più lavori di programmazione stanno diventando sempre meno impegnativi. Ma ci sono ancora abbastanza sfide per chiunque le stia cercando .

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

Non prendere tempo per attuare le migliori pratiche

Molte persone non lo fanno, molte persone lo fanno. Dieci 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. Oggi è quasi materiale standard nelle università, quindi molti neolaureati lo capiscono già.

Utilizzare il codice di altre persone il più possibile (codice personalizzato come responsabilità)

Al contrario di cosa? Reinventare la ruota? O usando il codice di altre persone per evitarlo?

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

Utilizzo di linguaggi di livello sempre più elevato per migliorare la produttività

Al contrario di codificare tutto in assembly? ;-)

"Strumenti" di sviluppo basati sulla GUI che semplificano notevolmente la "programmazione" e non richiedono alle persone di comprendere le tubature alla base del codice

IMHO qualsiasi strumento può essere utilizzato in modo improprio. Il che non vuol dire che i costruttori della GUI fossero necessariamente perfetti o addirittura buoni - la maggior parte (o almeno alcuni) di loro 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 ci sono prove per dimostrarlo) che ai tempi delle schede perforate e dei codici macchina, approssimativamente la stessa proporzione del codice esistente era orribile come ora, solo entrambi

• la quantità complessiva di codice e
• le possibilità che gli estranei vedano mai tale codice

era molto molto meno.

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

Riassumi la situazione correttamente, ma interpreti completamente il significato.

Man mano che il software diventa più potente, i compiti che assume su scala. Pertanto, al giorno d'oggi potrebbe non essere necessario 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 è ordini di grandezza maggiori di quello che si potrebbe fare 15 anni fa.

Lasciatemi 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 iniziare a comprendere il loro scopo e scala. E quei sistemi, come quelli attuali, saranno ben lontani dall'impiegato medio perché alcune persone, chiamate programmatori, sceglieranno di specializzarsi per spingere al massimo la tecnologia di quell'epoca.

Ho letto quel genere di cose per quarant'anni ormai, e non ero all'inizio delle previsioni. Non è ancora successo.

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

Ogni tanto, succede qualcosa che consente ai non programmatori di fare qualcosa di più come il lavoro di programmazione. C'erano "lingue di quarta generazione" degli anni '80, fogli di calcolo elaborati come Excel, generatori di rapporti e simili. Ciò che hanno fatto uniformemente, in caso di successo, è rimuovere parte dello scutwork dalla programmazione e consentire ai programmatori di fare altre cose più interessanti.

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

Il problema di 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 stiamo andando via per molto tempo.

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

Alla fine, 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 precedentemente richiesto dozzine di persone, ora tutto quel lavoro può essere svolto dal lavoro di uno o due. Di conseguenza, i pali dell'obiettivo si sono spostati e ora ci aspettiamo lo standard di capacità extra da un contabile.

Pixar impiega più tempo per eseguire il rendering di film che mai. Nonostante l'enorme aumento della velocità di elaborazione, insieme ad esso, gli animatori hanno richiesto complessità e dettagli sempre maggiori nelle loro scene. L'animazione del calibro di Toy Story non è accettabile nel 2010 come lo era nel 1995. Poiché i loro strumenti sono avanzati, così hanno le loro capacità e quindi le aspettative.

Quando il trascinamento della selezione o altre metodologie di programmazione sono all'ordine del giorno, il mondo richiederà soluzioni a problemi ancora più difficili e complessi, e avranno bisogno di programmatori che utilizzino quegli strumenti fantasiosi più recenti per risolverli. I pali dell'obiettivo si sposteranno.

Mentre sono d'accordo con la maggior parte delle risposte che sottolineano che ci sarà ancora molto lavoro da fare, darò una risposta diversa da considerare:

Sì, lo è, e DOVREBBE essere

Sono qui per progettare una soluzione a problemi che altri non possono. Qualsiasi cosa nel set di strumenti che mi toglie il tempo di risolvere i problemi per gestire tutti i piccoli dettagli su come implementare il mio design è uno spreco.

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

Ci sono sempre più problemi da risolvere di quanti ne risolvano i problemi. Anche se l'intera catena di sviluppo diventasse così semplice, i bambini in età prescolare potrebbero usarla la maggior parte delle soluzioni progettate sarebbe insufficiente o abbastanza inefficiente da permettere alle persone di pagare per una soluzione migliore perché la maggior parte delle persone non è in grado di vedere la soluzione corretta ai problemi con tutti i casi limite e what-if che devi considerare per fare una buona soluzione.

Il nostro compito è risolvere i problemi meglio della maggior parte degli altri, la complessità della toolchain non è terribilmente rilevante nella visione d'insieme, purché si allontani e ti permetta di costruire e costruire qualcosa di buono.

Anche se le tecnologie di programmazione possono cambiare, la complessità di base di un prodotto software è ancora presente. Se il software potesse essere scritto completamente usando diagrammi o diagrammi di flusso (o in 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 fine di aggiornarli o aggiungere nuove funzionalità. E può richiedere 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 software in pacchetto rientra in due categorie:

1. È semplice da usare, ma non corrisponde esattamente a ciò di cui l'azienda ha veramente bisogno
2. È altamente personalizzabile, ma richiede uno specialista per comprendere e sfruttare la personalizzazione

Immagino di aver dimenticato il terzo software di produttività standard (e-mail, browser, word proc, ecc.) Il software della categoria uno porta le aziende ad assumere sviluppatori di software per personalizzare il software standard (se possibile). Il software di categoria 2, beh potrebbero anche assumere uno sviluppatore perché la persona che conosce quel sistema personalizzabile dentro e fuori è molto ricercata (pensa a SAP, PeopleSoft, ecc.) o una razza morente (pensa a un sistema simile a SAP e PeopleSoft che non è del tutto avere la stessa penetrazione nel mercato).

Ci sarà sempre bisogno di sviluppatori. Quello che sto vedendo è che più di quello che era un lavoro manuale, noioso e ripetitivo è diventato automatizzato (pensa a scrivere il codice per l'accesso ai dati a mano anziché usando un O / RM). Ciò consente agli sviluppatori di offrire più valore all'azienda con meno sforzi.

Non accetto i tuoi argomenti:

1. Non prendere tempo per attuare le migliori pratiche

salvo che.

1. Utilizzare il codice di altre persone il più possibile (codice personalizzato come responsabilità)

Il riutilizzo del codice è una buona pratica. Il codice usato è stato testato. Ovviamente dovresti usare il codice proveniente da buone fonti, che è gestito e utilizzato da molti.

1. Utilizzo di linguaggi di livello sempre più elevato per migliorare la produttività

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

1. "Strumenti" di sviluppo basati sulla GUI che semplificano notevolmente la "programmazione" e non richiedono alle persone di comprendere le tubature alla base del codice

Se lo strumento fa il lavoro: usalo. In caso contrario: rifiutalo. Se la promessa è valida e le persone non hanno davvero bisogno di capire il codice, ben fatto! Sembri dire che questa è una promessa che non regge?

(I numeri qui vengono automaticamente resi di nuovo errati. :))

La programmazione visiva non è meno valida o meritevole di disprezzo della programmazione testuale.

Ci sono alcuni deficit e sfide durante la programmazione visiva, ma l'impianto idraulico dei componenti sottostanti è potenzialmente pericoloso se ignorato non è monopolizzato dai componenti visivi e, soprattutto, dai progettisti visivi. L'impianto idraulico sottostante 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 privo di difetti o carenze, ci sono vantaggi ereditari. Vedere per credere.

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). Prova i bonus che Goole e Facebook stanno pagando per ottenere i migliori tecnici.

Non esiste altra professione che si occupi 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 a muoverci verso nuove sfide, idee ed esperienze degli utenti con le cattive pratiche, le cattive abitudini e le maniere del singolo praticante prive dell'umanesimo.

Se prendiamo le pratiche di:

WTF? Intendevi che questo elenco fosse incoerente? Gli elenchi dovrebbero provenire dalla stessa parte per ciascun elemento anziché passare avanti e indietro senza preavviso. Quindi il tuo elenco dovrebbe contenere:

Se prendiamo le pratiche di: