Attentes entre diplômés et réalité [fermé]

Lorsque nous choisissons ce que nous voulons étudier, que nous faisons avec notre carrière et nos vies, nous attendons tous de voir ce que cela va devenir. Maintenant que je suis dans l’industrie depuis presque une décennie, j’ai réfléchi un peu à ce que je pensais (à l’époque où j’étudiais en informatique) programmer la vie professionnelle allait être comme et comment être.

Mes deux plus gros chocs (ou devrais-je dire, attentes déçues) sont de loin la quantité de travail de maintenance impliquée dans les logiciels et le manque général de professionnalisme:

1. Maintenance : À l'université, nous avons tous appris que la majeure partie du travail logiciel est la maintenance des systèmes existants. J'ai donc su m'attendre à cela dans l'abstrait. Mais je n’ai jamais imaginé à quel point cela serait écrasant. Peut-être que c'est quelque chose que j'ai glacé mentalement, et espéré que je construirais beaucoup plus de nouvelles choses cool. Mais il est vrai que la plupart des travaux sont essentiellement axés sur la maintenance, la correction de bogues et le support.

2. Manque de professionnalisme : À l'université, j'ai toujours eu l'impression que les logiciels commerciaux sont très orientés processus et rigoureusement conçus. J'avais des images de processus ISO, de nombreuses documentations techniques, chaque fonctionnalité et chaque bogue étant strictement documentés, ainsi qu'un environnement généralement professionnel. Cela a été un choc énorme de se rendre compte que la plupart des entreprises de logiciels ne fonctionnent pas différemment d'une équipe d'étudiants travaillant sur un projet d'un semestre important. Et j'ai aussi bien travaillé dans le petit magasin de hack agile que dans les moyennes entreprises. Bien que je ne dirais pas que cela a toujours été carrément "non professionnel", on a vraiment le sentiment que l'industrie du logiciel (dans son ensemble) est loin de la discipline d'ingénierie forte à laquelle je m'attendais.

Est-ce que quelqu'un d'autre a vécu des expériences similaires? En quoi vos attentes sur ce que serait notre profession seraient-elles différentes de la réalité?

Je te sens mec. En fait, je viens d'obtenir mon diplôme il y a un peu plus d'un an, j'ai sauté sur la première offre d'emploi qui m'a été présentée et qui a été le choc le plus important de ma vie.

Choses que je n'attendais pas:

Le stress scolaire et le stress professionnel ne sont pas les mêmes - Le stress de travailler sur un projet scolaire avec des amis ou de travailler en solo, même avec l'échéance imminente d'une thèse ou la défense d'un projet spécial, ne se compare pas au stress de délais de travail apparemment déraisonnables, de problèmes de communication , (un peu de politique de bureau) et des temps difficiles.

Manque de meilleures pratiques - Identique à votre expérience en matière de professionnalisme. Avant de prendre mon premier emploi et pendant ma période de formation, je me suis empressé de passer en revue et de lire les meilleures pratiques en matière de programmation et de génie logiciel. Ceux-ci ne sont pas suivis aussi bien qu'ils le devraient pour des raisons peu pratiques et, pour être juste, pratiques. Et parfois, votre connaissance compte très peu contre d’autres qui ont simplement peur de l’inconnu et traitent ces pratiques avec dédain.

Ce qu’ils enseignaient à l’école n’était que la partie émergée de l’iceberg - Pensant que c’était assez pour apprendre ce que j’avais appris en autodidacte et en classe, j’étais choqué, j’avais le moins du mal à dire que je regardais abasourdi le premier code que j’étais censé maintenir. Un grand nombre des compétences que j'utilise actuellement ont été acquises au travail ou au cours de mon travail et je me demande si je pourrais l'avoir fait sans diplôme universitaire. XD

L'importance de la communication - m'a fait comprendre à quoi servaient tous ces cours d'anglais. Avant le monde réel, je ne pouvais pas voir la pertinence d'avoir trois ou quatre cours d'anglais différents à l'université quand ils étaient enseignés depuis que nous étions en première année. Votre travail ne vous est d'aucune utilité lorsque vous pouvez parler à un ordinateur sans parler aux gens.

La plupart du travail que vous faites n'est pas révolutionnaire

Quand à Uni, j'ai travaillé sur des routines d'IA pour contrôler des robots jouant au football, j'ai construit des compilateurs et piraté des noyaux de systèmes d'exploitation.

