Devenir un Ninja en Java
Au début de ma carrière, je me souviens qu’un de mes collègues m’a dit « Tu sais, au final, on se rend compte qu’il n’y a que très peu de différence de productivité entre un bon développeur et un développeur lambda ». Je l’ai cru, et il m’a fallu quelques années pour me rendre compte qu’il avait complétement tort. Un développeur productif peu produire jusqu’à 10 fois plus (sans diminuer la qualité du code). Sachant que les tarifs vont du simple au double, engager un bon développeur, 2 fois plus cher, peut s’avérer en fait 5 fois plus rentable pour le client. Pensez y au prochain entretien 
A votre avis, un client préférera prendre un développeur productif mais cher ou un développeur lambda pas cher ?
Apprendre en continu
Le seul moyen de s’améliorer c’est d’apprendre, apprendre, apprendre. N’hésitez pas à poser une journée ou deux par mois, et de préférence en semaine pour vous former au calme, chez vous. Les transports sont aussi une bonne occasion, pour ceux qui ont la chance de les utiliser.
Ce n’est que quand j’ai commencé à m’ennuyer en mission que j’ai décidé de lire. Et c’est en lisant que je me suis rendu compte à quel point j’étais mauvais en Java. Le livre qui m’a fait prendre conscience est « Effective Java » :
Bien, une fois que j’ai pris conscience qu’en fait j’avais rien compris à Java, suis je meilleur développeur ? Non, mais c’est un début. Maintenant il faut apprendre se comporter comme un bon développeur. Que ce soit avec votre code : « Don’t repeat yourself », avec les autres : « Provide Options, Don’t Make Lame Excuses » ou avec vous même : « Invest Regularly in Your Knowledge Portfolio »
« The pragmatic programmer » est LE livre à lire et se présente sous la forme d’une liste d’astuces :
Dans le même style, les astuces sont plutôt orientées Business mais certaines peuvent s’appliquer à nos développements. Et puis, quel freelance ne rêve pas de monter sa petite entreprise ? Rework est le genre de livre qui peut révolutionner une vie :
Et après ?
Voici une liste d’astuces, issue de ma propre expérience.
– Maîtriser vos outils : Apprenez les raccourcis clavier de votre IDE et utilisez les. Regarder comment les autres développeur utilisent vos outils, c’est très instructif !
– Choisissez vos missions : Débrouiller vous pour toujours travailler avec des gens meilleurs que vous. Faites en sortes de toujours apprendre quelque chose de nouveau (technos, architecture, langage, métier, méthodologie).
– Reposez vous : Inutile de se fatiguer au travail, cela ne fera que baisser votre productivité. Fatigue = erreurs. Un besoin incompris, c’est une productivité nulle.
– Changez vous les idées, consacrez du temps à vos loisirs et à votre famille. Cela boostera votre créativité et vous aidera à résoudre les problèmes complexes.
– Limitez les sources de perturbations. Coupez Twitter, votre e-mail (même le pro) ainsi que Facebook. Profitez de votre téléphone 3G dernier cris pour traiter tous ça dans les transports le matin et le soir.
– Travaillez vos forces et laissez tomber vos faiblesses : Est ce bien utile de s’obstiner à maîtriser CSS et photoshop alors que l’on n’est pas artiste pour un sou ? Cela va vous prendre énormément de temps. Temps qui serait mieux utilisé à augmenter votre expertise dans votre domaine de compétence. Ne soyez pas dupes et ne soyez pas jaloux des « rockstar », vous êtes sans doute meilleur qu’eux dans un autre domaine !
Livres Bonus
Pour ceux qui vont vite et aussi parceque cet article est l’occasion de tester les liens sponsorisés Amazon ;), voici 3 livres qui m’ont également aidé à progresser et que je vous conseil pour compléter votre read list:
YapluKa !
Java | Jean-Baptiste | 4 octobre 2010
J’irai même jusqu’à 40 fois plus productif, sans compter la capacité d’analyse dans des situations critiques comme le support de production.
« Clean Code » existe aussi en français chez Pearson.
Quand à « Apache Maven », ce livre devrait être obligatoire 😛
Honte à moi, je n’ai toujours pas lu la bible du DDD …
Il est aussi intéressant de se pencher sur les technologies voisines: Groovy ou Scala. Je m’y suis penché assez récemment et ça m’a fait gagner beaucoup en productivité.
De mémoire il me semble que la moyenne mondiale de LoC (Lines of Code) produites par jour est d’environ 27.
Ca permet déjà de se donner une idée de sa productivité.
Sur les 2 derniers mois d’une mission où nous étions 2 nous avons produit :
java: 16589 (73.11%)
xml: 6103 (26.89%)
Total Physical Source Lines of Code (SLOC) = 22,692
Development Effort Estimate, Person-Years (Person-Months) = 5.31 (63.66)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 1.01 (12.12)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 5.25
Total Estimated Cost to Develop = $ 716,652
(average salary = $56,286/year, overhead = 2.40).
Credits: dgenerated using David A. Wheeler’s ‘SLOCCount’.
Soit pour 40 jours de missions : 283 LoC / personne / jour. Et sur ces 40 jours vous imaginez bien qu’il y a des meetings, des phases d’analyse et de design où vous ne codez absolument rien.
Donc si certains pensent qu’il n’y a aucune différence entre un junior et un senior : think again!
Il y a évidemment des différences de productivité entre junior et senior, et il y en a évidemment entre seniors…
Je suis toujours un peu gêné par ces mesures de LOC produites par jour. Un développeur qui ne refactore pas son code et qui laisse du code dupliqué est donc plus productif que son collègue clean coder? 😉
Bon article merci, je rajouterais Refactoring de Martin Fowler qui est très facile à lire et qui m’a ouvert les yeux.
Je suis assez d’accord sur le LOC, il faut supprimer les effets de bords avant de pouvoir vraiment comparer 😉
Merci pour le livre, je ne connaissais pas, je le rajoute a ma readlist !
Un bon conseil que je note.
La remarque très superficielle sur la productivité équivalente d’un bon et d’un mauvais programmeur ne m’étonne pas, moi. On peut vraiment avoir cette sensation si l’on s’arrête aux apparences. En réalité, un bon programmeur ne va pas pondre plus de lignes de code dans la plupart des cas, ni plus vite. Par contre, il va prendre le temps de réfléchir à son code, et écrire du code plus propre. De cette manière, son code comportera moins de bugs, sera plus facile à lire et à maintenir. Pour moi, c’est ici qu’on trouve véritablement le facteur 10 entre un bon et un mauvais.
Bonjour,
petite info, Rework est désormais disponible en Français:
https://www.amazon.fr/Rework-Réussir-autrement-Jason-Fried/dp/2840016605/ref=sr_1_1?ie=UTF8&qid=1292412250&sr=1-1
Venant de Vba (programmation Access) je vais, bientôt, commencer à développer en Java. C’est un univers si grand que les sites comme le votre sont toujours les bienvenus pour ceux qui se lancent dans de « nouvelles aventures » et vous me semblez prodiguer les mêmes conseils que je n’hésiterais pas à donner moi-même. Quant à la « productivité il me semble que le « bon » développeur est celui qui essait de créer un code propre et le plus économique possible et prends le temps de réfléchir à ce qui serait la meilleur solution ou n’hésite pas à changer une grande partie son code s’il en retire des bénéfices dans le long terme. C’est comme ça que j’ai toujours procédé et ça me semble logique… Je ne suis jamais aussi content que lorsque je réduis mes lignes de code avec une efficacité accrue. Et pour ça une unique solution, travailler beaucoup et apprendre beaucoup, les résultats arrivent forcément (sauf si on est vraiment « bouché »…). Merci à vous et à ceux qui donnent leur avis et conseils.
Bonjour,
Merci pour les ocnseils et les livres.
Je débute en Java.
Actuellement à l’IESA multimédia, en Septembre 2013 je vais passer le Titre Certifié « Chef de Projet Multimédia ».
Si tout se passe comme je le souhaite, je vais apprendre à coder chez EPITECH à partir de l’année prochaine.
En attendant je m’entraîne car cela est ce que j’aime.
Wafaa.
De très bons conseils pour les débutants, comme pour les confirmés.