Évitez de devenir un programmeur «théoricien»

J'ai trouvé cet article dans plusieurs articles sur SO. Je me retrouve dans le 6e archétype; le "théoricien".

Il définit le "théoricien" comme:

Le théoricien sait tout ce qu'il y a à savoir sur la programmation. Il ou elle peut passer quatre heures à enseigner l'histoire d'un langage de programmation obscur ou à fournir une preuve de la façon dont le code que vous avez écrit n'est pas parfaitement optimal et peut prendre trois nanosecondes supplémentaires pour s'exécuter. Le problème est que le théoricien ne sait rien du développement logiciel. Lorsque le théoricien écrit du code, il est si «élégant» que les simples mortels ne peuvent pas le comprendre. Sa technique préférée est la récursivité, et chaque bloc de code est modifié au maximum, au détriment de la rapidité et de la lisibilité.

Le théoricien est également facilement distrait. Une tâche simple qui devrait prendre une heure prend trois mois aux théoriciens, car ils décident que les outils existants ne sont pas suffisants et ils doivent construire de nouveaux outils pour construire de nouvelles bibliothèques pour construire un tout nouveau système qui répond à leurs normes élevées. Le théoricien peut devenir l'un de vos meilleurs joueurs, si vous pouvez le faire jouer dans les limites du projet lui-même et arrêter de passer du temps à travailler sur l'algorithme de tri ultime.

