D’un coté il y a l’algorithmique que l’on souhaite enseigner aux étudiants, avec des concepts spécifiques (les structures de contrôle, les structures de données, …), des problématiques de modélisation, de validation et d’évaluation, … Cette science repose sur les facultés de notre cerveau à organiser et prévoir, manipuler des objets, réaliser une action, une activité, pour « faire ». Elle nécessite et mobilise la pensée « algorithmique » (si on peut la définir ainsi).

Tant que l’on reste au niveau d’un petit problème, le travail se fait en contact quasi direct avec les objets manipulés ; quand le problème devient plus gros, l’habitude consiste à réduire le problème à un ensemble de sous-problèmes plus simples, à prévoir plusieurs couches (par exemple) pour résoudre le problème, et  à chaque niveau on est en contact avec des objets -certes- mais ceux-ci sont de plus en plus complexes. S’observe alors la nécessité d’un basculement vers une autre forme de pensée, plus organisatrice (de haut niveau), on passe de l’algorithmique au génie logiciel.

Le passage de l’algorithmique au génie logiciel s’accompagne souvent de l’introduction de bibliothèques de programmes prêts à l’emploi et, à la suite, permet une autre forme de programmation qui ne demande ni conceptualisation, ni sens de la prévision, ni sens de l’organisation : la programmation-bricolage. Qu’est-ce que la programmation-bricolage ? C’est -face au problème- regarder dans sa boîte à outils quel est l’ustensile le plus facile à utiliser pour arriver à résoudre le problème, quitte à utiliser l’outil à mauvais escient, à écraser une mouche avec un marteau. C’est déplacer le travail sur la recherche de l’outil plutôt que la construction du programme. C’est préférer un programme d’une ligne à une exécution en temps constant. C’est préférer un programme d’une ligne même s’il engendre une exécution en un temps indéterminé à une exécution en temps constant à partir du moment celui-ci demande l’écriture d’un long programme.C’est bien connu, tout a déjà été fait, il ne faut pas réinventer la roue, allons sur internet ou dans la boite à outils de notre langage voir si la fonction n’existe pas déjà ou comment d’autres ont résolut le problème et copions-collons le résultat.

Espérons que celui qui agit ainsi ne perd pas le sens de ce qu’il fait, qu’il a su construire des outils pour valider et évaluer son travail …

Même si la distance entre le programmeur maître de ce qu’il fait et celui qui agit en croisant les doigts est grande, la frontière entre ces deux pratiques est parfois difficile à définir (dans tel domaine on peut agir en connaissance de cause, et ailleurs [devoir] faire confiance ; -et il y a du bon aussi à ne pas toujours réinventer la roue), il est donc délicat d’encenser l’un et condamner l’autre, mais j’ai tout de même le sentiment de voir chez l’un de la responsabilité, là où je ne vois chez l’autre qu’une envie de finir son travail le plus vite possible, à moindre coût (pour lui).