Mais dans le monde réel, 99% ^* du développement logiciel est en fait assez ennuyeux. J'ai toujours admiré les architectes ou les constructeurs qui, lorsqu'on leur a demandé "que faites-vous dans la vie?" peut pointer vers un bâtiment ou autre chose et dire « je l'ai fait que ». Mais la plupart des développeurs de logiciels ne peuvent pas faire cela. Quand on lui demande "Que faites-vous dans la vie?" ce qui me rapproche le plus de ce que j’ai pu arriver c’est quand j’ai travaillé pour une entreprise qui construisait un logiciel qui traitait les SMS pour les stations de radio, etc. Je pourrais dire: "vous savez, quand vous envoyez un message texte à une station de radio pour voter pour une chanson, eh bien, j’ai écrit le logiciel qui traite ces votes et ces choses-là. " Toujours pas aussi cool que de pouvoir pointer un bâtiment et dire "J'ai construit ça".

Bien sûr, il y a des gens qui peuvent dire "j'ai travaillé sur Windows" ou autre chose, mais je suis sûr qu'ils ne disent à personne que de peur que la question suivante ne soit "je ne parviens pas à faire fonctionner mon imprimante, pouvez-vous résoudre ce problème pour moi? "

^* et 62% de toutes les statistiques sont fabriquées sur place

Si vous regardez le logiciel aujourd'hui, à travers le prisme de l'histoire de l'ingénierie, c'est certainement une sorte d'ingénierie - mais c'est le genre d'ingénierie que les gens sans le concept d'arc ont fait. La plupart des logiciels actuels ressemblent beaucoup à une pyramide égyptienne avec des millions de briques empilées les unes sur les autres, sans intégrité structurelle, mais utilisant la force brutale et des milliers d'esclaves. -Alan Kay, 2004

l'interview complète: http://queue.acm.org/detail.cfm?id=1039523

Je ne suis pas un vétérinaire de l'industrie; Bien au contraire, je suis un diplômé récent mais issu d'une grande école de la CS aux États-Unis. Mais mon sentiment instinctif est que la façon dont nous construisons les logiciels est fausse. Plutôt que de cliquer sur le bouton de pause et de réexaminer les principes fondamentaux de notre programmation, nous venons de nous dépêcher en utilisant des modèles obsolètes des années 50, des années 60 en ajoutant continuellement un peu de sucre. Si nous continuons ainsi, nous ne pourrons jamais nous en sortir. Les humains ne peuvent tout simplement pas gérer la complexité de choses qui sont la taille de la base de code MS Windows. Nous avons besoin d'une nouvelle façon. Je ne sais pas ce que c'est.

Je pense que c'est la raison sous-jacente du sentiment que les grands et les petits éditeurs de logiciels semblent créer des logiciels en les piratant ensemble sans aucune compréhension profonde des principes fondamentaux.

Je n'ai pas obtenu de diplôme, mais j'en ai appris un peu dans les bibliothèques et les laboratoires des universités et des collèges.

• Big Iron - Les technologies qu’ils enseignaient étaient principalement des ordinateurs centraux et des mini-ordinateurs. Le doyen d'une université m'a dit que je ne pourrais pas obtenir d'emploi, car je ne savais même pas ce qu'est un fichier maître. Je n'avais pas l'intention de travailler sur des ordinateurs centraux car je ne pouvais pas m'en payer un, mais je n'allais pas être assez stupide pour ne pas être légèrement préparé. VAXen était cool, et j'avais hâte d'être payé pour coder sur mon propre Micro VAX dans mon box. Quel dommage que ce marché ait totalement implosé. (Il s'est avéré que j'avais deux postes sur des ordinateurs centraux… en tant que contractant pour IBM.)

• Génie logiciel - À la suite de la programmation structurée, de SASD et d'autres méthodologies de conception, vous avez peut-être pensé que nous allions être de vrais ingénieurs. J'ai fait. Mais les enseignants donnaient très peu de conseils sur les techniques de conception que je lisais à la bibliothèque. Les étudiants ont dû se débrouiller seuls et micros ont rendu la tâche trop facile pour trouver du code jusqu'à ce qu'ils obtiennent une réponse qui leur convient. Je n'avais pas réalisé à quel point c'était pire sur le marché du travail. D'une manière ou d'une autre, j'ai dû créer pas mal de nouveau code, donc ce n'était pas si ennuyeux. Mais j’ai aussi pris beaucoup de responsabilités et c’était déjà assez grave, c’était comme un nouveau projet car je devais corriger beaucoup de code. C'était à la fois une recherche de fonctionnalités existantes et la création d'un nouveau code (son remplacement); des outils d'écriture pour simplifier le processus et mettre en place une meilleure gestion de projet.

