IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelles sont les choses qu'on devrait enseigner aux développeurs à l'université ?
L'auteur de la plateforme Binaris passe en revue une liste non exhaustive d'aspects

Le , par Patrick Ruiz

255PARTAGES

18  2 
De façon traditionnelle, l’exercice en tant que professionnel de l’informatique en général est conditionné par le passage du postulant par une formation qui mène à un diplôme dans le domaine. La France est un bel exemple de ces pays où l’accès à bon nombre de postes de développeur informatique nécessite de présenter au futur employeur un parchemin qui correspond à 4 années d’études supérieures à minima (bac+4, bac+5, doctorat, etc.).

L’obtention d’un emploi nécessite de faire valoir le diplôme adéquat ou du moins celui que le futur employeur mentionne sur l’offre. De façon générale, le cursus universitaire apparaît donc comme une sorte de préparation aux défis qui attendent le postulant sur le terrain. Seulement, l’auteur de la plateforme serverless Binaris lui attribue un certain nombre de tares dont la propension à pencher sur la théorie plutôt que sur des aspects susceptibles de faire de ses produits d’excellents praticiens.

« Voici quelques-unes des choses que j’aimerais que l’on enseigne à l’université plutôt que de s’appesantir sur de la théorie pure » :

1. Éviter de baser ses décisions sur le nombre de lignes de code

Le nombre de lignes de code est l’une des métriques autour desquelles les discussions d’équipes de développement en informatique tournent souvent. Pour un projet donné, il peut être question de savoir s’il est mieux d’avoir une grosse ou une petite base de code (en termes de nombre de lignes de code). Le développement de l’auteur de la plateforme Binaris laisse filtrer que ce type de questionnement est quasi inutile lorsqu’il souligne que « le faire serait similaire à évaluer la qualité d’un livre sur la base du nombre de lignes de code. »

De façon brossée, il précise qu’il n’est pas nécessaire de compter, mais d’écrire autant de lignes de code que nécessaire tout en restant cohérent avec quelques principes : le code est cohérent ; le code est autodescriptif ; le code est bien documenté ; le code s’appuie sur des fonctionnalités modernes et stables ; le code n’est pas inutilement complexe, etc.

2. Il n’y a pas de « bons » et de « mauvais » langages de programmation

Dans un parallèle qu’il établit avec une boîte à outils, il montre que chaque langage de programmation introduit un jeu de compromis avec lequel chaque développeur doit traiter. En d’autres termes, il n’y a pas de
« bons » et de « mauvais » langages de programmation. Il y aurait simplement un choix à effectuer et même s’il souligne qu’il y a, dans la plupart des cas, peu de situations pour lesquelles le choix du langage est une question cruciale, il dresse une liste de points à prendre en compte pour l’atteinte de cet objectif : la disponibilité des ressources en ligne ; la rapidité de développement ; la tendance à générer des bogues ; la qualité et l’étendue de l’écosystème de bibliothèques ; les performances, etc.

« Il y a aussi un type d’association que les tendances actuelles suggèrent fortement. Si vous travaillez dans le domaine de la science des données, il serait réaliste d'utiliser Python, R ou Scala (peut-être Java). Si c'est un projet pour passer du temps, utilisez le langage qui vous rendra le plus heureux. Il n'y a qu'une seule règle non négociable sur laquelle je m'appuie. Je refuse d'utiliser des langages qui n'ont pas la plupart des problèmes que je vais rencontrer directement résolus sur StackOverflow. Ce n'est pas que je ne peux pas le résoudre, c'est juste que ce n'est pas la peine d'y consacrer du temps », ajoute-t-il


3. Lire le code d’autres développeurs est une activité difficile

« Lire le code des autres donne presque l'impression de lire une langue étrangère. Même si vous êtes à l'aise avec le choix du langage de programmation de l'auteur, vous devez quand même vous adapter à différents styles et choix d'architecture. Cela suppose également que l'auteur a écrit un code cohérent et fiable - une cible qui peut être atteinte ou manquée », écrit-il laissant ainsi filtrer que la lecture du code d’autres développeurs n’est pas une activité aisée. Pourtant, c’est une activité qui meuble une bonne partie du quotidien du développeur qui travaille au sein d’une équipe. Il faut arriver à maîtriser cet exercice et le développeur de la plateforme Binaris suggère de faire de la revue de code sur des plateformes comme GitHub pour aiguiser cette aptitude.

