Tout est une mode passagère. Vous en apprendrez plus au cours de votre première année à l'université que toutes vos années à l'université. L'informatique n'a rien à voir avec les ordinateurs.
College vous fournit une boîte à outils pleine d'outils. Ceci est un tournevis, c'est une clé à molette. Vous pourriez utiliser chaque outil une fois à l'université. C'est lorsque vous entrez dans le monde réel que vous découvrez vraiment ce que vous avez. Vous triez les éléments utiles du reste, ceux que vous souhaitez laisser à la maison sur l'établi, au cas où, et ceux que vous gardez dans votre poche tous les jours.
Tqm, Iso, Cmm, Agile, etc. Ce sont toutes des modes, elles viendront et elles iront, aucune des réussites n'est plus que du bon sens. Tous les ingénieurs et entreprises qui réussissent utilisent une certaine saveur de bon sens, c'est ce qui a fait leur succès, peu avaient besoin d'un nom pour cela. Le problème est que vous ne pouvez pas vendre du bon sens, un gestionnaire ne peut pas prouver sa valeur à l'entreprise en formant et en achetant du bon sens sans un nom accrocheur. Mettez un nom dessus que leurs supérieurs ont lu dans un article de presse ou un magazine et le manager garde son travail et vous gardez le vôtre. Très peu d'entreprises qui prétendent suivre ces pratiques le font réellement. La plupart écrivent un chèque à un consultant et obtiennent leur certificat annuel et / ou à vie dans un club afin qu'ils puissent mettre un graphique sur leur site Web ou une étiquette sur la boîte dans laquelle leur produit entre. Beaucoup diront que c'est rare ... été là, vu, ça arrive. Tout cela fait partie des affaires, il faut parfois couper les coins ronds pour rester rentable et garder les portes ouvertes et les lumières allumées. Les adeptes inconditionnels de toutes ces pratiques ont tous soutenu que la dernière était une mode et que celle-ci ne l'est pas, la dernière était vraiment trop chère à suivre, celle-ci ne l'est pas. Le dernier était faux, vous venez d'embaucher un consultant, celui-ci est réel. Tout comme les langages de programmation, ceux-ci évolueront eux aussi. Le dernier était faux, vous venez d'embaucher un consultant, celui-ci est réel. Tout comme les langages de programmation, ceux-ci évolueront eux aussi. Le dernier était faux, vous venez d'embaucher un consultant, celui-ci est réel. Tout comme les langages de programmation, ceux-ci évolueront eux aussi.
Votre capacité à comprendre les réalités des entreprises, le système universitaire et votre rôle dans celui-ci est la clé. Comme tout dans la vie, choisissez vos batailles. Ce n'est pas à l'université ou à l'entreprise, au gouvernement ou à quelqu'un d'autre d'enseigner que vous voulez ou voulez savoir. C'est votre travail de rechercher le numéro un. De même, vous ne pouvez blâmer personne de vous avoir donné le temps de le faire, vous devez le faire. Vous tomberez du cheval, vous n'êtes pas une victime, levez-vous et remettez-vous en marche, pas d'excuses, la vie n'est pas juste avec elle. Profitez des documents, ne prétendez pas être indépendant. Et certainement payer vos cotisations, ne pas sucer une entreprise à sec de documents, sans leur donner quelque chose (votre meilleur à l'époque?) En retour.
Pourquoi les gens pensent-ils que cmm ou agile ou l'un des autres est une mode? Pourquoi pensent-ils qu'ils ne le sont pas? Pourquoi le professeur vous a-t-il enseigné le programme de cette façon? Pour éviter les gotos ou pour éviter les constantes ou pour éviter ceci et cela? Est-ce parce qu'il produit un code plus fiable? Un code plus performant? Réduit l'erreur humaine? Ou est-ce parce qu'il est plus facile de noter les articles / programmes en leur donnant plus de temps pour faire des recherches? Est-ce parce qu'ils ne savent pas programmer et qu'ils ne font que suivre le livre de quelqu'un d'autre sur le sujet? Vous ont-ils appris que vous ne pouvez pas avoir de code maintenable, fiable et performant? Vous ne pouvez même pas «choisir deux» interférences maintenables à la fois fiables et performantes? Parfois, vous sacrifiez la fiabilité au profit de la performance. Parfois, vous ne vous souciez pas de la fiabilité ou des performances, vous voulez simplement obtenir de la version 117.34. 2 d'un autre logiciel de comptabilité à la version 118.0.0. Votre modèle commercial consiste à vendre des mises à niveau de version et un support technique et, dans la mesure où les développeurs de logiciels le feront, tout ancien robot peut écrire le même code de la même manière. Remplacez le brûlé par celui qui vient de sortir du collège et continuez à vendre des mises à niveau.
Il n'y a pas de réponses universelles à ces questions, vous devez découvrir votre opinion, vivre avec et la défendre. Changez d'avis, vivez avec et défendez-le.
Tout remettre en question ... vais-je vraiment me brûler si je touche le pot chaud sur la cuisinière? Les effets psychologiques de la peur causeront-ils plus de dégâts que le simple fait de se brûler? Existe-t-il un moyen sûr de tester la réponse sans se blesser?
Quand je pouvais me le permettre, j'achèterais et finirais par faire fondre des transistors, des capuchons, des résistances, etc. dans mon dortoir, qui ont tous une mauvaise odeur distinctive. Il est beaucoup moins cher et plus facile d'acheter simplement un ampli pour votre chaîne stéréo que d'essayer d'en construire un le lendemain de votre première classe de transistors. Linus étant l'exception, bien sûr, il est plus facile d'acheter un système d'exploitation que d'en écrire un ... Vous pouvez en faire plus, même si ce que vous apprenez à ce moment-là est différent de ce que Linus a appris.
Le monde à l'intérieur et à l'extérieur de l'université adoptera ces formules (cmm, agile, etc.) pour résoudre les problèmes et lorsque la suivante sortira, ils les abandonneront tout aussi rapidement. Vous n'avez pas besoin d'utiliser le contrôle de version pour réussir, il y a autant de succès avec que sans (enfin en fait à cause de l'âge de l'industrie, il y a beaucoup plus de succès sans contrôle de version jusqu'à présent). De même, vous pouvez réussir avec un minimum de tests (regardez les très grands noms de l'industrie informatique comme exemples). Vous pouvez réussir en testant votre propre code, ainsi qu'en suivant la règle selon laquelle vous ne devez jamais tester votre propre code. Vous pouvez réussir avec emacs et vous pouvez réussir avec vi. Vous devez décider quelle combinaison vous convient et si vous avez de la chance, trouvez un lieu de travail qui vous convient.
Lorsque vous sortez de l'université et que vous entrez dans le monde réel, écoutez et travaillez avec et discutez avec les «anciens». Ils ont des décennies, voire des siècles d'expérience combinée, des pièges dans lesquels ils sont tombés que vous pourriez éviter et / ou tester par vous-même (peut-être réalisez-vous que vous n'avez pas à toucher le pot chaud pour savoir qu'il vous brûlera). La plupart auront vu au moins une ou deux de ces modes aller et venir, et en particulier à quel point elles ont été brûlées et ce qu'elles ont fait pour s'en remettre. Ils connaissent de nombreuses façons différentes de tester les choses, ainsi que les noms des styles de test qui ont évolué. Ce qui fonctionne, ce qui ne fonctionne pas. Où est le risque et comment éviter de perdre du temps sur une tangente. Au fur et à mesure que vous mûrissez et que vous devenez l'ancien, faites-le passer. Payez ce que vous avez appris en essayant d'enseigner à ceux qui vous suivent. N'oubliez pas de leur apprendre à pêcher, ne leur donnez pas simplement un poisson. Et parfois, vous devez les laisser échouer avant de réussir, les empêcher de trop se brûler.
Ce que je voulais vraiment dire ici, c'est qu'en ce moment nous sommes dans une situation rare où nous pouvons assister à une évolution d'un univers parallèle (et peut-être l'influencer). Oui, l'informatique est une science jeune par rapport à la physique. Mais en même temps, il a évolué à plusieurs reprises. Selon l'endroit où vous travaillez et avec qui vous travaillez, vous pourrez peut-être observer des ingénieurs en matériel. Les langages de programmation dans le monde du matériel ne sont certainement pas nouveaux, mais ils n'ont pas évolué aussi rapidement que le monde du logiciel. Les logiciels avaient quelques décennies d'avance. Le matériel a toujours considéré les ingénieurs en logiciel comme des citoyens de seconde zone. Notre travail est facile, leur travail est difficile. (Notez que je suis en fait à la fois un ingénieur matériel et logiciel). Ce qui est intéressant, c'est qu'à l'heure actuelle, ils sont toujours aux prises avec ce que nous considérons comme des problèmes élémentaires ou infantiles. Pourquoi aurais-je besoin d'utiliser le contrôle de version, je suis le seul à travailler sur cette puce. Votre expérience avec gcc ou d'autres compilateurs bon marché ou IDE gratuits ne peut pas être comparée aux outils coûteux que j'utilise, si l'entreprise pensait que vous étiez assez digne de l'utiliser ou même de savoir comment l'utiliser, elle vous en achèterait une copie. Et une longue liste d'autres excuses. J'ai eu le plaisir d'apprendre à la fois le vhdl et le verilog et de devenir productif en une semaine grâce à ce qui était presque un défi d'un tel ingénieur en matériel (malgré mon diplôme disant ingénieur électricien, mon titre de poste est ingénieur logiciel). Je voulais apprendre ces langues, lorsque les outils étaient à ma disposition, je suis resté au bureau toute la nuit et j'ai appris moi-même. À partir de là, cet ingénieur en particulier s'est rendu compte que ce que je disais était vrai, les langues ne sont que de la syntaxe, les principes de base de la programmation sont les mêmes, les outils font tous la même chose. Ses pommes et ses pommes, pas ses pommes et ses oranges.
En général, il est encore difficile d'envoyer le message que l'une de ces deux industries parallèles a beaucoup plus d'expérience dans les langages, les habitudes de programmation, le contrôle de source, les tests, les outils, les environnements de programmation, etc. que l'autre. Le problème que j'essaie de résoudre est de prendre les conceptions matérielles au fur et à mesure qu'elles sont développées, de créer des simulateurs fonctionnels abordables que nous pouvons associer à une simulation (machine virtuelle) du processeur afin que nous puissions commencer à tester le matériel et développer le test et logiciel livrable bien avant de passer au silicium. Non, il n'y a rien de «nouveau» à ce sujet, mais nous n'avons aucun mécanisme pour obtenir le dernier code, suivre les modifications du code pour voir où nous devons concentrer notre temps. Aucun mécanisme de suivi de la documentation définissant l'interface utilisateur (de programmation) avec le matériel. La seule copie dorée se trouve dans la boîte de réception de quelqu'un sous forme binaire et ne change que lorsque, eh bien, il n'est pas nécessaire de lire le verilog pour savoir ce qui se passe. Attendez, ce verilog a quel âge? Ce bug que j'ai passé toute la semaine sur vous a découvert il y a trois semaines et corrigé? Alors, nous nous envolons pour un lieu de vacances et faisons la fête pendant six mois en attendant que les gens du matériel finissent leur tâche et nous la jettent par-dessus le mur, ou profitons-nous de cette occasion pour essayer d'être patient et optimiste et leur apprendre qu'ils il existe des méthodes de bon sens qui ne sont pas si intrusives qui leur permettent à la fois de faire leur travail, de sauvegarder leur travail et de partager leurs affaires pour examen par les pairs ... ce verilog a quel âge? Ce bug que j'ai passé toute la semaine sur vous a découvert il y a trois semaines et corrigé? Alors, nous nous envolons pour un lieu de vacances et faisons la fête pendant six mois en attendant que les gens du matériel terminent leur tâche et nous la jettent par-dessus le mur, ou profitons-nous de cette occasion pour essayer d'être patient et optimiste et leur apprendre qu'ils il existe des méthodes de bon sens qui ne sont pas si intrusives qui leur permettent à la fois de faire leur travail, de sauvegarder leur travail et de partager leurs affaires pour examen par les pairs ... ce verilog a quel âge? Ce bug que j'ai passé toute la semaine sur vous a découvert il y a trois semaines et corrigé? Alors, nous nous envolons pour un lieu de vacances et faisons la fête pendant six mois en attendant que les gens du matériel finissent leur tâche et nous la jettent par-dessus le mur, ou profitons-nous de cette occasion pour essayer d'être patient et optimiste et leur apprendre qu'ils il existe des méthodes de bon sens qui ne sont pas si intrusives qui leur permettent à la fois de faire leur travail, de sauvegarder leur travail et de partager leurs affaires pour examen par les pairs ...
N'oubliez pas que les ingénieurs en matériel ont quitté l'université avec une boîte de nouveaux outils brillants, tout comme vous. Vous avez appris 17 langages de programmation différents dont vous ne pouvez en utiliser qu'un, le reste des langages que vous avez dans votre carrière seront inventés après votre sortie du collège. Quand ils ont quitté l'université, ils peuvent vous dire ce qu'ils savent sur le calcul et la théorie de la relativité combien d'électrons sont dans chacun des éléments et calculer la charge autour d'une surface gaussienne. Mais l'essentiel de leur carrière est un, zéro, et, ou et non (hé nous avons ceux en commun, tout ce que vous devez vraiment savoir sur les ordinateurs, un, zéro et, ou et non ingénieur matériel ou logiciel). Compte tenu des lois fondamentales de la physique, du calcul, les électrons ne changeront pas aussi vite que le font les langages de programmation. Mais les principes fondamentaux de la programmation sont les mêmes dans toutes les langues et continueront de l'être dans le futur. Avez-vous quitté l'université en sachant cela ou avez-vous quitté en pensant que Java est différent et meilleur que C ++ parce que ceci et cela et l'autre?
Comme toute autre entreprise, le travail des universités est de rester rentable. Ils doivent embaucher les bons universitaires pour attirer les bons étudiants, les bons fonds de recherche et les bons types de recherche pour rentabiliser l'université. Ils doivent offrir les bonnes classes pour attirer les bons étudiants et former les bons diplômés afin qu'au fil des décennies, les employeurs à la fois près de l'université et, espérons-le, très loin, reconnaissent que cette université produit des employés productifs et rentables. (oui et parfois vous devez attirer les bons athlètes dans le bon sport pour obtenir la bonne quantité de temps à la télévision et la bonne quantité de reconnaissance de nom et de revenus sportifs). Certaines universités enseigneront le C ++ et Java, d'autres ne le feront jamais. Certains inventeront la CMM, d'autres enseigneront l'Agile, d'autres ne feront ni l'un ni l'autre. Si l'université a une quelconque valeur, il y a quelque chose à apprendre. Ils ne vous apprendront pas tout ce qu'il y a à apprendre, mais ils auront quelque chose d'utile. Apprenez ce quelque chose pendant que vous y êtes, rassemblez un nombre raisonnable de différentes formes d'outils dans votre boîte à outils. Quittez l'université et trouvez un emploi. Si votre boîte à outils est nulle, trouvez peut-être une autre université et ne mentionnez jamais la première. Si c'est une boîte à outils correcte, utilisez ces outils et créez-en de nouveaux à votre rythme. Si c'est une très bonne boîte à outils, dites de bonnes choses à propos de cette université et des bons universitaires avec lesquels vous avez appris ceci et cela et payez l'école pour ce qu'ils vous ont donné. Même si vous n'avez pas obtenu tous les outils possibles dans le catalogue universel des outils universitaires, vous repartirez avec un certain sous-ensemble. Même si vous n'êtes pas diplômé ...