Discussion :

[MarieKisSlaJoue]

Lire des livres est quelque chose d'important car en général ce sont les seules ressources écrites qui vont vraiment dans le détail d'une techno ou d'un concept. Les tuto "Comprenez Docker en 5 minutes" ou créer votre Pipeline en 8, ne vous apprendront rien sur docker et les pipelines. Par contre des livres comme Up ou Running sont longs a lire, mais une vraie mine d'information.

Apprendre à d'autre ce que l’on sait est aussi clairement la meilleure façon de progresser, ça oblige à bien définir ce que l’on sait, se poser de nouvelles questions…

Sinon j’ai répondu autre, pour moi le seul premier conseil et de ne pas rejoindre une SSII.

[Matthieu Vergne]

J'ai bien dit, lib de base.

[...]

De mon coté, peu m'importe que les mecs de mon équipe comprennent 100% du code des lib que l'on utilise. De toute manière, personne dan la boite ne maintiendra le code qu'ils auront pondu 5 ans plus tot...

Si ton conseil est de faire du code jetable sur lequel personne ne reviendra, fallait le dire tout de suite. Du coup je comprends mieux le focus.

Sinon, les libs de base changent selon le contexte et le temps. Dans une boîte, on sera parti sur tel langage avec telles libs, dans une autre le même langage mais avec d'autres libs, et tu auras l'air bien con à maîtriser cette troisième lib que tu pensais être une lib de base mais qui n'intéresse pas les boîtes qui t'embauchent.

Je suis pas convaincu qu'un débutant ait pour premier objectif de se faire un panel de libs. En tout cas, ceux qui passent leur temps à se mettre à jour sur les nouvelles lib qui font la hype ont moins de temps pour maîtriser les bases du dév (commun à tous les projets), ce que je trouve bien dommage.

Sinon j’ai répondu autre, pour moi le seul premier conseil et de ne pas rejoindre une SSII.

Pourtant, si on tombe bien, c'est un bon moyen de s'assurer un job de technique sans tomber dans le travers de l'"upgrade" en chef de projet. Quand tu as fini ta mission, tu passes à une autre, ce qui te permet de toucher à diverses technos, dans différents contextes, et donc de pratiquer beaucoup plus.

Et puis ça n'existe plus les SSII. On parle d'ESN maintenant.

[VBurel]

il me semble que l'on mélange deux trucs qui n'ont pas grand chose en commun: Développeur de logiciels et programmeur.
Pourrait-on définir ce qu'est "un développeur de logiciels"?

ouaip, Le développeur est un peu à la filaire informatique ce que l'auteur est à la filaire du livre.

Le développeur n’a pas besoin d’être expert en langage ou autres technologie à la mode pour créer et développer des logiciels ou des services IT. De même qu’un auteur n’a pas besoin d’être expert en grammaire ou technique d’impression pour imaginer et écrire des histoires.

Ce qui demande de l’expérience et un savoir faire solide, c’est ce qu’on appelle « l’industrialisation », c’est à dire l’écriture d’un code source qui a vocation à être optimal sur plusieurs axes (charge CPU, fiabilité, portabilité, consommation électrique etc..) et être validé le plus rapidement possible (le code validé coute d’ailleurs de plus en plus cher aujourd’hui). Mais quand on commence à industrialiser, le développement proprement dit est terminé.

Dans les années 90, Le développeurs pouvait être capable de tout faire : le prototype, le pré-produit, et le produit. Aujourd’hui c’est un profile assez rare du fait que toute les phases de construction d’un logiciel se sont complexifiés, de la conception à la mise en ligne / en prod, et du fait que les attentes utilisateurs sont bien plus difficiles à satisfaire qu’il y a 20 ans.

[MarieKisSlaJoue]

Pourtant, si on tombe bien, c'est un bon moyen de s'assurer un job de technique sans tomber dans le travers de l'"upgrade" en chef de projet. Quand tu as fini ta mission, tu passes à une autre, ce qui te permet de toucher à diverses technos, dans différents contextes, et donc de pratiquer beaucoup plus.

Et puis ça n'existe plus les SSII. On parle d'ESN maintenant.

Si on tombe bien, là est tout le problème, pour 1 bonne c'est 10 pourris. On peut toucher un plein de techno hors SSII. D'ailleurs il n'est pas dans l'intérêt d'une SSII de te laisser toucher à des technos que tu ne connais pas, car ils sont là pour vendre des experts, or on ne peut pas être expert sans avoir pratiqué de façon récurrente une techno.
Le seul endroit ou on peut être expert en quelque chose en ayant juste eux trois jour de formation et lu une doc.... c'est en SSII, mais on l'est juste au moment de la facturation.

Il aurait des tas de chose à reprocher encore au SSII qui montre que ce n'est pas un bon endroit pour évoluer et devenir meilleurs, au pif, les SSII on la facheusse tendance de recruter n'importe qui, même le plus mauvais. Car au mieux il sera quand même placé sur un truc pourri mais sera facturé, au pire il ne passera pas la période d'essai.