« La seconde astuce qui peut vous aider à lire le code d'autres personnes est un peu plus unique. C'est une technique que j'ai mise au point et elle a vraiment réduit le temps qu'il me faut pour me sentir à l'aise avec du code d'autres développeurs. Après avoir regardé le style du code que je veux lire, je commence par ouvrir vi et à écrire du code dans le style utilisé par le projet. Lorsque vous écrivez du code dans le nouveau style, vous améliorerez également vos compétences en lecture. Le style vous semblera moins étranger, comme vous l'avez déjà expérimenté. Même lorsque je parcours un projet aléatoire sur Github, je m'y adonne rapidement », ajoute-t-il.

4. Garder à l’esprit qu’il n’y a pas de code « parfait »

Dans son billet, l’auteur de la plateforme Binaris a aussi tenu à recadrer l’idée selon laquelle tous les programmeurs en industrie écrivent du code « parfait ». Il insiste sur ceci que même dans ces sphères où l’on a affaire à des programmeurs très expérimentés, le salut passe par les revues de code.

« Je travaille avec une équipe d'ingénieurs vraiment brillants. Ce sont quelques-uns des programmeurs les plus compétents et les plus confiants dont on puisse s'attacher les services. Chaque membre de notre équipe (y compris moi) aurait une crise de panique totale si quelqu'un suggérait de faire passer du code non révisé. Même si vous pensez être le prochain Bill Gates vous ferez des erreurs. Je ne parle même pas d'erreurs logiques, je parle de fautes de frappe, de caractères manquants. Je parle de choses pour lesquelles on a besoin d'une autre paire d'yeux », écrit-il.

5. Travailler comme développeur ne veut pas dire 8 heures de programmation par jour

Dans bien de pays au monde, la journée de travail a une durée de 8 heures. Pour un employé de bureau, on arrive au lieu de service, s’installe sur un siège devant un ordinateur et se lance dans ses activités. Mais, lesquelles ? De quoi s’agit-il dans la réalité ? De « 8 heures de travail » ou « 8 heures au travail » ? En d’autres termes, pour combien de temps les travailleurs sont-ils productifs sur une journée de travail ?

« Très peu de personnes sont capables d’écrire du code pendant plus de 4 heures par jour. Les personnes qui ne sont pas d'accord avec cette affirmation sont soit l'exception à la règle, soit travaillent dans des entreprises qui devraient mieux les traiter. La programmation est une tâche exigeante sur le plan mental. Il est tout à fait déraisonnable de s'attendre à ce que quelqu'un écrive du code 8 heures par jour, 5 jours par semaine. », répond l’auteur de la plateforme Binaris dans son billet de blog.

Un sondage d’Invitation Digital Ltd – une firme de marketing basée au Royaume-Uni – paru en début d’année met en lumière des tendances similaires : la durée moyenne de productivité sur le lieu de service est de 2 h 53 min, soit moins de 3 h.


Il s’agit d’un avis avec des points susceptibles de faire débat. Par exemple, il semble difficile d’imaginer une formation de niveau universitaire au cours de laquelle l’on n’enseigne pas aux étudiants qu’il n’y a pas de « bons » et de « mauvais » langages de programmation ou encore que lire le code d'autres intervenants dans la filière n'est pas une activité aisée. Cela reste néanmoins une contribution aux questionnements liés aux habitudes que les travailleurs de la filière programmation informatique doivent avoir.

Source : billet de blog

Et vous ?

Les aspects que soulèvent l’auteur de la plateforme Binaris font-ils vraiment défaut aux cursus de formations universitaires en informatique ?

Êtes-vous issu d’une formation universitaire en informatique ? Si oui, lui reconnaissez-vous ces tares ?

Quels sont d’après vous les choses que l’on devrait enseigner aux développeurs à l’université ?

Voir aussi :

Qu'est-ce qui fait un bon programmeur ? Un senior liste cinq caractéristiques d'un bon programmeur

Faut-il éliminer le mythe du programmeur génie ? Selon un sénior, « la plupart des gens sont moyens » et cela n'est pas grave

Le talent et la passion suffisent-ils pour faire un bon développeur ? Les créateurs de Django, PHP et Rails n'étaient pas des passionnés du code