Même lorsque je travaille sur ce qui devrait être un projet simple, j'ai tendance à m'enliser en essayant de tout sur-concevoir à partir de zéro (cela explique probablement pourquoi j'ai perdu environ 2 ans à essayer de créer un système d'exploitation à partir de zéro. Mais même moi, je l'ai vu était finalement inutile).

Qu'est-ce qui peut m'aider à éviter de faire cela? Et respectez les principes KISS?

Merci

Étant théoricien par nature, je peux vous dire que travailler dans une boutique Agile guérira rapidement et de manière décisive toutes ces tendances. En particulier, une opération de programmation eXtreme, avec programmation par paires (idéalement en rotation fréquente), développement piloté par les tests, boxe temporelle et sprints bornés, met immédiatement à nu votre travail pour tous vos collègues et vous oblige à vous ouvrir et à collaborer sur minute par minute. Il s'agit d'un changement énorme par rapport aux tâches distinctes dans l'environnement de bureaux isolés dans lequel le travail de style théoricien s'épanouit. Cela requiert une honnêteté et une intégrité totales, car tout le monde dépend activement de tous les autres en permanence.

Je chéris toujours mon nombril, mais je dois le faire à la maison ou dans les rares occasions où je peux travailler sur un projet parallèle qui ne fait pas partie du développement de la ligne principale.

1. Ayez des objectifs pour ce que vous êtes censé développer.

2. Limitez ces objectifs à quelque chose de livrable dans un avenir proche.

3. Concentrez-vous ensuite sur ces objectifs, en éliminant toutes les autres considérations. Pas de fond. Pas d'histoire. Pas d'extensions. Rien de général ni d'abstrait.

4. Ensuite, réduisez-les davantage dans le moins possible, ce qui sera livrable. Pas bon. Pas flexible. Non maintenable. Tout simplement acceptable.

5. Ensuite, donnez la priorité au minimum absolu requis pour obtenir le moins que vous puissiez faire. Le point est de choisir une date dans environ une semaine et de construire vers cette date. Si vous ne pouvez pas livrer quelque chose en une semaine. Étroit. Concentrer. Réduire. Réduire.

6. Éliminez ensuite les peluches. Vous avez seulement une semaine. Continuez à couper.

7. Ensuite, concentrez-vous uniquement sur une mise en œuvre réduite qui sera effectuée le plus tôt possible. Idéalement, moins d'une semaine, vous avez donc le temps d'écrire de la documentation.

J'ai travaillé avec des théoriciens. Je considère les "extras" comme une excuse pour éviter de faire quelque chose qui pourrait être qualifié d'échec.

Faire - et échouer - est difficile. Parler de faire quelque chose est plus facile que de faire quelque chose. Beaucoup de recherches et de réflexions sont un moyen d'éviter de faire la mauvaise chose et de la retravailler après avoir appris que les utilisateurs ont menti.

Mettez simplement le code devant eux. Ils appellent le code un échec. Ça arrive. Mais dans le processus d'échec, vous apprendrez quelles sont les vraies exigences. Et vous apprendrez qu'ils ont menti.

Je ne suis pas sûr que ce soit une si mauvaise chose. De toute évidence, vous devez être productif ou vous ne ferez pas votre travail, mais avoir un intérêt dans le domaine, être un étudiant de l'art, pour ainsi dire n'est pas une mauvaise chose.

Je jouerais à vos forces, chercherais des opportunités où votre style et vos préférences seraient un avantage.

Afin de vous assurer de rester productif tout en vous livrant à l'écriture d'un cadre MVC à Erlang (ou tout ce que vous trouvez intéressant), vous devriez peut-être chronométrer votre travail plus essotérique à, disons, une heure par jour. Pour le reste de la journée, concentrez-vous sur le travail de grognement et faites le travail. Lorsque vous voyez quelque chose d'intéressant qui pourrait vous distraire, vous pouvez le mettre en signet ou prendre une note, mais continuer, puis y revenir dans votre créneau horaire alloué.

Personnellement, j'ai une multitude d'URL qui semblent intéressantes, et une pile de livres de bibliothèque aussi. J'obtiens peut-être 10% de ces URL à la fin, et peut-être que je lis 50% des livres à la fin, mais je fais aussi le travail de jour.

J'ai moi-même eu ce problème. Deux techniques ont aidé:

1. Utilisez la technique de Pomodoro ou une autre technique de gestion du temps où vous définissez une séquence d'objectifs à très court terme. Lorsque vous devez déterminer ce que vous pouvez accomplir au cours des 25 prochaines minutes, cela vous permet de rester concentré sur un travail utile.
2. Développement piloté par les tests. Si vous devez écrire un test concret avant d'écrire un code, cela minimise la rêverie. (Il n'y a aucun moyen d'écrire un test pour "élégant".) Une fois que quelque chose fonctionne, vous pouvez passer plus de temps que vous ne devriez le refactoriser, mais au moins vous travaillerez sur du vrai code plutôt que sur un idéal imaginaire.

Ne vous battez pas trop. Il est plus facile d'amener un théoricien à se concentrer et à faire un travail utile que d'amener les personnes qui s'en moquent à élargir leurs horizons.

Évitez stackoverflow.com . Ne vous méprenez pas - je suis un grand fan - mais SO et d'autres forums orientés programmation font de l'ennemi du bien un parfait ennemi . Après un certain temps, vous pourriez avoir l'impression que des milliers de personnes intelligentes regardent par-dessus votre épaule et que rien de ce que vous écrivez n'est assez bon. Faites simplement fonctionner quelque chose et essayez de le rendre compréhensible. Vous pouvez toujours revoir si elle a besoin d'amélioration.

Évitez également les articles comme celui que vous avez lié. Croyez-vous vraiment qu'il existe dix types de programmeurs? Ou que quelqu'un que vous connaissez rentre entièrement dans exactement l'une des catégories décrites? Des articles comme celui-ci ont un certain attrait car ils contiennent un peu de vérité - vous pouvez vous voir et / ou certains de vos collègues dans certains des stéréotypes. Mais les catégories contiennent autant d'eau que de signes astrologiques. Essayez ceci la prochaine fois que vous êtes au mixeur post-conférence: "Salut, je suis un Code Cowboy! Quel est votre type?"

Cela ne veut pas dire que votre question n'est pas valable - si vous pensez trop, il est bon d'apprendre comment éviter cette tendance. Mais ne laissez pas cette pudeur vous inciter à vous pigeonner.

Il existe une directive simple qui, une fois entièrement déballée, explique en détail comment éviter ce scénario.

Faites la chose la plus simple qui pourrait fonctionner.

- Kent Beck

Je pense qu'une façon de garder la tête hors des nuages ​​est de se forcer à écrire des applications réelles du début à la fin, en plus d'écrire vos API ou frameworks théoriques. Essayez de mettre une boîte de temps autour de quelque chose et essayez de la "terminer" dans ce délai. L'écriture de frameworks nécessite une bonne compréhension des modèles de conception et de l'architecture, mais j'ai trouvé que l'écriture d'une application complète dans un laps de temps fixe requiert des compétences différentes de l'écriture d'un framework super bien conçu.

Si vous souhaitez compléter une demande, vous devez à un moment donné vous mettre sur terre et le faire. Cela peut nécessiter des sacrifices sur les conceptions ou être obligé d'implémenter une fonctionnalité d'une manière qui ne vous satisfait pas, en raison d'un certain type de contrainte. Je suis un peu comme vous - enclin à écrire et réécrire des choses un million de fois, mais si je suis confronté à des tâches qui doivent être effectuées dans un certain laps de temps, je trouve que je choisis mes batailles, et les choses les plus importantes.

Simple:

1. Soyez pragmatique .

Le côté opposé du théoricien (qui a ses avantages du côté information / connaissance du domaine de programmation) est le pragmatique.

Appliquer KISS, DRY, SOC et d'autres modes de pensée, comme décrit dans cette réponse , signifie être pragmatique.

Vous pouvez également apprendre à être pragmatique en lisant ce livre:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

N'oubliez pas que la théorie et la pratique fonctionnent ensemble, pas seules. Sans beaucoup de pratique, votre connaissance n'est rien. Sans beaucoup de connaissances, vous ne pouvez pas améliorer rapidement votre pratique.

Alors, pratiquez beaucoup. Et apprenez beaucoup. Mais ne laissez pas l'un l'emporter sur l'autre.

Dans vos projets, fixez une date limite. Tenez-vous-y. Réfléchissez ensuite de manière pragmatique à la manière de terminer votre projet avant cette date limite. (lire le livre, vraiment) Ensuite, commencez à coder, commencez à lire ce que vous devrez savoir, passez de la lecture au codage et limitez votre temps de lecture.

Hrm ... Peut-être essayez peut-être d'obtenir un emploi dans une entreprise qui vous oblige à écrire des candidatures dans un délai. Je dirais pour moi-même, que je suis probablement aussi loin d'être un théoricien que vous pouvez l'être, du moins au travail. Faire ce type de travail a sa place et son temps et est important pour se développer. Cependant, même si j'apprécie ce genre de capacité, il n'a pas sa place dans le monde des affaires, surtout là où je travaille. Un environnement de développement rapide où vous écrivez des applications en quelques semaines et où le client les veut hier! J'ai eu la chance d'avoir des développeurs incroyables et il a fallu du temps pour que tout le monde travaille en équipe.

J'avais un gars qui était à peu près aussi brillant que possible, mais comme vous, j'ai toujours dû extraire le dernier morceau de son code, même quand cela fonctionnait bien, même au point où il a commencé à écrire des contrôles personnalisés qui étaient essentiellement les mêmes que ceux fournis par l'environnement. C'était très cool mais une telle perte de temps quand nous devions sortir les choses à temps. Souvent, ces projets parallèles ont soutenu l'équipe et finalement, il a commencé à ressentir la pression des autres et il s'est formé. Je suggérerais de commencer à travailler dans un environnement d'équipe avec d'autres bons développeurs qui doivent sortir des produits. Il est toujours temps plus tard de refactoriser et de refaire des choses ou d'écrire le MergeSort le plus excitant jamais créé; mais parfois, vous devez amener le produit à un point où il fonctionne et le faire parvenir au client.

Il n'y a rien de mal à être un «théoricien» au sens habituel du terme. Avoir des connaissances de base et être capable de comprendre les dernières recherches en CS est une grande capacité, car c'est une mine d'or d'idées bonnes et originales.

La «vraie question» ici est plus apparente dans la dernière moitié de l'article. Connaissez l'objectif spécifique du projet et travaillez dans ce but, pas dans un autre. C'est vraiment juste une question d'autodiscipline dans ce cas. Voir la réponse de S. Lott pour en savoir plus à ce sujet :).

