Comment maintenez-vous votre concentration lorsqu'un aspect particulier de la programmation prend plus de 10 secondes?
J'ai du mal à me concentrer sur ce que je fais (au niveau de la programmation) quand quelque chose (compilation, temps de démarrage, etc.) prend plus que quelques secondes. Pour l'anecdote, il semble que le seuil soit d'environ 10 secondes (et je me souviens avoir lu une étude qui disait la même chose, bien que je ne puisse pas la trouver maintenant). Donc, ce qui se passe généralement, c'est que j'apporte une modification, puis j'exécute le programme pour le tester. Cela prend environ 30 secondes, alors je commence à lire autre chose, et avant que je ne le sache, 20 minutes se sont écoulées, puis il faut (si j'ai de la chance!) 10 minutes supplémentaires pour gérer le changement de contexte pour revenir à la programmation .
Ce n'est pas une exagération de dire que certaines choses qui devraient me prendre des minutes prennent littéralement des heures.
Je suis très curieux de savoir ce que font les autres programmeurs pour combattre cette tendance (ou si je suis unique et qu'ils n'ont pas cette tendance?). Les suggestions de tout type sont les bienvenues - n'importe quoi de "s'asseoir sur vos mains après avoir appuyé sur le bouton de compilation", des astuces mentales, à "s'il faut 30 secondes pour démarrer quelque chose pour tester un changement, alors quelque chose ne va pas avec votre processus de développement ! "
J'ai écrit un petit utilitaire de ligne de commande appelé 'alert' qui fera bip/jouer un son/etc. de l'ordinateur Ensuite, quand j'ai une longue commande à exécuter comme un make, je lance make; alert. Là où je peux, je lui demanderai également de prendre un argument afin de produire un son différent selon l'argument. Ainsi je peux faire make; alert $? et je saurai a) que la construction est terminée et b) qu'elle a réussi ou échoué. Vous n'avez pas besoin d'être aussi fantaisiste avec ça; juste un echo -e "\a" peut suffire.
Si vous vouliez devenir vraiment fantaisiste/ennuyeux, utilisez un package de synthèse vocale et déclenchez une boîte de dialogue.
L'idée principale ici est d'interrompre votre distraction dès que la tâche liée au travail est terminée.
J'ai le même problème, et la solution pour moi a été de passer du temps à faire quelque chose qui ne vous fera pas aspirer. Pour moi, c'est généralement (1) remplir une bouteille d'eau, ou (2) se lever et faire une promenade de 30 secondes dans le bureau pour me dégourdir les jambes, qui ont quand même besoin du mouvement. Vous pouvez vous perdre en naviguant sur Internet; vous vous perdez rarement en vous promenant dans votre propre cabine.
Faites quelque chose pour votre santé:
Levez-vous, éloignez-vous de votre ordinateur et faites des exercices d'étirement des mains et des bras. Cela prendra 2 à 5 minutes maximum. Votre futur moi ne souffrant pas de RSI vous en remerciera.
En outre, en ce qui concerne la pause de 2 à 5 minutes, lisez la technique de Pomodoro . Ceci est basé sur l'idée de faire de courtes pauses fréquentes pour vous distraire de votre tâche actuelle et laisser les choses s'enfoncer un peu. C'est une pause assez courte pour ne pas perdre complètement le fil de vos pensées, mais assez longue pour donner une pause à votre cerveau.
Le développement est un processus créatif. Vous ne pouvez pas être constamment productif, surtout s'il y a beaucoup de distractions dans votre bureau. C'est pourquoi le Joel Test suggère des conditions de travail calmes.
Joel Spolsky aussi explique ce que signifie "ne pas être dans la zone" . Chaque fois que quelque chose vous empêche de faire votre travail, vous devez passer dix minutes, souvent plus pour revenir dans la zone et redevenir productif.
Il y a beaucoup de distractions:
- Un coup de fil de ta femme,
- Un coup de téléphone à l'homme d'affaires dans le bureau proche du vôtre,
- Un collègue vous demande de l'aide,
- Avoir faim,
- Ayant des problèmes personnels,
- Devoir travailler sur du code hérité écrit par un développeur inexpérimenté il y a dix ans et jamais refactorisé,
- Avoir un PC lent ou une connexion Internet lente,
- Ayant un long processus de compilation,
- etc.
Il n'y a rien à voir avec ça. La seule chose que vous pouvez faire est d'éliminer les distractions elles-mêmes:
- Pas de téléphone dans votre bureau,
- Des conditions de travail tranquilles,
- Accès rapide à l'ordinateur et à Internet,
- Processus de compilation rapide,
- etc.
Dans votre cas, si c'est le compilateur qui vous distrait, essayez de réduire le temps de compilation en:
- Réduire la taille de votre programme (certains IDE par exemple vous permettent de décharger certains projets d'une solution, réduisant ainsi fortement le temps de compilation),
- Utiliser les builds nocturnes et compiler moins pendant votre travail,
- Acheter une machine plus rapide (s'il n'y a rien d'autre à faire),
- etc.
Je suppose que je serai le seul à le dire, mais vous devriez simplement vous asseoir là et attendre qu'il se termine.
Vous devez vous recycler pour ne pas ressentir le besoin d'être constamment en train de faire les choses. Il s'agit d'un problème très préjudiciable qui affecte non seulement les développeurs mais toutes les personnes. La société est devenue obsédée par la nécessité d'une stimulation constante (visuelle, audio, mentale). Il semble que personne ne puisse rester inactif pendant plus de 30 secondes sans sortir son téléphone et envoyer des SMS, surfer sur le Web, consulter Facebook, etc.
Si vous appuyez sur compiler et que cela prend environ une minute, considérez que c'est une excellente occasion de simplement vous asseoir et de laisser votre cerveau se détendre. Résistez à l'envie de faire quelque chose de stimulant et profitez simplement d'un moment de non-activité.
Avec le temps, cela deviendra plus facile et vous constaterez que vous aurez une bien meilleure expérience de travail lorsque vous cesserez d'essayer de garder votre cerveau à 100% toute la journée.
Je suis d'accord avec ce que @retracile suggère, mais notez que selon les règles de programmation Zen vous ne devriez vous concentrer que sur une seule tâche à la fois. Répondre aux appels téléphoniques, naviguer sur le Web, les réseaux sociaux ou même effectuer des tâches multiples réduira très probablement votre productivité. Utilisez le court délai d'attente pour réfléchir à la tâche/solution existante et à ce que vous pouvez faire pour l'améliorer.
J'ai un bar attaché au montant de la porte
Je ne peux faire que 5 tractions donc cela prend moins d'une minute. Ou je fais une tasse de thé.
Pour moi, la façon de rester concentré est d'être impitoyable sur le maintien d'un espace de travail propre, quel que soit cet espace de travail. Tout ce qui ne fait pas partie de mon projet actuel est du bruit dans le rapport signal/bruit sanctifié. Une partie essentielle du maintien de la concentration consiste à maintenir un rapport signal/bruit élevé.
Lorsque je code, cela signifie fermer des programmes que je n'ai pas utilisés récemment, élaguer régulièrement les onglets de mon navigateur et garder mon bureau à l'écart des éléments qui ne sont pas immédiatement pertinents pour mes projets en cours. J'utilise les dix secondes de retard pour "faire le tour", pour ainsi dire - fermer les onglets, fermer les programmes, supprimer les fichiers temporaires et archiver ce qui doit être archivé, etc.
Prendre l'habitude de "faire le tour" aide également à prévenir les traînées de lapin, car cela m'oblige à évaluer en permanence - et à me souvenir - toutes les tâches en cours.
Il y a un petit prix à payer lorsque vous devez rouvrir un onglet que vous avez déjà ouvert 5 fois aujourd'hui ou relancer une invite de commande avec des privilèges élevés pour la 15e fois, mais tirer parti des accélérateurs comme les raccourcis clavier peut réduire cela à un très petit prix en effet.
Je trouve que cela aide à suivre le temps réel que je passe sans travailler
Vous pouvez utiliser un certain nombre de choses pour cela. Je sais qu'il existe de nombreuses applications gratuites que vous pouvez télécharger pour le faire pour vous (je ne peux pas en penser à une en ce moment, mais si quelqu'un m'en donne, je les ajouterai à cette réponse), ou il est très facile de créer le vôtre. J'utilise généralement celle que j'ai créée, qui est une petite fenêtre dans le coin de mon écran avec des boutons pour Working/NotWorking, et je clique simplement sur celle sur laquelle je me trouve chaque fois que je change de focus.
Une horloge d'échecs fonctionne également
Le fait même de suivre votre temps vous rend plus conscient du temps que vous perdez que vous devriez passer à travailler, et je trouve que cela me rend plus productif parce que je vais me forcer à quitter cette question super intéressante de stackoverflow, ou blog article, et se remettre au travail
Pour garder mon attention, j'utilise des gribouillis. J'ai toujours un stylo et un bloc-notes derrière mon clavier et je griffonne. Ce n'est pas plus que de griffonner sur un morceau de papier sans aucun sens, mais cela garde mon attention juste assez et ne me distrait pas pour que je puisse revenir à ce sur quoi je travaillais.
J'ai fait ça toute ma vie inconsciemment mais j'ai récemment trouvé un wiki à ce sujet: http://en.wikipedia.org/wiki/Doodle
Quoi que vous fassiez n'allez pas sur l'un des sites StackExchange. Ils vont vous aspirer :)
Plus sérieusement, naviguer sur le Web en attendant que quelque chose se termine n'est pas bon pour la productivité (sauf si vous recherchez quelque chose en rapport avec la tâche en cours).
Je fais généralement quelques tâches mineures qui ne prendront pas plus de 1 à 2 minutes. (nettoyer quelque chose, écrire des commentaires, des notes).
Pendant ces 10-30 secondes, allez faire quelque chose:
- qui ne nécessite pas beaucoup d'activité mentale
- ouvrez le code que vous compilez et vérifiez-le à nouveau (vous pourriez trouver quelque chose de mal ou un moyen de l'améliorer)
Pendant ce temps, ne faites pas des choses dont vous savez que cela vous prendra du temps (à moins que vous ne puissiez vous permettre de passer du temps) comme:
- commencer à lire un livre
- lire des e-mails si vous savez que cela peut vous prendre longtemps
- etc
De plus, n'installez pas d'alarme sonore pour signaler la fin de la compilation. Vos collègues l'apprécieront.
Dans votre cas, levez-vous et promenez-vous un peu. S'il est difficile de revenir dans "la zone", c'est probablement parce que vous êtes trop loin. Faire des trucs sur le Web n'est qu'une autre zone et il est facile de perdre le temps. Donnez à votre cerveau la pause qu'il veut clairement et allez vous promener, prenez un assistant, idéalement dans les toilettes, ou parlez à un collègue au hasard. Nous faisons beaucoup de choses en coulisses sur le pilote automatique. Les pauses ne sont pas mauvaises pour le codage, elles sont bonnes, mais l'idée est d'arrêter de tirer sur tous les cylindres pendant un certain temps et de voir ce que vos brûleurs de dos produisent tandis que la partie la plus consciente de votre esprit se repose. Les bons développeurs ne sont pas des calculateurs humains. Laissez les parties de votre cerveau qui font tout ce qui est intuitif et assorti de motifs sur le pilote automatique faire leur travail pendant un certain temps.
Si ce n'est pas seulement un problème de codage, vous voudrez peut-être envisager ADD.
Les suggestions pour se lever et se promener, etc. sont bonnes si vos cycles sont longs (environ une heure). Mais lorsque les temps de cycle sont courts et que je me retrouve à faire des allers-retours entre vim et make toutes les quelques minutes, je reste dans la zone en restant dans le pipeline: pendant que la suite de build ou de test est en cours d'exécution, j'ai tendance à revenir en arrière et examinez le code, puis commencez à travailler sur le morceau suivant que je ferais de toute façon si la construction ou les tests réussissaient.
Faites un plan au début de chaque journée sur la façon d'utiliser ce "temps libre". Cela pourrait impliquer
- rattraper son retard sur certaines tâches de documentation,
- élaborer des cas de tests unitaires pour la classe que vous allez écrire ensuite,
- étudier une nouvelle technologie que vous vouliez apprendre,
- écrire une lettre à votre tante préférée,
ou à peu près tout.
Ayez toujours cette tâche secondaire ouverte dans une fenêtre quelque part sur votre bureau. Dès que vous appuyez sur le bouton "compiler" (ou tout ce qui vous prend plus de 30 secondes), passez à la tâche secondaire et accordez suffisamment de temps pour avancer, ce qui pourrait prendre quelques minutes, ou pourrait être moins.
Pendant que vous effectuez la tâche secondaire, gardez à l'esprit que ce n'est pas ce sur quoi votre cerveau devrait se concentrer. Continuez à penser à la programmation. Ce n'est pas facile; vous souffrirez toujours du changement de contexte le plus souvent.
Si vous faites cela, même si vous perdez du contexte plusieurs fois, votre temps perdu n'est pas réellement du temps perdu, et vous avez quelque chose à montrer à la fin de la journée. Mais le plus important est de planifier, au début de la journée, quelle sera la tâche secondaire de la journée.
Je suppose que nous pouvons utiliser le temps de compilation pour documenter le code, nettoyer le code, aligner le code correctement, afin de ne pas nous éloigner de notre IDE et d'améliorer encore la qualité du code.
J'essaie généralement de chercher des bogues, des fautes de frappe ou des moyens d'améliorer le style du code en attendant. Cela me fait regarder le code, mais je ne suis pas (toujours) distrait par quelque chose d'intéressant. Aussi, ceci !
Il est concevable que vous ayez un peu de TDAH. Beaucoup de gens le font. Les mécanismes d'adaptation sont ceux indiqués dans les autres réponses (ou éventuellement les médicaments).
Pour la distraction sur Internet pendant le travail en général, je suggère Le plugin Pomodoro si vous utilisez Google Chrome
Personnellement, je pense que vous ne pouvez pas être productif pendant tout votre temps de travail! puisque vous compilez, cela signifie que vous avez fait suffisamment d'efforts pour reprendre votre souffle ... pour ne pas abuser ou sortir du contexte, continuez à penser à l'étape suivante si la compilation ne génère pas d'erreurs ... Ou nettoyez votre travail zone: Bureau, Tabs, Explorer ...
Ce que vous décrivez est parfaitement normal.
Lorsque nous faisions des études d'utilisabilité, nous examinions les retards par ordre de grandeur. Lorsqu'un utilisateur clique sur un bouton, combien de temps doivent-ils attendre?
- 0,1 sec: pas de retard perçu
- 1 sec: pas de changement de focus
- 10 sec: attention perdue
- 1 min: l'utilisateur passe à une autre tâche
- 10 min: l'utilisateur se lèvera et partira
Il existe de nombreuses exceptions, telles que les opérations composées, comme la saisie.
Lorsque nous effectuions un travail de performance, nous avons souvent posé la question "à quelle vitesse l'opération X devrait-elle être?" La réponse est que tant que l'utilisateur peut percevoir un retard, plus vite serait mieux.
Dans votre cas, vous atteignez ce seuil de 10 secondes et votre attention s'éloigne. La meilleure chose que vous puissiez faire est de réduire le délai. Plus le délai est court, meilleure est votre productivité. Imaginez que vous aviez le code sur le côté gauche de votre écran et l'application en cours d'exécution sur la droite. Lorsque vous modifiez le code, l'application change en temps réel. Tant que vous n'y êtes pas, vous pouvez vous améliorer.
Voir aussi le récent article de blog de Jeff (les tonnes de bon contenu qu'il mène): http://www.codinghorror.com/blog/2012/03/visualizing-code-to-fail-faster.html =
Si vous allez passer à autre chose, choisissez quelque chose qui n'engage pas votre cerveau de la même manière que le travail que vous faisiez. Nettoyez votre bureau, méditez, étirez-vous, pompes, art, regardez par la fenêtre.
Lorsque je fais un travail ad hoc dans SAS, je trouve la ligne suivante très utile:
dm log 'postmessage "Code finished"' continue;
Cela produit une boîte de dialogue contextuelle une fois que tout le code précédent a terminé son exécution. Je suis sûr qu'il existe des équivalents dans d'autres langues. J'aurais posté cela comme un commentaire à la réponse de retracile mais je n'ai pas assez de réputation.