Tout le monde ne peut pas devenir développeur, il faut d'abord disposer de certains prérequis

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de pboulanger
Membre éprouvé https://www.developpez.com
Le 18/10/2019 à 10:30
Des cours d'algorithmes, on retrouve beaucoup trop de 'développeurs' ne sachant pas choisir la structure de données adaptées à son problème ou l'algorithme adapté... Comprendre la différence en une std::map et un std::unordered_map par exemple en terme de performance mais aussi en consommation mémoire... etc...

On retrouve de plus en plus de développeurs très fort en coding game mais incapable de s'adapter à un problème qu'ils n'ont pas étudié précédemment. Je me souviens d'un collègue; qui pour un parcours d'une structure de données arborescente, avait implémenter 3 boucles for imbriquées (le concept de la récursivité lui était étranger....

L'apprentissage d'un langage pure fonctionnel est un plus...
7  2 
Avatar de Angelsafrania
Membre éclairé https://www.developpez.com
Le 18/10/2019 à 9:55
Les tests automatisés !
Apprendre les différents types de tests automatisés existant, apprendre à en écrire des pertinents.
6  2 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 18/10/2019 à 16:59
La maintenance. Les foutre sur des vieux codes pourris, avec plein de couches de maintenances différentes qui puent.... Mais qui marchent comme du papier à musique. Et leur faire faire une petite modif, comme ça, juste pour rigoler.

Sinon, l'autre truc que j’aimerais de la part des établissements de formation, c'est de ne pas diplômer les gens qui n'ont pas le niveau. Mais bon, vœu pieux.
4  0 
Avatar de Gnomial
Futur Membre du Club https://www.developpez.com
Le 18/10/2019 à 11:10
Sortant tout juste d'un cursus universitaire, je me permets de donner mon point de vue.

1. Éviter de baser ses décisions sur le nombre de lignes de code
L'auteur a bien raison, on nous chambre en permanence sur le nombre de lignes de code. Je pense qu'il faut faire la balance entre performances et maintenabilité. Le problème est que la compétition innée dans les cursus de programmation est :

1 - Le premier qui finira à écrire son algorithme (donc en négligeant toutes les règles de qualité du code)
2 - Celui qui aura écrit le moins de lignes de codes (quitte à se retrouver avec des if else (habituellement écrits sur 4 lignes) rédigés sur 1 seule ligne mais incompréhensibles)

Et je pense que ces "unités de mesure" viennent principalement du fait que les algorithmes que l'on écrit en cours ne sont jamais très conséquents et tournent toujours plus ou moins rapidement et qu'il n'y a pas d'utilisateur final, à tel point que mesurer la performance paraît inutile (et implicitement la maintenabilité). Mais également du fait que aucun outil pour mesurer les performances ne sont enseignés aux élèves. Lors de ma 1ère année de Licence, nous programmions en Ada et la moitié des programmes des élèves n'étaient pas indentés. Le seul objectif était de produire un algorithme fonctionnel.
Seulement lorsque tu rentres dans la "vraie vie" d'un programmeur, tu te rends comptes que tu as un résultat à produire auprès du client et que la performance et la maintenabilité font partie des premiers critères.

