La programmation est-elle un métier dans une course vers le bas? [fermé]

Il me semble que l'industrie de la programmation est dans une course vers le bas. Si nous prenons les pratiques de:

1. Ne pas prendre le temps de mettre en œuvre les meilleures pratiques
2. Utiliser le code des autres personnes autant que possible (code personnalisé en tant que responsabilité)
3. Utiliser des langages de plus en plus avancés pour améliorer la productivité
4. Des "outils" de développement basés sur une interface graphique qui simplifient grandement la "programmation" et ne nécessitent pas que les gens comprennent la plomberie qui se cache derrière le code

Ces choses impliquent pour moi que nous sommes dans la course pour devenir comme n'importe quel autre employé de bureau. Il est dans l’intérêt de l’employeur que les choses ne requièrent pas de compétences (plus faciles à remplacer), que les choses soient préconstruites (moins de temps de projet).

Ce que je veux dire, c'est que a) existe-t-il un décalage entre les compétences et les intérêts économiques de l'employeur? et b) le cas échéant, comment l'atténuer pour faire respecter les normes professionnelles?

Je pense que vous avez posé une question très poignante.

La création d’outils de codage pour l’interface graphique met les programmeurs hors de travail autant que les robots supprime les travailleurs de la chaîne de montage. À mon avis, s'il y a une perte d'emplois, il y a aussi un changement dans la position des prochains emplois.

La technologie nécessaire pour accomplir une tâche change, mais la tâche doit encore être complétée: les voitures doivent encore être fabriquées / assemblées avant de pouvoir être conduites; le code / la logique métier doit encore être mis en place pour que l'application fonctionne.

Les changements technologiques présentent des choix pour les programmeurs: apprenez la programmation basée sur l'interface graphique ou les outils d'interface graphique de programme ... ou ... autre chose.

Il peut y avoir un décalage entre les compétences des employés et les intérêts de l’employeur, mais pas pour longtemps, surtout si l’employeur est averti. Il est donc dans l'intérêt de l'employeur et de l'employé qu'ils recherchent ce qui est dans leur intérêt mutuel. Mais l'un sera inévitablement en avance sur l'autre. J'espère que c'est vous (-:

Meilleurs vœux,

KM

Aux tendances que vous mentionnez, j'en ajouterais une de plus, à laquelle IMHO les explique:

Il y a beaucoup plus de programmeurs (nécessaires) que jamais.

Le nombre de tâches qui nécessitent ou incluent la programmation est en augmentation constante et à un taux encore plus élevé que celui du nombre de programmeurs. De nos jours, il y a plusieurs micropuces dans une voiture moyenne. Dans 5 ans, il pourrait y avoir une puce dans votre réfrigérateur et votre grille-pain. Dans 10 ans, vos sous-vêtements? ... Et quelqu'un doit produire tout ce logiciel pour les faire fonctionner. Tous les efforts possibles sont donc déployés pour automatiser tout ce qui est automatisable et pour améliorer la "productivité" (quelle que soit sa définition). Et de plus en plus de cerveaux frais sont recrutés.

Cela implique que la majorité des programmeurs actifs actuels sont inexpérimentés et / ou mal préparés à leur travail. Il faut plusieurs années pour acquérir un niveau d'expérience suffisant et apprendre continuellement pour rester en place. En bout de ligne, de plus en plus d'emplois de programmation deviennent de moins en moins difficiles. Mais il y a encore suffisamment de défis pour ceux qui les recherchent .

Laissez-moi jouer l'avocat du diable contre vos points ci-dessus:

Ne pas prendre le temps de mettre en œuvre les meilleures pratiques

Beaucoup de gens ne le font pas, beaucoup de gens le font. Il y a dix ans, lorsque j'ai découvert les tests unitaires et l'approche agile, aucun de mes collègues n'avait la moindre idée de ce que c'était. De nos jours, il s’agit d’un matériel presque standard dans les universités et de nombreux nouveaux diplômés le comprennent déjà.

Utiliser le code des autres personnes autant que possible (code personnalisé en tant que responsabilité)

Par opposition à quoi? Réinventer la roue? Ou en utilisant le code d'autres personnes pour éviter cela?

Je pense qu'il est important de noter que nous sommes payés (principalement) pour résoudre des problèmes, et écrire du code n'est pas la fin, mais seulement le moyen d'y parvenir . Si un problème peut être résolu sans écrire une seule ligne de code, le client est toujours content. Surtout si nous parvenons ainsi à produire une solution plus fiable, plus rapide et moins chère. Je ne vois pas de problème avec ça.

Utiliser des langages de plus en plus avancés pour améliorer la productivité

Par opposition à tout coder en assembleur? ;-)

