Conseils à un jeune développeur Java

Par | Classé dans Débutant, Java | Le 29/09/2012

20

Tu viens de démarrer (ou vas bientôt démarrer) dans la vie active , tu sors d’une école d’ingénieur ou de l’université et tu as choisi d’être développeur (souvent java d’ailleurs). C’est cool, tu as choisi un beau métier pas forcément encore très reconnu et estimé à sa juste valeur en France, mais ça c’est une autre histoire.

Toujours est-il que je te vois très souvent, que ce soit en face à face lors d’un entretien ou directement sur un projet et si je peux me permettre j’aimerais te donner quelques conseils parce que … tu me déprimes.

  • J2ee tu n’écriras plus sur ton CV : pour ton info ça s’écrit JEE (voire comme me le fait remarquer sami, Java EE). Et arrête de mettre spring, struts dans cette norme, mais jette un œil ici une fois pour toutes. Parfois tu n’écris pas j2ee mais java/j2ee (java-ji-deux-e) comme s’il s’agissait d’un seul mot. Tu as certainement du t’inspirer de CVs qu’on t’a recommandés à l’école ou  d’une version retravaillée par une ssii. Et au fait, depuis quand struts et spring font-ils partie de la norme Java EE.
  • Le langage et le Sdk tu connaîtras : c’est quand même le minimum lorsqu’on programme dans un langage que de connaitre ses possibilités : et pourtant combien de fois je me surprends en train de t’expliquer l’intérêt d’utiliser telle collection plutôt que telle autre. Ça veut aussi dire que tu suivras les évolutions du jdk : on en est à la version 7 et combien de nouvelles fonctionnalités peux-tu me citer ?
  • Au Jug tu iras : il y en a certainement un près de chez toi. Les cast codeurs tu écouteras (http://javaposse.com/ également si tu es anglophone). Les flux rss tu liras, et les bonnes personnes tu ‘followeras’ sur twitter. Si tu es plutôt du matin ce sera http://thecodersbreakfast.net/ ou du soir http://blog.paumard.org/ : bref, intéresse toi un minimum.
  • A vie tu apprendras : c’est vrai pour n’importe quel programmeur mais tu devras le faire encore plus que tes collègues dans d’autres langages. Tu as choisi un écosystème de cinglé ou il ne se passe pas un jour sans qu’un nouveau framework/langage/concept ne sorte et il te faudra discernement et courage pour suivre le rythme car le tempo est soutenu.
  • Les bases de l’informatique tu “réviseras” : j’écris tu réviseras mais c’est uniquement pour ne pas faire répétition avec le conseil précédent. C’est vrai que l’industrie du software n’est pas hyper poussée en France et qu’il y a de fortes chances pour que tu travailles sur une application de gestion (avec une base de données , des serveurs/services web …) ce n’est pas une raison pour ignorer tout ce qui est en dessous, la JVM et la façon dont sont utilisées les ressources que tu sollicites sans t’en rendre compte.
  • Performance tu penseras : attention je n’ai pas dit “tu optimiseras” (chaque chose en son temps) : mais déjà essaye de penser que quand ton appli sera livrée, tu risques d’avoir légèrement plus de données à gérer, plus d’utilisateurs, plus de pression sur les ressources, plus de concurrence d’accès … : si tu en as la possibilité, prends une configuration pas trop puissante pour exécuter ton code, tu vas t’apercevoir des lenteurs plus tôt dans ton projet; utilise un jeu de données représentatif tant au niveau des valeurs qu’au niveau du volume. Pour coder en revanche, débrouille toi pour avoir la config la plus puissante : Quand je vois le temps perdu par jour et par développeur rien qu’à attendre que son build se termine ou que son serveur d’appli veuille bien démarrer …
  • Le sql tu maîtriseras : tu penses que tu connais hibernate/jpa et tu penses que ce vieux langage (qui a ton age !?) qu’est le sql ne vaut pas la peine que tu t’y attardes parce que c’est “has been” : d’ailleurs avoue que tu n’as jamais pensé à regarder quelles étaient les requêtes générées par ta couche de persistance préférée. Et si je te demande pourquoi ton code rame ne me dis pas “je ne sais pas, mais, le dba regarde” ou “c’est hibernate” : il faut te rendre à l’évidence : le problème est avant tout entre la chaise et le clavier.
  • D’ailleurs ton clavier par coeur tu connaîtras. Fais d’une pierre deux coups et profites-en pour en faire de même avec ton ide/éditeur : quand je te mets devant un écran pour observer comment tu codes, (en ayant bien entendu pris soin de te laisser le choix des armes – eclipse, netbeans, intellij, voire emacs ou vi), je ne te sens pas hyper à l’aise : tu regardes ton clavier, cherches tes touches, et passes un temps fou sur cette satanée souris pour fouiller dans les menus, lancer des commandes etc : tu es freiné par des considérations d’ordre purement techniques, des frottements qui t’empêchent de coder plus vite : débranche ton mulot et force toi à utiliser le clavier en le regardant un minimum voire en le cachant, apprends les raccourcis clavier : tu vas découvrir à quel point tu étais handicapé …
  • Pour terminer, outille toi avec tout ce qui pourras améliorer la qualité et la rapidité de tes développements : analyse de code, profiler, couverture de code, tests unitaires, jrebel  …

Tu as choisi un langage dont la difficulté ne réside ni dans le langage en lui même ni dans le sdk déjà bien fourni, mais dans la recherche et le choix des bons composants/framework et dans leur configuration / paramétrage : tu as passé beaucoup de temps à essayer de faire fonctionner ton assemblage de composants et tu as oublié de creuser les sujets qui te donneront des bases solides pour la suite de ta carrière.

Bref tu auras compris, si tu veux être un bon développeur et ne pas être obligé de passer chef de projet ou côté métier par la force des choses plus que par choix, donne toi les moyens et prends tout de suite les bons réflexes, reprends les bases et ne brûle pas les étapes, reste humble (il y en toujours qui en savent plus que toi)  … et code !

Partagez !    |
  • http://twitter.com/lambdadevfr lambdadev

    Amen!

  • Nicolas Noullet

    J’adhère totalement au contenu mais moins sur la forme. On voit fleurir des recommandations à destinations des petits jeunes et autres stagiaires qui ont une fâcheuse tendance au paternalisme “Toi, petit jeune qui ne sais pas bien ce qu’il fait, tu étais une brebis égarée mais grâce à mes précieux conseils, tu es sauvé !”.

    Je suis à peine diplômé, et pour avoir fait un tour en SSII, j’estime déjà suivre ces recommandations bien plus que nombre de développeurs plus âgés avec qui j’ai travaillé. A titre d’exemple, j’ai croisé une seule fois un employé de cette SSII au Jug alors que l’agence compte 1600 personnes.
    J’étendrais donc vos conseils (et ils sont de qualité) à l’ensemble des développeurs, à tout âge on a des choses à apprendre pour s’améliorer !

    • Antoine Ramponi

      Bonjour Nicolas, il se trouve que dans les autres langages on a un écosystème moins “touffu”. Par exemple les développeurs .Net sont guidés par microsoft et ne se perdent pas dans les méandres des frameworks pour savoir lequel choisir : Ils se concentrent plus rapidement sur le dev plutôt que d’essayer d’assembler les composants (c’est un peu comme si on avait en java que JEE). Par conséquent, ils maîtrisent plus tôt les SDK que les javamen qui dépensent de l’énergie là où il ne faut pas. play!, vert.x … attendront leur tour, rien ne presse. Il faut déjà comprendre dans quels cas j’utilise une TreeMap plutôt qu’une HashMap, combien de mémoire occupe une string, a quoi sert une variable volatile, Externalizable vs Serializable, comment fonctionne le gc et ses différentes stratégies …. il y a du taf ! Celui qui dit “ça me sert à quoi de connaître tout ça, ça ne m’empêche pas de programmer”, je lui “spécial dédicace” cet article

      • seb

        Salut Antoine,

        Je suis moi même un Java-iste de la première heure (J’ai écrit “Hello World” il y a 17 ans) et un ex-évangéliste Java (J’ai travaillé pour Sun pendant 10 ans, je suis JUG leader depuis plus de 5 ans, speaker @ JavaOne, Devoxx etc) et je reconnais que tu as tout à fait raison.

        Le gros problème de Java, c’est de choisir quel outil, quel framework, quel app serveur… Et sans un vieux brisquard expérimenté, ce choix est très complexe et te lie presque toujours pour la durée de vie de ton application. Sans compter les querelles de religion et de clocher.

        D’autres plate-formes, moins ouvertes, mais tout aussi complètes et mures offrent moins de choix. Du coup on se retrouve à programmer, à créer de la valeur et non à intégrer des frameworks ou ré-écrire telle partie du code pour utiliser “le-dernier-framework-geniaaal-dont-on-a-parlé-au-JUG”
        Les gens qui “vivent” et “respirent” Java ne se rendent pas compte de la complexité qu’ils ont crée ces 10 dernières années, largement pour de bonnes raisons, à savoir les problèmes de jeunesse de Java EE, le manque d’outil proposés par Sun à l’époque qui n’offrait “que” un SDK.

        Quand j’ouvre les yeux, sort mon nez du guidon, je découvre – et apprend très vite à apprécier – des environnements comme Python ou Objective-C / Cocoa. Moins de choix mais tout autant de possibilités et – au final – une meilleure productivité de la part des développeurs.

        L’industrie IT n’a d’industrie que le nom (en tout cas en matière de soft). Les processus de fabrication de logiciels n’ont – dans la plupart des cas – rien d’industriels. Nous travaillons plutôt comme des artisants.

        Je sais que je vais me faire “bashé” pour ce post – n’oubliez pas que je ne suis pas un Intégriste .Net ou anti-java, je suis lourdement impliqué dans la communauté Java depuis ses tout début :-)

        Merci pour ce blog post !

        Seb

      • Horacio Gonzalez

        Quelque part tu as raison… Moi aussi je suis “vieux” développeur Java, j’ai fait mon HelloWorld.java en 97, et je suis aussi impliqué dans la communauté (JUG leader, speaker occasionnel, je fais des formations…). Et je suis 100% d’accord qu’aujourd’hui on fait plus de l’artisanat que de l’industrie… mais pur moi cela est une avantage, pas un inconvénient !

        Je me revendique artisan développeur, software craftsman, et je me reconnais plus dans ce titre que dans l’officiel d’architecte logiciel. L’artisant, cette part de création, cette remise en question continue, ce foisonnement de nouvelles choses ¦a apprendre c’est ce qui rend ce métier passionnant pour moi. Je n’ai pas envie que le développeur soit l’ouvrier qualifié de l’industrie informatique, je préfère qu’il soit l’artisan (et à terme le maître artisan) de cette oeuvre collective.

        Enfin, ce n’est que mon avis, peut-être un peu trop idéaliste (mon côté bisounours 😉 ).

        Horacio

      • african style

        Bonjour,
        je suis comptable et j’ai 37 ans,
        Sa fait 12 ans que je travaille dans la compta mais je m’épanouie pas? je souhaite ùe reconvertir dans l’informatique,
        Pensez-vous qu’après une formation courte est-il possible de se reconvertir à la programmation java ?
        Je vous remercie d’avance de vos réponses,

  • pikatchoum

    mais dites moi, autant d efforts et de competences doivent meriter un bon salaire, hmmm? petit conseil au ssii: arretez de payer des ingés au lance pierre si vous voulez des skills!

    • http://twitter.com/FlorianBoulay Florian Boulay

      Sans vouloir défendre ma paroisse (je bosse chez In Fine), je pense que les SSII paient plutôt bien dans l’ensemble. Bien sûr, j’ai tendance à parler des SSII de taille modeste comme In Fine, Zenika, Xebia… . Peut-être ne parlais-tu pas d’In Fine ? Dans ce cas je suis d’accord avec toi, les grosses SSII ont tendance à embaucher à des salaires bas, et pour des missions peu motivantes…. heureusement qu’elles ne sont pas toutes comme ça.

    • Antoine Ramponi

      complètement d’accord pour payer les skills …. quand il y en a ! Et si connaître les fondamentaux te réclame autant d’efforts comme tu dis, pose toi les vraies questions. peace.

  • http://twitter.com/ehsavoie ehsavoie

    On a les ingénieurs qu’on mérite: à vouloir faire du développeur Java et J(2)EE une commodité on ne peut pas exiger de la qualité et de la passion …

  • Nessi

    J’allais dire à la première lecture que les conseils étaient peut-être un peu trop poussé “développeur pur”, et puis j’ai relu le titre et la phrase “si tu veux être un bon développeur et ne pas être obligé de passer chef de projet ou côté métier” et puis tout m’a semblé finalement “logique” dans la position :)

    N’empêche qu’il est plutôt difficile je trouve d’obtenir un chef de projet “débutant” sans passer par la case développeur ou mi-chef de projet/mi-développeur (chef de projet mais en faisant le boulot d’un développeur), de fait il y a une forte population qui ne développe pas par choix mais en attendant de “trouver mieux” (du moins selon eux, ces sales traîtres).

    Force est de constater que les “sur-couches” qui s’appliquent aux langages éloignent de plus en plus des préoccupations liées à l’espace mémoire par exemple ou l’optimisation des requêtes SQL (en plus la tendance est plutôt au no-SQL). Tiens, moi j’ai appris à faire un MCD à la main (litéralement), construire son schéma et choisir soigneusement les typages correspondant aux données à stocker, tout ça pour me coller dans les pattes des sur-couches du langage qui font ça “tout seul et sûrement mieux que toi”. Je trouve que l’évolution des langages vont faire la simplification du codage (write less do more) et le développement des langages “génériques” qui fleurissent dans le développement “web” et où le typage fait office de souvenir des “langages de l’ère du brontosoique” !

    Bref, je comprends les préoccupations d’avoir de bons développeurs JAVA, mais je comprends aussi que certains concepts énoncés peuvent ne pas avoir d’écho dans les nouvelles générations de développeurs.

    Mais bon, en même temps si tu veux faire du JAVA, t’assumes jusqu’au bout :)

  • Mick

    Ok pour le fond, bien que plus destiné aux développeurs qu’aux jeunes qui sortent de l’école. C’est plutôt en bossant qu’on apprend ça… d’autant plus vite qu’on est bien entouré.
    Par contre le forme est assez à l’encontre de l’avant dernier conseil “reste humble”.

  • Cédric

    Je trouve que l’on va trop loin dans la responsabilisation du développeur, sans jamais vraiment lui donner la possibilité de s’améliorer. Depuis quelques années, les employeurs demandent aux développeur de voir des exemples de code sur des projet perso sur github, de participer aux JUG sur leur soirée, de connaitre les dernières techno à la mode… Dans la réalité, dans l’entreprise, on n’a pas le choix de l’OS, de l’IDE, de la DB , de la version du JDK, du gestionnaire de version. Faut se battre pour avoir une machine qui fait un build continu, on te reproche de passer trop de temps à faire des Tests Unitaires…
    Tout le monde est ok pour s’améliorer en continu… Mais les employeurs proposent quoi ?

    • Anonyme

      Absolument d’accord. Les employeurs veulent toujours des mecs qui font de la veille, ont des projets perso, sont actifs dans les communautés, se tiennent à jour… mais ils veulent surtout que tout ça ne soit jamais aux frais de l’entreprise. Il va falloir ouvrir les yeux un jour.

      Soit on veut du passionné pur jus, et il faudra lui offrir un salaire à la hauteur, ainsi que du temps pour s’éclater entre deux projets mous du genou. Et ne pas s’étonner qu’il finisse par se barrer,frustré par vos stacks techno trop vieillissantes.
      Soit on prend du mec «normal», moins cher et surtout moins chiant à garder, mais dans ce cas il faut lui offrir à lui aussi du temps pour se former continuellement, parce qu’il a une.vie…

      Bref, il ne faudrait pas oublier de partager les charges du métier.

  • Pingback: La gestion des compétences « Anthony Patricio ’s Blog()

  • Anonyme

    Article intéressant mais de loin derrière les commentaires. Bravo !

  • Sami

    pour info c’est Java EE et non JEE ni J2ee

  • Mourad Toumi

    L’avant dernier conseil me fait doucement rire :) ça me rappelle un recruteur qui a réussi à me poser une colle sur un raccourci Éclipse, quelques minutes avant de le corriger sur un DP 😀

    Sinon, je suis d’accord avec le tout dernier paragraphe, de plus en plus de gens veulent devenir Chef de projet, tout le monde en France veut devenir chef :( à la différence des pays anglophones où un développeur expérimenté est payé 3x plus que son chef de projet :p