3. Lire le code d’autres développeurs est une activité difficile
Quand le développeur écrit son programme, il a son propre "environnement de réflexion". Soit il a créé le code de A à Z, soit il a déjà pris connaissance du code précédent (et si ce n'est ni l'un ni l'autre, chapeau ). Il est donc implicite que la personne qui va relire le code n'aura pas la même réflexion et la même image d'ensemble du code que le développeur précédent. Un code qui peut nous paraître simple à "déchiffrer" peut paraître tout aussi compliqué à autrui. Je pense que peu importe qui écrit du code, il sera toujours difficilement intégrable à notre propre réflexion.
C'est comme décrire un endroit que tu as visité le mois dernier à Châteauroux: tu as l'image d'ensemble, tu sais à quoi ça ressemble.. mais la personne en face s'en fout cherchera à s'imaginer l'endroit et ça ne ressemblera jamais exactement à ce que tu essaies de décrire.

4. Garder à l’esprit qu’il n’y a pas de code « parfait »
J'associe toujours l'écriture du code à l'écriture d'un livre ou la création d'une oeuvre d'art... Existe t-il vraiment des critères pouvant définir ce qu'est un code parfait ? Outre les critères de performances, ce sera toujours plus ou moins subjectif. Michel adore les boucles while, alors que Jacquie préfère les boucles for avec un exit. Qui a raison ?

5. Travailler comme développeur ne veut pas dire 8 heures de programmation par jour
Et pour n'importe quel métier, honnêtement. Je pense qu'il faut simplement faire attention à notre "passion" pour la programmation et ne pas se laisser prendre au piège pour que l'on en fasse plus sous prétexte que cela nous plaît. Personnellement, j'aime la programmation, mais pas au point que ce soit ma passion (ou du moins pas ma première passion) et je pense que ça m'aide à équilibrer ma vie au travail. Mais ça ne m'empêche pas de m'appliquer (et de m'impliquer) dans mon travail.
4  1 
Avatar de Gunny
Membre confirmé https://www.developpez.com
Le 28/10/2019 à 9:35
J'ai appris tout ça à l'Université personnellement...
Par contre, ce que je regrette n'avoir pas appris alors qu'on s'en sert tout le temps (je suis sorti en 2010, ça a peut-être changé depuis) :
- Tests automatisés : ok, j'ai eu un seul module, ça a servi d'introduction technique, mais après, plus rien. Or le plus important et le plus difficile c'est de réfléchir à quels tests écrire, et comment les écrire.
- Contrôle de source : je n'ai simplement jamais utilisé de logiciel de contrôle de source durant mes études. C'est incroyablement important quelle que soit la taille du projet (même un tout petit projet perso).
- Travail en équipe, code review, maintenance, refactoring : cela compte pour au moins la moitié du travail d'un dev.

Je pense que se focaliser sur les technologies que "le marché" cherche est une erreur, il faut voir un niveau au dessus. Être un bon développeur c'est posséder de solides bases en programmation (algorithmique, bases de données, réseaux), mais aussi beaucoup de méta-compétences : capacité d'adaptation, rigueur, curiosité, etc. Les technologies en elles-même importent peu car elles changent tout le temps et s'apprennent vite.
2  0 
Avatar de JeanYvette
Membre averti https://www.developpez.com
Le 29/10/2019 à 14:46
J'ai vu plusieurs commentaires parler de cours d'algorithmie, il en est en effet réellement important. Combien de fois j'ai vu des gens venir me demander de les aider sur quelque choses en pensant qu'ils avaient moins de compétences là où au final, le problème venait simplement de l'algo.
Certains veulent tuer une mouche avec un bazooka et donc se retrouvent avec des besoins beaucoup trop élevés...

Apprendre, par la même, à faire un code simplifié, qui est souvent synonyme d'un algo simple ou au moins simplifié.

Un problème majeur que je retrouve est... le copier/coller. Certains s'en sortent grâce à un petit coup de ctrl + c / ctrl + v... En effet, comme disent certains, un dév "flemmard" est un dev "astucieux (pour expliquer le principe de classes que l'on peut porter sur plein de projet). Mais parfois, il serait bon de savoir comment faire quelque chose voulue DEPUIS ZÉRO, j'ai l'impression que plus le temps passe, plus cela se perd (moi en premier) mais les bases aussi, par conséquent, peuvent se perdre...

Ensuite, et là c'est la personne qui travaillent pas mal sur les SGBD qui donne un exemple de ce qu'il croise quotidiennement, il faut arrêter de commencer l'enseignement/prise en main avec des outils de style TOAD. Je m'explique (Ceci est un exemple que l'on peut retrouver dans d'autres domaines):
"Vous voulez la liste des tables qui contiennent le mot xxx dans son nom ?"
=> "Lancez TOAD est faites une recherche dans les noms d'objets via le menu machin"
"Vous cherchez la liste des procédures qui font appel/utilisent une table spécifique ?"
=> "Lancez TOAD et cherchez dans les textes des objets via le menu truc"
Conclusion : Les gens ne connaissent pas/plus les tables systèmes et un moment ça devient gênant. Alors bien sûr qu'ne fois qu'on sait le faire en requête, que l'on sait comment ça fonctionne "derrière" utiliser un outils comme cela fait gagner du temps, mais il ne faut pas que ça soit au détriment de connaissance de bases
=> Des outils oui, pour gagner du temps oui, pour perdre nos connaissances, non !
2  0 
Avatar de
https://www.developpez.com
Le 17/11/2019 à 9:13
Citation Envoyé par Gnomial Voir le message

