Au Pied Levé - À Main Levée
1. Doloop
par , 01/04/2022 à 10h30 (6570 Affichages)
Forum -► Général Développement -► Débats sur le développement – Le Best Of
■ ■ ■ SOMMAIRE ■ ■ ■
- Avant-propos
- Qui pratique la programmation spontanée ?
- Qu’est ce que l'on peut apprendre lorsque l'on est obligé de tout faire !
- La programmation spontanée se vit, mais ne s'explique pas fondamentalement, elle fait partie de nous.
- 10% des programmeurs sont capables d'écrire un programme sans ordinogramme.
- Programme bien pensé, fonctionnement assuré. Programme mal pensé est à recommencer.
- L'eXtreme Programming.
- Conclusion
■ Avant-proposEnvoyé par mumen
Inscrit en décembre 2003, Doloop est un développeur expérimenté qui programme spontanément depuis + de 8 ans. Compte tenu de son discours et de sa période d’activité (1995-2003), c’est vraisemblablement un informaticien de gestion. Sa démarche peut froisser certains informaticiens susceptibles, évoluant dans des contextes professionnels spécifiques (scientifique ou internet).
En six messages, Doloop analyse parfaitement sa démarche de développement qu’il nomme Programmation spontanée. Son analyse décrypte aussi bien l’aspect informatique de sa démarche que l’aspect psychologique de sa personnalité, ces deux aspects ayant en commun la maitrise de soi.
Doloop définit sa programmation spontanée ainsi :
- « Qui se fait de façon naturelle, sans arrière-pensée / Que l'on fait de soi-même, sans sollicitation extérieure. »
- « On invente l'algorithme pendant le codage du programme au fur et à mesure des besoins, au moment de se focaliser sur des points précis. Devant le clavier, on sait immédiatement ce que l'on a à faire, il suffit de transposer ce que l'on voit mentalement sur l'écran. »
- « L'algorithme du programme est conçu et optimisé au mieux simultanément au moment de sa saisie et de son étude. »
- « La programmation spontanée, c'est avant tout du travail mental assisté par de la méthode, lorsque l'on commence un programme on sait tout de suite ce qu'il nous manque à chaque étape. Il n'est pas utile de comprendre tout le programme à chaque seconde, mais de se focaliser sur les points qui nous manquent au présent. »
- « La programmation spontanée se vit, mais ne s'explique pas fondamentalement, elle fait partie de nous ».
- « Le programme que l'on a conçu, il est en nous, en le parcourant c'est un peu comme si l'on se promenait dans sa tête.
- « On s'adapte sans cesse au fonctionnement du langage de programmation et de l'ordinateur. »
- « On a une idée en tête qui va se réactualiser à chaque étape, on la suit. »
- « On arrive à déboguer par intuition, on parcourt le programme sans toujours savoir précisément ce que l'on recherche, dès que l'on est dessus on sait que c'est là, on réalise quelques tests de confirmation, une modification, le bogue est décelé et résolu. »
- « On isole mentalement chaque étapes du programme comme ceux qui élaborent l'algorithme sur papier, et on les réalise, il n'y a pas de sorcellerie, le programme ne se fait pas tout seul. »
- « Le programme codé en temps réel, l'algorithme est conçu et optimisé simultanément au moment de sa saisie et de son étude. »
Salut à tous,
Je souhaiterais savoir si beaucoup de personnes programment de manière spontanée comme moi.
J'ai déjà posé des questions à des personnes du domaine et ce n'était pas le cas pour eux. Cependant sur ce forum et d'autre, il y a des posts qui me semble confirmer que oui.
L'auteur d'un livre dans les années 80, annonçait qu'il n'y aurait que 10 % des programmeurs qui peuvent se passer de dessiner un algorithme pour faire un programme. Faisait-il allusion à la programmation spontanée, ou ce type de programmation porte-t-elle un autre nom ?
Double définition : Qui se fait de façon naturelle, sans arrière-pensée / Que l'on fait de soi-même, sans sollicitation extérieure.
On invente l'algorithme directement dans le programme au fur et à mesure des besoins qui se font ressentir au moment de se focaliser sur des points précis. Devant le clavier, on sait immédiatement ce que l'on a à faire, il suffit de transposer ce que l'on voit mentalement sur l'écran.
(Avec l'expérience, par concentration les solutions sur les points délicats des programmes, apparaissent dans la tête sous forme de flash). Attention cela ne veut pas dire que l'on ne fasse pas de bugs, si bug il y a, il n'est pas de structure, le programme est destiné à fonctionner sans modifier l'algorithme pensé initialement. Face à un bug, aucune panique par rapport à nos débuts, on sait qu'on va le trouver, ça remplace un jeu de déduction sans plus. Il n'est même pas nécessaire de rajouter le moindre commentaire pour comprendre ses propres programmes ou ceux des autres.
À la lecture des lignes d'instruction, on les simule dans sa tête. (Inutile de paraphraser ce que l'on est en train de lire). Je suis persuadé que tout le monde peut y arriver à force de pratiquer.
Cela fait penser aux dessinateurs comme Cabu et Plantu qui peuvent commencer leurs dessins par n'importe quel bout et parvenir au même résultat à la fin. (En ce qui concerne le dessin, ça doit être moins sûr. On doit avoir le truc en série ou on ne l'a pas).
Je rajoute une information qui me concerne et qui a peut-être son importance, c'est que je n'ai pas la mémoire qui retient facilement les récitations, en contrepartie j'utilise en remplacement la mémoire dite procédurale. La mémoire procédurale est peut être la mémoire la plus sollicitée pour programmer ?
Une personne sur un autre forum avait dit qu'il devenait en quelque sorte le programme (un peu comme Rambo devient la guerre). Ce qui prouve bien que ce cas n'est pas une exception.
- Qu'en est-il de vous et de ceux que vous connaissez ?
Merci pour vos réponses, et joyeuses fêtes à tous.
Merci pour vos réponses.
Le travail en équipe est différent, le niveau de compréhension de chacun est aussi variable.
La programmation spontanée, c'est avant tout du travail mental assisté par de la méthode, lorsque l'on commence un programme on sait tout de suite ce qu'il nous manque à chaque étape. Il n'est pas utile de comprendre tout le programme à chaque seconde, mais de se focaliser sur les points qui nous manquent au présent.
Revenir sur un ancien programme, n'est absolument pas un problème. Si chaque partie de programme a été testée et est conforme aux attentes, il n'y a plus à revenir dessus, il n'y aura pas de bugs. Si une modification du programme s’avère nécessaire, quelques tests suffisent pour identifier les lignes souhaitées.
La méthode est mauvaise ? Mes premiers pas se sont porté sur un logiciel complet pour me faire la main alors que je n'y connaissais pas grand chose (tout à découvrir, comme ceux qui commencent leurs études).
Le total de nombre de ligne du logiciel terminé :
45.338 lignes dont 38.063 lignes non espacées, programme compilé 1 Mo tout rond soit 743.755 caractères saisis au clavier + quelques programmes complémentaires < 100 Ko. (temps de réalisation 2.5 ans, c'est pas terrible comme délai, mais qu'est ce que l'on peut apprendre lorsque l'on est obligé de tout faire !).
En tant que débutant à l'époque, si la programmation spontanée n'avait pas été réalisable, je me serais arrêté à la 100ème ligne.
Je n'ai jamais prétendu que la programmation spontanée était facile surtout au début, cela demande beaucoup d'effort mental à cause de tout ce qu'il y a à apprendre, ensuite c'est l’expérience qui fait le reste.
Le programmeur qui se perd dans son propre programme, c'est qu'il n'a pas assez programmé ou alors qu’il s'est trompé d'orientation.
Se passer de commentaires c'est peut être dur au début, mais ensuite on développe d'autres facultés, celle de simuler le fonctionnement de chaque ligne observée. Si l'on part du principe qui peut le plus peut le moins. Rajouter des commentaires ne pose pas de problème en soi, tant que cela peut aider les autres. Mais lorsque l'on a le choix entre rajouter un commentaire et poursuivre le programme à la ligne suivante, j'ai fait le choix que la sortie de mon programme était prioritaire avant tout. Les commentaires ça peut toujours se rajouter ultérieurement une fois le programme achevé voir même vendu (d'ailleurs les compilateurs n'en tiennent même pas compte).
Un programme qui emploie des noms de variables, de sous-programmes et de fonctions significatifs pour moi contient plus d'information que nécessaire, c'est comme pour le Port-Salut, c'est marqué dessus.
Si quelqu'un fait une erreur de structure de programme (algorithme), le programme ne fonctionnera pas peu importe les commentaires employés même avec ; Jésus revient (quoi que). S'il faut passer 2 fois plus de temps à établir un algorithme qui à une chance de fonctionner que de faire le programme, moi je suis le patron, je pleure pour l'argent perdu à l'étude. Car s'il y a un endroit ou l'on peut gagner du temps et de l'argent, c'est bien à celui là.
@+
Merci beaucoup ErwanVDF d'avoir consacré de ton temps à répondre, et de me redonner un petit peu de crédibilité. Tu as fort bien expliqué le fonctionnement de la programmation spontanée.30/12/2003, 21h59 #28
■ La programmation spontanée se vit, mais ne s'explique pas fondamentalement, elle fait partie de nous.
La programmation spontanée se vit, mais ne s'explique pas fondamentalement, elle fait partie de nous.
La première fois que je me suis concentré pour commencer à créer véritablement un programme, ça m’a déconcentré immédiatement de me voir concentré à ce niveau (d'un point de vue extérieur).
Le simple fait de se concentrer permet de voir immédiatement non seulement la solution, mais les solutions. Il suffit ensuite d'effectuer son choix par rapport aux besoins futurs du programme.
J'ai même cru un moment que ces visions allaient finir par s'arrêter un jour ou l'autre, mais celles-ci se sont amplifiées et solidifiées avec l'expérience.
Cela me fait penser au jeu d'échecs, où l'on aurait déjà anticipé toute la stratégie de mise à mort de l'adversaire.
Les chiens ont une mémoire sélective en ce qui concerne l'odorat, ils peuvent se fixer sur une seule odeur et la suivre à la trace. Pour la programmation spontanée, c'est un peu la même chose on se fixe sur un détail, on ressent en parcourant le programme, l'endroit de ce que l'on recherche, pour finir par le trouver. L'intuition reprend le relais.
Le programme que l'on a conçu, il est en nous, en le parcourant c'est un peu comme si l'on se promenait dans sa tête.
À la création de mon premier programme, je me suis laissé dépasser comme tout novice, entre tout ce qu'il fallait faire pour le réussir, et découvrir en même temps toutes les possibilités algorithmiques par moi-même.
La seule envie finale, c'était de surpasser le programme, pour que ce ne soit plus le programme qui nous dépasse.
En ayant com
mencé par réaliser un logiciel sans aucune connaissance solide, l'immensité de ses possibilités et de sa complexité ma bouffé la tête au départ, je ne m'en cache pas, il était difficile de savoir par quoi commencer. Maintenant, mentalement je ne force plus. Lorsqu'il y a vraiment une difficulté d'un truc que l'on souhaite faire et que l'on ne sache pas encore faire, en se concentrant je ressens un flash (< 1") qui s'apparente à de la simulation accélérée, représentant la meilleure solution pour y parvenir, pour le reste c'est toujours la même chose, on sait déjà.
S'il y avait un bug, on part du principe qu'on va le trouver, il n'y a pas d'inquiétude. Au contraire cela met un petit peu d'action, ce qui n'est pas un mal en soi, il y a des limites, il faut les atteindre pour savoir où elles se situent.
Lorsque je fais un programme, je ne m’attends pas à ce qu'il fonctionne parfaitement du premier coup, mais on va adapter sa programmation par rapport au résultat obtenu en déterminant les éléments fautifs à son dysfonctionnement.
Il m'est déjà arrivé de continuer à débugger un programme l'ordinateur éteint, on l'allume et c'est bien ça.
J'ai remarqué que conduire une voiture pour moi, nécessitait plus d'effort d'attention cérébral, que de passer une journée entière à programmer et à débugger.
Récemment j'ai reporté la méthode sur l'électronique, et j'obtiens des résultats de fonctionnement identique. Dernièrement j'ai réalisé 3 cartes d'interfaces pour n'en former qu'une au final, en dessinant directement les typons en reliant manuellement les pattes des composants sur un logiciel de CAO : soit au total + 50 composants dont + 20 de différents. Tout fonctionne bien sur le port parallèle en bidirectionnel, il n'y a pas eu de modification.
Ce qui veut dire que le spontanéisme, ne s'arrête pas à l'informatique.
Lorsque l'on réussit quelque chose en tant que débutant, on ressent une autosatisfaction, tout le monde y est passé. Maintenant, à chaque programme réalisé, l'autosatisfaction est quasi inexistante, on est content que le programme soit terminé, on n'est pas déçu mais sans plus, on pense plus au prochain qu'à celui qui vient d'être fait.
Sur les forums je vois pour faire de l'informatique, qu’il faut être bon en math. Ce n'est pas mon cas ce serait même le contraire et cela ne me gène pas, peut être que cela peut aider dans des domaines spécifiques mais je ne me sens pas concerné.
Cela fait maintenant + de 8 ans que je programme spontanément, rajouter des commentaires ne me gênent pas et comme l'a bien fait comprendre ErwanVDF, à condition que ce ne soit pas n'importe quoi non plus.
Il était difficile voire impossible d'être le seul dans ce cas là, l'auteur du livre qui annonçait 10 % des programmeurs qui avait le potentiel ne devait pas se tromper à son époque, chez certain il faudra plus de temps pour que cela se développe, il ne suffit que d'un facteur déclencheur.
Je respecte tout à fait les autres programmeurs qui emploient une autre méthode, ils sont très méritants, il faut programmer avec la manière qui nous correspond le mieux, ce qui est important c'est de parvenir au résultat.
Le dicton du jour : Heureux est celui qui programme ce qu'il veut.
Bonne continuation à tous. Et que l'alignement des octets de vos programmes vous soit favorable.
Salut à tous,
Je rajoute un petit complément d'information à propos du livre des 10 % en question.
Citation du livre : Programmation du 6502 de Rodnay Zaks aux éditions SYBEX (dépôt légal initial : 3ème trimestre 1981)
Le tracé de l'ordinogramme est une étape hautement conseillée entre la spécification de l'algorithme et le codage proprement dit de la solution. Il est remarquable que l'on ait observé que peut-être seulement 10 % de la population des programmeurs sont capables d'écrire un programme correct sans passer par l'ordinogramme. Malheureusement, on a observé aussi que 90 % de la population croient faire partie des 10 % qui n'ont pas besoin d'ordinogramme.
Il en résulte qu’en moyenne, 80 % des programmes ne fonctionneront pas à leur premier passage en machine. (Ces nombres n'ont bien sûr pas la prétention d'être très précis). En bref, la plupart des programmeurs novices voient rarement la nécessité de tracer un ordinogramme. Ceci entraîne habituellement des programmes "boiteux", ou erronés. Ils doivent alors passer un temps considérable à tester et à corriger leur programme (cela s'appelle la phase de mise au point). Il est donc fortement recommandé d'avoir la discipline de tracer l'ordinogramme dans tous les cas. Cela demandera un petit supplément de temps avant le codage, mais il en résultera habituellement un programme clair qui s'exécutera vite correctement. Lorsque les ordinogrammes sont bien compris, un faible pourcentage des programmeurs sont capables de franchir cette étape mentalement sans avoir à faire de tracé sur papier. Malheureusement, dans ce cas, les programmes qu'ils écriront seront difficiles à comprendre pour quelqu'un d'autre privé de documentation que constitue l'ordinogramme. Il est donc universellement recommandé d'avoir la stricte discipline de tracer l'ordinogramme pour tout programme important.
L'auteur a enseigné la programmation et les microprocesseurs à plus de 3.000 personnes dans le monde entier. Il est ingénieur de l'École Centrale et docteur de l'université de Berkeley où il a développé un interpréteur APL microprogrammé, ...
Bonne continuation.
Salut à tous,22/02/2004, 20h46 #81
■ Programme bien pensé, fonctionnement assuré. Programme mal pensé est à recommencer.
Merci à tous et merci M. Cedric Girard de nous faire part de l'eXtreme Programming, suite à la lecture du site, cela correspond exactement à ce qu'est la programmation que j'ai nommé spontanée.
Il y a longtemps sans avoir de nom, j'avais déjà eu des échos sur des concours de programmation (tournois au USA) se passant sur plusieurs jours, comme ceux qui pratiquent les jeux en réseaux, ils étaient capables de réaliser des programmes sur mesures en un minimum de temps, ils en faisaient donc partie.
Il serait même possible de la qualifier de programmation temps réel, du fait qu'elle ne se base que sur le résultat obtenu, et que l'algorithme du programme est conçu et optimisé, à chaque fois pour le mieux au moment de sa saisie et de son étude simultanées.
C'est avant tout une question de méthode qui se base sur l'expérimentation, plus on programme, plus ça devient facile. Pour les algorithmes, il y a toujours plusieurs solutions, seule l'expérience nous fera choisir la plus adaptées pour le futur du programme. J'ai remarqué qu'au fil du temps on s'attache plus au coté technique, si l'on regarde bien dans un programme, il y a beaucoup de morceaux d'algorithme qui sont du déjà vu.
Cela se base aussi sur l'anticipation, si l'on peut augmenter les possibilités d'un sous programme ou d'une fonction, on réalise la modification de cette façon immédiatement, il n'est plus utile de revenir dessus par la suite.
(C'est sûr pour les entreprises qui vivent des mises à jour, ils se doivent de calmer leur ardeur. Ou bien leur laisser réaliser la version entière et débrider des morceaux au fil des numéros.)
Pour moi, la programmation remplace un jeu de stratégie ou de logique. Ce type de programmation arrive à me faire penser au mastermind, où à chaque départ de jeux on commence à découvrir à chaque fois au moins 4 couleurs bien placées sur les 5 (structure), dont il ne reste plus à découvrir la 5ème (paramétrage).
On ne se base que sur le résultat obtenu, c'est la recherche du principe logique à découvrir, on s'adapte sans cesse au fonctionnement du langage de programmation et de l'ordinateur, ainsi qu'à leurs caprices.
Finalement, on passe très peu de temps sur le débogage, qui s'avère sans difficulté apparente, et que je considère plutôt comme du paramétrage inévitable.
Il arrive que des parties de programme fonctionnent parfaitement du premier coup, ce qui arrive à me surprendre, car je ne m'attends jamais à ce que cela fonctionne du premier coup, mais ce n'est pas une raison pour ne pas pousser les tests, ou bien tester une autre méthode, si l'on en voit une autre ensuite.
C'est un type de programmation difficile à expliquer aux autres, même aux programmeurs expérimentés, on a une idée en tête qui va se réactualiser à chaque étape, on la suit. Si cette idée était fausse, ça ne marcherait pas. Sinon il y aurait plus de chance de gagner au loto, que de réussir le moindre programme.
Programme bien pensé, fonctionnement assuré. Programme mal pensé est à recommencer.
Avec l'expérience, on arrive à déboguer par intuition, on parcourt le programme sans toujours savoir précisément ce que l'on recherche, dès que l'on est dessus on sait que c'est là, on réalise quelques tests de confirmation, une modification, le bogue est décelé et résolu.
On isole mentalement chaque étapes du programme comme ceux qui élaborent l'algorithme sur papier, et on les réalise, il n'y a pas de sorcellerie, le programme ne se fait pas tout seul.
Programmer sur papier ou non, ça n'empêchera pas qu'il faudra quand même passer devant l'ordinateur, de plus un algorithme conçu sur papier ne tient pas compte de tout, il y aura des modifications à la suite du programme.
L'eXtreme Programming est une méthode sûre, qui pour moi a déjà fait ses preuves et pas seulement en informatique. (Ça doit être possible dans tous les métiers, l'informatique n'en est qu'un parmi tant d'autres).
S'il fallait procéder autrement, je considérerais cet acte comme une régression accompagnée d'une perte de temps. Pourquoi changer une méthode sûre qui marche à chaque fois ?
Pour modifier un programme, on ne cherche pas à comprendre son fonctionnement, on part uniquement à la recherche de la partie que l'on souhaite modifier ou en rapport avec. Si l'on part du principe que le programme sur lequel on est fonctionne sans problème, il ne suffit que de lui apporter une modification au bon endroit, nul besoin de se préoccuper du reste. C'est sûr que si l'on reprend des programmes d'autres personnes bogués à mort (algorithme mal pensé, illogique, ...), ce sera plus simple de tout recommencer à sa manière, que de corriger ou de masquer les erreurs de conceptions.
Si je devais dessiner un algorithme, il me serait plus facile de réaliser le programme et de faire l'algorithme ensuite. Bien qu'il y ait des programmes où je n'aurais pas envie de réaliser l'algorithme de par le temps que ça va prendre.
Depuis que je programme, sur 8 ans je n'ai recommencé que 3 morceaux de programmes différents, non pas parce qu'ils ne marchaient pas, mais que j'avais découvert une méthode différente, plus technique à la suite de leur réalisation.
Chaque personne ne fonctionne pas pareil, sinon tout le monde aurait les mêmes notes à l'école.
Finalement, la programmation ce serait plus une question de logique que d'autres choses. De mauvaises notes à l'école ne feront pas forcément de mauvais programmeurs, ce n'est pas un argument à resservir pour en avoir non plus.
- Est-ce que tout le monde peut faire de l'eXtreme Programming ?
- Quelles sont les qualités requises pour y parvenir ?
- Quel peut être le pourcentage des informaticiens qui la pratique ou qui en sont tout simplement capables ?
- Quels sont les points communs de ceux qui pratiquent l'eXtreme Programming ?
Merci de nous faire partager vos expériences.
Merci M. Cedric Girard d'avoir apporté une précision sur la différence de la programmation spontanée et de l'eXtreme Programming. Mais pour moi, la différence est très mince, mis à part les tests automatiques, j'ai reconnu beaucoup de propos qui m'ont laissé présumer que l'eXtreme Programming était le terme Anglophone de programmation spontanée. L'objectif commun de tous les programmeurs est d'achever leurs programmes dans les meilleures conditions.
Les programmeurs XP ne débordent pas du cahier des charges, on peut le comprendre c'est essentiellement du sur mesure. Ils recherchent la simplicité, les PS aussi comme tout le monde, c'est plus rapide à faire et le débogage est réduit.
En PS des tests pour déceler des bogues sont effectués couramment pour s'adapter au résultat, c'est ce qui déterminera la direction à prendre. Des programmes de tests peuvent être réalisés, mais uniquement sur des points plus délicats (synchronisation fichiers, ...), c'est selon chacun.
À chaque fois qu'un XP effectue une fonction ou un sous-programme, donc il crée un autre sous-programme spécifique pour les tester ou bien en utilise un déjà existant. Vous avez aussi des programmes pour tester le code source en vue de l'optimiser et de trouver tout erreur de saisie, ...
Il faut reconnaître que c'est une programmation très axée sur les bogues.
Je l'ai déjà employé à mes débuts, c'est du débogage rapide et ça marche sans problèmes, mais c'est la première fois que je le vois expliqué.
La programmation en binôme est intéressante.
L'eXtreme Programming est une innovation dans le monde du travail et dans l'ensemble un bon concept.
Comme dans tous les métiers, plus ont pratique plus on y arrive facilement, mais si l'on se souvient de ses débuts en programmation, on se souvient de notre première rencontre insurmontable avec les bogues. Un programmeur qui débogue vite est un programmeur qui passe au plus vite à la suite. Avec du recul, on peut s'apercevoir que les bogues sont du déjà vu, et à force d'en traiter, on arrive à deviner leurs origines. L'expérience sert à effectuer le meilleur choix selon les circonstances. Alors que lorsque qu'on débute si l'on en voit un, c'est déjà bien.
Il serait intéressant de connaître les méthodes de tous les autres programmeurs, en expliquant à leur tour leurs méthodes de débogages... On a tous à apprendre les uns des autres, à condition de savoir comment chacun fait.
Merci de faire part de vos techniques.
■ Conclusion
En six messages, Doloop analyse parfaitement sa démarche de développement qu’il nomme Programmation spontanée. Son analyse décrypte aussi bien l’aspect informatique de sa démarche que l’aspect psychologique de sa personnalité, ces deux aspects ayant en commun la maitrise de soi.
Lorsqu’il dit : « J'ai remarqué que conduire une voiture pour moi, nécessitait plus d'effort d'attention cérébral, que de passer une journée entière à programmer et à débugger », je comprends tout-à-fait son ressenti. Son effort d’attention n’a en fait qu’un seul but, celui de toujours maitriser la situation, ce qu’il fait quand il développe. Et maitriser la conduite automobile pose le problème insoluble d’une situation jamais stable qui oblige mentalement à s’adapter en permanence à un contexte incontrôlable.
Pour ma part, par exemple, j’entrouvre légèrement ma vitre afin de ne pas m’isoler de la réalité, afin de garder le contact avec l’extérieur. Lorsqu’il pleut, je tarde à mettre mes essuie-glaces car je ne regarde pas à travers le pare-brise mais je fixe avec intensité mon attention et mon regard à l’extérieur du pare-brise. À tout moment, je sais ce qui se passe tout autour de moi, ma vision est panoramique. Je vois tout, la personne qui conduit dans la voiture qui me dépasse, le gendarme avec ses jumelles-radar positionné loin de l’autoroute dans un champ, etc. J’anticipe tous les événements. Sur de longues distances, j’aime rejoindre un automobiliste qui roule dans les règles à peu près à ma vitesse. Je me cale à distance derrière lui, nous nous comprenons lors de nos dépassements, je sécurise ses arrières pour lui faciliter le dépassement. Ça me repose mentalement d’avoir un compagnon de route et je suis déçu lorsque nos itinéraires se séparent.
De manière générale, mon comportement dans la vie courante est toujours maitrisé. Le rapport au jeu est un autre témoignage de ce besoin de tout maitriser. Je ne joue pas, à rien.
Concernant son texte, je doute que Doloop l’ait travaillé sous Word avant de le poster, ainsi que je le fais. J’ai corrigé une vingtaine de fautes peut-être mais compte tenu du volume et de sa saisie vraisemblablement spontanée, je ne peux les lui reprocher. Ses phrases sont bien construites, avec du vocabulaire et peu de fautes finalement. On ne peut pas en dire autant de la plupart de ses détracteurs.
Je regrette juste qu’il n’ait pas titré ses messages. En l’absence de titre, la fonctionnalité « Trouver tous les messages » dans le profil du membre, reprend les 50 premiers caractères du message, ce qui n’est pas vraiment significatif du message lui-même, d’autant que la fonctionnalité n’affiche que les 200 premiers caractères du message. Ne pas titrer ses messages est un manque d’empathie à l’égard des autres. Dans ce billet, je me suis donc substitué à Doloop pour titrer ses messages.
Sauf erreur, le dernier message de Doloop date du 23/02/2004, soit moins de deux mois après avoir posté sa question et sa dernière activité, date du 26/06/2004. Depuis, silence radio ! Bien qu'orphelin le sujet vit toujours.
Autre question postée par Doloop le 23 février 2004, moins de deux heures après sa dernière intervention concernant sa première question :
Quelles sont vos méthodes de programmation et de débogage ?
Cette question, bien que toujours "vivante" n'a pas rencontré le succès de la première.
Consulter le profil
Marquer ce blog comme lu
