Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Envoyé par Matthieu Vergne
Pour les formations courtes [intensives], on oublie même les bases (algorithmie, génie logiciel, différents paradigmes, ...) parce que, en plus du manque de temps, elles sont diluées dans les cadriciels ("framework") utilisés par les développeurs.
Mais, elles réapparaitront lorsqu'on est hors-cadre, comme pour des optimisations ou des fonctionnalités non supportées.
Je suis bien d'accord avec toi sur ce point. A ceci près que je ne qualifierai pas cela avec Technicien/ingénieur mais avec Spécialiste/généraliste, mais là on chipote
Par base j'entendais les origines effectivement
Vive le papier et le crayon !
Pour le cas Java, vu le nombre de gens qui ne comprenne pas pourquoi on compare des String avec .equals(), ou d'autres problèmes du genre, je pense que si c'est nécessaire pour devenir un bon dev.
Pour XML, je suis d'accord puisque ce n'est pas un language de programmation.
Pour HTML, CSS, et surement plein d'autres je ne connais pas assez... Des avis à partager ?
"On sera toujours mieux installé assis en 1ère que debout en 2nde", un illustre inconnu
Avant de poser une question vérifiez si elle n'a pas déjà une réponse dans les cours et tutoriels
pensez à marquer la conversation comme telle
à l'inverse s'il est inutile, faux ou que vous n'êtes pas d'accord, pensez à
Peter Norvig voulait dire qu'il fallait avoir vu suffisamment de langages différents pour avoir abordé les principaux paradigmes. Je pense que ce genre de "culture générale" est nécessaire même pour quelqu'un qui veut se spécialiser. Les formations qui prétendent faire de vous un "développeur web" en six mois, qui ne se concentrent réellement que sur ce qui est strictement nécessaire pour devenir développeur web, forment des générations entières de gnous qui ne seront jamais bons à faire autre chose.
EDIT : Les conseils de Peter Norvig me semblent tous pertinents (pas forcément de façon égale, par exemple ennuyer le peuple avec les macros de Lisp ne me semble pas nécessaire, c'est trop puissant et trop à part), même si je pense que si on veut vraiment tous les suivre, il faut plus de dix ans !
Se spécialiser, pour moi c’est s’enterrer.Je suis d'accord avec ça sauf qu'aujourd'hui le marché de l'emploi va à l'opposé.
Pour le web par exemple , il faudrait des dev frontend (html/css/js) , des dev backend (php/java/js/...) des dba (gestion base de données) et des admin système. Sauf que le seul mot qu'on les employeur à la bouche c'est "fullstack" , comprendre , qui sait tout faire. Et on va pas se mentir il est impossible d'être au top sur tous à la fois.
Être au top partout est peut être impossible mais aussi tout à fait vain.
J’ai bossé dans des équipes hyper compétentes, motivées, productives avec des gens qui étaient plus « full stack » que spécialisés. Ok il y avait toujours un trou dans les stacks (e. g. Le mec qui est plus Unix / système que front et vice-versa) mais et alors ?
Il y a pleins de passionnés capable de sortir des supers contenus sur des stacks différentes genre Front et Data, sans parler des autodidactes qui, ne savant pas que c’était impossible, l’ont fait (peut être d’une manière tordue).
Je pense qu’on a parfaitement le droit de souhaiter être un développeur versatile, à l’aise avec toutes les stacks. Et c’est ça un developpeur full stack. C’est quelqu’un qui compose tant avec le front, que le back que la data, du système. Et on peut largement être très bon avec toutes ces stacks, en comprendre la substance sans pour autant être « le killer » d’une stack.
Avec l’éxperience, les choses que l’on a fait mal une fois, n’étant pas un pro de telle ou telle stack, on les fait mieux après, et à la fin on sais coordonner les stacks entre elles.
Par contre à l’opposé j’ai bossé pleins de fois avec des devs spécialisés ou ça me posait vraiment problème. Ils s’arretent parfois à leur input leurs output, sont souvent tellement portés sur le techniques qu’ils ne s’interessent pas au métier, ils ne sortent jamais de leur zone de confort et n’ont pas de vision globale. Franchement, le pire c’est d’entendre « T’as compris cette discussion ? -> Non mais je m’en fou c’est du front, je verrais avec bidule. Ah mais bidule est pas là… ». Je préfère entendre « Ben j’avoue que cette partie front me parait tendue, mais bon on vas s’y attaquer et voir ce qu’on peut faire ! »
Les spécialistes c’est des gens que je vois souvent très mal travailler en équipe et avoir une valeur ajouté très restreinte, avoir leurs normes à eux etc…
Ce n'est pas du tout l'expérience que j'ai.
Etre spécialiste ne veut pas dire être obtus.
Tous les spécialistes sont expert dans une ou deux techno mais ont tout de même une énorme culture générale dans d'autres techno et heureusement !
De plus, les spécialistes sont souvent d'excellent concepteur et la conception s'abstrait souvent de la techno dans pas mal de domaines.
C'est au moment de choisir le type d'implémentation face à une conception que leur expertise est précieuse car connaissant parfaitement leur domaine, ils savent dire et justifier pourquoi il recommande telle techno et non telle autre et ce n'est pas tjrs celle de leur spécialité qu'ils recommandent justement car ils en connaissent parfaitement les forces, les faiblesses et les limites.
De plus, les experts que je connais sont tous d'excellent pédagogue et ils donnent souvent des formations pour leur entreprises ou bien interviennent dans des formations d'ingénieurs.
Bref, tout l'inverse de personnes ne sachant pas communiquer ou pas travailler en équipe.
Ceux que je connais qui justement, se limitent à leur domaine d'intervention sont le plus souvent de jeunes développeurs qui s'investissent peu dans leur travail.
==> Attention!!! je n'ai pas dit tous les jeunes mais certains et la nouvelle génération des millénials en devient une caricature
Alors que les experts sont souvent très investis et c'est une caractéristique nécessaire et indispensable pour devenir expert et cela se voit sur tous les aspects des projets
Je veux juste poser ici la magnifique ode à l'apprentissage du poète.
Quand on connaît le poème, on s'aperçoit que ça n'est pas dangereux pour les raisons que l'on pense, ie cet article, mais parce que l'on risque d'y prendre goût !
https://en.wikipedia.org/wiki/An_Essay_on_Criticism
Alexander POPE (1711)
A little learning is a dangerous thing ;
Drink deep, or taste not the Pierian spring :
There shallow draughts intoxicate the brain,
And drinking largely sobers us again.
Fired at first sight with what the Muse imparts,
In fearless youth we tempt the heights of Arts ;
While from the bounded level of our mind
Short views we take, nor see the lengths behind,
But, more advanced, behold with strange surprise
New distant scenes of endless science rise !
So pleased at first the towering Alps we try,
Mount o’er the vales, and seem to tread the sky ;
The eternal snows appear already past,
And the first clouds and mountains seem the last ;
But those attained, we tremble to survey
The growing labours of the lengthened way ;
The increasing prospect tires our wandering eyes,
Hills peep o’er hills, and Alps on Alps arise !
Traduction libre de Sylvie VAUTHIER aka Dendrite
Apprendre un peu est chose dangereuse;
Buvez en profondeur, ou ne goûtez pas à la source de Piérie :
Là où de légers courants d'air embrouillent le cerveau,
boire généreusement nous dégrise à nouveau.
Frappés par la foudre de ce que la Muse inspire,
Dans notre jeunesse intrépide, nous taquinons les sommets des Arts;
Tandis que de notre esprit borné
Des aperçus nous prenons, sans voir les étendues derrière,
Mais, plus engagé, on contemple alors avec grande surprise
L'émergence infinie de nouveaux paysages scientifiques plus lointains !
Si charmés au début par les Alpes imposantes nous tentons,
de dominer les vallées, pensant chevaucher le ciel ;
Les neiges éternelles semblent déjà derrière nous,
Et les premiers nuages et montagnes se présentent comme les derniers;
Mais ceux-ci atteints, nous vibrons d'arpenter
d'un effort toujours croissant le chemin qui s'allonge;
La perspective se déroule et sature nos regards éperdus,
Les collines s'empilent sur les collines, et des Alpes surgissent les Alpes !
PDO, une soupe et au lit !
Partir de la fin est un bon moyen de retrouver son chemin. Bibi - 2020
Le titre m'a fait penser à cette phrase que j'ai lue sur Facebook. Il s'agissait de quelqu'un qui faisait ses premiers pas en JavaScript. Quelqu'un a répondu en disant "il m'a fallu trois jours pour maitriser JavaScript".
La maitrise d'un langage d'un langage à mon humble avis c'est pas après deux nuits blanches. Maitriser un langage ça demande beaucoup de temps d'apprentissage et ça c'est pas du jour au lendemain que cela se fait.
C'est clair.
Oh le beau Dunning Kruger...
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Se spécialiser ou non, vaste sujet...
Je suis plutôt full stack et je pense que c'est intéressant de connaître un peu toute la chaîne, ça permet de prendre du recul, de voir les points de contention possibles, d'imaginer des solutions diverses à un problème. par contre ne me demandez pas de faire un site web avec une ihm hyper léchée où le CSS est au top, je ne sais pas faire. Pourquoi? Parce que je ne suis ni ergonome ni designer, et que l'expérience utilisateur par le biais de l'IHM est devenue trop importante pour que j'ai la prétention de faire ça alors que des gens plus compétents sauront le faire mieux que moi.
Comment ça se fait?
Et bien, depuis l'avènement de l'informatique grand public, des interfaces web et encore plus depuis l'arrivée des smartphone, l'expérience utilisateur a pris une importance primordiale dns le développement des logiciels. Les fonctionnalités doivent toujours être là mais si l'IHM est devenue un élément primordial pour l'adoption d'un logiciel par ces utilisateurs.
Conséquence: une équipe aura toujours intérêt à avoir des développeurs full stack qui pourront servir de ciment, de liant entre les différentes couches d'un logiciel mais il faudra également avoir des gens dédiés à l'UX pour avoir une interface qui permettra au logiciel de trouver ses utilisateurs (une bonne couhce de méthode agile aidera aussi).
Ca a tjrs été le cas même au temps des écrans AS400.
Ce qui a permis au Mac de percer dans les années 70/80 puis de revenir sur le devant de la scène à la fin des années 90 et début 2000, c'est l’ergonomie et le design si chères à Steve Jobs.
Le truc, c'est que depuis 15 ans, la multiplicité des offres fait que l'ergonomie prend encore plus de place qu'avant car permet de se distinguer de la masse de solutions proposées.
De plus, la technologie a considérablement évolué ce qui offre de nouvelles possibilités beaucoup plus avancées que ce qui se faisait auparavant.
Il est donc possible de mettre en place des IHM très évoluées et les utilisateurs sont devenus beaucoup plus exigeants.
Et pourtant l'ergonomie de sites grand public (Météofrance, SNCF, etc.) est franchement mauvaise. Et l'utilisation des "dernières technologies" par des personnes un peu diminuées relève de la mission impossible. Il semble que les développeurs cherchent plus à impressionner par leur virtuosité qu'à être utiles aux utilisateurs finaux.A mon sens, un développeur accompli sait concentrer ses efforts sur le résultat à obtenir et considère la programmation comme un outil qu'il peut apprendre très rapidement.
Ce qui s'énonce clairement se conçoit bien ( Le hautbois)
Le fait qu'il soit possible de mettre en place des IHM particulièrement évoluées ne signifie en rien que tous le font.
De même, ça ne signifie en rien que ceux qui tente de le faire y parviennent.
De plus, lorsqu'une IHM devient complexe, le développeur se met au service d'un ergonome qui lui même peut être assisté par un web analyste.
Au delà de la techno utilisée, il faut donc bien définir les spec de cette IHM.
Pour finir, la programmation n'est pas un outil qui peut s'apprendre rapidement.
On en connaît certains principes rapidement mais cela nécessite beaucoup de pratique afin de savoir les mettre en oeuvre efficacement.
Si tu as des doutes, je t'invite à faire du placage et de l'enduis et tu te rendras compte que comprendre le principe de la manipulation des spatules est incroyablement simple et rapide mais savoir les utiliser efficacement nécessite énormément de pratique.
.
La multiplication des intermédiaires est, amha, la cause la plus fréquente de résultats insatisfaisants
100% d'accord. L'important est de bien définir ce que l'on veut obtenir..Au delà de la techno utilisée, il faut donc bien définir les spec de cette IHM..Avec un peu de rigueur intellectuelle, je pense qu'on peut arriver assez rapidement à être efficace. Moins que 10 ans en tout cas.
Pour finir, la programmation n'est pas un outil qui peut s'apprendre rapidement..
.Je bricole un peu et je suis assez maladroit. Mais si l'informatique a progressé si vite, c'est que justement elle ne nécessite pas de savoir faire de ce type.Si tu as des doutes, je t'invite à faire du placage et de l'enduis et tu te rendras compte que comprendre le principe de la manipulation des spatules est incroyablement simple et rapide mais savoir les utiliser efficacement nécessite énormément de pratique.
Ce qui s'énonce clairement se conçoit bien ( Le hautbois)
Parler de l'enduis est une métaphore pour signifier qu'il faut de la pratique, de la pratique, de la pratique et encore, de la pratique.
Bien sûr que les savoirs faire entre l'enduis et le dev ne sont pas les mêmes par contre, les 2 ont pour point commun de paraître simple au premier abord mais de s'avérer complexe lorsqu'on cherche la perfection et/ou que l'on s’attelle à des tâches moins triviales.
Oui, entièrement d'accord avec Peter Norvig
Oui, je suis entièrement d'accord avec Peter Norvig, à quelques différences près, en se basant sur deux ou trois langages parfaitement maitrisés et couvrant le développement multiplateforme (Desktop, Web et Mobile).
Les autres langages seront à découvrir en fonction des projets et des équipes avec lesquels vous serez amenés à travailler, la procédure d'apprentissage d'un nouveau langage est la même pour tous.
Par la suite avec l'expérience vous serez en mesure tel qu'il a indiqué d'anticiper des stratégies de développement, de concevoir des systèmes fiables, de gérer plus aisément la communication entre diverses interfaces d'applications différentes, bref de faire une excellente intégration dans vos développements.
Practice makes perfect !
C'est par la pratique que l'on parvient à la perfection !
--------------------------------------------------------------
Artificial Intelligence Ph.D. Student, Bircham International University (BIU) - Madrid
Civilian in Côte d'Ivoire, Developer, Network Engineer & Machine Learning Engineer
contexte
cela dépend de l'objectif ;-)
pour écrire 3 lignes de VB repompées partiellement sur developpez.net (MERCI !) on a pas besoin d'être une bête
pour faire une modif dans un projet de 100K lignes de C++ codées par des névrosés cela me semble indispensable
Bien sûr mais ce que je veux dire est que l'essentiel du développement est la phase d'analyse qui précède l'écriture du code. Si elle est bien faite, l'écriture du code n'est (presque) qu'une formalité. Et cela requiert de la discipline, de la réflexion et l'expérience aide beaucoup.
Ce qui s'énonce clairement se conçoit bien ( Le hautbois)
D'accord et j'en rajoute 2
Je me retrouve dans ces critères, avec 12 ans d'expérience, une dizaine de langages de programmation, 3ans d'électronique 6 ans d'études d'informatiques à l'université, centaine cours autodidactes etc. mais je ne me considère toujours pas "développeur accompli". Vu que le monde de la programmation évolue tout aussi vite que celui des infrastructures informatiques et/ou le monde de l'information même.
J'en rajoute que :
- Il faut aussi avoir écrit au moins un programme pour un public étranger, parlant au moins deux langues étrangères, ça vous permettrai de faire face à des réalités d'autre d'encodage des caractères, rtl, ltr, etc
- Il faut beaucoup plus apprendre les principes généralistes sans directement plonger dans un langage...Là je fais allusion à des concepts tels que le Design Pattern, la POO, le Web etc. ça vous permettra de pouvoir pousser les limites d'un langage de programmation ou d'un framework que l'on recontrera sur le chemin
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager