La programmation informatique est "flow-friendly"

Je réfléchissais à pourquoi programmer est si flowy pour moi, plus que l’écriture de textes, et c’est lié à la boucle input output qui est tellement serrée. Dès que tu fais un changement, tu as directement l’effet de ce changement quand tu lances le programme, tu vois ce qui va/ce qui ne va pas/ce qu’il reste à faire. Pareil si tu as une erreur, ça te le dit directement, ça te met l’endroit et tout donc tu sais précisément où tu dois aller. Ça te « feed » la prochain étape d’action. Ce « serrage » du retour sur l’input, ça coupe tous les temps morts et permet de l’aérodynamisme de malade.
Je sais pas si je pourrais trouver un moyen de simuler ça dans d’autres activités, notamment l’écriture.
Actuellement l’écriture mon flow repose essentiellement sur le momentum.

Je suis obligé de relire tout le texte pour voir quoi ajuster
C’est pratiquement l’équivalent de regarder directement dans le code quoi faire, ce que je ne fais jamais.

Je réfléchissais à pourquoi programmer est si flowy pour moi, plus que l’écriture de textes, et c’est lié à la boucle input output qui est tellement serrée. Dès que tu fais un changement, tu as directement l’effet de ce changement quand tu lances le programme, tu vois ce qui va/ce qui ne va pas/ce qu’il reste à faire. Pareil si tu as une erreur, ça te le dit directement, ça te met l’endroit et tout donc tu sais précisément où tu dois aller. Ça te « feed » la prochain étape d’action. Ce « serrage » du retour sur l’input, ça coupe tous les temps morts et permet de l’aérodynamisme de malade.

@Bertrand Mais en soit l’écriture (et toute ces choses qui ont un output subjectif) l’output c’est la qualité subjective de ce que tu écris non (et puis une correspondance avec le sujet sur lequel tu écris, aussi large soit-il) ? Est-ce que dans ce cas l’implémentation ce n’est pas « juste » de rester conscient du chemin parcouru localement ? Finalement ça peut revenir à 1) juger très régulièrement d’une progression plutôt que uniquement considérer la progression macro (ce qu’on a tendance à faire il me semble sur ce genre d’activité) et 2) structurer sa progression dans le sens où on sait plus ou moins où on va, et même si c’est une étape d’une sous étape d’une sous étape, le fait d’être conscient de la place de ce qu’on vient de produire localement a tendance à motiver. (Évidemment 1) et 2) sont indissociables, c’est deux faces d’une même pièce)
Par exemple lorsque j’écris une dissert si j’écris sans savoir où je vais globalement ça peut être déprimant car je ne sais pas si j’avance. Si par contre je pose à l’avance les parties, les sous parties etc. Alors je sais que je progresse même quand j’écris la seconde phrase du premier paragraphe d’une sous partie d’une partie… Et cette décomposition progressive me permet de me dire que je suis à disons 25% de mon objectif local plutôt que 0,2% de mon objectif global.
Dans le cas de la dissert (en situation de DS) c’est peut-être trompeur parce que c’est contraint par le temps et que je choisis rapidement une structure là où dans la réflexion, la contemplation on est beaucoup plus ouvert, et finalement on laisse une structure se dessiner. Néanmoins je pense qu’il y a moyen d’appliquer ces principes tout de même, de façon plus organique sûrement :upside_down_face:

Mais en soit l’écriture (et toute ces choses qui ont un output subjectif) l’output c’est la qualité subjective de ce que tu écris non (et puis une correspondance avec le sujet sur lequel tu écris, aussi large soit-il) ? Est-ce que dans ce cas l’implémentation ce n’est pas « juste » de rester conscient du chemin parcouru localement ? Finalement ça peut revenir à 1) juger très régulièrement d’une progression plutôt que uniquement considérer la progression macro (ce qu’on a tendance à faire il me semble sur ce genre d’activité) et 2) structurer sa progression dans le sens où on sait plus ou moins où on va, et même si c’est une étape d’une sous étape d’une sous étape, le fait d’être conscient de la place de ce qu’on vient de produire localement a tendance à motiver. (Évidemment 1) et 2) sont indissociables, c’est deux faces d’une même pièce)
Par exemple lorsque j’écris une dissert si j’écris sans savoir où je vais globalement ça peut être déprimant car je ne sais pas si j’avance. Si par contre je pose à l’avance les parties, les sous parties etc. Alors je sais que je progresse même quand j’écris la seconde phrase du premier paragraphe d’une sous partie d’une partie… Et cette décomposition progressive me permet de me dire que je suis à disons 25% de mon objectif local plutôt que 0,2% de mon objectif global.
Dans le cas de la dissert (en situation de DS) c’est peut-être trompeur parce que c’est contraint par le temps et que je choisis rapidement une structure là où dans la réflexion, la contemplation on est beaucoup plus ouvert, et finalement on laisse une structure se dessiner. Néanmoins je pense qu’il y a moyen d’appliquer ces principes tout de même, de façon plus organique sûrement :upside_down_face:

@DocDoc Ouais mais du coup c’est beaucoup plus délibéré d’avoir l’output et moins « dans ta gueule » (moins compressé). La programmation ça te micro-feed pleins de trucs à faire, et de proche en proche tu construis quelque chose de gros. Tu peux oublier le chemin parcouru et ne pas en rester conscient, contrairement à l’écriture.

Ouais la structuration aide clairement, et permet en fait de simuler cette compression du programme qui se lance et qui te révèle où il en est. Le « plan » d’un texte étant en gros une version compressée, plus facilement appréhendable et manipulable par l’esprit. Mais avec la programmation tu n’as pas besoin de créer toute la structure en mode top-down. Tu peux la faire en mode bottom-up. Et c’est ça que j’adore quand je programme. C’est genre du ping-pong infini. Avec l’écriture ça m’arrive de fonctionner comme ça, mais c’est rare. Et souvent quand je casse le momentum, la probabilité de repartir diminue grandement. Alors qu’avec la prog je peux repartir de n’importe où. L’infrastructure du code te soutient (tu lui délègues plein de fonctions), alors qu’avec l’écriture tu dois te soutenir tout seul. Rien que d’enlever le debugger qui t’indique où arrivent les erreurs d’exécution ça rend les choses bien plus analytiques.
Après c’est peut-être aussi du au fait qu’un texte se doit d’être pleinement cohérent, contrairement à un assemblage de code.

Ouais mais du coup c’est beaucoup plus délibéré d’avoir l’output et moins « dans ta gueule » (moins compressé). La programmation ça te micro-feed pleins de trucs à faire, et de proche en proche tu construis quelque chose de gros. Tu peux oublier le chemin parcouru et ne pas en rester conscient, contrairement à l’écriture.

Ouais la structuration aide clairement, et permet en fait de simuler cette compression du programme qui se lance et qui te révèle où il en est. Le « plan » d’un texte étant en gros une version compressée, plus facilement appréhendable et manipulable par l’esprit. Mais avec la programmation tu n’as pas besoin de créer toute la structure en mode top-down. Tu peux la faire en mode bottom-up. Et c’est ça que j’adore quand je programme. C’est genre du ping-pong infini. Avec l’écriture ça m’arrive de fonctionner comme ça, mais c’est rare. Et souvent quand je casse le momentum, la probabilité de repartir diminue grandement. Alors qu’avec la prog je peux repartir de n’importe où. L’infrastructure du code te soutient (tu lui délègues plein de fonctions), alors qu’avec l’écriture tu dois te soutenir tout seul. Rien que d’enlever le debugger qui t’indique où arrivent les erreurs d’exécution ça rend les choses bien plus analytiques.

@Bertrand Je comprends pas très bien ce que tu veux dire par créer la structure bottom up ?

@DocDoc En gros tu t’occupes de coller un légo avec un autre, et par incidence tu développes une structure. C’est ça en gros le bottom-up.

Mais est-ce qu’il ne faut pas déjà avoir fait le trajet top-down mentalement pour avoir des briques correctes ?

Non pas nécessairement, justement souvent ça de dessine grâce à ça. Combien des fois j’ai commencé un programme en mode minimaliste et sans le planifier le truc a fini par évoluer et devenir beaucoup plus complexe haha

Hum je vois, mais dans une certaine mesure l’écriture fonctionne pareil nn ? On écrit au fil de sa pensée et on voit une structure se dessiner (ou pas aha) et on peut pareil faire une sorte de ping pong

Oui ça m’arrive assez souvent (en fait c’est comme ça dans l’idéal) mais comme je disais le soucis c’est que dès que t’arrêtes c’est plus difficile de rebrancher et repartir
alors qu’avec la programmation tu peux davantage être aveugle à l’ensemble et recommencer à travailler de n’importe où

Oui je pense que je vois ce que tu veux dire

En conseil de procrastination on parle souvent de la décomposition d’un but en petit buts
c’est lié à ça
Il m’arrive assez souvent d’être « assommé » par un texte que j’ai commencé à écrire et que je dois continuer
Avec le code ça m’arrive jamais
parce que je peux opérer au niveau local en faisant abstraction du global

Oui tandis que pour pouvoir faire ça sur un texte il faut à minima avoir écrit un plan/des plans. Finalement la façon même de coder implique de créer un plan/une structure
Mais est-ce que du coup il ne « suffit » pas d’organiser son écriture de la même façon ? Par exemple quand j’écris je mets toujours les questions directrices à un endroit, ou alors le titre global du passage. Ce qui fait que quand je reviens je peux regarder globalement toutes les questions/titres et avoir un vision d’ensemble + aller directement à une question/titre précis

Possible ouais, après c’est un effort d’organisation. Mais quelque part c’est ce qu’on fait avec le code (quand on code proprement). Je me souviens quand j’étais dev et que je devais reprendre des vieux programmes (faits par d’autres), les fonctions étaient énormes, rien n’était divisé, et du coup ouais pour reprendre ce code il y avait une grosse phase d’analyse avant de pouvoir comprendre quoi faire. Je pouvais pas sauter dans l’action comme je peux le faire quand un programme est bien codé et que où aller est clair et évident.
Du coup ouais écrire des textes en s’organisant au moment de l’écriture, et non pas tout enchaîner sans structure comme un gros pavé (et se retrouver bien embêté pour reprendre une fois dépotentialisé).