Or pour un junior, être entouré de vrai expert et bon développeur est important, les SSII ne sont pas là pour attirer et garder les bons développeurs.

Bref, les SSII devraient tous simplement disparaître du paysage informatique, ça serait mieux pour le monde de l'IT en général.

Et bien sûr je continue de dire SSII, car je n'ai aucune considération pour ces structures et que changer de nom, ne change pas le fond.

[pmithrandir]

Si ton conseil est de faire du code jetable sur lequel personne ne reviendra, fallait le dire tout de suite. Du coup je comprends mieux le focus.

Sinon, les libs de base changent selon le contexte et le temps. Dans une boîte, on sera parti sur tel langage avec telles libs, dans une autre le même langage mais avec d'autres libs, et tu auras l'air bien con à maîtriser cette troisième lib que tu pensais être une lib de base mais qui n'intéresse pas les boîtes qui t'embauchent.

Je suis pas convaincu qu'un débutant ait pour premier objectif de se faire un panel de libs. En tout cas, ceux qui passent leur temps à se mettre à jour sur les nouvelles lib qui font la hype ont moins de temps pour maîtriser les bases du dév (commun à tous les projets), ce que je trouve ça dommage.

Pour moi on ne parle pas de devenir un assembleur de lib mais de créer un logiciel maintenable.
Et ça veut souvent dire que le plus important, C est la base de code fonctionnelle spécifique de la boîte.
Et quand je parle de code non maintenu, c est parce que du code bien spécifique pour faire des opérations basiques, ça sera souvent mal maintenu. Seul le dev qui l a créé va penser à l utiliser, les autres utilisant d autres méthodes standard. Et du coup on se retrouve vite avec quelques années qui passe, le dev qui part et d un coup la prise de conscience de l horreur à maintenir.

C est pour ca que je n aime pas les dev qui se croient plus intelligent. Sous prétexte souvent de vouloir faire gagner des performances ils refont tout... mal.
Je n ai jamais croisé un dev qui seul arrive à surpasser une équipe de senior qui font un projet commun.

[Matthieu Vergne]

Seul le dev qui l a créé va penser à l utiliser, les autres utilisant d autres méthodes standard.

Attention, faut pas mélanger standards et libs !
Réutiliser les méthodes standards qui font déjà le boulot, oui, ça montre qu'on maîtrise notre langage.
Réutiliser des libs, ça peut être comme le code perso : si j'utilise une lib qui fait le boulot que je suis le seul à connaître, ça vaut pas mieux.

Par exemple en Java, ne pas s'amuser à recréer une liste chaîné, on utilise un LinkedList. Ça fait partie de la librairie standard, on n'a rien à ajouter au langage, c'est toujours dispo quel que soit le projet. Par contre si tu me dis que je dois maîtriser tous les détails des collections Apache commons, ça ne m'aidera pas beaucoup dans un projet qui utilise Google Collections ou Vavr. De même pour les frameworks, si tu me dis que je dois maîtriser Spring, ça me fait une belle jambe quand je tombe sur un projet qui utilise l'un des nombreux équivalents :
https://www.g2.com/products/spring-f...s/alternatives

Et encore, même la lib standard : c'est beau de maîtriser les streams et lambda de Java 8 quand tu bosses sur un projet encore en Java 6. Pas sûr que remplacer tes lambdas par des classes anonymes à tout bout de champs convainc grand monde dans l'équipe.

Donc oui, c'est important d'avoir une certaine familiarité avec des libs grand public, mais faut pas faire l'erreur de se dire qu'on pourra l'utiliser partout. A contrario, connaître l'algorithmie et des design patterns, ça te servira beaucoup plus facilement.

[chlubister]

Je développe des logiciels à la demande depuis 1987, principalement de gestion de données (facturation,stock, etc etc..) au tout début avec Dbase II, Dbase III, Foxbase, Clipper, aujourd'hui Delphi 5 & SQLite, les conseils n'engageant que ceux qui les écoutent, je dirais simplement "SOYER CURIEUX"

[patrick72]

Il faut d’abord comprendre "la machine" : pour cela, il faut passer par la "case" d'un langage de base niveau, type "C". Cela permet de comprendre comment est stocké l'information en mémoire et comment ont peut y accéder, avec les notions de pointeurs et d'adresses.

Ensuite, on peut passer sur des langages plus évolués qui "cachent" ces mécanismes...

Enfin, « la meilleure façon d’apprendre une chose est de l’enseigner » est à mon avis ensuite un bon moyen d’évoluer : devenir un membre actif sur un forum pour aider les autres permet d'aller au de là de ce compétence, découvrir d'autres besoins, les analyser et proposer des solutions...

[DevTroglodyte]

il faut passer par la "case" d'un langage de base niveau, type "C"