3. Lire le code d’autres développeurs est une activité difficile
Quand le développeur écrit son programme, il a son propre "environnement de réflexion". Soit il a créé le code de A à Z, soit il a déjà pris connaissance du code précédent (et si ce n'est ni l'un, ni l'autre, chapeau ). Il est donc implicite que la personne qui va relire le code n'aura pas la même réflexion, ni la même image d'ensemble du code que le développeur précédent. Un code qui peut nous paraître simple à "déchiffrer" peut paraître tout aussi compliqué à autrui. Je pense que peu importe qui écrit du code, il sera toujours difficilement intégrable à notre propre réflexion.

C'est comme décrire un endroit que tu as visité le mois dernier à Châteauroux : tu as l'image d'ensemble, tu sais à quoi ça ressemble.. mais la personne en face s'en fout cherchera à s'imaginer l'endroit et ça ne ressemblera jamais exactement à ce que tu essaies de décrire.
Source : CHANGER D’ALTITUDE - Bertrand PICCARD

Ce que nous croyons être un dialogue entre deux individus, n'est en réalité que deux monologues. Le premier a lieu entre nous-même et notre imaginaire et le second entre notre interlocuteur et son propre imaginaire.

Quand on parle à quelqu’un, les mots que l’on prononce correspondent, lorsqu’ils sortent de notre bouche, à une image, une émotion ou une représentation que l’on pense être très claires et univoques dans notre esprit. Du côté de notre interlocuteur, il n’en sera pas de même. Les mots arriveront soit sur un terrain vierge, où ils devront être décodés, puis interprétés, soit sur un terrain familier, où ils seront tout de suite associés à des images, émotions ou représentations personnelles, qui peuvent se révéler différentes des nôtres. À défaut d’expérience commune, notre interlocuteur essayera de construire la situation dans son imagination, mais nous devrons rester conscients du décalage inévitable que cela engendrera.

Une idée ou un ressenti qui passe dans notre conscience sera traduit en mots (première déformation) pour être communiqué à notre vis-à-vis (deuxième déformation). Ce dernier comprendra les mots comme il peut (troisième déformation) pour les retraduire en idées ou ressentis (quatrième déformation) qui seront intégrés en fonction de son propre vécu (cinquième déformation).

Il faut bien comprendre que quelqu’un qui entend nos paroles, il les passe au filtre de ce qu’il est prêt à comprendre, qu’il essaie de les intégrer en fonction de son propre vécu pour ensuite se créer une représentation mentale de ce que l’on a voulu dire.

Des mots, des phrases ont certes été perçus mais leur sens n’a pas été identique pour l’émetteur et le récepteur. D’un côté comme de l’autre, les sources de déformations et de distorsions sont multiples et comme nous négligeons le plus souvent de nous enquérir de ce que l’autre a compris, nous vivons régulièrement dans des mondes parallèles. Ce n’est qu’en cherchant à percevoir ce que l’autre a réellement compris et en comparant les expériences personnelles de chacun face à un même sujet que l’on peut commencer à communiquer. Pas avant !

Dans notre rapport à l’autre, nous devons abandonner l’idée d’une réalité unique et comprendre la communication comme un partage d’expérience et non comme un échange d’informations.

Chacun fabrique l’autre par projection. Il s’en suit un décalage qui peut devenir abyssal. La projection peut être positive ou négative se faire par idéalisation ou par rejet. Dans les deux cas, ne pas en être conscient engendre une bonne partie de nos problèmes relationnels.

En réalité, il importe moins de savoir ce que pense, ce que dit quelqu’un que pourquoi il le pense, il le dit. Les désaccords peuvent faire peur et il est très confortable d’être d’accord, les similitudes rassurent mais ça ne sert à rien. Chacun a de bonnes raisons de dire ce qu’il dit en fonction de son vécu. On s’enrichit mutuellement au contact du vécu de l’autre. Rejeter les divergences, chacun prouvant qu’il a raison et l’autre tort, rend les relations difficiles, voire même inutiles.

Il y a trois règles pour construire une relation :

  1. Parler de son ressenti…

    Lorsque l’on dialogue, nous n’avons pas à juger le comportement de l’autre, la règle d’or consiste à exprimer ce que l’autre provoque en nous, ce que nous ressentons vis-à-vis de son attitude.
  2. Partager des expériences…

    On communique véritablement quand on partage des expériences personnelles, pas quand on transmet des informations.

    Si nous n’apprenons rien de nouveau sur l’autre ou sur nous-même dans une discussion, ou que pire encore notre seul but est de persuader l’autre qu’il a tort, nous ne communiquons pas, nous transmettons des informations qui ne peuvent que susciter le rejet de quelqu’un de différend et l’approbation de quelqu’un de similaire.

    Une expérience est unique ; elle appartient à celui qui en fait part et à personne d’autre, jusqu’à ce que l’interlocuteur en saisisse le caractère spécifique. Il est donc important pour faire passer notre message d’expliquer simultanément d’où provient notre avis et sur quelle expérience nous nous fondons car soit notre discours devra être décodé puis interprété, soit il sera associé à des images, des émotions ou représentations personnelles qui peuvent se révéler différentes des nôtres.

    Les mots, les phrases sont certes perçus mais leur sens n’est pas identique pour l’émetteur et le récepteur. La transmission de notre pensée subit plusieurs déformations :

    • Une idée ou un ressenti qui passe dans notre conscience est d’abord traduit en mots,
    • Communiqués à notre interlocuteur, ce dernier comprend, filtre les mots comme il peut et les retraduit en idées ou ressentis,
    • Il s’en crée pour finir une représentation mentale qu’il intègre en fonction de son propre vécu.

    À défaut d’expériences communes, nous essayons de construire la situation dans notre imagination.
  3. Réaliser qu’il y a autant de réalités différentes que d’individus…

    Cela signifie que la plupart des conflits sont aussi vains qu’inutiles.

    Comme nous négligeons de nous enquérir de ce que l’autre comprend, nous vivons régulièrement dans des mondes parallèles. Il nous appartient de choisir si nous préférons résister face à des manières différentes de fonctionner ou développer la liberté de découvrir d’autres façons de penser.

CHANGER D’ALTITUDE - Quelques solutions pour mieux vivre sa vie - Bertrand PICCARD - Octobre 2014
2  0 
Avatar de iclo
Membre régulier https://www.developpez.com
Le 18/10/2019 à 15:29
Bonjour,

Les formations actuelles manquent souvent de bonnes bases algorithmiques et de méthodologies de développements et de tests.
J'en suis arrivé quand je fais passer des tests techniques lors d'un recrutement à demander un pseudo code pour trier un simple tableau de 5 nombres entiers. Les 3/4 des candidats diplômés ou sur le point de l'être sont incapables de sortir ne serait-ce qu'une base de programme.

Il serait plus judicieux d'insister pendant les études sur des bases intemporelles, et surtout à apprendre "à apprendre par soi même" que de vouloir former des gens sur des outils / framework/ technologies précises qui auront soit disparu quelques années après ou bien mutées à un point qu'il aura fallu se former pour rester compétent.
1  0 
Avatar de iclo
Membre régulier https://www.developpez.com
Le 21/10/2019 à 10:12
Citation Envoyé par el_slapper Voir le message

Sinon, l'autre truc que j’aimerais de la part des établissements de formation, c'est de ne pas diplômer les gens qui n'ont pas le niveau. Mais bon, vœu pieux.
Je suis en effet souvent sidérer par le niveau de certains candidats : il est tout à fait normal d'avoir encore beaucoup à apprendre (nous en sommes tous là durant l'ensemble de notre carrière) mais quand le "bootstrap" du développement n'est pas là, ça devient très compliqué.
1  0 
Avatar de
https://www.developpez.com
Le 05/11/2019 à 20:56
Citation Envoyé par iclo Voir le message
Il serait plus judicieux d'insister pendant les études sur des bases intemporelles, et surtout à apprendre "à apprendre par soi même" que de vouloir former des gens sur des outils / framework/ technologies précises qui auront soit disparu quelques années après ou bien mutées à un point qu'il aura fallu se former pour rester compétent.
D'un côté, il est enseigné une technicité dans une forme pédagogique et de l'autre les étudiants ne viennent pas chercher du grain à moudre mais des recettes. Tout va bien donc, l'offre répond à la demande, sauf que cela contribue à former des Ouvriers Spécialisés et non des ingénieurs autonomes, à l’esprit ouvert, en quête de réflexion.
1  0