Des "outils" de développement basés sur une interface graphique qui simplifient grandement la "programmation" et ne nécessitent pas que les gens comprennent la plomberie qui se cache derrière le code

À mon humble avis, tout outil peut être mal utilisé. Ce qui ne veut pas dire que les constructeurs d’interface graphique étaient nécessairement parfaits, voire bons - la plupart (ou du moins certains) sont utilisables dans les limites de leurs possibilités. Mais si quelqu'un ne connaît pas ces limites, s'agit-il d'un outil ou d'un utilisateur?

En général, je crois (bien que je n’aie aucune preuve à l’évidence) que, à l’époque des cartes perforées et du code machine, à peu près la même proportion du code existant était horrible qu’aujourd’hui, à la fois

• la quantité globale de code, et
• les chances des étrangers jamais voir un tel code

était beaucoup beaucoup moins.

Maintenant, avec Internet et le Daily WTF, nous sommes quotidiennement exposés aux pires exemples. C'est un peu comme regarder toutes les nouvelles sur le terrorisme, les tremblements de terre et les divorcées, et crier à quel point ce monde est devenu dangereux et immoral.

Vous résumez correctement la situation, mais vous en interprétez complètement le sens.

Au fur et à mesure que le logiciel devient plus puissant, les tâches qu'il prend avec elle. Donc, bien sûr, il n’est peut-être plus nécessaire aujourd’hui d’être un programmeur de base de données pour créer une base de données de contacts téléphoniques lorsque vous pouvez utiliser Access. Et il n’est peut-être pas nécessaire d’être un programmeur Web pour créer un blog lorsque vous pouvez vous rendre sur wordpress. Mais, alors qu'il était il y a 15 ans, il était nécessaire d'être un programmeur pour faire ces choses, mais ce que font les programmeurs à l'heure actuelle est bien plus grand que ce qu'il était possible de faire il y a 15 ans.

Permettez-moi de formuler les choses ainsi: dans 100 ans, il sera trivial de mettre en place un système aussi complexe que Facebook ou Google. Je ne parle pas de leurs pages Web, je parle de leurs centres de données. Tout le monde pourra le faire. Cela sera intégré aux téléphones, en supposant que nous les utilisions encore. MAIS, il y aura toujours des programmeurs, et même s’ils ne travaillent peut-être pas sur de tels systèmes «triviaux» dans 100 ans, ils travailleront sur des systèmes tellement plus complexes et sophistiqués que personne ici ne pourra même commencer à en comprendre la portée et la pertinence. échelle. Et ces systèmes, comme ceux d’aujourd’hui, seront bien loin du personnel de bureau moyen, car certains, appelés programmeurs, choisiront de se spécialiser pour pousser la technologie de cette époque à son extrême.

Je lis ce genre de choses depuis quarante ans maintenant et je n’étais pas au début des prédictions. Cela n'est pas encore arrivé.

COBOL était l'outil de développement original destiné à supprimer le besoin de programmeurs professionnels et constituait un langage de niveau beaucoup plus élevé que l'assembleur. Les bibliothèques de code (pour ne pas avoir à écrire son propre code) sont d'une antiquité similaire.