• Carrière dans les hautes technologies - C'est une chose quand les écoles ont de vieux bâtiments et de l'équipement (l'équipement de cartes perforées a été remplacé un semestre avant mon début… en 1984), mais quand vous travaillez dans un entrepôt mal éclairé ou pour un patron qui raccroche sur les clients qui appellent la ligne d'assistance, vous commencez à réaliser que votre description de poste n'inclut pas la possibilité de faire cuire du pop-corn avec un laser de 5 mégawatts.

• Le développement est principalement un travail d'équipe. Cela signifie que la communication (parlée et lue), la lecture du code d'autrui et la réutilisation des modules précédents (internes et externes) sont quelque chose à faire presque tous les jours. Dans mon collège, au moins, je devais coder avec plus de gens à quelques occasions, alors je pensais que l'essentiel du travail consistait à coder seul, dans le désert. Ce n'est pas.
• Expliquer des choses à des non-développeurs est difficile (également couvert pour le premier point), et il est de votre responsabilité de faire valoir vos points (pas de l'autre 99% du monde).
• Le bon test est le test qui échoue. (la première fois, au moins) Et, bien sûr, il n’existe pas de code sans bug. Vous n'êtes pas un mauvais programmeur si vous avez des bugs. Les bugs ne sont qu’une partie (très importante et fastidieuse) de votre travail.
• Il n'y a pas de balles d'argent. Chaque technologie a ses avantages et ses inconvénients.
• Collège ne vous enseigne pas les technologies de pointe. Mais aussi, 90% des œuvres utilisent des technologies assez anciennes. Ce qui est d'ailleurs parfois nécessaire.
• Les personnes non techniques décident des solutions techniques , principalement pour des raisons ésotériques telles que la maintenance, les partenariats, la disponibilité des travailleurs ...
• Vous venez juste de commencer , jeune padawan .

Depuis lors, j'ai commencé à prendre conscience du fait que le codage est un travail que vous faites en collaboration avec plus de gens, spécialement maintenant que l'open source est plus important. Mais quand j'étais au collège (fin des années 90), j'étais convaincu que j'allais faire des choses à partir de rien et ne jamais regarder dans le code des autres ou avoir à me coordonner avec les autres ...

En rétrospective, l’un des meilleurs éléments de ma vie est l’ apprentissage et l’ enseignement aux autres .

• La programmation informatique est non physique et non intuitive.
  • Lorsqu'un constructeur de maisons termine son travail, il peut se promener et voir immédiatement si quelque chose ne va pas. Un bogue de programmation informatique ne peut pas être découvert de la même manière et peut se cacher dans le système pendant des mois, voire des décennies.
  • Même si un programmeur peut avoir l’air de ressentir un morceau de code source lors de la révision du code, il n’est pas garanti de repérer chaque erreur contenue dans le code. Cependant, un ordinateur serait capable de reproduire exactement l'erreur à chaque fois en exécutant le programme avec certaines entrées. Ainsi, la compréhension humaine d'un morceau de code source est toujours un modèle imparfait de l'essentiel, à savoir qu'il s'agisse d'instructions à un ordinateur.
• Il est très facile de coder un programme qui gère les cas les plus courants, mais échoue complètement à gérer les cas extrêmes.
  • Dans d'autres disciplines, il est relativement facile d'appliquer une mesure corrective après coup. Il peut même y avoir un corpus de connaissances spécifiquement consacré aux actions correctives. Il n'y a pas une telle chose dans le développement de logiciels.
  • Heureusement, le développement piloté par les tests permet de codifier les cas extrêmes que le code est supposé gérer.
  • Ajouté D'autre part, certaines méthodologies de développement de logiciels semblent suggérer que nous pouvons extraire la valeur commerciale (plus rapide de temps sur le marché, etc.) en choisissant délibérément de ne pas cas de pointe de la poignée, et de communiquer ces décisions aux clients.
• Les clients peuvent trouver des valeurs commerciales dans un logiciel ne gérant que les cas les plus courants. Par conséquent, les fournisseurs de logiciels ne sont pas trop préoccupés par le traitement des cas rares.
  • Les clients apprennent simplement à éviter les aspérités.

Ajoutée

• L'élégance du code source n'est pas valorisée.
  • Les clients ne voient pas l'élégance du code source. Ils ne voient que l'élégance de l'interface utilisateur et des interactions.
  • Les programmeurs, en revanche, n'apprécient généralement pas l'élégance de l'interface utilisateur et ne restent pas longtemps dans un seul projet suffisamment longtemps pour commencer à apprécier un logiciel élégant.
  • Parce que ni les clients ni les programmeurs n'apprécient l'élégance du code source, les entreprises ne le valorisent pas non plus.

Ajoutée

Mes deux cents: juste s'y habituer.

Des images de processus ISO, de nombreuses documentations techniques, chaque fonctionnalité et chaque bogue faisant l'objet d'une documentation stricte, ainsi qu'un environnement généralement professionnel décrivent assez bien mon entreprise. Nous faisons des logiciels critiques infrastructure / produits matériels, donc, eh bien, la pression est sur la qualité (nous sommes certifiés ISO 9001, par exemple).

Après avoir obtenu mon diplôme, je pensais que les responsables seraient en mesure de reconnaître le bon travail d’un mauvais travail. Après avoir reçu le millionième exemplaire de "très bon code, notre meilleur codeur mis en place" et l’avoir ressemblé à ceci:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

J'ai presque cessé d'essayer de comprendre ce qui se passe entre les oreilles du patron aux cheveux pointus. "Grand" signifie maintenance cauchemar, "bon" signifie un crash dans une brise légère et "horrible gâchis" signifie soit cela, soit une base de code bien structurée dont les ingénieurs ont manifestement refusé de respecter les délais obscènes pour garder leur bon sens.

J'ai entendu dire que tout le génie logiciel après la première ligne de code est la maintenance. Et cela semble certainement correspondre à mon expérience. Le seul code que j’ai écrit et qui ne finissait pas par avoir une grande partie de son coût de maintenance, c’est un code tellement infructueux qu’il n’a jamais ou peu été utilisé.

Je pense que vous pouvez trouver des équipes d’ingénierie dissidentes qui développent et suivent des processus solides menant à la publication d’un code robuste dans lequel l’équipe peut avoir un niveau de confiance élevé (bien que je n’aie rien à dire avec beaucoup de documentation). Je crois que je travaille dans une équipe comme ça pour le moment. Bien que j'ai certainement expérimenté l'autre type de développement.

Ce que j’ai compris, c’est que le défi n’est pas toujours de trouver l’algorithme parfait ni la solution la plus propre au problème. Mais souvent, il faut échanger toutes sortes de contraintes (ressources, connaissances, argent, temps, compétences, risques, formation des utilisateurs préexistants, etc., etc.) pour obtenir le meilleur retour sur investissement disponible. Il s’agit de créer un système qui convient le mieux à tous ces facteurs et pas seulement aux influences techniques.

Beaucoup de logiciels ne parviennent tout simplement pas au point où ils sont suffisamment utilisés / achetés. Quand on le fait, il a tendance à rester en place et est seulement "foutu" en maintenance.

Les attentes des utilisateurs augmentent chaque jour pour les fonctionnalités, mais dans de nombreux domaines, elles sont plus faibles dans les domaines de l'ingénierie. Supposons qu'un logiciel de transaction bancaire est aussi solide et professionnellement conçu qu'une automobile moderne. Le traitement des volumes est une merveille moderne, mais qu’en est-il de la fiabilité de chaque transaction? Pas tellement. Votre message sur la première merde de votre chiot sur le tapis a été abandonné, alors quoi. Cela ressemble plus aux petits sacs en plastique à l'épicerie. Ils en fabriquent des milliards, ils déchirent et se font jeter. La plupart des gens ne se soucient pas assez d'exiger un meilleur sac.

Je pense qu'un logiciel de qualité est finalement créé. Une partie de celle-ci frappe le marché plus tôt que la plupart des produits commerciaux. Qui peut conduire une voiture à Beta?