Heu... personnellement, c'est un des deux langages que j'ai appris à mes débuts (en IUT), avec le Pascal, et honnêtement, même s'il permet de comprendre les mécaniques internes d'un programme, il a un effet repoussoir, sauf pour les passionnés ou ceux qui ont déjà des notions de dev. J'en ai vu un paquet, ramer avec les pointeurs, sans comprendre la moitié des TP. Je dirais plutot que pour commencer, il est préférable d'utiliser un truc plus simple, pour assimiler les notions de base, puis éventuellement (et préférable) de faire du C, pour, en effet, voir ce qu'il se passe sous le capot.

Et je dis ça alors que je me suis bien amusé à apprendre le C.

[Paul_Le_Heros]

J'ai souvent été dans cette attente, et aussi souvent déçu ! J'ai déposé le code d'une application JS ici, et le seul feekback que j'ai reçu concernait les couleurs que j'avais choisies ! Et je ne crois pas que mon code était sans ombres, loin de là !
Je suppose qu'il y a de nombreux membres de Developpez.net de mon âge qui sont comme moi : autodidactes et souffrent de cette situation, parce qu'ils savent que ce n'est pas génial, et se considèrent en carence.
Tout ça, c'est beau comme du Verlaine !

[Matthieu Vergne]

Mais devenir un bon développeur ne s'apprend ni en 2 mois, ni sur un forum. Comme dans tous les autres domaines, pour devenir bon il faut pratiquer, chercher à s'améliorer, comprendre différentes manières de travailler pour comprendre qu'il n'y a pas qu'une seule "bonne" façon de faire, et se poser beaucoup de questions pour savoir où on se place soi-même et déterminer progressivement des pratiques efficientes, efficaces et cohérentes.

[eautret]

Après un DUT Génie Electrique et Informatique Industrielle, j'ai commencé à IBM en langage C (sous OS/2) en 1995.

J'avais acheté un livre sur le langage C. J'avais appris le Pascal en IUT. Le chef m'a donné du temps pour le bouquiner et faire les exercices pratiques.

Mes collègues étaient vraiment des pros. Ils étaient à mes côtés lors de mon premier trap D sur un 486. J'ai appris beaucoup avec eux.

Le chef m'a envoyé a bon nombres de formations IBM à Noisy-Le-Grand: OS/2, langage C, SGBD, DB2, SQL, Unix... Orienté Objet, JAVA, Visual Age for JAVA. C'était vraiment super.

Il faut aussi passer du temps dans les différentes documentations.

[pmithrandir]

Si je devais préciser d'autres points important pour bien progresser :
- Choisir une équipe qui fait du code review, de l'intégration continue et qui fait participer tout le monde
- Prendre un langage objet (ou d'un autre type) et le pousser loin. Une fois que l'on a assimilé les concepts, on se rends compte que tous les langages ont a peu près les mêmes mécanismes à quelques variantes près. Et une fois que l'on sait quoi chercher, on trouve facilement des réponses.

Pour moi, si vous allez faire du dev logiciel de haut niveau, laissez passer C ou d'autres languages comme l'assembleur. C'est peut etre fun, mais ce n'est pas nécessaire.
Le monde de l'informatique devient trop vaste pour qu'un développeur soit bon partout. Donc si vous vous dispersez trop, vous allez arriver avec 25 technos sur votre CV, mais vous serez qualifié de junior dans toutes ces technos.

En revanche, prenez le temps de comprendre les archi cloud. Ca force a repenser totalement la manière de fabriquer un logiciel, et c'est l'avenir pour 90% de la profession de dev logiciel. (que ca soit en cloud privé ou public). Archi micro service, deploiement canari ou blue green, lambda, stockage objet, docker, terraform, ansible, ... des mots que vous devriez connaitre et qui mérite que l'on y passe un peu de temps pour explorer les concepts derrière. Concepts qui s'appliquent très bien sur openstack, aws, azure, et tous els autres cloud possible.

[Matthieu Vergne]

Le cloud, c'est quand même bien particulier. Certes c'est la hype du moment, mais comme toute hype, ça monte avant de redescendre. Et je ne suis pas du tout convaincu que ça réponde à tous les besoins, donc pour moi ce n'est pas une référence.

Par contre, la programmation concurrente oui, et ça ça sert dans le cloud mais pas seulement. J'ai trouvé le langage Go particulièrement efficace sur ce plan, il introduit une façon de concevoir et de travailler à base d'échanges de messages qui se réplique bien ailleurs (j'ai appliqué le même style en bash avec les pipes nommés par exemple, en Java on peut faire du thread mais c'est pas aussi efficace, mais avec le projet Loom ça promet).

La programmation concurrente est un paradigme en soi. Ça ne s'apprend pas facilement car on est trop habitué au séquentiel avec les maths et l'informatique "écolière". Mais ça devient très accessible : Scratch le fait par exemple, alors que c'est pour les enfants.