De temps en temps, quelque chose apparaît qui permet aux non-programmeurs de faire quelque chose qui ressemble davantage à du travail de programmation. Il y a eu les "langues de quatrième génération" des années 1980, des feuilles de calcul sophistiquées comme Excel, des générateurs de rapports, etc. En cas de succès, ce qu’ils ont fait de façon uniforme, c’est de supprimer une partie de la complexité de la programmation et de permettre aux programmeurs de faire d’autres choses plus intéressantes.

Ce schéma ne durera pas éternellement, mais je vais avoir besoin de quelque chose de plus que des arguments théoriques et des prédictions pour me convaincre que la programmation est en train de se dégrader.

Le problème entre COBOL et les outils de développement modernes est qu’ils ne remplacent pas la possibilité de prendre une spécification inexacte et de la transformer en quelque chose de précis et utile. C’est la capacité fondamentale des programmeurs et la raison pour laquelle nous ne partirons pas avant longtemps.

Les programmeurs d'Assembly et de FORTRAN ont probablement dit la même chose lorsque la programmation structurée et les interprètes répandus entraient en scène.

À la fin de la journée, le logiciel est une création destinée à automatiser quelque chose qui était auparavant fait à la main. Un département de comptabilité dans une société modérée aurait déjà eu besoin de dizaines de personnes. Désormais, tout ce travail peut être accompli par le travail d'une ou deux personnes. En conséquence, les postes de but ont été déplacés et nous attendons maintenant cette norme de capacité supplémentaire de la part d’un comptable.

Le rendu des films par Pixar est plus long que jamais. En dépit de l'énorme augmentation de la vitesse de calcul, les animateurs ont exigé une complexité et des détails sans cesse croissants dans leurs scènes. L’animation de calibre Toy Story n’est pas acceptable en 2010, contrairement à 1995. Au fur et à mesure du développement de leurs outils, leurs capacités et leurs attentes aussi.

Lorsque le glisser-déposer ou d'autres méthodes de programmation sont monnaie courante, le monde exigera des solutions à des problèmes encore plus complexes et complexes, et il faudra que les programmeurs utilisent ces nouveaux outils sophistiqués pour les résoudre. Les poteaux de but vont bouger.

Bien que je sois d’accord avec la plupart des réponses qui indiquent qu’il y aura encore beaucoup de travail à faire, je vais vous donner une réponse différente à considérer:

Oui, c’est le cas.

Je suis ici pour concevoir une solution à des problèmes que d'autres ne peuvent pas. Tout ce qui, dans les outils, me permet de perdre du temps à résoudre des problèmes et à traiter tous les détails de la mise en œuvre de ma conception est un gaspillage.

La seule raison pour laquelle je craindrais de passer à un langage de niveau supérieur ou à un outil plus simple et plus abstrait, c’est que ces outils font souvent des hypothèses qui me gênent et me demandent du temps pour les contourner afin d’obtenir la mise en œuvre souhaitée.

Il y a toujours plus de problèmes à résoudre que de bons résolveurs de problèmes. Même si toute la chaîne de développement devenait si simple, les enfants d'âge préscolaire pourraient l'utiliser et si-ce que vous devez considérer pour faire une bonne solution.

Notre travail consiste à résoudre les problèmes mieux que la plupart des autres; la complexité de la chaîne d'outils n'est pas très pertinente dans une vue d'ensemble, dans la mesure où cela vous échappe et vous permet de construire et de construire quelque chose de bien.

