Apprendre à développer en quelques mois, vraiment ?

android-growth-chart
Les besoins de développeurs informatique sont très importants aux Etats-Unis, portés par notamment par les croissance des OS de téléphones mobiles et par le fait que certains sociétés telles que Google, Facebook, Twitter etc … placent leurs réalisateurs de logiciels au niveau de stars …
De plus les salaires de bons développeurs aux Etats-Unis sont à une moyenne de 90 000 $ / an ce qui est argument suffisant pour attirer nombre de candidats à la reconversion …
C’est dans ce contexte qu’apparaissent Outre-Atlantique de plus en plus de “Coding Bootcamps” qui sont des formations intenses de quelques mois pour apprendre un langage de développement (Android, iOS, html5, php, java …) ; chaque formation a sa spécialité et certains de ces cursus se vantent d’avoir un taux d’embauche suite à la formation de 85 % … Ce taux est alléchant mais il ne faut pas oublier que la sélection a l’entrée est très difficile (jusqu’à plusieurs milliers de demandes pour moins d’une centaine de places disponibles parfois) et coûte plusieurs milliers de dollars …
Si la formation donnée peut permettre d’être opérationnel dans un langage donné, il ne faut pas croire que cela transforme les élèves en développeur à vie … En effet, en quelques mois, ils peuvent développer dans un langage et pourront satisfaire ponctuellement un employeur sachant qu’une mission de développement dure rarement plusieurs années et qu’il est facile de licencier aux Etats-Unis. En plus de connaître un langage, il faut aussi maîtriser le travail en équipe car l’une des phases la plus délicate de réalisation d’un logiciel est la phase d’intégration ; plus le développeur aura documenté et expliqué ses API et discuté avec les autres développeurs, moins les risques ‘”d’explosion” lors de la mise en commun des différentes parties du logiciels seront importants.
De plus il faut éviter de tomber dans certains pièges liés à la réalisation de code (ce qui peut parfois s’apparenter à une réalisation artistique ; en tout cas en développant, j’ai réellement l’impression de créer …) :

  • vous en serez pas le seul ou la seule à lire, utiliser ou maintenir votre code ; il faut donc le documenter et éviter la factorisation à outrance pour rendre le code facile à maintenir
  • moins il y a de lignes de codes moins il y a le risque de bogues ; c’est en grande partie vrai mais si le code est trop compliqué ou trop factorisé, il sera difficile à maintenir (même pour vous si vous le reprenez plusieurs mois après l’avoir écrit), il faut donc trouver le bon compromis entre efficacité, quantité et qualité
  • ne jamais négliger les tests unitaires et les tests de non-régression (si possible automatiques …)
  • le mieux peut parfois être l’ennemi du bien ; en effet, le code peut quasiment toujours être optimisé et donc on peut vite déborder de ses objectifs en essayant de rendre la meilleure copie possible …

Cela signifie aussi qu’il faut maîtriser les outils de gestion de configuration (ClearCase, git …) pour faciliter l’intégration et le suivi des sources et savoir s’adapter car il est très difficile d’avoir des spécifications détaillées d’un logiciel (et des spécifications qui ne changeront pas en cours de développement) comme on pourrait avoir les plans d’une maison … C’est un des inconvénients du développement, il n’y a pas de solution miracle, il faut faire avec (même lorsque l’on adapte des normes qui sont pourtant figées à la publication, ce que l’on en fait peut changer).
Les missions de développement sont généralement de quelques mois et pendant ce laps de temps il faut savoir s’adapter (nouvelles spécifications, nouvelles interfaces, nouveaux outils) ; il est donc très important de rester toujours en veille …
Si ces formations accélérées arrivent en France, ce n’est pas sûr qu’elles soient adaptées au marché du travail car on mise plus sur le potentiel du développeur et sa capacité à s’adapter sur des plusieurs missions de courtes durées en CDI (alors qu’aux Etats-Unis on peut licencier à la fin de la mission).
Je code à temps plein depuis 1996 et je ne cesse d’apprendre pour rester au niveau ;  donc faire miroiter des expertises à des élèves en quelques mois, je reste tout de même sceptique …
Plus d’informations (en anglais) : ReadWrite

Mon robot Danael présente le boxing day rugby

Nous sommes le 29 Décembre 2013, il est presque midi et il me vient une idée : faire présenter à mon robot Danael le programme du boxing day rugby qui va démarrer à 15 H.
2Je réfléchis aussitôt à la mise en scène (lieu, informations à transmettre, comportements …).
Je souhaite que le robot soit proche d’un écran qui affichera des informations concernant les matches en même temps que le robot annoncera le programme. J’ai donc programmé rapidement une petite application en WPF et CSharp qui fera apparaître les matches aux moments choisis ; par manque de temps, je n’ai pas synchronisé automatiquement les animations avec le robot.
Je n’ai pas non plus eu le temps de faire un dialogue entre mes 2 robots (comme pour la vidéo du Pilou-Pilou) mais cela sera peut-être pour une autre fois.
Vous pouvez voir la vidéo ci-dessous :