Recentrez votre esprit de la programmation et même de l'accomplissement des choses à la livraison de logiciels fonctionnels. Il définit vos priorités.

Comment y parvenir est une autre histoire. La meilleure façon est de concevoir un projet et de passer par toutes les étapes pour le lancer en production. Après cela, vous aurez un état d'esprit différent qu'auparavant.

Merci pour ce post. Cela rend mon travail encore plus intéressant. Je ressens la même chose en ayant une formation en architecture de l'information en tant que développeur de logiciels. Souvent, je me retrouve à me demander «où changer les choses» plutôt que «quoi changer». Il y a trop de relations, trop de choses intelligentes et génériques autour desquelles il faut trop de temps pour savoir comment ça fonctionne.

Je commence donc à poser des questions, et encore plus de questions jusqu'à ce que je sache comment et où cela est vraiment construit. Et laissez-moi vous dire - cela fonctionne. Plus un incendie pose de questions, moins il est important de conserver l'architecture d'origine, et enfin de revenir aux sources

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Demandez à votre patron de trouver un mentor, puis faites comme le dit le mentor.

La partie difficile est de rester concentré et de reconnaître que "hé, réécrivons le système d'exploitation" ne bénéficiera pas de manière substantielle à la fin de la tâche qui vous a été confiée (c'est pourquoi un chef de projet ne le fera pas).

Demandez également au mentor d'examiner TOUTES vos conceptions avant le codage et le code réel après le codage. Cela vous aidera à rester concentré sur ce qui doit être fait.

J'ai la même tentation de trop ingénier les choses, et il faut de l'autodiscipline et de l'organisation pour les dépasser. Lors du codage pour quelqu'un d'autre, voici comment je le fais:

1. Lors du démarrage d'une tâche discrète, passez quelques minutes à réfléchir à ce qui est vraiment nécessaire en termes de fonctionnalité, de qualité, de date de livraison, etc.
2. Prenez plus de temps pour planifier la façon de procéder , en les décomposant en sous-tâches, sous-sous-tâches, etc., en gardant à l'esprit les objectifs du client du code.
3. Estimez le temps pour chaque élément , en ajoutant jusqu'à 50% pour les inconnus. Si un article prend plus de quatre heures, décomposez-le un peu plus. (Si je faisais des projets collégiaux, j'utiliserais une feuille de calcul, mais en tant que consultant avec plusieurs clients, j'utilise un système de suivi des problèmes appelé Redmine.)
4. Plus important encore: ne faites que les éléments que j'ai inventés .

Bien sûr, des choses se produisent. Parfois, je trouve que je dois faire plus de choses - alors je recommence à # 1. Parfois, je trouve qu'une tâche prendra beaucoup plus de temps que je ne le pensais - recommencez à # 1. Parfois, je sais à l'avance que ma conception aura besoin de plus de détails plus tard - je prévois donc une sous-tâche de réestimation où je recommence à # 1.

Plus je fais cela, mieux je m'y mets. L'autodiscipline est un muscle mental qui se renforce avec l'exercice, et je m'améliore également pour estimer la durée des choses et faire des compromis techniques. Et je trouve utile de se rappeler une citation du général Patton: "Un bon plan exécuté violemment vaut mieux qu'un plan parfait exécuté la semaine prochaine."

En tant que développeur isolé, mon flux de travail combine cela avec des aspects d'Agile, y compris un tableau Kanban. Je pars parfois sur des tangentes, mais j'essaie de limiter les écarts à quelques heures par semaine, et ça marche plutôt bien.

Si vous prévoyez de travailler dans le secteur privé, il est vraiment important de contrôler l'impulsion du "théoricien". Le programmeur le plus brillant que je connaisse vit dans la Silicon Valley, mais n'a pas eu de travail depuis des années, car il a une telle réputation de livrer un code parfait beaucoup trop tard.