Même si les technologies de programmation peuvent changer, la complexité sous-jacente d'un logiciel est toujours là. Si le logiciel peut être entièrement écrit à l'aide de diagrammes ou de diagrammes (ou d'une autre manière «simple»), toute la complexité du logiciel doit encore être comprise et traitée. Pour cette raison, il est important pour les employeurs de disposer de programmeurs connaissant parfaitement les produits de l'entreprise afin de les mettre à jour ou d'ajouter de nouvelles fonctionnalités. Et cela peut prendre un certain temps aux employés pour apprendre un logiciel.

Peu importe ce que vous pouvez automatiser ou retirer du commerce, la plupart des logiciels fournis entrent dans deux catégories:

1. C'est simple à utiliser, mais cela ne correspond pas vraiment à ce dont l'entreprise a réellement besoin
2. Il est hautement personnalisable, mais il faut un spécialiste pour comprendre et tirer parti de la personnalisation.

J'imagine que j'ai oublié le troisième logiciel de productivité standard (courrier électronique, navigateur, traitement de texte, etc.). Le logiciel de la première catégorie amène les entreprises à embaucher des développeurs pour personnaliser le logiciel standard (si cela est possible). ils pourraient aussi bien engager un développeur, car la personne qui connaît ce système personnalisable est très recherchée (pensez à SAP, PeopleSoft, etc.) ou à une race en voie de disparition (pensez à tout système similaire à SAP et PeopleSoft avoir la même pénétration du marché).

Il y aura toujours un besoin de développeurs. Ce que je constate, c’est que la plupart des tâches manuelles, fastidieuses et répétitives sont devenues automatisées (pensez à écrire du code pour l’accès manuel aux données plutôt qu’à l’utilisation d’un O / RM). Cela permet aux développeurs de fournir plus de valeur à l'entreprise avec moins d'effort.

Je ne prends pas vos arguments:

1. Ne pas prendre le temps de mettre en œuvre les meilleures pratiques

excepté.

1. Utiliser le code des autres personnes autant que possible (code personnalisé en tant que responsabilité)

La réutilisation du code est une pratique exemplaire. Le code utilisé est testé. Bien sûr, vous devriez utiliser du code provenant de bonnes sources, qui est maintenu et utilisé par beaucoup.

1. Utiliser des langages de plus en plus avancés pour améliorer la productivité

La productivité n'est pas mauvaise en soi, n'est-ce pas?

1. Des "outils" de développement basés sur une interface graphique qui simplifient grandement la "programmation" et ne nécessitent pas que les gens comprennent la plomberie qui se cache derrière le code

Si l'outil fait le travail: Utilisez-le. Si non: refusez. Si la promesse tient, et que les gens n'ont vraiment pas besoin de comprendre le code - bravo! Vous semblez dire que c'est une promesse qui ne tient pas?

(Les numéros ici sont automatiquement rendus de nouveau faux. :))

La programmation visuelle n’est pas moins valable et mérite le mépris que la programmation textuelle.

La programmation visuelle présente certains déficits et défis, mais la plomberie du composant sous-jacent étant potentiellement périlleuse si elle est ignorée, elle n’est pas monopolisée par les composants visuels et, plus important encore, par les concepteurs visuels. Ignorer la plomberie sous-jacente est un risque pour tout développement.

Si vous avez la possibilité d'essayer Labview, vous en verrez peut-être le potentiel (ou même une variante spécialisée dans l'environnement Lego NXT). Bien que non sans défauts ou lacunes, il existe des avantages hérités. Voir c'est croire.

Les pratiques de programmation augmentent non seulement la productivité et réduisent les coûts de certains types de développement (votre course vers le bas), mais augmentent les capacités des applications et les attentes des clients (encourageant ainsi une course vers le haut). Soyez témoin des bonus que Goole et Facebook paient pour obtenir les meilleurs technologues.

Aucune autre profession s'occupant d'ingénierie de l'existence ne cherche autant à changer que la programmation. Dès que vous simplifiez quelque chose, vous ouvrez une boîte de dialogue à de nouveaux problèmes qui génèrent de nouvelles idées.

Donc, je ne souillerais pas les efforts des autres pour partager le code et les solutions afin de nous aider à avancer vers de nouveaux défis, idées et expériences d'utilisateurs avec les mauvaises pratiques, les mauvaises habitudes et les mœurs dépourvues d'humanisme de chaque pratiquant.

Si nous prenons les pratiques de:

WTF? Voulez-vous dire pour que cette liste soit incohérente? Les listes doivent provenir du même côté pour chaque élément plutôt que de changer d'avant en arrière. Ainsi, votre liste devrait se lire comme suit:

Si nous prenons les pratiques de: