MENTALITÉ DE HACKEUR ET DÉVELOPPEMENT PERSONNEL.
TECHNIQUES DE HACKING POUR AUGMENTER SES CAPACITÉS RÉDACTIONNELLES
( Mel Vadeker, 1998 )

Dans le monde fermé des créateurs de logiciels et des spécialistes en conception de systèmes, se faire appeler hackeur est honorifique, c'est comme un titre d’excellence. Dans le langage courant, il a souvent pris le sens péjoratif de pirate et de bricoleur de réseau.
Donc à l'origine de la création du terme, dans le milieu des informaticiens de haut niveau, être un hackeur ou être désigné comme tel, était un signe de maîtrise de l'art de la programmation, il honorait un talent particulier, une connaissance approfondie des systèmes informatiques et des algorithmes, distingaitdes capacités psychologiques et physiques adaptées au travail intensif.
 

COMMENT DEVENIR HACKEUR ?

Le hacking est une manière de voir un travail à accomplir ainsi qu’une mise en production efficace et économique. Il peut s'appliquer aussi bien à la programmation qu'à l’écriture.

Il s'agit de faire le travail avec le maximum de productivité. En informatique, il faut produire du code jetable avec le minimum de bogues. Ayant remarqué que les bons hackeurs étaient capables d’être aussi productif qu'une dizaine de programmeurs à plein temps pour une durée réduite de production. Il s'agit alors de gagner du temps et de produire le plus vite possible pour satisfaire les contraintes industrielles.
 

RESUME DE LA PHILOSOPHIE DU HACKING :

Production du travail descendante (top-down), on produit à partir d'une idée générale que l'on décompose sans réfléchir en utilisant les procédures les plus simples possibles. Il faut éviter de bloquer par l'acte de réflexion, il faut surtout produire à partir d’une idée simple que l'on décompose jusqu’à ce qu'elle se trouve exprimée par ses parties, c'est une arborescence inversée. Le tronc c'est le point de départ de l’idée principale (main fonction), ensuite l’idée se divise en fonctions très simples dans lesquelles on appelle d'autres fonctions jusqu’à épuisement de la représentation et de la problématique exprimée dans l’idée de départ, c'est à dire jusqu’au plus bas de l'arborescence.

Un exemple, construire une voiture :

- mauvaise solution, réfléchir sur l'ensemble dans toute sa complexité sans maîtriser le réseau des relations qui lie tous les éléments.

-bonne solution, créer un modèle simplifié de voiture avec le minimum de pièces puis faire évoluer chacune de pièces selon les critères les plus simples possible pour les accorder avec les autres pièces qui évoluent de concert.

La production se fait par pallier, elle est quantifié et normalisé par un seuil de qualité que l'on peut faire progresser à loisir.

Voilà donc deux approches opposées, la première qui se veut exhaustive s'appelle approche ascendante (bottom-up), elle a l'ambition de décrire la complexité d'une seule traite puis de la synthétiser en remontant.

L'autre approche, utilisé dans le hacking, dite approche descendante (top-down), fait l'inverse et part de l'idée la plus simple, elle rejette toutes contraintes de complexité pour formaliser par étape les niveaux de représentation d'une manière limpide avec le minimum de dépense énergétique.

En fin de compte, produire du code, c'est produire un texte hautement formalisé avec sa syntaxe propre, sa grammaire tout en respectant un niveau de qualité au final.
 

PHASE DE CODAGE :

Le codeur ne réfléchi pas à ce qu'il doit faire puisqu'il ne le sait pas. Il ne connaît pas le résultat de son travail, il ne sait pas d'avance à quoi va ressembler le résultat final. On peut dire qu'il improvise au fur et à mesure en réfléchissant le moins possible, en simplifiant les taches complexes pour en atteindre les singularités afin que de l'ensemble de toutes les singularités émerge cette complexité qu'il ne maîtrise pas mais que le réseau de relation qu'il a échafaudé permet d'extraire.
 

ETAPE DE LA PRODUCTION :

Le codeur ne s’arrête pas tant que son travail n'est pas abouti, tant qu'il n'est pas arrivé à descendre au plus bas dans l'arborescence, au plus bas dans la décomposition de la complexité. Il travaille avec sa mémoire, un minimum de notes, et code sans s’arrêter. On dit alors qu'il crache du code. Le rendement journalier d'un bon hackeur étant compris entre deux mille et deux mille cinq cents lignes de code sans bogues graves. Quelques retouches seront nécessaires mais dès que le taux d'erreurs devient trop important, le code entier est jeté pour reprendre la production au début. Cette technique a fait ses preuves, il a été prouvé que pour une certaine qualité et rentabilité, il était plus coûteux de maintenir et de déboguer un programme que de la refaire à zéro. Bien sur, il s'agit de production à fortes contraintes de temps et de qualité. Selon le cahier des charges et le milieu de production, on fait appel à l'une ou à l'autre des techniques (top-down, bottom-up), il arrive de faire également des compromis pour uliser ces deux techniques en parallèles par la décomposition modulaire du travail.
 

MENTALITE DU HACKEUR :

C'est la même approche que celui qui s’entraîne à un sport d'endurance, il faut pratiquer au plus bas niveau pour sentir les premiers effets et ensuite diriger la progression.

Près-requis nécessaire : il faut une parfaite maîtrise du langage que l'on manipule et éviter les erreurs de syntaxe, utiliser le vocabulaire étendue le plus possible pour exprimer les fonctions à traiter de la manière la plus simple. Le début du hacking est toujours une gymnastique qui abouti à un conditionnement psychologique. Un hackeur qui s’arrête de produite redevient aussi mauvais qu'a ses débuts, il doit alors reprendre sa progression depuis le début, comme un sportif reprenant l’entraînement après une longue période de congé. Il y a bien sur des subtilités du hack qu'il peut découvrir au fur et à mesure ou inventer de manière à accélérer le travail. Par exemple dans la manière de décomposer et de simplifier, dans sa manières de relier les singularités qu'il a formalisé dans un réseau de relation cohérent. Mais ce n'est que le fruit de la pratique qui permet de faire émerger un style de production. Le taux de progression est rapide dès que le conditionnement du hack est amorcé.

Premiers jours de hack, quelques lignes. Ensuite l'effet apparaît avec une meilleure concentration sur les taches à effectuer, une vingtaine de lignes. La progression est très rapide mais se fait par pallier. Une autre étape du conditionnement est de verrouiller son attention sur la tache à effectuer jusqu'au but souhaité et s'il faut décomposer le temps, il faut veiller à ne pas rompre le fil de l’écriture en oubliant les étapes que l'on a mémorisées.
 

VISION DE LA TACHE A ACCOMPLIR :

Le hackeur ne se dit pas qu'il doit faire un travail à venir. Il ne se dit pas, je dois le faire avant qu'il ne soit trop tard. Cela ne l'aide pas de voir sont travail planifié par des contraintes qu'il a lui-même fixé. Le hackeur ne se fixe aucune limite car plus grande et la portée de son imagination et plus grande est sa capacité d'aboutir rapidement. Il imagine une manière de décomposer, il le fait sans effort car il n'a pas le temps de souffrir. Il suit simplement le flot de la simplification le guider jusqu’à ce que se résorbe toute la représentation dans son expression la plus simple. Il s’arrête de coder dès qu'il ne trouve plus de fonction à simplifier, c’est alors qu’il saura que le travail est abouti, toute la problématique est alors contenue dans l’écriture, la boucle est bouclé.
 

LES DEBUTS DU HACK :

Il se fixe une plage horaire pour coder, il se donne 3 heures pour commencer. Il fait ce qu'il faut durant ce laps de temps ensuite il s’arrête pour reprendre le lendemain. Il ne se lève pas pour se dire, il faut que je code, non, il prend ses trois heures pour coder et ensuite il peut aller s'amuser s'il le désire. Cela ne doit pas lui prendre un effort surhumain pour se mettre en condition ni pour produire car cela gênerais sa vitesse de progression. Ensuite, il se fixe, cinq heures par jour, il code d'une traite sans s'en rendre compte, étonné par la facilité. Il reprend les jours suivant pour conforter le conditionnement.

Même si les étapes sont pénible dans un premier temps, il sait que le conditionnement fonctionnera car il en a la preuve par l'exemple. Il a vu les collègues réussir de hautes prouesses en apparence alors qu'en fait ils ne faisaient que suivre le flot continu d'une simplification. Il sait aussi que cela marche sur tout le monde sans exception. Il suffit de ne pas se tromper dans la manière de voir la tache à accomplir. Une tache qui n'est pas à faire mais qui devient un travail borné dans le temps quotidien par le propre conditionnement que l'on s'est fixé.

Rapidement, le hackeur est capable de coder 8 heures par jour, sans en ressentir le stress, 8 heures d'une traite ou 4 heures le matin et 4 heures l’après-midi. La seule contrainte du conditionnement est de respecter le taux horaire prévu d'avance. S'il travaille 8 heures, il sait qu'il peut faire plus sans trop de problèmes avec des pauses. Dix heures par jours, quinze et plus selon son niveau de fatigue.
 

L’ECOUTE DU CORPS :

Le hackeur ne doit pas se faire un ennemi de son corps. Il est à son écoute, dès qu'il se sent trop fatigué il se repose, dort une, deux ou trois heures et reprend ensuite. Il dort dans le lieu de sa production. Très souvent, on voit les hackeurs étalés sous la table pour deux heures de récupération et reprendre ensuite pour quatre heures ou plus. Une parfaire écoute pour un rendement maximum. Il est évident que l'excellence ne s'obtient pas du jour au lendemain mais elle vient très vite dans le cas du hack, infiniment plus vite que dans le sport.
 

LE CONDITIONNEMENT :

En quelques jours il est possible de voir sur la personnalité un conditionnement de hackeur. Le conditionnement pouvant être étendu selon les besoins. Les progrès sont toujours spectaculaires chez le débutant qui passe du jour au lendemain, de codeur lent à moyen, puis d'un coup, de codeur moyen à codeur rapide. Il n'y a pas de discrimination, l’expérience a démontré que la pratique égalise les niveaux quels que soit l'origine du débutant, hommes, femmes, handicapés, enfants, adolescents, vieux. Il n'y a pas de limite à priori à la progression. On pourrait dire par exemple que l'on code comme on lit un roman, si on lit dix heures par jour, on code dix heures par jour. On reste concentré sans souffrir du stress.
 

UN EXEMPLE :

Ecrire un mémoire de 50 pages en hackant son texte.

Cracher du texte sans se retenir. Faire les rajouts à la fin ou par annotation périodique. Se remplir la tête de connaissances avant et jamais pendant la phase d’écriture. Provoquer l'inspiration après l’assimilation des connaissances.

En 7 jours par pallier.

jour un : 2 fois 2 heures, 3 pages
jour deux : 2 fois 2heures, 4 pages
jour trois : 2 fois 3 heures, 6 pages
jour quatre : 3 fois 3heures, 10 pages
jour cinq : 3 fois 4 heures, 12 pages
jour six : 3 fois 4 heures, 15 pages
jour sept : correction

En 5 jours facilement.

A peu près 10 pages par jour durant environ deux fois quatre heures

En 4 jours avec de l’entraînement

12 pages pour les 3 premiers jours et 14 pages le dernier durant 3 fois 4 heures.

Il faut faire les corrections et l'acquisition des connaissances dans les jours de relâche.

Il est possible d'avoir un meilleur rendement en augmentant le taux journalier de travail jusqu’à 15 heures par jour.

Le hackeur pour conserver son niveau, continue à coder même s’il n'y est pas contraint. Il le fait tout simplement comme le ferait un sportif pour maintenir sa condition.
 

RESUME DE LA TECHNIQUE DU HACKING :

- acquisition des connaissances avant tout lancement de codage. Phase d’imprégnation et de digestion des spécifications du cahier des charges.

- Mise en conditionnement par provocation de l'inspiration, création de la ligne directrice. Création de l'amorce du code qu'est la fonction principale (main fonction) de laquelle découle tous les descendants des fonctions et sous-fonctions (arborescence inversé). Phase de près visualisation du plan de départ qui sera décomposé par la suite.

- Lancement de la production, codage selon la marge d'erreur et les contraintes de la production. Planning journalier ou travail à l’écoute du corps à la limite des possibilités physiques.

- Ecriture du code en flux continu, avec mémorisation et création des sous-fonctions simplificatrices qui elles-mêmes appelleront d'autres fonctions. La fonction étant la représentation du traitement le plus simple. Si un traitement peut être simplifié, il devra l’être en autant de sous-fonction jusqu’à épuisement de la complexité, en d’autres termes jusqu’à l’arrêt de la problématique que l'on a décrite dans la fonction principale (main fonction).

- Phase de compilation et d'estimation du taux d'erreurs, vérification du code et exécution du programme.
 
 

PIEGES A EVITER :

- Ne pas respecter le planning qui permet d'amorcer le conditionnement du hack.

- Repousser la phase de codage plus que nécessaire au profit de la phase d'acquisition des connaissances.

- Ne pas écouter son corps, son état de fatigue et ses besoins.

- Se stresser inutilement en pensant aux contraintes industrielles et au délais. Il n'y a pas de délai à priori, il faut coder selon les nécessités journalières et suivre si possible un ligne de progression stable.

- Oublier de penser à l'interconnexion des différents modules ou parties du travail d'où l’utilité de la mémorisation du point d'origine, de l'historique même si on ne connaît pas le point d’arrivé.

- Simplifier et créer des parties vides plutôt que de bâcler le travail. Les parties vides seront complétées plus tard en accord avec le cahier des charges.

- Ne pas confondre l'approche top-down (descendante) avec l'approche bottom-up (ascendante)

- Oublier la simplification des fonctions

- Oublier de se concentrer, de se focaliser sur le code que l'on découvre en continu. Repousser la distraction comme on la repousse qu'en on lit un roman passionnant.

- Ne pas se fixer de limite dans la créativité, éviter les contraintes de styles qui n'ont pas lieu d’être, viser en priorité l’efficacité et la limpidité.

- Ne pas hésiter à faire des sacrifices en période de corrections de code quitte à refaire des parties du programme, certains modules. Eviter de passer plus de temps à corriger qu'a créer du code. Rendre la période de deboguage la plus courte possible. C'est de cette manière qu'on reconnaît un code bien hacké.
______________

Ce texte a été produit par hacking avec un min. d'effort pour un max. de rendement.
Idée principale : expliquer le hacking.
Cahier des charges : faire court et simple
But : faire le tour de la question même s'il faut se répéter par endroit.
Durée : 6 pages en moins de deux heures

• Retour aux articles